Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1363964 > unrolled thread
| Started by | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| First post | 2016-03-24 08:30 +0100 |
| Last post | 2016-03-24 14:40 +0100 |
| Articles | 20 on this page of 25 — 9 participants |
Back to article view | Back to linux.kernel
Warnings for invalid VDD (sdhci-s3c) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-24 08:30 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Jaehoon Chung <jh80.chung@samsung.com> - 2016-03-24 09:10 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Jisheng Zhang <jszhang@marvell.com> - 2016-03-24 09:30 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-24 09:50 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Adrian Hunter <adrian.hunter@intel.com> - 2016-03-24 14:20 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Adrian Hunter <adrian.hunter@intel.com> - 2016-03-24 14:30 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Jisheng Zhang <jszhang@marvell.com> - 2016-03-24 15:00 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Ludovic Desroches <ludovic.desroches@atmel.com> - 2016-03-24 15:30 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-28 08:10 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Adrian Hunter <adrian.hunter@intel.com> - 2016-03-29 11:50 +0200
[PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board Adrian Hunter <adrian.hunter@intel.com> - 2016-03-29 11:50 +0200
Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board Jaehoon Chung <jh80.chung@samsung.com> - 2016-03-29 12:10 +0200
Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board Jisheng Zhang <jszhang@marvell.com> - 2016-03-29 12:10 +0200
Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board Anand Moon <linux.amoon@gmail.com> - 2016-03-29 12:30 +0200
Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board Ulf Hansson <ulf.hansson@linaro.org> - 2016-03-29 12:50 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Markus Reichl <m.reichl@fivetechno.de> - 2016-03-24 14:50 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Ludovic Desroches <ludovic.desroches@atmel.com> - 2016-03-24 15:10 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Adrian Hunter <adrian.hunter@intel.com> - 2016-03-24 15:40 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Anand Moon <linux.amoon@gmail.com> - 2016-03-27 09:50 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-03-28 07:40 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Anand Moon <linux.amoon@gmail.com> - 2016-03-28 13:40 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Adrian Hunter <adrian.hunter@intel.com> - 2016-03-29 10:10 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Anand Moon <linux.amoon@gmail.com> - 2016-03-29 12:10 +0200
Re: Warnings for invalid VDD (sdhci-s3c) Jisheng Zhang <jszhang@marvell.com> - 2016-03-24 09:10 +0100
Re: Warnings for invalid VDD (sdhci-s3c) Tobias Jakobi <tjakobi@math.uni-bielefeld.de> - 2016-03-24 14:40 +0100
Page 1 of 2 [1] 2 Next page →
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2016-03-24 08:30 +0100 |
| Subject | Warnings for invalid VDD (sdhci-s3c) |
| Message-ID | <rg7Sq-7F5-3@gated-at.bofh.it> |
Hi,
After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
external regulator") On Trats2 board I see warnings for invalid VDD
value (2.8V):
[ 3.119656] ------------[ cut here ]------------
[ 3.119666] WARNING: CPU: 3 PID: 90 at
../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
[ 3.119669] mmc0: Invalid vdd 0x10
[ 3.119673] Modules linked in:
[ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
4.5.0-next-20160324 #23
[ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 3.119690] Workqueue: events_freezable mmc_rescan
[ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
(show_stack+0x10/0x14)
[ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
(dump_stack+0x88/0x9c)
[ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
[ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
(warn_slowpath_fmt+0x38/0x48)
[ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
(sdhci_do_set_ios+0x4cc/0x5e0)
[ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
(sdhci_runtime_resume_host+0x60/0x114)
[ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
[<c0402570>] (__rpm_callback+0x2c/0x60)
[ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
(rpm_callback+0x20/0x80)
[ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
(rpm_resume+0x36c/0x558)
[ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
(__pm_runtime_resume+0x4c/0x64)
[ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
(__mmc_claim_host+0x170/0x1b0)
[ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
(mmc_rescan+0x54/0x348)
[ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
(process_one_work+0x120/0x3f4)
[ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
(worker_thread+0x38/0x554)
[ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
(kthread+0xdc/0xf4)
[ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
(ret_from_fork+0x14/0x3c)
[ 3.119834] ---[ end trace a22d652aa3276886 ]---
The device seems to work correctly but I suppose the patch still has
an effect - the mmc_regulator_set_ocr() is not called.
Any ideas for fixing this?
The board is Trats2 (Exynos4412).
Best regards,
Krzysztof
[toc] | [next] | [standalone]
| From | Jaehoon Chung <jh80.chung@samsung.com> |
|---|---|
| Date | 2016-03-24 09:10 +0100 |
| Message-ID | <rg8v8-8at-13@gated-at.bofh.it> |
| In reply to | #1363964 |
Hi,
On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
> Hi,
>
> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>
>> Hi,
>>
>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>> external regulator") On Trats2 board I see warnings for invalid VDD
>> value (2.8V):
>>
>> [ 3.119656] ------------[ cut here ]------------
>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>> [ 3.119669] mmc0: Invalid vdd 0x10
>
> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
> this host's vmmc regulator?
As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
I didn't check this entirely..need to check ocr value.
Best Regards,
Jaehoon Chung
>
> Thanks,
> Jisheng
>
>
[toc] | [prev] | [next] | [standalone]
| From | Jisheng Zhang <jszhang@marvell.com> |
|---|---|
| Date | 2016-03-24 09:30 +0100 |
| Message-ID | <rg8Ou-8iV-5@gated-at.bofh.it> |
| In reply to | #1363998 |
Hi,
On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
> Hi,
>
> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
> > Hi,
> >
> > On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
> >
> >> Hi,
> >>
> >> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
> >> external regulator") On Trats2 board I see warnings for invalid VDD
> >> value (2.8V):
> >>
> >> [ 3.119656] ------------[ cut here ]------------
> >> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> >> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> >> [ 3.119669] mmc0: Invalid vdd 0x10
> >
> > Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
> > this host's vmmc regulator?
>
> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
> I didn't check this entirely..need to check ocr value.
>
I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
case and isn't accepted by current sdhci driver.
I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
idea.
Thanks,
Jisheng
[toc] | [prev] | [next] | [standalone]
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2016-03-24 09:50 +0100 |
| Message-ID | <rg97P-8qE-1@gated-at.bofh.it> |
| In reply to | #1364006 |
On 24.03.2016 17:24, Jisheng Zhang wrote:
> Hi,
>
> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>
>> Hi,
>>
>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>> Hi,
>>>
>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>
>>>> Hi,
>>>>
>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>> value (2.8V):
>>>>
>>>> [ 3.119656] ------------[ cut here ]------------
>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>
>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>> this host's vmmc regulator?
>>
>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>> I didn't check this entirely..need to check ocr value.
>>
>
> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
> case and isn't accepted by current sdhci driver.
Yeah, I already wrote that. It is the part of the warning and my email.
Our regulator is fixed at 2.8 which is 0x10. :)
> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
> idea.
Hmm...
Best regards,
Krzysztof
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-03-24 14:20 +0100 |
| Message-ID | <rgdl9-38k-25@gated-at.bofh.it> |
| In reply to | #1364010 |
On 24/03/16 10:42, Krzysztof Kozlowski wrote:
> On 24.03.2016 17:24, Jisheng Zhang wrote:
>> Hi,
>>
>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>
>>> Hi,
>>>
>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>> Hi,
>>>>
>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>> value (2.8V):
>>>>>
>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>
>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>> this host's vmmc regulator?
>>>
>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>> I didn't check this entirely..need to check ocr value.
>>>
>>
>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>> case and isn't accepted by current sdhci driver.
>
> Yeah, I already wrote that. It is the part of the warning and my email.
> Our regulator is fixed at 2.8 which is 0x10. :)
>
>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>> idea.
>
> Hmm...
I haven't tested it, but what about this:
From: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu, 24 Mar 2016 14:29:24 +0200
Subject: [PATCH] mmc: sdhci: Fix regression setting power on Trats2 board
Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.
Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd4340. The desired behaviour
of commit 918f4cbd4340 is gotten by having sdhci-pxav3 provide
its own set_power callback.
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.5+
---
drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
drivers/mmc/host/sdhci.c | 36 +++++++++++++++++++++++++++++-------
drivers/mmc/host/sdhci.h | 4 ++++
3 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d3a18a..673d1e8446a5 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
__func__, uhs, ctrl_2);
}
+static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+ u8 pwr = host->pwr;
+
+ sdhci_set_power(host, mode, vdd);
+
+ if (host->pwr == pwr)
+ return;
+
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+}
+
static const struct sdhci_ops pxav3_sdhci_ops = {
.set_clock = sdhci_set_clock,
+ .set_power = pxav3_set_power,
.platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index add9fdfd1d8f..3c5dc2f73d5e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1269,10 +1269,24 @@ clock_set:
}
EXPORT_SYMBOL_GPL(sdhci_set_clock);
-static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
unsigned short vdd)
{
struct mmc_host *mmc = host->mmc;
+
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+
+ if (mode != MMC_POWER_OFF)
+ sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
+ else
+ sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
+}
+
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
u8 pwr = 0;
if (mode != MMC_POWER_OFF) {
@@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
mdelay(10);
}
+}
+EXPORT_SYMBOL_GPL(sdhci_set_power);
- if (!IS_ERR(mmc->supply.vmmc)) {
- spin_unlock_irq(&host->lock);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
- spin_lock_irq(&host->lock);
- }
+static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+
+ if (host->ops->set_power)
+ host->ops->set_power(host, mode, vdd);
+ else if (!IS_ERR(mmc->supply.vmmc))
+ sdhci_set_power_reg(host, mode, vdd);
+ else
+ sdhci_set_power(host, mode, vdd);
}
/*****************************************************************************\
@@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
}
}
- sdhci_set_power(host, ios->power_mode, ios->vdd);
+ __sdhci_set_power(host, ios->power_mode, ios->vdd);
if (host->ops->platform_send_init_74_clocks)
host->ops->platform_send_init_74_clocks(host, ios->power_mode);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0115e9907bf8..033d72b5bbd5 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -529,6 +529,8 @@ struct sdhci_ops {
#endif
void (*set_clock)(struct sdhci_host *host, unsigned int clock);
+ void (*set_power)(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
int (*enable_dma)(struct sdhci_host *host);
unsigned int (*get_max_clock)(struct sdhci_host *host);
@@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
}
void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
--
1.9.1
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-03-24 14:30 +0100 |
| Message-ID | <rgduO-3cJ-15@gated-at.bofh.it> |
| In reply to | #1364154 |
On 24/03/16 15:11, Adrian Hunter wrote:
> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>> Hi,
>>>
>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>
>>>> Hi,
>>>>
>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>> value (2.8V):
>>>>>>
>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>
>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>> this host's vmmc regulator?
>>>>
>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>> I didn't check this entirely..need to check ocr value.
>>>>
>>>
>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>> case and isn't accepted by current sdhci driver.
>>
>> Yeah, I already wrote that. It is the part of the warning and my email.
>> Our regulator is fixed at 2.8 which is 0x10. :)
>>
>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>> idea.
>>
>> Hmm...
>
> I haven't tested it, but what about this:
And now with checkpatch complaints fixed:
From: Adrian Hunter <adrian.hunter@intel.com>
Date: Thu, 24 Mar 2016 14:29:24 +0200
Subject: [PATCH V2] mmc: sdhci: Fix regression setting power on Trats2 board
Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.
Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
behavior when setting VDD via external regulator"). The desired
behaviour of that commit is gotten by having sdhci-pxav3 provide
its own set_power callback.
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.5+
---
drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
drivers/mmc/host/sdhci.c | 38 ++++++++++++++++++++++++++++++--------
drivers/mmc/host/sdhci.h | 4 ++++
3 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d3a18a..673d1e8446a5 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
__func__, uhs, ctrl_2);
}
+static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+ u8 pwr = host->pwr;
+
+ sdhci_set_power(host, mode, vdd);
+
+ if (host->pwr == pwr)
+ return;
+
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+}
+
static const struct sdhci_ops pxav3_sdhci_ops = {
.set_clock = sdhci_set_clock,
+ .set_power = pxav3_set_power,
.platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index add9fdfd1d8f..282257222121 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1269,10 +1269,24 @@ clock_set:
}
EXPORT_SYMBOL_GPL(sdhci_set_clock);
-static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
- unsigned short vdd)
+static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
{
struct mmc_host *mmc = host->mmc;
+
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+
+ if (mode != MMC_POWER_OFF)
+ sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
+ else
+ sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
+}
+
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
u8 pwr = 0;
if (mode != MMC_POWER_OFF) {
@@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
mdelay(10);
}
+}
+EXPORT_SYMBOL_GPL(sdhci_set_power);
- if (!IS_ERR(mmc->supply.vmmc)) {
- spin_unlock_irq(&host->lock);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
- spin_lock_irq(&host->lock);
- }
+static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+
+ if (host->ops->set_power)
+ host->ops->set_power(host, mode, vdd);
+ else if (!IS_ERR(mmc->supply.vmmc))
+ sdhci_set_power_reg(host, mode, vdd);
+ else
+ sdhci_set_power(host, mode, vdd);
}
/*****************************************************************************\
@@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
}
}
- sdhci_set_power(host, ios->power_mode, ios->vdd);
+ __sdhci_set_power(host, ios->power_mode, ios->vdd);
if (host->ops->platform_send_init_74_clocks)
host->ops->platform_send_init_74_clocks(host, ios->power_mode);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0115e9907bf8..033d72b5bbd5 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -529,6 +529,8 @@ struct sdhci_ops {
#endif
void (*set_clock)(struct sdhci_host *host, unsigned int clock);
+ void (*set_power)(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
int (*enable_dma)(struct sdhci_host *host);
unsigned int (*get_max_clock)(struct sdhci_host *host);
@@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
}
void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
--
1.9.1
[toc] | [prev] | [next] | [standalone]
| From | Jisheng Zhang <jszhang@marvell.com> |
|---|---|
| Date | 2016-03-24 15:00 +0100 |
| Message-ID | <rgdXQ-3nm-7@gated-at.bofh.it> |
| In reply to | #1364159 |
On Thu, 24 Mar 2016 15:21:47 +0200
Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 24/03/16 15:11, Adrian Hunter wrote:
> > On 24/03/16 10:42, Krzysztof Kozlowski wrote:
> >> On 24.03.2016 17:24, Jisheng Zhang wrote:
> >>> Hi,
> >>>
> >>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
> >>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
> >>>>>> value (2.8V):
> >>>>>>
> >>>>>> [ 3.119656] ------------[ cut here ]------------
> >>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> >>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> >>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
> >>>>>
> >>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
> >>>>> this host's vmmc regulator?
> >>>>
> >>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
> >>>> I didn't check this entirely..need to check ocr value.
> >>>>
> >>>
> >>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
> >>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
> >>> case and isn't accepted by current sdhci driver.
> >>
> >> Yeah, I already wrote that. It is the part of the warning and my email.
> >> Our regulator is fixed at 2.8 which is 0x10. :)
> >>
> >>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
> >>> idea.
> >>
> >> Hmm...
> >
> > I haven't tested it, but what about this:
>
> And now with checkpatch complaints fixed:
>
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu, 24 Mar 2016 14:29:24 +0200
> Subject: [PATCH V2] mmc: sdhci: Fix regression setting power on Trats2 board
>
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
Tested-by: Jisheng Zhang <jszhang@marvell.com>
The only problem is atmel's sdhc host also need similar own .set_power
Ludovic knows details.
Thanks,
Jisheng
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
> drivers/mmc/host/sdhci.c | 38 ++++++++++++++++++++++++++++++--------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 51 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..673d1e8446a5 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..282257222121 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> - unsigned short vdd)
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
[toc] | [prev] | [next] | [standalone]
| From | Ludovic Desroches <ludovic.desroches@atmel.com> |
|---|---|
| Date | 2016-03-24 15:30 +0100 |
| Message-ID | <rgeqS-3Ql-27@gated-at.bofh.it> |
| In reply to | #1364177 |
On Thu, Mar 24, 2016 at 09:45:56PM +0800, Jisheng Zhang wrote:
> On Thu, 24 Mar 2016 15:21:47 +0200
> Adrian Hunter <adrian.hunter@intel.com> wrote:
>
> > On 24/03/16 15:11, Adrian Hunter wrote:
> > > On 24/03/16 10:42, Krzysztof Kozlowski wrote:
> > >> On 24.03.2016 17:24, Jisheng Zhang wrote:
> > >>> Hi,
> > >>>
> > >>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
> > >>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
> > >>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
> > >>>>>> value (2.8V):
> > >>>>>>
> > >>>>>> [ 3.119656] ------------[ cut here ]------------
> > >>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> > >>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> > >>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
> > >>>>>
> > >>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
> > >>>>> this host's vmmc regulator?
> > >>>>
> > >>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
> > >>>> I didn't check this entirely..need to check ocr value.
> > >>>>
> > >>>
> > >>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
> > >>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
> > >>> case and isn't accepted by current sdhci driver.
> > >>
> > >> Yeah, I already wrote that. It is the part of the warning and my email.
> > >> Our regulator is fixed at 2.8 which is 0x10. :)
> > >>
> > >>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
> > >>> idea.
> > >>
> > >> Hmm...
> > >
> > > I haven't tested it, but what about this:
> >
> > And now with checkpatch complaints fixed:
> >
> > From: Adrian Hunter <adrian.hunter@intel.com>
> > Date: Thu, 24 Mar 2016 14:29:24 +0200
> > Subject: [PATCH V2] mmc: sdhci: Fix regression setting power on Trats2 board
> >
> > Several commits relating to setting power have been introducing
> > problems by putting driver-specific rules into generic SDHCI code.
> >
> > Fix by adding a 'set_power' callback and restoring the default
> > behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> > behavior when setting VDD via external regulator"). The desired
> > behaviour of that commit is gotten by having sdhci-pxav3 provide
> > its own set_power callback.
> >
> > Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>
> Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
> Tested-by: Jisheng Zhang <jszhang@marvell.com>
>
> The only problem is atmel's sdhc host also need similar own .set_power
> Ludovic knows details.
It doesn't introduce regression on my side since I have removed
regulators from my device tree. If I introduce then back, I'll need my
own set_power callback.
I am not in favour of this patch only because I have the feeling that
sdhci_set_power_reg() is not conform to the specification.
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>
> Thanks,
> Jisheng
>
> > Cc: stable@vger.kernel.org # v4.5+
> > ---
> > drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
> > drivers/mmc/host/sdhci.c | 38 ++++++++++++++++++++++++++++++--------
> > drivers/mmc/host/sdhci.h | 4 ++++
> > 3 files changed, 51 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> > index f5edf9d3a18a..673d1e8446a5 100644
> > --- a/drivers/mmc/host/sdhci-pxav3.c
> > +++ b/drivers/mmc/host/sdhci-pxav3.c
> > @@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> > __func__, uhs, ctrl_2);
> > }
> >
> > +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd)
> > +{
> > + struct mmc_host *mmc = host->mmc;
> > + u8 pwr = host->pwr;
> > +
> > + sdhci_set_power(host, mode, vdd);
> > +
> > + if (host->pwr == pwr)
> > + return;
> > +
> > + spin_unlock_irq(&host->lock);
> > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > + spin_lock_irq(&host->lock);
> > +}
> > +
> > static const struct sdhci_ops pxav3_sdhci_ops = {
> > .set_clock = sdhci_set_clock,
> > + .set_power = pxav3_set_power,
> > .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> > .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > .set_bus_width = sdhci_set_bus_width,
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index add9fdfd1d8f..282257222121 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -1269,10 +1269,24 @@ clock_set:
> > }
> > EXPORT_SYMBOL_GPL(sdhci_set_clock);
> >
> > -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> > - unsigned short vdd)
> > +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd)
> > {
> > struct mmc_host *mmc = host->mmc;
> > +
> > + spin_unlock_irq(&host->lock);
> > + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > + spin_lock_irq(&host->lock);
> > +
> > + if (mode != MMC_POWER_OFF)
> > + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> > + else
> > + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> > +}
> > +
> > +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd)
> > +{
> > u8 pwr = 0;
> >
> > if (mode != MMC_POWER_OFF) {
> > @@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> > if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> > mdelay(10);
> > }
> > +}
> > +EXPORT_SYMBOL_GPL(sdhci_set_power);
> >
> > - if (!IS_ERR(mmc->supply.vmmc)) {
> > - spin_unlock_irq(&host->lock);
> > - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> > - spin_lock_irq(&host->lock);
> > - }
> > +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd)
> > +{
> > + struct mmc_host *mmc = host->mmc;
> > +
> > + if (host->ops->set_power)
> > + host->ops->set_power(host, mode, vdd);
> > + else if (!IS_ERR(mmc->supply.vmmc))
> > + sdhci_set_power_reg(host, mode, vdd);
> > + else
> > + sdhci_set_power(host, mode, vdd);
> > }
> >
> > /*****************************************************************************\
> > @@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> > }
> > }
> >
> > - sdhci_set_power(host, ios->power_mode, ios->vdd);
> > + __sdhci_set_power(host, ios->power_mode, ios->vdd);
> >
> > if (host->ops->platform_send_init_74_clocks)
> > host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> > index 0115e9907bf8..033d72b5bbd5 100644
> > --- a/drivers/mmc/host/sdhci.h
> > +++ b/drivers/mmc/host/sdhci.h
> > @@ -529,6 +529,8 @@ struct sdhci_ops {
> > #endif
> >
> > void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> > + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd);
> >
> > int (*enable_dma)(struct sdhci_host *host);
> > unsigned int (*get_max_clock)(struct sdhci_host *host);
> > @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> > }
> >
> > void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> > +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> > + unsigned short vdd);
> > void sdhci_set_bus_width(struct sdhci_host *host, int width);
> > void sdhci_reset(struct sdhci_host *host, u8 mask);
> > void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
>
[toc] | [prev] | [next] | [standalone]
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2016-03-28 08:10 +0200 |
| Message-ID | <rhyxc-2Ws-5@gated-at.bofh.it> |
| In reply to | #1364159 |
On 24.03.2016 22:21, Adrian Hunter wrote:
> On 24/03/16 15:11, Adrian Hunter wrote:
>> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>>> Hi,
>>>>
>>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>>> value (2.8V):
>>>>>>>
>>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>>
>>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>>> this host's vmmc regulator?
>>>>>
>>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>>> I didn't check this entirely..need to check ocr value.
>>>>>
>>>>
>>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>>> case and isn't accepted by current sdhci driver.
>>>
>>> Yeah, I already wrote that. It is the part of the warning and my email.
>>> Our regulator is fixed at 2.8 which is 0x10. :)
>>>
>>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>>> idea.
>>>
>>> Hmm...
>>
>> I haven't tested it, but what about this:
>
> And now with checkpatch complaints fixed:
>
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu, 24 Mar 2016 14:29:24 +0200
> Subject: [PATCH V2] mmc: sdhci: Fix regression setting power on Trats2 board
>
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
s/behavior/behaviour/
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
> drivers/mmc/host/sdhci.c | 38 ++++++++++++++++++++++++++++++--------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 51 insertions(+), 8 deletions(-)
>
Works for me (sdhci-s3c, Exynos4412 on Trats2 board):
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Best regards,
Krzysztof
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-03-29 11:50 +0200 |
| Message-ID | <rhYrD-46p-7@gated-at.bofh.it> |
| In reply to | #1365337 |
On 28/03/16 09:07, Krzysztof Kozlowski wrote:
> On 24.03.2016 22:21, Adrian Hunter wrote:
>> On 24/03/16 15:11, Adrian Hunter wrote:
>>> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>>>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>>>> value (2.8V):
>>>>>>>>
>>>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>>>
>>>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>>>> this host's vmmc regulator?
>>>>>>
>>>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>>>> I didn't check this entirely..need to check ocr value.
>>>>>>
>>>>>
>>>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>>>> case and isn't accepted by current sdhci driver.
>>>>
>>>> Yeah, I already wrote that. It is the part of the warning and my email.
>>>> Our regulator is fixed at 2.8 which is 0x10. :)
>>>>
>>>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>>>> idea.
>>>>
>>>> Hmm...
>>>
>>> I haven't tested it, but what about this:
>>
>> And now with checkpatch complaints fixed:
>>
>> From: Adrian Hunter <adrian.hunter@intel.com>
>> Date: Thu, 24 Mar 2016 14:29:24 +0200
>> Subject: [PATCH V2] mmc: sdhci: Fix regression setting power on Trats2 board
>>
>> Several commits relating to setting power have been introducing
>> problems by putting driver-specific rules into generic SDHCI code.
>>
>> Fix by adding a 'set_power' callback and restoring the default
>> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
>> behavior when setting VDD via external regulator"). The desired
>
> s/behavior/behaviour/
It seems checkpatch insists the commit message must be identical to the
original, so I am leaving it that way.
>
>> behaviour of that commit is gotten by having sdhci-pxav3 provide
>> its own set_power callback.
>>
>> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> Cc: stable@vger.kernel.org # v4.5+
>> ---
>> drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
>> drivers/mmc/host/sdhci.c | 38 ++++++++++++++++++++++++++++++--------
>> drivers/mmc/host/sdhci.h | 4 ++++
>> 3 files changed, 51 insertions(+), 8 deletions(-)
>>
>
> Works for me (sdhci-s3c, Exynos4412 on Trats2 board):
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
I made a V3 which has a couple of minor changes for pxav3_set_power()
and consequently have not added the Reviewed/Tested-by Jisheng Zhang.
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-03-29 11:50 +0200 |
| Subject | [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board |
| Message-ID | <rhYrE-46p-21@gated-at.bofh.it> |
| In reply to | #1366078 |
Several commits relating to setting power have been introducing
problems by putting driver-specific rules into generic SDHCI code.
Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
sdhci: restore behavior when setting VDD via external regulator")
on Trats2 board there are warnings for invalid VDD value (2.8V):
[ 3.119656] ------------[ cut here ]------------
[ 3.119666] WARNING: CPU: 3 PID: 90 at
../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
[ 3.119669] mmc0: Invalid vdd 0x10
[ 3.119673] Modules linked in:
[ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
4.5.0-next-20160324 #23
[ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 3.119690] Workqueue: events_freezable mmc_rescan
[ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
(show_stack+0x10/0x14)
[ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
(dump_stack+0x88/0x9c)
[ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
[ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
(warn_slowpath_fmt+0x38/0x48)
[ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
(sdhci_do_set_ios+0x4cc/0x5e0)
[ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
(sdhci_runtime_resume_host+0x60/0x114)
[ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
[<c0402570>] (__rpm_callback+0x2c/0x60)
[ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
(rpm_callback+0x20/0x80)
[ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
(rpm_resume+0x36c/0x558)
[ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
(__pm_runtime_resume+0x4c/0x64)
[ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
(__mmc_claim_host+0x170/0x1b0)
[ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
(mmc_rescan+0x54/0x348)
[ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
(process_one_work+0x120/0x3f4)
[ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
(worker_thread+0x38/0x554)
[ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
(kthread+0xdc/0xf4)
[ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
(ret_from_fork+0x14/0x3c)
[ 3.119834] ---[ end trace a22d652aa3276886 ]---
Fix by adding a 'set_power' callback and restoring the default
behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
behavior when setting VDD via external regulator"). The desired
behaviour of that commit is gotten by having sdhci-pxav3 provide
its own set_power callback.
Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.5+
---
Changes in V3:
Expanded commit message.
Removed redundant vdd = 0 from sdhci_set_power()
Make pxav3_set_power() check the regulator was created successfully
before using it, and ensure vdd is 0 when pwr is 0.
drivers/mmc/host/sdhci-pxav3.c | 22 ++++++++++++++++++++++
drivers/mmc/host/sdhci.c | 39 ++++++++++++++++++++++++++++++---------
drivers/mmc/host/sdhci.h | 4 ++++
3 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d3a18a..0535827b02ee 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -307,8 +307,30 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
__func__, uhs, ctrl_2);
}
+static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+ u8 pwr = host->pwr;
+
+ sdhci_set_power(host, mode, vdd);
+
+ if (host->pwr == pwr)
+ return;
+
+ if (host->pwr == 0)
+ vdd = 0;
+
+ if (!IS_ERR(mmc->supply.vmmc)) {
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+ }
+}
+
static const struct sdhci_ops pxav3_sdhci_ops = {
.set_clock = sdhci_set_clock,
+ .set_power = pxav3_set_power,
.platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index add9fdfd1d8f..f5b52b4308cc 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1269,10 +1269,24 @@ clock_set:
}
EXPORT_SYMBOL_GPL(sdhci_set_clock);
-static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
- unsigned short vdd)
+static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
{
struct mmc_host *mmc = host->mmc;
+
+ spin_unlock_irq(&host->lock);
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ spin_lock_irq(&host->lock);
+
+ if (mode != MMC_POWER_OFF)
+ sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
+ else
+ sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
+}
+
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
u8 pwr = 0;
if (mode != MMC_POWER_OFF) {
@@ -1304,7 +1318,6 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
sdhci_runtime_pm_bus_off(host);
- vdd = 0;
} else {
/*
* Spec says that we should clear the power reg before setting
@@ -1335,12 +1348,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
mdelay(10);
}
+}
+EXPORT_SYMBOL_GPL(sdhci_set_power);
- if (!IS_ERR(mmc->supply.vmmc)) {
- spin_unlock_irq(&host->lock);
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
- spin_lock_irq(&host->lock);
- }
+static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd)
+{
+ struct mmc_host *mmc = host->mmc;
+
+ if (host->ops->set_power)
+ host->ops->set_power(host, mode, vdd);
+ else if (!IS_ERR(mmc->supply.vmmc))
+ sdhci_set_power_reg(host, mode, vdd);
+ else
+ sdhci_set_power(host, mode, vdd);
}
/*****************************************************************************\
@@ -1490,7 +1511,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
}
}
- sdhci_set_power(host, ios->power_mode, ios->vdd);
+ __sdhci_set_power(host, ios->power_mode, ios->vdd);
if (host->ops->platform_send_init_74_clocks)
host->ops->platform_send_init_74_clocks(host, ios->power_mode);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0115e9907bf8..033d72b5bbd5 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -529,6 +529,8 @@ struct sdhci_ops {
#endif
void (*set_clock)(struct sdhci_host *host, unsigned int clock);
+ void (*set_power)(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
int (*enable_dma)(struct sdhci_host *host);
unsigned int (*get_max_clock)(struct sdhci_host *host);
@@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
}
void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
+void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
+ unsigned short vdd);
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
--
1.9.1
[toc] | [prev] | [next] | [standalone]
| From | Jaehoon Chung <jh80.chung@samsung.com> |
|---|---|
| Date | 2016-03-29 12:10 +0200 |
| Subject | Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board |
| Message-ID | <rhYL2-4yM-13@gated-at.bofh.it> |
| In reply to | #1366082 |
On 03/29/2016 06:45 PM, Adrian Hunter wrote:
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
> sdhci: restore behavior when setting VDD via external regulator")
> on Trats2 board there are warnings for invalid VDD value (2.8V):
>
> [ 3.119656] ------------[ cut here ]------------
> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> [ 3.119669] mmc0: Invalid vdd 0x10
> [ 3.119673] Modules linked in:
> [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
> 4.5.0-next-20160324 #23
> [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 3.119690] Workqueue: events_freezable mmc_rescan
> [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
> (show_stack+0x10/0x14)
> [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
> (dump_stack+0x88/0x9c)
> [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
> [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
> (warn_slowpath_fmt+0x38/0x48)
> [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
> (sdhci_do_set_ios+0x4cc/0x5e0)
> [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
> [<c0402570>] (__rpm_callback+0x2c/0x60)
> [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
> (rpm_callback+0x20/0x80)
> [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
> (rpm_resume+0x36c/0x558)
> [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
> (__pm_runtime_resume+0x4c/0x64)
> [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
> (__mmc_claim_host+0x170/0x1b0)
> [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
> (mmc_rescan+0x54/0x348)
> [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
> (process_one_work+0x120/0x3f4)
> [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
> (worker_thread+0x38/0x554)
> [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
> (kthread+0xdc/0xf4)
> [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
> (ret_from_fork+0x14/0x3c)
> [ 3.119834] ---[ end trace a22d652aa3276886 ]---
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
With trats2 board.
>
> Changes in V3:
>
> Expanded commit message.
>
> Removed redundant vdd = 0 from sdhci_set_power()
>
> Make pxav3_set_power() check the regulator was created successfully
> before using it, and ensure vdd is 0 when pwr is 0.
>
>
> drivers/mmc/host/sdhci-pxav3.c | 22 ++++++++++++++++++++++
> drivers/mmc/host/sdhci.c | 39 ++++++++++++++++++++++++++++++---------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..0535827b02ee 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,30 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + if (host->pwr == 0)
> + vdd = 0;
> +
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> + }
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..f5b52b4308cc 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> - unsigned short vdd)
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1304,7 +1318,6 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> sdhci_runtime_pm_bus_off(host);
> - vdd = 0;
> } else {
> /*
> * Spec says that we should clear the power reg before setting
> @@ -1335,12 +1348,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1511,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
>
[toc] | [prev] | [next] | [standalone]
| From | Jisheng Zhang <jszhang@marvell.com> |
|---|---|
| Date | 2016-03-29 12:10 +0200 |
| Subject | Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board |
| Message-ID | <rhYL3-4yM-35@gated-at.bofh.it> |
| In reply to | #1366082 |
On Tue, 29 Mar 2016 12:45:43 +0300
Adrian Hunter <adrian.hunter@intel.com> wrote:
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
> sdhci: restore behavior when setting VDD via external regulator")
> on Trats2 board there are warnings for invalid VDD value (2.8V):
>
> [ 3.119656] ------------[ cut here ]------------
> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> [ 3.119669] mmc0: Invalid vdd 0x10
> [ 3.119673] Modules linked in:
> [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
> 4.5.0-next-20160324 #23
> [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 3.119690] Workqueue: events_freezable mmc_rescan
> [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
> (show_stack+0x10/0x14)
> [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
> (dump_stack+0x88/0x9c)
> [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
> [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
> (warn_slowpath_fmt+0x38/0x48)
> [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
> (sdhci_do_set_ios+0x4cc/0x5e0)
> [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
> [<c0402570>] (__rpm_callback+0x2c/0x60)
> [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
> (rpm_callback+0x20/0x80)
> [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
> (rpm_resume+0x36c/0x558)
> [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
> (__pm_runtime_resume+0x4c/0x64)
> [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
> (__mmc_claim_host+0x170/0x1b0)
> [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
> (mmc_rescan+0x54/0x348)
> [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
> (process_one_work+0x120/0x3f4)
> [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
> (worker_thread+0x38/0x554)
> [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
> (kthread+0xdc/0xf4)
> [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
> (ret_from_fork+0x14/0x3c)
> [ 3.119834] ---[ end trace a22d652aa3276886 ]---
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
Tested-by: Jisheng Zhang <jszhang@marvell.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
>
>
> Changes in V3:
>
> Expanded commit message.
>
> Removed redundant vdd = 0 from sdhci_set_power()
>
> Make pxav3_set_power() check the regulator was created successfully
> before using it, and ensure vdd is 0 when pwr is 0.
>
>
> drivers/mmc/host/sdhci-pxav3.c | 22 ++++++++++++++++++++++
> drivers/mmc/host/sdhci.c | 39 ++++++++++++++++++++++++++++++---------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..0535827b02ee 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,30 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + if (host->pwr == 0)
> + vdd = 0;
> +
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> + }
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..f5b52b4308cc 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> - unsigned short vdd)
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1304,7 +1318,6 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> sdhci_runtime_pm_bus_off(host);
> - vdd = 0;
> } else {
> /*
> * Spec says that we should clear the power reg before setting
> @@ -1335,12 +1348,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1511,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
[toc] | [prev] | [next] | [standalone]
| From | Anand Moon <linux.amoon@gmail.com> |
|---|---|
| Date | 2016-03-29 12:30 +0200 |
| Subject | Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board |
| Message-ID | <rhZ4m-4HB-13@gated-at.bofh.it> |
| In reply to | #1366082 |
hi Adrian Hunter,
On 29 March 2016 at 15:15, Adrian Hunter <adrian.hunter@intel.com> wrote:
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
> sdhci: restore behavior when setting VDD via external regulator")
> on Trats2 board there are warnings for invalid VDD value (2.8V):
>
> [ 3.119656] ------------[ cut here ]------------
> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> [ 3.119669] mmc0: Invalid vdd 0x10
> [ 3.119673] Modules linked in:
> [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
> 4.5.0-next-20160324 #23
> [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 3.119690] Workqueue: events_freezable mmc_rescan
> [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
> (show_stack+0x10/0x14)
> [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
> (dump_stack+0x88/0x9c)
> [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
> [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
> (warn_slowpath_fmt+0x38/0x48)
> [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
> (sdhci_do_set_ios+0x4cc/0x5e0)
> [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
> [<c0402570>] (__rpm_callback+0x2c/0x60)
> [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
> (rpm_callback+0x20/0x80)
> [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
> (rpm_resume+0x36c/0x558)
> [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
> (__pm_runtime_resume+0x4c/0x64)
> [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
> (__mmc_claim_host+0x170/0x1b0)
> [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
> (mmc_rescan+0x54/0x348)
> [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
> (process_one_work+0x120/0x3f4)
> [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
> (worker_thread+0x38/0x554)
> [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
> (kthread+0xdc/0xf4)
> [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
> (ret_from_fork+0x14/0x3c)
> [ 3.119834] ---[ end trace a22d652aa3276886 ]---
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
>
>
> Changes in V3:
>
> Expanded commit message.
>
> Removed redundant vdd = 0 from sdhci_set_power()
>
> Make pxav3_set_power() check the regulator was created successfully
> before using it, and ensure vdd is 0 when pwr is 0.
>
>
> drivers/mmc/host/sdhci-pxav3.c | 22 ++++++++++++++++++++++
> drivers/mmc/host/sdhci.c | 39 ++++++++++++++++++++++++++++++---------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..0535827b02ee 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,30 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + if (host->pwr == 0)
> + vdd = 0;
> +
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> + }
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..f5b52b4308cc 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> - unsigned short vdd)
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1304,7 +1318,6 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> sdhci_runtime_pm_bus_off(host);
> - vdd = 0;
> } else {
> /*
> * Spec says that we should clear the power reg before setting
> @@ -1335,12 +1348,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1511,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
> --
> 1.9.1
>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested on Odroid U3
Best Regards
-Anand Moon
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-03-29 12:50 +0200 |
| Subject | Re: [PATCH V3] mmc: sdhci: Fix regression setting power on Trats2 board |
| Message-ID | <rhZnH-4Qd-11@gated-at.bofh.it> |
| In reply to | #1366082 |
On 29 March 2016 at 11:45, Adrian Hunter <adrian.hunter@intel.com> wrote:
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Krzysztof Kozlowski reported that after commit 918f4cbd4340 ("mmc:
> sdhci: restore behavior when setting VDD via external regulator")
> on Trats2 board there are warnings for invalid VDD value (2.8V):
>
> [ 3.119656] ------------[ cut here ]------------
> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> [ 3.119669] mmc0: Invalid vdd 0x10
> [ 3.119673] Modules linked in:
> [ 3.119679] CPU: 3 PID: 90 Comm: kworker/3:1 Tainted: G W
> 4.5.0-next-20160324 #23
> [ 3.119681] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 3.119690] Workqueue: events_freezable mmc_rescan
> [ 3.119708] [<c010e0ac>] (unwind_backtrace) from [<c010ae10>]
> (show_stack+0x10/0x14)
> [ 3.119719] [<c010ae10>] (show_stack) from [<c0323260>]
> (dump_stack+0x88/0x9c)
> [ 3.119728] [<c0323260>] (dump_stack) from [<c011b754>] (__warn+0xe8/0x100)
> [ 3.119734] [<c011b754>] (__warn) from [<c011b7a4>]
> (warn_slowpath_fmt+0x38/0x48)
> [ 3.119740] [<c011b7a4>] (warn_slowpath_fmt) from [<c0527d28>]
> (sdhci_do_set_ios+0x4cc/0x5e0)
> [ 3.119748] [<c0527d28>] (sdhci_do_set_ios) from [<c0528018>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 3.119758] [<c0528018>] (sdhci_runtime_resume_host) from
> [<c0402570>] (__rpm_callback+0x2c/0x60)
> [ 3.119767] [<c0402570>] (__rpm_callback) from [<c04025c4>]
> (rpm_callback+0x20/0x80)
> [ 3.119773] [<c04025c4>] (rpm_callback) from [<c04034b8>]
> (rpm_resume+0x36c/0x558)
> [ 3.119780] [<c04034b8>] (rpm_resume) from [<c04036f0>]
> (__pm_runtime_resume+0x4c/0x64)
> [ 3.119788] [<c04036f0>] (__pm_runtime_resume) from [<c0512728>]
> (__mmc_claim_host+0x170/0x1b0)
> [ 3.119795] [<c0512728>] (__mmc_claim_host) from [<c0514e2c>]
> (mmc_rescan+0x54/0x348)
> [ 3.119807] [<c0514e2c>] (mmc_rescan) from [<c0130dac>]
> (process_one_work+0x120/0x3f4)
> [ 3.119815] [<c0130dac>] (process_one_work) from [<c01310b8>]
> (worker_thread+0x38/0x554)
> [ 3.119823] [<c01310b8>] (worker_thread) from [<c01365a4>]
> (kthread+0xdc/0xf4)
> [ 3.119831] [<c01365a4>] (kthread) from [<c0107878>]
> (ret_from_fork+0x14/0x3c)
> [ 3.119834] ---[ end trace a22d652aa3276886 ]---
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340 ("mmc: sdhci: restore
> behavior when setting VDD via external regulator"). The desired
> behaviour of that commit is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Link: http://lkml.kernel.org/r/CAJKOXPcGDnPm-Ykh6wHqV1YxfTaov5E8iVqBoBn4OJc7BnhgEQ@mail.gmail.com
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
Thanks, applied for fixes!
Kind regards
Uffe
> ---
>
>
> Changes in V3:
>
> Expanded commit message.
>
> Removed redundant vdd = 0 from sdhci_set_power()
>
> Make pxav3_set_power() check the regulator was created successfully
> before using it, and ensure vdd is 0 when pwr is 0.
>
>
> drivers/mmc/host/sdhci-pxav3.c | 22 ++++++++++++++++++++++
> drivers/mmc/host/sdhci.c | 39 ++++++++++++++++++++++++++++++---------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..0535827b02ee 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,30 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + if (host->pwr == 0)
> + vdd = 0;
> +
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> + }
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..f5b52b4308cc 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> - unsigned short vdd)
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1304,7 +1318,6 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> if (host->quirks2 & SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON)
> sdhci_runtime_pm_bus_off(host);
> - vdd = 0;
> } else {
> /*
> * Spec says that we should clear the power reg before setting
> @@ -1335,12 +1348,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1511,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
> --
> 1.9.1
>
>
[toc] | [prev] | [next] | [standalone]
| From | Markus Reichl <m.reichl@fivetechno.de> |
|---|---|
| Date | 2016-03-24 14:50 +0100 |
| Message-ID | <rgdOa-3jF-15@gated-at.bofh.it> |
| In reply to | #1364154 |
Am 24.03.2016 um 14:11 schrieb Adrian Hunter:
> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>> Hi,
>>>
>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>
>>>> Hi,
>>>>
>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>> value (2.8V):
>>>>>>
>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>
>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>> this host's vmmc regulator?
>>>>
>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>> I didn't check this entirely..need to check ocr value.
>>>>
>>>
>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>> case and isn't accepted by current sdhci driver.
>>
>> Yeah, I already wrote that. It is the part of the warning and my email.
>> Our regulator is fixed at 2.8 which is 0x10. :)
>>
>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>> idea.
>>
>> Hmm...
>
> I haven't tested it, but what about this:
This fixes the warnings on Odroid U3.
Thanks,
--
Markus Reichl
>
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu, 24 Mar 2016 14:29:24 +0200
> Subject: [PATCH] mmc: sdhci: Fix regression setting power on Trats2 board
>
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340. The desired behaviour
> of commit 918f4cbd4340 is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
> drivers/mmc/host/sdhci.c | 36 +++++++++++++++++++++++++++++-------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..673d1e8446a5 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..3c5dc2f73d5e 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
>
[toc] | [prev] | [next] | [standalone]
| From | Ludovic Desroches <ludovic.desroches@atmel.com> |
|---|---|
| Date | 2016-03-24 15:10 +0100 |
| Message-ID | <rge7y-3Hv-21@gated-at.bofh.it> |
| In reply to | #1364154 |
Hi,
On Thu, Mar 24, 2016 at 03:11:25PM +0200, Adrian Hunter wrote:
> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
> > On 24.03.2016 17:24, Jisheng Zhang wrote:
> >> Hi,
> >>
> >> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
> >>
> >>> Hi,
> >>>
> >>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
> >>>>> external regulator") On Trats2 board I see warnings for invalid VDD
> >>>>> value (2.8V):
> >>>>>
> >>>>> [ 3.119656] ------------[ cut here ]------------
> >>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
> >>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
> >>>>> [ 3.119669] mmc0: Invalid vdd 0x10
> >>>>
> >>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
> >>>> this host's vmmc regulator?
> >>>
> >>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
> >>> I didn't check this entirely..need to check ocr value.
> >>>
> >>
> >> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
> >> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
> >> case and isn't accepted by current sdhci driver.
> >
> > Yeah, I already wrote that. It is the part of the warning and my email.
> > Our regulator is fixed at 2.8 which is 0x10. :)
> >
> >> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
> >> idea.
> >
> > Hmm...
>
> I haven't tested it, but what about this:
>
> From: Adrian Hunter <adrian.hunter@intel.com>
> Date: Thu, 24 Mar 2016 14:29:24 +0200
> Subject: [PATCH] mmc: sdhci: Fix regression setting power on Trats2 board
>
> Several commits relating to setting power have been introducing
> problems by putting driver-specific rules into generic SDHCI code.
>
I remember that I have acked this patch and I still believe it is not
driver-specific code.
Without this patch, if a regulator is used, we set this regulator and we
write SDHCI_POWER_ON to SDHCI_POWER_CONTROL so 0x01. In the
specification, it is said:
'If an unsupported voltage is selected, the Host System shall not supply
SD Bus voltage'.
Valid voltage are 111b for 3.3V, 110b for 3.0V and 101b for 1.8V. 0 is
seen as an invalid voltage.
If the controller strictly applies the specification then it won't perform
the power on request. It's what happens with sdhci-pxav3 and
sdhci-of-at91.
I don't care if the patch is reverted because I no more describe
the regulators but I think the behavior with Jisheng's patch is the right
one. Maybe more cases should be managed in the switch statement as
suggested by Tobias.
> Fix by adding a 'set_power' callback and restoring the default
> behaviour prior to commit 918f4cbd4340. The desired behaviour
> of commit 918f4cbd4340 is gotten by having sdhci-pxav3 provide
> its own set_power callback.
>
Adding callbacks is the only way to solve all these quirks or
interpretations of the specification.
> Reported-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Fixes: 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD...)
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Cc: stable@vger.kernel.org # v4.5+
> ---
> drivers/mmc/host/sdhci-pxav3.c | 17 +++++++++++++++++
> drivers/mmc/host/sdhci.c | 36 +++++++++++++++++++++++++++++-------
> drivers/mmc/host/sdhci.h | 4 ++++
> 3 files changed, 50 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
> index f5edf9d3a18a..673d1e8446a5 100644
> --- a/drivers/mmc/host/sdhci-pxav3.c
> +++ b/drivers/mmc/host/sdhci-pxav3.c
> @@ -307,8 +307,25 @@ static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
> __func__, uhs, ctrl_2);
> }
>
> +static void pxav3_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> + u8 pwr = host->pwr;
> +
> + sdhci_set_power(host, mode, vdd);
> +
> + if (host->pwr == pwr)
> + return;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +}
> +
> static const struct sdhci_ops pxav3_sdhci_ops = {
> .set_clock = sdhci_set_clock,
> + .set_power = pxav3_set_power,
> .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index add9fdfd1d8f..3c5dc2f73d5e 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1269,10 +1269,24 @@ clock_set:
> }
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> -static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> +static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> unsigned short vdd)
> {
> struct mmc_host *mmc = host->mmc;
> +
> + spin_unlock_irq(&host->lock);
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> + spin_lock_irq(&host->lock);
> +
> + if (mode != MMC_POWER_OFF)
> + sdhci_writeb(host, SDHCI_POWER_ON, SDHCI_POWER_CONTROL);
> + else
> + sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +}
> +
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> u8 pwr = 0;
>
> if (mode != MMC_POWER_OFF) {
> @@ -1335,12 +1349,20 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
> mdelay(10);
> }
> +}
> +EXPORT_SYMBOL_GPL(sdhci_set_power);
>
> - if (!IS_ERR(mmc->supply.vmmc)) {
> - spin_unlock_irq(&host->lock);
> - mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
> - spin_lock_irq(&host->lock);
> - }
> +static void __sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + if (host->ops->set_power)
> + host->ops->set_power(host, mode, vdd);
> + else if (!IS_ERR(mmc->supply.vmmc))
> + sdhci_set_power_reg(host, mode, vdd);
> + else
> + sdhci_set_power(host, mode, vdd);
> }
>
> /*****************************************************************************\
> @@ -1490,7 +1512,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> }
> }
>
> - sdhci_set_power(host, ios->power_mode, ios->vdd);
> + __sdhci_set_power(host, ios->power_mode, ios->vdd);
>
> if (host->ops->platform_send_init_74_clocks)
> host->ops->platform_send_init_74_clocks(host, ios->power_mode);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0115e9907bf8..033d72b5bbd5 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -529,6 +529,8 @@ struct sdhci_ops {
> #endif
>
> void (*set_clock)(struct sdhci_host *host, unsigned int clock);
> + void (*set_power)(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
>
> int (*enable_dma)(struct sdhci_host *host);
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> @@ -660,6 +662,8 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> }
>
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> + unsigned short vdd);
> void sdhci_set_bus_width(struct sdhci_host *host, int width);
> void sdhci_reset(struct sdhci_host *host, u8 mask);
> void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
> --
> 1.9.1
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-03-24 15:40 +0100 |
| Message-ID | <rgeAx-3Uf-7@gated-at.bofh.it> |
| In reply to | #1364186 |
On 24/03/16 16:03, Ludovic Desroches wrote:
> Hi,
>
> On Thu, Mar 24, 2016 at 03:11:25PM +0200, Adrian Hunter wrote:
>> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>>> Hi,
>>>>
>>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>>> value (2.8V):
>>>>>>>
>>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>>
>>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>>> this host's vmmc regulator?
>>>>>
>>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>>> I didn't check this entirely..need to check ocr value.
>>>>>
>>>>
>>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>>> case and isn't accepted by current sdhci driver.
>>>
>>> Yeah, I already wrote that. It is the part of the warning and my email.
>>> Our regulator is fixed at 2.8 which is 0x10. :)
>>>
>>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>>> idea.
>>>
>>> Hmm...
>>
>> I haven't tested it, but what about this:
>>
>> From: Adrian Hunter <adrian.hunter@intel.com>
>> Date: Thu, 24 Mar 2016 14:29:24 +0200
>> Subject: [PATCH] mmc: sdhci: Fix regression setting power on Trats2 board
>>
>> Several commits relating to setting power have been introducing
>> problems by putting driver-specific rules into generic SDHCI code.
>>
>
> I remember that I have acked this patch and I still believe it is not
> driver-specific code.
It depends how you look at it. I decided that since the previous code had
been there for a while (since 3.19), it should stay the default.
I agree you could look at it differently.
>
> Without this patch, if a regulator is used, we set this regulator and we
> write SDHCI_POWER_ON to SDHCI_POWER_CONTROL so 0x01. In the
> specification, it is said:
> 'If an unsupported voltage is selected, the Host System shall not supply
> SD Bus voltage'.
> Valid voltage are 111b for 3.3V, 110b for 3.0V and 101b for 1.8V. 0 is
> seen as an invalid voltage.
Again, it depends how you look at it. From my point of view, the
specification doesn't cover external regulators so you can't expect to know
what to put in the power control register.
>
> If the controller strictly applies the specification then it won't perform
> the power on request. It's what happens with sdhci-pxav3 and
> sdhci-of-at91.
So if I make the same change to sdhci-of-at91 as sdhci-pxav3, it will work
for you?
>
> I don't care if the patch is reverted because I no more describe
> the regulators but I think the behavior with Jisheng's patch is the right
> one. Maybe more cases should be managed in the switch statement as
> suggested by Tobias.
But always the possibility it won't work for some driver.
>
>
>> Fix by adding a 'set_power' callback and restoring the default
>> behaviour prior to commit 918f4cbd4340. The desired behaviour
>> of commit 918f4cbd4340 is gotten by having sdhci-pxav3 provide
>> its own set_power callback.
>>
>
> Adding callbacks is the only way to solve all these quirks or
> interpretations of the specification.
>
At least it means we can go forward.
[toc] | [prev] | [next] | [standalone]
| From | Anand Moon <linux.amoon@gmail.com> |
|---|---|
| Date | 2016-03-27 09:50 +0200 |
| Message-ID | <rhdCq-4Za-11@gated-at.bofh.it> |
| In reply to | #1364198 |
Hi All,
On 24 March 2016 at 20:04, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 24/03/16 16:03, Ludovic Desroches wrote:
>> Hi,
>>
>> On Thu, Mar 24, 2016 at 03:11:25PM +0200, Adrian Hunter wrote:
>>> On 24/03/16 10:42, Krzysztof Kozlowski wrote:
>>>> On 24.03.2016 17:24, Jisheng Zhang wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 03/24/2016 04:58 PM, Jisheng Zhang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, 24 Mar 2016 16:28:56 +0900 Krzysztof Kozlowski wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> After 918f4cbd4340 ("mmc: sdhci: restore behavior when setting VDD via
>>>>>>>> external regulator") On Trats2 board I see warnings for invalid VDD
>>>>>>>> value (2.8V):
>>>>>>>>
>>>>>>>> [ 3.119656] ------------[ cut here ]------------
>>>>>>>> [ 3.119666] WARNING: CPU: 3 PID: 90 at
>>>>>>>> ../drivers/mmc/host/sdhci.c:1234 sdhci_do_set_ios+0x4cc/0x5e0
>>>>>>>> [ 3.119669] mmc0: Invalid vdd 0x10
>>>>>>>
>>>>>>> Per my understanding, the wrong vdd indicates a wrong ocr, what's the voltage of
>>>>>>> this host's vmmc regulator?
>>>>>>
>>>>>> As i know, it's fixed-voltage with gpio on trats2. It's 2.8V.
>>>>>> I didn't check this entirely..need to check ocr value.
>>>>>>
>>>>>
>>>>> I may know the reason. the vmmc is 2.8v, then mmc_regulator_get_supply() convert
>>>>> the value to a ocr as 0x10. The key here is that the 2.8v is invalid in SDHCI
>>>>> case and isn't accepted by current sdhci driver.
>>>>
>>>> Yeah, I already wrote that. It is the part of the warning and my email.
>>>> Our regulator is fixed at 2.8 which is 0x10. :)
>>>>
>>>>> I dunno the elegant solution to handle this case, let's wait for sdhci maintainers
>>>>> idea.
>>>>
>>>> Hmm...
>>>
>>> I haven't tested it, but what about this:
>>>
>>> From: Adrian Hunter <adrian.hunter@intel.com>
>>> Date: Thu, 24 Mar 2016 14:29:24 +0200
>>> Subject: [PATCH] mmc: sdhci: Fix regression setting power on Trats2 board
>>>
>>> Several commits relating to setting power have been introducing
>>> problems by putting driver-specific rules into generic SDHCI code.
>>>
>>
>> I remember that I have acked this patch and I still believe it is not
>> driver-specific code.
>
> It depends how you look at it. I decided that since the previous code had
> been there for a while (since 3.19), it should stay the default.
>
> I agree you could look at it differently.
>
>>
>> Without this patch, if a regulator is used, we set this regulator and we
>> write SDHCI_POWER_ON to SDHCI_POWER_CONTROL so 0x01. In the
>> specification, it is said:
>> 'If an unsupported voltage is selected, the Host System shall not supply
>> SD Bus voltage'.
>> Valid voltage are 111b for 3.3V, 110b for 3.0V and 101b for 1.8V. 0 is
>> seen as an invalid voltage.
>
> Again, it depends how you look at it. From my point of view, the
> specification doesn't cover external regulators so you can't expect to know
> what to put in the power control register.
>
>>
>> If the controller strictly applies the specification then it won't perform
>> the power on request. It's what happens with sdhci-pxav3 and
>> sdhci-of-at91.
>
> So if I make the same change to sdhci-of-at91 as sdhci-pxav3, it will work
> for you?
>
>>
>> I don't care if the patch is reverted because I no more describe
>> the regulators but I think the behavior with Jisheng's patch is the right
>> one. Maybe more cases should be managed in the switch statement as
>> suggested by Tobias.
>
> But always the possibility it won't work for some driver.
>
>>
>>
>>> Fix by adding a 'set_power' callback and restoring the default
>>> behaviour prior to commit 918f4cbd4340. The desired behaviour
>>> of commit 918f4cbd4340 is gotten by having sdhci-pxav3 provide
>>> its own set_power callback.
>>>
>>
>> Adding callbacks is the only way to solve all these quirks or
>> interpretations of the specification.
>>
>
> At least it means we can go forward.
On My Odroid U3 with debug flags enable I am observing bellow deadlock.
---------------------------------------------------------------------------------------------------------
[ 202.519524] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:617
[ 202.522364] in_atomic(): 1, irqs_disabled(): 128, pid: 100, name: mmcqd/0
[ 202.529129] 1 lock held by mmcqd/0/100:
[ 202.529150] #0: (&(&host->lock)->rlock#2){-.-...}, at:
[<c059db68>] sdhci_do_set_ios+0x1c/0x484
[ 202.529271] irq event stamp: 703530
[ 202.529291] hardirqs last enabled at (703529): [<c076d108>]
_raw_spin_unlock_irqrestore+0x6c/0x74
[ 202.529343] hardirqs last disabled at (703530): [<c076cea8>]
_raw_spin_lock_irqsave+0x1c/0x84
[ 202.529384] softirqs last enabled at (703456): [<c0127518>]
__do_softirq+0x244/0x2c0
[ 202.529438] softirqs last disabled at (703445): [<c0127938>]
irq_exit+0xec/0x128
[ 202.529472] Preemption disabled at:[< (null)>] (null)
[ 202.534415]
[ 202.534449] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
[ 202.534473] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 202.534544] [<c010ee2c>] (unwind_backtrace) from [<c010bab8>]
(show_stack+0x10/0x14)
[ 202.534594] [<c010bab8>] (show_stack) from [<c037e0c0>]
(dump_stack+0x98/0xc4)
[ 202.534639] [<c037e0c0>] (dump_stack) from [<c0768934>]
(mutex_lock_nested+0x2c/0x4dc)
[ 202.534685] [<c0768934>] (mutex_lock_nested) from [<c05c00a0>]
(clk_prepare_lock+0x50/0xf8)
[ 202.534726] [<c05c00a0>] (clk_prepare_lock) from [<c05c14b0>]
(clk_round_rate+0x1c/0x58)
[ 202.534773] [<c05c14b0>] (clk_round_rate) from [<c05a00a0>]
(sdhci_s3c_set_clock+0x18c/0x1b0)
[ 202.534819] [<c05a00a0>] (sdhci_s3c_set_clock) from [<c05a00e8>]
(sdhci_cmu_set_clock+0x24/0x17c)
[ 202.534860] [<c05a00e8>] (sdhci_cmu_set_clock) from [<c059dbc4>]
(sdhci_do_set_ios+0x78/0x484)
[ 202.534904] [<c059dbc4>] (sdhci_do_set_ios) from [<c059e1a8>]
(sdhci_runtime_resume_host+0x60/0x114)
[ 202.534957] [<c059e1a8>] (sdhci_runtime_resume_host) from
[<c04728c8>] (__rpm_callback+0x2c/0x60)
[ 202.535000] [<c04728c8>] (__rpm_callback) from [<c0472950>]
(rpm_callback+0x54/0x80)
[ 202.535041] [<c0472950>] (rpm_callback) from [<c0473830>]
(rpm_resume+0x364/0x558)
[ 202.535081] [<c0473830>] (rpm_resume) from [<c0473a84>]
(__pm_runtime_resume+0x60/0x8c)
[ 202.535125] [<c0473a84>] (__pm_runtime_resume) from [<c0588f50>]
(__mmc_claim_host+0x1b4/0x1f8)
[ 202.535176] [<c0588f50>] (__mmc_claim_host) from [<c059174c>]
(mmc_sd_runtime_resume+0x20/0xac)
[ 202.535220] [<c059174c>] (mmc_sd_runtime_resume) from [<c04728c8>]
(__rpm_callback+0x2c/0x60)
[ 202.535259] [<c04728c8>] (__rpm_callback) from [<c0472950>]
(rpm_callback+0x54/0x80)
[ 202.535299] [<c0472950>] (rpm_callback) from [<c0473830>]
(rpm_resume+0x364/0x558)
[ 202.535340] [<c0473830>] (rpm_resume) from [<c0473a84>]
(__pm_runtime_resume+0x60/0x8c)
[ 202.535379] [<c0473a84>] (__pm_runtime_resume) from [<c0588fa8>]
(mmc_get_card+0x14/0x24)
[ 202.535420] [<c0588fa8>] (mmc_get_card) from [<c0598b50>]
(mmc_blk_issue_rq+0x258/0x4f0)
[ 202.535461] [<c0598b50>] (mmc_blk_issue_rq) from [<c059a4b0>]
(mmc_queue_thread+0xd0/0x1d8)
[ 202.535513] [<c059a4b0>] (mmc_queue_thread) from [<c0142c6c>]
(kthread+0xf4/0x10c)
[ 202.535561] [<c0142c6c>] (kthread) from [<c0107950>]
(ret_from_fork+0x14/0x24)
[ 202.535624]
[ 202.535893] ======================================================
[ 202.542059] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 202.548742] 4.6.0-rc1-u3s #38 Not tainted
[ 202.552732] ------------------------------------------------------
[ 202.558902] mmcqd/0/100 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 202.565317] (prepare_lock){+.+...}, at: [<c05c00a0>]
clk_prepare_lock+0x50/0xf8
[ 202.572695]
[ 202.572695] and this task is already holding:
[ 202.578510] (&(&host->lock)->rlock#2){-.-...}, at: [<c059db68>]
sdhci_do_set_ios+0x1c/0x484
[ 202.586930] which would create a new lock dependency:
[ 202.591964] (&(&host->lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
[ 202.598650]
[ 202.598650] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 202.606546] (&(&host->lock)->rlock#2){-.-...}
[ 202.606546] ... which became HARDIRQ-irq-safe at:
[ 202.614359] [<c076cc5c>] _raw_spin_lock+0x3c/0x74
[ 202.619219] [<c059f44c>] sdhci_irq+0x1c/0x814
[ 202.623732] [<c01810e8>] handle_irq_event_percpu+0x9c/0x150
[ 202.629461] [<c01811d4>] handle_irq_event+0x38/0x5c
[ 202.634495] [<c0184504>] handle_fasteoi_irq+0xd0/0x1a8
[ 202.639790] [<c0180704>] generic_handle_irq+0x24/0x34
[ 202.644998] [<c0180a18>] __handle_domain_irq+0x7c/0xec
[ 202.650293] [<c0101514>] gic_handle_irq+0x54/0x94
[ 202.655154] [<c010c5b8>] __irq_svc+0x58/0x98
[ 202.659581] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 202.664354] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 202.669128] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
[ 202.674423] [<c0b00c88>] start_kernel+0x39c/0x3a8
[ 202.679284] [<4000807c>] 0x4000807c
[ 202.682933]
[ 202.682933] to a HARDIRQ-irq-unsafe lock:
[ 202.688399] (prepare_lock){+.+...}
[ 202.688399] ... which became HARDIRQ-irq-unsafe at:
[ 202.695429] ... [<c07687e8>] mutex_trylock+0x130/0x250
[ 202.700637] [<c05c0060>] clk_prepare_lock+0x10/0xf8
[ 202.705672] [<c05c2a0c>] __clk_create_clk.part.13+0x4c/0x80
[ 202.711400] [<c05c33e8>] __of_clk_get_from_provider+0x88/0xf8
[ 202.717303] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
[ 202.722771] [<c05bfb68>] clk_get+0x2c/0x5c
[ 202.727024] [<c05bf62c>] devm_clk_get+0x3c/0x78
[ 202.731712] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
[ 202.737093] [<c046baa4>] platform_drv_probe+0x4c/0xb0
[ 202.742301] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
[ 202.747769] [<c046863c>] bus_for_each_drv+0x60/0x94
[ 202.752804] [<c0469fb8>] __device_attach+0xb4/0x118
[ 202.757838] [<c046945c>] bus_probe_device+0x88/0x90
[ 202.762873] [<c0467794>] device_add+0x370/0x570
[ 202.767560] [<c05babe0>] of_platform_device_create_pdata+0x84/0xb8
[ 202.773896] [<c0b1d784>] exynos_iommu_of_setup+0x120/0x158
[ 202.779538] [<c0b1d59c>] of_iommu_init+0x44/0x78
[ 202.784312] [<c0b03594>] customize_machine+0x8/0x44
[ 202.789347] [<c01017f4>] do_one_initcall+0x90/0x1dc
[ 202.794381] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
[ 202.799936] [<c076527c>] kernel_init+0x8/0x114
[ 202.804537] [<c0107950>] ret_from_fork+0x14/0x24
[ 202.809313]
[ 202.809313] other info that might help us debug this:
[ 202.809313]
[ 202.817299] Possible interrupt unsafe locking scenario:
[ 202.817299]
[ 202.824068] CPU0 CPU1
[ 202.828581] ---- ----
[ 202.833094] lock(prepare_lock);
[ 202.836394] local_irq_disable();
[ 202.842295] lock(&(&host->lock)->rlock#2);
[ 202.849065] lock(prepare_lock);
[ 202.854881] <Interrupt>
[ 202.857484] lock(&(&host->lock)->rlock#2);
[ 202.861912]
[ 202.861912] *** DEADLOCK ***
[ 202.861912]
[ 202.867820] 1 lock held by mmcqd/0/100:
[ 202.871634] #0: (&(&host->lock)->rlock#2){-.-...}, at:
[<c059db68>] sdhci_do_set_ios+0x1c/0x484
[ 202.880489]
[ 202.880489] the dependencies between HARDIRQ-irq-safe lock and the
holding lock:
[ 202.888106] -> (&(&host->lock)->rlock#2){-.-...} ops: 69588 {
[ 202.893768] IN-HARDIRQ-W at:
[ 202.896893] [<c076cc5c>] _raw_spin_lock+0x3c/0x74
[ 202.903316] [<c059f44c>] sdhci_irq+0x1c/0x814
[ 202.909392] [<c01810e8>]
handle_irq_event_percpu+0x9c/0x150
[ 202.916683] [<c01811d4>] handle_irq_event+0x38/0x5c
[ 202.923280] [<c0184504>] handle_fasteoi_irq+0xd0/0x1a8
[ 202.930137] [<c0180704>] generic_handle_irq+0x24/0x34
[ 202.936908] [<c0180a18>] __handle_domain_irq+0x7c/0xec
[ 202.943765] [<c0101514>] gic_handle_irq+0x54/0x94
[ 202.950188] [<c010c5b8>] __irq_svc+0x58/0x98
[ 202.956177] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 202.962513] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 202.968850] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
[ 202.975707] [<c0b00c88>] start_kernel+0x39c/0x3a8
[ 202.982130] [<4000807c>] 0x4000807c
[ 202.987340] IN-SOFTIRQ-W at:
[ 202.990463] [<c076ced4>] _raw_spin_lock_irqsave+0x48/0x84
[ 202.997581] [<c059d71c>] sdhci_tasklet_finish+0x18/0x1f4
[ 203.004611] [<c01271b4>] tasklet_action+0xac/0x164
[ 203.011122] [<c012743c>] __do_softirq+0x168/0x2c0
[ 203.017544] [<c0127938>] irq_exit+0xec/0x128
[ 203.023534] [<c0180a1c>] __handle_domain_irq+0x80/0xec
[ 203.030391] [<c0101514>] gic_handle_irq+0x54/0x94
[ 203.036814] [<c010c5b8>] __irq_svc+0x58/0x98
[ 203.042804] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 203.049140] [<c01083b8>] arch_cpu_idle+0x24/0x3c
[ 203.055476] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
[ 203.062334] [<c0b00c88>] start_kernel+0x39c/0x3a8
[ 203.068756] [<4000807c>] 0x4000807c
[ 203.073966] INITIAL USE at:
[ 203.077003] [<c076ced4>] _raw_spin_lock_irqsave+0x48/0x84
[ 203.084033] [<c059db68>] sdhci_do_set_ios+0x1c/0x484
[ 203.090630] [<c059e1a8>]
sdhci_runtime_resume_host+0x60/0x114
[ 203.098008] [<c04728c8>] __rpm_callback+0x2c/0x60
[ 203.104345] [<c047291c>] rpm_callback+0x20/0x80
[ 203.110507] [<c0473830>] rpm_resume+0x364/0x558
[ 203.116670] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
[ 203.123440] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
[ 203.130124] [<c058b9fc>] mmc_start_host+0x34/0xa8
[ 203.136461] [<c058cb00>] mmc_add_host+0x5c/0x80
[ 203.142624] [<c059eb20>] sdhci_add_host+0x8c4/0xdec
[ 203.149133] [<c05a0704>] sdhci_s3c_probe+0x4c4/0x568
[ 203.155730] [<c046baa4>] platform_drv_probe+0x4c/0xb0
[ 203.162414] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
[ 203.169358] [<c046a410>] __driver_attach+0xc0/0xc4
[ 203.175781] [<c0468594>] bus_for_each_dev+0x68/0x9c
[ 203.182291] [<c046970c>] bus_add_driver+0x1a0/0x218
[ 203.188801] [<c046ab24>] driver_register+0x78/0xf8
[ 203.195224] [<c01017f4>] do_one_initcall+0x90/0x1dc
[ 203.201734] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
[ 203.208765] [<c076527c>] kernel_init+0x8/0x114
[ 203.214841] [<c0107950>] ret_from_fork+0x14/0x24
[ 203.221091] }
[ 203.222740] ... key at: [<c1617248>] __key.32364+0x0/0x8
[ 203.228556] ... acquired at:
[ 203.231506] [<c0174a48>] lock_acquire+0xa8/0xd0
[ 203.236280] [<c0768980>] mutex_lock_nested+0x78/0x4dc
[ 203.241575] [<c05c00a0>] clk_prepare_lock+0x50/0xf8
[ 203.246696] [<c05c14b0>] clk_round_rate+0x1c/0x58
[ 203.251643] [<c05a00a0>] sdhci_s3c_set_clock+0x18c/0x1b0
[ 203.257199] [<c05a00e8>] sdhci_cmu_set_clock+0x24/0x17c
[ 203.262667] [<c059dbc4>] sdhci_do_set_ios+0x78/0x484
[ 203.267875] [<c059e1a8>] sdhci_runtime_resume_host+0x60/0x114
[ 203.273864] [<c04728c8>] __rpm_callback+0x2c/0x60
[ 203.278812] [<c0472950>] rpm_callback+0x54/0x80
[ 203.283586] [<c0473830>] rpm_resume+0x364/0x558
[ 203.288359] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
[ 203.293741] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
[ 203.299036] [<c059174c>] mmc_sd_runtime_resume+0x20/0xac
[ 203.304591] [<c04728c8>] __rpm_callback+0x2c/0x60
[ 203.309539] [<c0472950>] rpm_callback+0x54/0x80
[ 203.314313] [<c0473830>] rpm_resume+0x364/0x558
[ 203.319087] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
[ 203.324468] [<c0588fa8>] mmc_get_card+0x14/0x24
[ 203.329243] [<c0598b50>] mmc_blk_issue_rq+0x258/0x4f0
[ 203.334538] [<c059a4b0>] mmc_queue_thread+0xd0/0x1d8
[ 203.339745] [<c0142c6c>] kthread+0xf4/0x10c
[ 203.344172] [<c0107950>] ret_from_fork+0x14/0x24
[ 203.349033]
[ 203.350509]
[ 203.350509] the dependencies between the lock to be acquired and
HARDIRQ-irq-unsafe lock:
[ 203.358904] -> (prepare_lock){+.+...} ops: 5285 {
[ 203.363531] HARDIRQ-ON-W at:
[ 203.366654] [<c07687e8>] mutex_trylock+0x130/0x250
[ 203.373164] [<c05c0060>] clk_prepare_lock+0x10/0xf8
[ 203.379761] [<c05c2a0c>]
__clk_create_clk.part.13+0x4c/0x80
[ 203.387052] [<c05c33e8>]
__of_clk_get_from_provider+0x88/0xf8
[ 203.394517] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
[ 203.401548] [<c05bfb68>] clk_get+0x2c/0x5c
[ 203.407363] [<c05bf62c>] devm_clk_get+0x3c/0x78
[ 203.413613] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
[ 203.420557] [<c046baa4>] platform_drv_probe+0x4c/0xb0
[ 203.427327] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
[ 203.434358] [<c046863c>] bus_for_each_drv+0x60/0x94
[ 203.440955] [<c0469fb8>] __device_attach+0xb4/0x118
[ 203.447552] [<c046945c>] bus_probe_device+0x88/0x90
[ 203.454149] [<c0467794>] device_add+0x370/0x570
[ 203.460399] [<c05babe0>]
of_platform_device_create_pdata+0x84/0xb8
[ 203.468297] [<c0b1d784>]
exynos_iommu_of_setup+0x120/0x158
[ 203.475501] [<c0b1d59c>] of_iommu_init+0x44/0x78
[ 203.481838] [<c0b03594>] customize_machine+0x8/0x44
[ 203.488434] [<c01017f4>] do_one_initcall+0x90/0x1dc
[ 203.495031] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
[ 203.502149] [<c076527c>] kernel_init+0x8/0x114
[ 203.508312] [<c0107950>] ret_from_fork+0x14/0x24
[ 203.514650] SOFTIRQ-ON-W at:
[ 203.517773] [<c07687e8>] mutex_trylock+0x130/0x250
[ 203.524283] [<c05c0060>] clk_prepare_lock+0x10/0xf8
[ 203.530880] [<c05c2a0c>]
__clk_create_clk.part.13+0x4c/0x80
[ 203.538171] [<c05c33e8>]
__of_clk_get_from_provider+0x88/0xf8
[ 203.545636] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
[ 203.552666] [<c05bfb68>] clk_get+0x2c/0x5c
[ 203.558482] [<c05bf62c>] devm_clk_get+0x3c/0x78
[ 203.564732] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
[ 203.571676] [<c046baa4>] platform_drv_probe+0x4c/0xb0
[ 203.578446] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
[ 203.585477] [<c046863c>] bus_for_each_drv+0x60/0x94
[ 203.592074] [<c0469fb8>] __device_attach+0xb4/0x118
[ 203.598671] [<c046945c>] bus_probe_device+0x88/0x90
[ 203.605267] [<c0467794>] device_add+0x370/0x570
[ 203.611517] [<c05babe0>]
of_platform_device_create_pdata+0x84/0xb8
[ 203.619416] [<c0b1d784>]
exynos_iommu_of_setup+0x120/0x158
[ 203.626620] [<c0b1d59c>] of_iommu_init+0x44/0x78
[ 203.632956] [<c0b03594>] customize_machine+0x8/0x44
[ 203.639553] [<c01017f4>] do_one_initcall+0x90/0x1dc
[ 203.646150] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
[ 203.653268] [<c076527c>] kernel_init+0x8/0x114
[ 203.659431] [<c0107950>] ret_from_fork+0x14/0x24
[ 203.665768] INITIAL USE at:
[ 203.668805] [<c07687b0>] mutex_trylock+0xf8/0x250
[ 203.675142] [<c05c0060>] clk_prepare_lock+0x10/0xf8
[ 203.681651] [<c05c2a0c>]
__clk_create_clk.part.13+0x4c/0x80
[ 203.688856] [<c05c2d2c>] clk_register+0x1b8/0x5f0
[ 203.695192] [<c05c4564>]
clk_register_fixed_rate_with_accuracy+0x94/0xc4
[ 203.703525] [<c05c45ac>] clk_register_fixed_rate+0x18/0x20
[ 203.710642] [<c0b249fc>]
samsung_clk_register_fixed_rate+0x4c/0xb8
[ 203.718455] [<c0b24af8>]
samsung_clk_of_register_fixed_ext+0x90/0x98
[ 203.726440] [<c0b25800>] exynos4_clk_init+0x88/0x5b0
[ 203.733037] [<c0b24650>] of_clk_init+0x14c/0x1d8
[ 203.739287] [<c0b04488>] time_init+0x24/0x2c
[ 203.745189] [<c0b00b4c>] start_kernel+0x260/0x3a8
[ 203.751526] [<4000807c>] 0x4000807c
[ 203.756647] }
[ 203.758296] ... key at: [<c0d3bf80>] prepare_lock+0x3c/0x54
[ 203.764373] ... acquired at:
[ 203.767322] [<c0174a48>] lock_acquire+0xa8/0xd0
[ 203.772096] [<c0768980>] mutex_lock_nested+0x78/0x4dc
[ 203.777391] [<c05c00a0>] clk_prepare_lock+0x50/0xf8
[ 203.782512] [<c05c14b0>] clk_round_rate+0x1c/0x58
[ 203.787460] [<c05a00a0>] sdhci_s3c_set_clock+0x18c/0x1b0
[ 203.793015] [<c05a00e8>] sdhci_cmu_set_clock+0x24/0x17c
[ 203.798484] [<c059dbc4>] sdhci_do_set_ios+0x78/0x484
[ 203.803691] [<c059e1a8>] sdhci_runtime_resume_host+0x60/0x114
[ 203.809680] [<c04728c8>] __rpm_callback+0x2c/0x60
[ 203.814628] [<c0472950>] rpm_callback+0x54/0x80
[ 203.819402] [<c0473830>] rpm_resume+0x364/0x558
[ 203.824176] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
[ 203.829558] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
[ 203.834852] [<c059174c>] mmc_sd_runtime_resume+0x20/0xac
[ 203.840408] [<c04728c8>] __rpm_callback+0x2c/0x60
[ 203.845355] [<c0472950>] rpm_callback+0x54/0x80
[ 203.850129] [<c0473830>] rpm_resume+0x364/0x558
[ 203.854903] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
[ 203.860285] [<c0588fa8>] mmc_get_card+0x14/0x24
[ 203.865059] [<c0598b50>] mmc_blk_issue_rq+0x258/0x4f0
[ 203.870354] [<c059a4b0>] mmc_queue_thread+0xd0/0x1d8
[ 203.875562] [<c0142c6c>] kthread+0xf4/0x10c
[ 203.879988] [<c0107950>] ret_from_fork+0x14/0x24
[ 203.884850]
[ 203.886326]
[ 203.886326] stack backtrace:
[ 203.890679] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
[ 203.897266] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 203.903374] [<c010ee2c>] (unwind_backtrace) from [<c010bab8>]
(show_stack+0x10/0x14)
[ 203.911089] [<c010bab8>] (show_stack) from [<c037e0c0>]
(dump_stack+0x98/0xc4)
[ 203.918296] [<c037e0c0>] (dump_stack) from [<c017098c>]
(check_usage+0x49c/0x658)
[ 203.925757] [<c017098c>] (check_usage) from [<c0170ba8>]
(check_irq_usage+0x60/0xb8)
[ 203.933509] [<c0170ba8>] (check_irq_usage) from [<c0173404>]
(__lock_acquire+0x15c8/0x201c)
[ 203.941844] [<c0173404>] (__lock_acquire) from [<c0174a48>]
(lock_acquire+0xa8/0xd0)
[ 203.949598] [<c0174a48>] (lock_acquire) from [<c0768980>]
(mutex_lock_nested+0x78/0x4dc)
[ 203.957639] [<c0768980>] (mutex_lock_nested) from [<c05c00a0>]
(clk_prepare_lock+0x50/0xf8)
[ 203.965969] [<c05c00a0>] (clk_prepare_lock) from [<c05c14b0>]
(clk_round_rate+0x1c/0x58)
[ 203.974085] [<c05c14b0>] (clk_round_rate) from [<c05a00a0>]
(sdhci_s3c_set_clock+0x18c/0x1b0)
[ 203.982551] [<c05a00a0>] (sdhci_s3c_set_clock) from [<c05a00e8>]
(sdhci_cmu_set_clock+0x24/0x17c)
[ 203.991403] [<c05a00e8>] (sdhci_cmu_set_clock) from [<c059dbc4>]
(sdhci_do_set_ios+0x78/0x484)
[ 203.999993] [<c059dbc4>] (sdhci_do_set_ios) from [<c059e1a8>]
(sdhci_runtime_resume_host+0x60/0x114)
[ 204.009094] [<c059e1a8>] (sdhci_runtime_resume_host) from
[<c04728c8>] (__rpm_callback+0x2c/0x60)
[ 204.017938] [<c04728c8>] (__rpm_callback) from [<c0472950>]
(rpm_callback+0x54/0x80)
[ 204.025661] [<c0472950>] (rpm_callback) from [<c0473830>]
(rpm_resume+0x364/0x558)
[ 204.033214] [<c0473830>] (rpm_resume) from [<c0473a84>]
(__pm_runtime_resume+0x60/0x8c)
[ 204.041201] [<c0473a84>] (__pm_runtime_resume) from [<c0588f50>]
(__mmc_claim_host+0x1b4/0x1f8)
[ 204.049885] [<c0588f50>] (__mmc_claim_host) from [<c059174c>]
(mmc_sd_runtime_resume+0x20/0xac)
[ 204.058563] [<c059174c>] (mmc_sd_runtime_resume) from [<c04728c8>]
(__rpm_callback+0x2c/0x60)
[ 204.067063] [<c04728c8>] (__rpm_callback) from [<c0472950>]
(rpm_callback+0x54/0x80)
[ 204.074788] [<c0472950>] (rpm_callback) from [<c0473830>]
(rpm_resume+0x364/0x558)
[ 204.082340] [<c0473830>] (rpm_resume) from [<c0473a84>]
(__pm_runtime_resume+0x60/0x8c)
[ 204.090326] [<c0473a84>] (__pm_runtime_resume) from [<c0588fa8>]
(mmc_get_card+0x14/0x24)
[ 204.098487] [<c0588fa8>] (mmc_get_card) from [<c0598b50>]
(mmc_blk_issue_rq+0x258/0x4f0)
[ 204.106559] [<c0598b50>] (mmc_blk_issue_rq) from [<c059a4b0>]
(mmc_queue_thread+0xd0/0x1d8)
[ 204.114903] [<c059a4b0>] (mmc_queue_thread) from [<c0142c6c>]
(kthread+0xf4/0x10c)
[ 204.122452] [<c0142c6c>] (kthread) from [<c0107950>]
(ret_from_fork+0x14/0x24)
---------------------------------------------------------------------------------------------------------
Best Regards
-Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2016-03-28 07:40 +0200 |
| Message-ID | <rhy4b-2we-17@gated-at.bofh.it> |
| In reply to | #1365087 |
On 27.03.2016 16:41, Anand Moon wrote:
>
> On My Odroid U3 with debug flags enable I am observing bellow deadlock.
There is a sleep in atomic context and possible deadlock, but:
1. Are you sure it does not happen without the patch?
2. Are you sure it is not the same as already known issue on sdhci-s3c?
For example reported here:
http://www.spinics.net/lists/linux-samsung-soc/msg42398.html
What is reproducibility rate?
Best regards,
Krzysztof
> ---------------------------------------------------------------------------------------------------------
> [ 202.519524] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:617
> [ 202.522364] in_atomic(): 1, irqs_disabled(): 128, pid: 100, name: mmcqd/0
> [ 202.529129] 1 lock held by mmcqd/0/100:
> [ 202.529150] #0: (&(&host->lock)->rlock#2){-.-...}, at:
> [<c059db68>] sdhci_do_set_ios+0x1c/0x484
> [ 202.529271] irq event stamp: 703530
> [ 202.529291] hardirqs last enabled at (703529): [<c076d108>]
> _raw_spin_unlock_irqrestore+0x6c/0x74
> [ 202.529343] hardirqs last disabled at (703530): [<c076cea8>]
> _raw_spin_lock_irqsave+0x1c/0x84
> [ 202.529384] softirqs last enabled at (703456): [<c0127518>]
> __do_softirq+0x244/0x2c0
> [ 202.529438] softirqs last disabled at (703445): [<c0127938>]
> irq_exit+0xec/0x128
> [ 202.529472] Preemption disabled at:[< (null)>] (null)
> [ 202.534415]
> [ 202.534449] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
> [ 202.534473] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 202.534544] [<c010ee2c>] (unwind_backtrace) from [<c010bab8>]
> (show_stack+0x10/0x14)
> [ 202.534594] [<c010bab8>] (show_stack) from [<c037e0c0>]
> (dump_stack+0x98/0xc4)
> [ 202.534639] [<c037e0c0>] (dump_stack) from [<c0768934>]
> (mutex_lock_nested+0x2c/0x4dc)
> [ 202.534685] [<c0768934>] (mutex_lock_nested) from [<c05c00a0>]
> (clk_prepare_lock+0x50/0xf8)
> [ 202.534726] [<c05c00a0>] (clk_prepare_lock) from [<c05c14b0>]
> (clk_round_rate+0x1c/0x58)
> [ 202.534773] [<c05c14b0>] (clk_round_rate) from [<c05a00a0>]
> (sdhci_s3c_set_clock+0x18c/0x1b0)
> [ 202.534819] [<c05a00a0>] (sdhci_s3c_set_clock) from [<c05a00e8>]
> (sdhci_cmu_set_clock+0x24/0x17c)
> [ 202.534860] [<c05a00e8>] (sdhci_cmu_set_clock) from [<c059dbc4>]
> (sdhci_do_set_ios+0x78/0x484)
> [ 202.534904] [<c059dbc4>] (sdhci_do_set_ios) from [<c059e1a8>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 202.534957] [<c059e1a8>] (sdhci_runtime_resume_host) from
> [<c04728c8>] (__rpm_callback+0x2c/0x60)
> [ 202.535000] [<c04728c8>] (__rpm_callback) from [<c0472950>]
> (rpm_callback+0x54/0x80)
> [ 202.535041] [<c0472950>] (rpm_callback) from [<c0473830>]
> (rpm_resume+0x364/0x558)
> [ 202.535081] [<c0473830>] (rpm_resume) from [<c0473a84>]
> (__pm_runtime_resume+0x60/0x8c)
> [ 202.535125] [<c0473a84>] (__pm_runtime_resume) from [<c0588f50>]
> (__mmc_claim_host+0x1b4/0x1f8)
> [ 202.535176] [<c0588f50>] (__mmc_claim_host) from [<c059174c>]
> (mmc_sd_runtime_resume+0x20/0xac)
> [ 202.535220] [<c059174c>] (mmc_sd_runtime_resume) from [<c04728c8>]
> (__rpm_callback+0x2c/0x60)
> [ 202.535259] [<c04728c8>] (__rpm_callback) from [<c0472950>]
> (rpm_callback+0x54/0x80)
> [ 202.535299] [<c0472950>] (rpm_callback) from [<c0473830>]
> (rpm_resume+0x364/0x558)
> [ 202.535340] [<c0473830>] (rpm_resume) from [<c0473a84>]
> (__pm_runtime_resume+0x60/0x8c)
> [ 202.535379] [<c0473a84>] (__pm_runtime_resume) from [<c0588fa8>]
> (mmc_get_card+0x14/0x24)
> [ 202.535420] [<c0588fa8>] (mmc_get_card) from [<c0598b50>]
> (mmc_blk_issue_rq+0x258/0x4f0)
> [ 202.535461] [<c0598b50>] (mmc_blk_issue_rq) from [<c059a4b0>]
> (mmc_queue_thread+0xd0/0x1d8)
> [ 202.535513] [<c059a4b0>] (mmc_queue_thread) from [<c0142c6c>]
> (kthread+0xf4/0x10c)
> [ 202.535561] [<c0142c6c>] (kthread) from [<c0107950>]
> (ret_from_fork+0x14/0x24)
> [ 202.535624]
> [ 202.535893] ======================================================
> [ 202.542059] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> [ 202.548742] 4.6.0-rc1-u3s #38 Not tainted
> [ 202.552732] ------------------------------------------------------
> [ 202.558902] mmcqd/0/100 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [ 202.565317] (prepare_lock){+.+...}, at: [<c05c00a0>]
> clk_prepare_lock+0x50/0xf8
> [ 202.572695]
> [ 202.572695] and this task is already holding:
> [ 202.578510] (&(&host->lock)->rlock#2){-.-...}, at: [<c059db68>]
> sdhci_do_set_ios+0x1c/0x484
> [ 202.586930] which would create a new lock dependency:
> [ 202.591964] (&(&host->lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
> [ 202.598650]
> [ 202.598650] but this new dependency connects a HARDIRQ-irq-safe lock:
> [ 202.606546] (&(&host->lock)->rlock#2){-.-...}
> [ 202.606546] ... which became HARDIRQ-irq-safe at:
> [ 202.614359] [<c076cc5c>] _raw_spin_lock+0x3c/0x74
> [ 202.619219] [<c059f44c>] sdhci_irq+0x1c/0x814
> [ 202.623732] [<c01810e8>] handle_irq_event_percpu+0x9c/0x150
> [ 202.629461] [<c01811d4>] handle_irq_event+0x38/0x5c
> [ 202.634495] [<c0184504>] handle_fasteoi_irq+0xd0/0x1a8
> [ 202.639790] [<c0180704>] generic_handle_irq+0x24/0x34
> [ 202.644998] [<c0180a18>] __handle_domain_irq+0x7c/0xec
> [ 202.650293] [<c0101514>] gic_handle_irq+0x54/0x94
> [ 202.655154] [<c010c5b8>] __irq_svc+0x58/0x98
> [ 202.659581] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 202.664354] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 202.669128] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
> [ 202.674423] [<c0b00c88>] start_kernel+0x39c/0x3a8
> [ 202.679284] [<4000807c>] 0x4000807c
> [ 202.682933]
> [ 202.682933] to a HARDIRQ-irq-unsafe lock:
> [ 202.688399] (prepare_lock){+.+...}
> [ 202.688399] ... which became HARDIRQ-irq-unsafe at:
> [ 202.695429] ... [<c07687e8>] mutex_trylock+0x130/0x250
> [ 202.700637] [<c05c0060>] clk_prepare_lock+0x10/0xf8
> [ 202.705672] [<c05c2a0c>] __clk_create_clk.part.13+0x4c/0x80
> [ 202.711400] [<c05c33e8>] __of_clk_get_from_provider+0x88/0xf8
> [ 202.717303] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
> [ 202.722771] [<c05bfb68>] clk_get+0x2c/0x5c
> [ 202.727024] [<c05bf62c>] devm_clk_get+0x3c/0x78
> [ 202.731712] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
> [ 202.737093] [<c046baa4>] platform_drv_probe+0x4c/0xb0
> [ 202.742301] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
> [ 202.747769] [<c046863c>] bus_for_each_drv+0x60/0x94
> [ 202.752804] [<c0469fb8>] __device_attach+0xb4/0x118
> [ 202.757838] [<c046945c>] bus_probe_device+0x88/0x90
> [ 202.762873] [<c0467794>] device_add+0x370/0x570
> [ 202.767560] [<c05babe0>] of_platform_device_create_pdata+0x84/0xb8
> [ 202.773896] [<c0b1d784>] exynos_iommu_of_setup+0x120/0x158
> [ 202.779538] [<c0b1d59c>] of_iommu_init+0x44/0x78
> [ 202.784312] [<c0b03594>] customize_machine+0x8/0x44
> [ 202.789347] [<c01017f4>] do_one_initcall+0x90/0x1dc
> [ 202.794381] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
> [ 202.799936] [<c076527c>] kernel_init+0x8/0x114
> [ 202.804537] [<c0107950>] ret_from_fork+0x14/0x24
> [ 202.809313]
> [ 202.809313] other info that might help us debug this:
> [ 202.809313]
> [ 202.817299] Possible interrupt unsafe locking scenario:
> [ 202.817299]
> [ 202.824068] CPU0 CPU1
> [ 202.828581] ---- ----
> [ 202.833094] lock(prepare_lock);
> [ 202.836394] local_irq_disable();
> [ 202.842295] lock(&(&host->lock)->rlock#2);
> [ 202.849065] lock(prepare_lock);
> [ 202.854881] <Interrupt>
> [ 202.857484] lock(&(&host->lock)->rlock#2);
> [ 202.861912]
> [ 202.861912] *** DEADLOCK ***
> [ 202.861912]
> [ 202.867820] 1 lock held by mmcqd/0/100:
> [ 202.871634] #0: (&(&host->lock)->rlock#2){-.-...}, at:
> [<c059db68>] sdhci_do_set_ios+0x1c/0x484
> [ 202.880489]
> [ 202.880489] the dependencies between HARDIRQ-irq-safe lock and the
> holding lock:
> [ 202.888106] -> (&(&host->lock)->rlock#2){-.-...} ops: 69588 {
> [ 202.893768] IN-HARDIRQ-W at:
> [ 202.896893] [<c076cc5c>] _raw_spin_lock+0x3c/0x74
> [ 202.903316] [<c059f44c>] sdhci_irq+0x1c/0x814
> [ 202.909392] [<c01810e8>]
> handle_irq_event_percpu+0x9c/0x150
> [ 202.916683] [<c01811d4>] handle_irq_event+0x38/0x5c
> [ 202.923280] [<c0184504>] handle_fasteoi_irq+0xd0/0x1a8
> [ 202.930137] [<c0180704>] generic_handle_irq+0x24/0x34
> [ 202.936908] [<c0180a18>] __handle_domain_irq+0x7c/0xec
> [ 202.943765] [<c0101514>] gic_handle_irq+0x54/0x94
> [ 202.950188] [<c010c5b8>] __irq_svc+0x58/0x98
> [ 202.956177] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 202.962513] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 202.968850] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
> [ 202.975707] [<c0b00c88>] start_kernel+0x39c/0x3a8
> [ 202.982130] [<4000807c>] 0x4000807c
> [ 202.987340] IN-SOFTIRQ-W at:
> [ 202.990463] [<c076ced4>] _raw_spin_lock_irqsave+0x48/0x84
> [ 202.997581] [<c059d71c>] sdhci_tasklet_finish+0x18/0x1f4
> [ 203.004611] [<c01271b4>] tasklet_action+0xac/0x164
> [ 203.011122] [<c012743c>] __do_softirq+0x168/0x2c0
> [ 203.017544] [<c0127938>] irq_exit+0xec/0x128
> [ 203.023534] [<c0180a1c>] __handle_domain_irq+0x80/0xec
> [ 203.030391] [<c0101514>] gic_handle_irq+0x54/0x94
> [ 203.036814] [<c010c5b8>] __irq_svc+0x58/0x98
> [ 203.042804] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 203.049140] [<c01083b8>] arch_cpu_idle+0x24/0x3c
> [ 203.055476] [<c0167100>] cpu_startup_entry+0x1c8/0x24c
> [ 203.062334] [<c0b00c88>] start_kernel+0x39c/0x3a8
> [ 203.068756] [<4000807c>] 0x4000807c
> [ 203.073966] INITIAL USE at:
> [ 203.077003] [<c076ced4>] _raw_spin_lock_irqsave+0x48/0x84
> [ 203.084033] [<c059db68>] sdhci_do_set_ios+0x1c/0x484
> [ 203.090630] [<c059e1a8>]
> sdhci_runtime_resume_host+0x60/0x114
> [ 203.098008] [<c04728c8>] __rpm_callback+0x2c/0x60
> [ 203.104345] [<c047291c>] rpm_callback+0x20/0x80
> [ 203.110507] [<c0473830>] rpm_resume+0x364/0x558
> [ 203.116670] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
> [ 203.123440] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
> [ 203.130124] [<c058b9fc>] mmc_start_host+0x34/0xa8
> [ 203.136461] [<c058cb00>] mmc_add_host+0x5c/0x80
> [ 203.142624] [<c059eb20>] sdhci_add_host+0x8c4/0xdec
> [ 203.149133] [<c05a0704>] sdhci_s3c_probe+0x4c4/0x568
> [ 203.155730] [<c046baa4>] platform_drv_probe+0x4c/0xb0
> [ 203.162414] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
> [ 203.169358] [<c046a410>] __driver_attach+0xc0/0xc4
> [ 203.175781] [<c0468594>] bus_for_each_dev+0x68/0x9c
> [ 203.182291] [<c046970c>] bus_add_driver+0x1a0/0x218
> [ 203.188801] [<c046ab24>] driver_register+0x78/0xf8
> [ 203.195224] [<c01017f4>] do_one_initcall+0x90/0x1dc
> [ 203.201734] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
> [ 203.208765] [<c076527c>] kernel_init+0x8/0x114
> [ 203.214841] [<c0107950>] ret_from_fork+0x14/0x24
> [ 203.221091] }
> [ 203.222740] ... key at: [<c1617248>] __key.32364+0x0/0x8
> [ 203.228556] ... acquired at:
> [ 203.231506] [<c0174a48>] lock_acquire+0xa8/0xd0
> [ 203.236280] [<c0768980>] mutex_lock_nested+0x78/0x4dc
> [ 203.241575] [<c05c00a0>] clk_prepare_lock+0x50/0xf8
> [ 203.246696] [<c05c14b0>] clk_round_rate+0x1c/0x58
> [ 203.251643] [<c05a00a0>] sdhci_s3c_set_clock+0x18c/0x1b0
> [ 203.257199] [<c05a00e8>] sdhci_cmu_set_clock+0x24/0x17c
> [ 203.262667] [<c059dbc4>] sdhci_do_set_ios+0x78/0x484
> [ 203.267875] [<c059e1a8>] sdhci_runtime_resume_host+0x60/0x114
> [ 203.273864] [<c04728c8>] __rpm_callback+0x2c/0x60
> [ 203.278812] [<c0472950>] rpm_callback+0x54/0x80
> [ 203.283586] [<c0473830>] rpm_resume+0x364/0x558
> [ 203.288359] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
> [ 203.293741] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
> [ 203.299036] [<c059174c>] mmc_sd_runtime_resume+0x20/0xac
> [ 203.304591] [<c04728c8>] __rpm_callback+0x2c/0x60
> [ 203.309539] [<c0472950>] rpm_callback+0x54/0x80
> [ 203.314313] [<c0473830>] rpm_resume+0x364/0x558
> [ 203.319087] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
> [ 203.324468] [<c0588fa8>] mmc_get_card+0x14/0x24
> [ 203.329243] [<c0598b50>] mmc_blk_issue_rq+0x258/0x4f0
> [ 203.334538] [<c059a4b0>] mmc_queue_thread+0xd0/0x1d8
> [ 203.339745] [<c0142c6c>] kthread+0xf4/0x10c
> [ 203.344172] [<c0107950>] ret_from_fork+0x14/0x24
> [ 203.349033]
> [ 203.350509]
> [ 203.350509] the dependencies between the lock to be acquired and
> HARDIRQ-irq-unsafe lock:
> [ 203.358904] -> (prepare_lock){+.+...} ops: 5285 {
> [ 203.363531] HARDIRQ-ON-W at:
> [ 203.366654] [<c07687e8>] mutex_trylock+0x130/0x250
> [ 203.373164] [<c05c0060>] clk_prepare_lock+0x10/0xf8
> [ 203.379761] [<c05c2a0c>]
> __clk_create_clk.part.13+0x4c/0x80
> [ 203.387052] [<c05c33e8>]
> __of_clk_get_from_provider+0x88/0xf8
> [ 203.394517] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
> [ 203.401548] [<c05bfb68>] clk_get+0x2c/0x5c
> [ 203.407363] [<c05bf62c>] devm_clk_get+0x3c/0x78
> [ 203.413613] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
> [ 203.420557] [<c046baa4>] platform_drv_probe+0x4c/0xb0
> [ 203.427327] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
> [ 203.434358] [<c046863c>] bus_for_each_drv+0x60/0x94
> [ 203.440955] [<c0469fb8>] __device_attach+0xb4/0x118
> [ 203.447552] [<c046945c>] bus_probe_device+0x88/0x90
> [ 203.454149] [<c0467794>] device_add+0x370/0x570
> [ 203.460399] [<c05babe0>]
> of_platform_device_create_pdata+0x84/0xb8
> [ 203.468297] [<c0b1d784>]
> exynos_iommu_of_setup+0x120/0x158
> [ 203.475501] [<c0b1d59c>] of_iommu_init+0x44/0x78
> [ 203.481838] [<c0b03594>] customize_machine+0x8/0x44
> [ 203.488434] [<c01017f4>] do_one_initcall+0x90/0x1dc
> [ 203.495031] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
> [ 203.502149] [<c076527c>] kernel_init+0x8/0x114
> [ 203.508312] [<c0107950>] ret_from_fork+0x14/0x24
> [ 203.514650] SOFTIRQ-ON-W at:
> [ 203.517773] [<c07687e8>] mutex_trylock+0x130/0x250
> [ 203.524283] [<c05c0060>] clk_prepare_lock+0x10/0xf8
> [ 203.530880] [<c05c2a0c>]
> __clk_create_clk.part.13+0x4c/0x80
> [ 203.538171] [<c05c33e8>]
> __of_clk_get_from_provider+0x88/0xf8
> [ 203.545636] [<c05bfb08>] __of_clk_get_by_name+0xfc/0x114
> [ 203.552666] [<c05bfb68>] clk_get+0x2c/0x5c
> [ 203.558482] [<c05bf62c>] devm_clk_get+0x3c/0x78
> [ 203.564732] [<c0b1d8a4>] exynos_sysmmu_probe+0xe8/0x310
> [ 203.571676] [<c046baa4>] platform_drv_probe+0x4c/0xb0
> [ 203.578446] [<c046a2a4>] driver_probe_device+0x20c/0x2b8
> [ 203.585477] [<c046863c>] bus_for_each_drv+0x60/0x94
> [ 203.592074] [<c0469fb8>] __device_attach+0xb4/0x118
> [ 203.598671] [<c046945c>] bus_probe_device+0x88/0x90
> [ 203.605267] [<c0467794>] device_add+0x370/0x570
> [ 203.611517] [<c05babe0>]
> of_platform_device_create_pdata+0x84/0xb8
> [ 203.619416] [<c0b1d784>]
> exynos_iommu_of_setup+0x120/0x158
> [ 203.626620] [<c0b1d59c>] of_iommu_init+0x44/0x78
> [ 203.632956] [<c0b03594>] customize_machine+0x8/0x44
> [ 203.639553] [<c01017f4>] do_one_initcall+0x90/0x1dc
> [ 203.646150] [<c0b00dec>] kernel_init_freeable+0x158/0x1e8
> [ 203.653268] [<c076527c>] kernel_init+0x8/0x114
> [ 203.659431] [<c0107950>] ret_from_fork+0x14/0x24
> [ 203.665768] INITIAL USE at:
> [ 203.668805] [<c07687b0>] mutex_trylock+0xf8/0x250
> [ 203.675142] [<c05c0060>] clk_prepare_lock+0x10/0xf8
> [ 203.681651] [<c05c2a0c>]
> __clk_create_clk.part.13+0x4c/0x80
> [ 203.688856] [<c05c2d2c>] clk_register+0x1b8/0x5f0
> [ 203.695192] [<c05c4564>]
> clk_register_fixed_rate_with_accuracy+0x94/0xc4
> [ 203.703525] [<c05c45ac>] clk_register_fixed_rate+0x18/0x20
> [ 203.710642] [<c0b249fc>]
> samsung_clk_register_fixed_rate+0x4c/0xb8
> [ 203.718455] [<c0b24af8>]
> samsung_clk_of_register_fixed_ext+0x90/0x98
> [ 203.726440] [<c0b25800>] exynos4_clk_init+0x88/0x5b0
> [ 203.733037] [<c0b24650>] of_clk_init+0x14c/0x1d8
> [ 203.739287] [<c0b04488>] time_init+0x24/0x2c
> [ 203.745189] [<c0b00b4c>] start_kernel+0x260/0x3a8
> [ 203.751526] [<4000807c>] 0x4000807c
> [ 203.756647] }
> [ 203.758296] ... key at: [<c0d3bf80>] prepare_lock+0x3c/0x54
> [ 203.764373] ... acquired at:
> [ 203.767322] [<c0174a48>] lock_acquire+0xa8/0xd0
> [ 203.772096] [<c0768980>] mutex_lock_nested+0x78/0x4dc
> [ 203.777391] [<c05c00a0>] clk_prepare_lock+0x50/0xf8
> [ 203.782512] [<c05c14b0>] clk_round_rate+0x1c/0x58
> [ 203.787460] [<c05a00a0>] sdhci_s3c_set_clock+0x18c/0x1b0
> [ 203.793015] [<c05a00e8>] sdhci_cmu_set_clock+0x24/0x17c
> [ 203.798484] [<c059dbc4>] sdhci_do_set_ios+0x78/0x484
> [ 203.803691] [<c059e1a8>] sdhci_runtime_resume_host+0x60/0x114
> [ 203.809680] [<c04728c8>] __rpm_callback+0x2c/0x60
> [ 203.814628] [<c0472950>] rpm_callback+0x54/0x80
> [ 203.819402] [<c0473830>] rpm_resume+0x364/0x558
> [ 203.824176] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
> [ 203.829558] [<c0588f50>] __mmc_claim_host+0x1b4/0x1f8
> [ 203.834852] [<c059174c>] mmc_sd_runtime_resume+0x20/0xac
> [ 203.840408] [<c04728c8>] __rpm_callback+0x2c/0x60
> [ 203.845355] [<c0472950>] rpm_callback+0x54/0x80
> [ 203.850129] [<c0473830>] rpm_resume+0x364/0x558
> [ 203.854903] [<c0473a84>] __pm_runtime_resume+0x60/0x8c
> [ 203.860285] [<c0588fa8>] mmc_get_card+0x14/0x24
> [ 203.865059] [<c0598b50>] mmc_blk_issue_rq+0x258/0x4f0
> [ 203.870354] [<c059a4b0>] mmc_queue_thread+0xd0/0x1d8
> [ 203.875562] [<c0142c6c>] kthread+0xf4/0x10c
> [ 203.879988] [<c0107950>] ret_from_fork+0x14/0x24
> [ 203.884850]
> [ 203.886326]
> [ 203.886326] stack backtrace:
> [ 203.890679] CPU: 0 PID: 100 Comm: mmcqd/0 Not tainted 4.6.0-rc1-u3s #38
> [ 203.897266] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 203.903374] [<c010ee2c>] (unwind_backtrace) from [<c010bab8>]
> (show_stack+0x10/0x14)
> [ 203.911089] [<c010bab8>] (show_stack) from [<c037e0c0>]
> (dump_stack+0x98/0xc4)
> [ 203.918296] [<c037e0c0>] (dump_stack) from [<c017098c>]
> (check_usage+0x49c/0x658)
> [ 203.925757] [<c017098c>] (check_usage) from [<c0170ba8>]
> (check_irq_usage+0x60/0xb8)
> [ 203.933509] [<c0170ba8>] (check_irq_usage) from [<c0173404>]
> (__lock_acquire+0x15c8/0x201c)
> [ 203.941844] [<c0173404>] (__lock_acquire) from [<c0174a48>]
> (lock_acquire+0xa8/0xd0)
> [ 203.949598] [<c0174a48>] (lock_acquire) from [<c0768980>]
> (mutex_lock_nested+0x78/0x4dc)
> [ 203.957639] [<c0768980>] (mutex_lock_nested) from [<c05c00a0>]
> (clk_prepare_lock+0x50/0xf8)
> [ 203.965969] [<c05c00a0>] (clk_prepare_lock) from [<c05c14b0>]
> (clk_round_rate+0x1c/0x58)
> [ 203.974085] [<c05c14b0>] (clk_round_rate) from [<c05a00a0>]
> (sdhci_s3c_set_clock+0x18c/0x1b0)
> [ 203.982551] [<c05a00a0>] (sdhci_s3c_set_clock) from [<c05a00e8>]
> (sdhci_cmu_set_clock+0x24/0x17c)
> [ 203.991403] [<c05a00e8>] (sdhci_cmu_set_clock) from [<c059dbc4>]
> (sdhci_do_set_ios+0x78/0x484)
> [ 203.999993] [<c059dbc4>] (sdhci_do_set_ios) from [<c059e1a8>]
> (sdhci_runtime_resume_host+0x60/0x114)
> [ 204.009094] [<c059e1a8>] (sdhci_runtime_resume_host) from
> [<c04728c8>] (__rpm_callback+0x2c/0x60)
> [ 204.017938] [<c04728c8>] (__rpm_callback) from [<c0472950>]
> (rpm_callback+0x54/0x80)
> [ 204.025661] [<c0472950>] (rpm_callback) from [<c0473830>]
> (rpm_resume+0x364/0x558)
> [ 204.033214] [<c0473830>] (rpm_resume) from [<c0473a84>]
> (__pm_runtime_resume+0x60/0x8c)
> [ 204.041201] [<c0473a84>] (__pm_runtime_resume) from [<c0588f50>]
> (__mmc_claim_host+0x1b4/0x1f8)
> [ 204.049885] [<c0588f50>] (__mmc_claim_host) from [<c059174c>]
> (mmc_sd_runtime_resume+0x20/0xac)
> [ 204.058563] [<c059174c>] (mmc_sd_runtime_resume) from [<c04728c8>]
> (__rpm_callback+0x2c/0x60)
> [ 204.067063] [<c04728c8>] (__rpm_callback) from [<c0472950>]
> (rpm_callback+0x54/0x80)
> [ 204.074788] [<c0472950>] (rpm_callback) from [<c0473830>]
> (rpm_resume+0x364/0x558)
> [ 204.082340] [<c0473830>] (rpm_resume) from [<c0473a84>]
> (__pm_runtime_resume+0x60/0x8c)
> [ 204.090326] [<c0473a84>] (__pm_runtime_resume) from [<c0588fa8>]
> (mmc_get_card+0x14/0x24)
> [ 204.098487] [<c0588fa8>] (mmc_get_card) from [<c0598b50>]
> (mmc_blk_issue_rq+0x258/0x4f0)
> [ 204.106559] [<c0598b50>] (mmc_blk_issue_rq) from [<c059a4b0>]
> (mmc_queue_thread+0xd0/0x1d8)
> [ 204.114903] [<c059a4b0>] (mmc_queue_thread) from [<c0142c6c>]
> (kthread+0xf4/0x10c)
> [ 204.122452] [<c0142c6c>] (kthread) from [<c0107950>]
> (ret_from_fork+0x14/0x24)
> ---------------------------------------------------------------------------------------------------------
>
> Best Regards
> -Anand Moon
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web