Re: [PATCH] serial: samsung: fix the inconsistency in spinlock
Hi Krzysztof,
On 19 February 2016 at 11:39, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2016-02-19 4:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> Hi Peter,
>>
>> On 18 February 2016 at 23:18, Peter Hurley <pe...@hurleysoftware.com> wrote:
>>> Hi Anand,
>>>
>>> On 02/18/2016 09:40 AM, Anand Moon wrote:
>>>> From: Anand Moon <linux.am...@gmail.com>
>>>>
>>>> changes fix the correct order of the spin_lock_irqrestore/save.
>>>>
>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>> ---
>>>> drivers/tty/serial/samsung.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>>>> index d72cd73..96fe14d 100644
>>>> --- a/drivers/tty/serial/samsung.c
>>>> +++ b/drivers/tty/serial/samsung.c
>>>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq,
>>>> void *id)
>>>> }
>>>>
>>>> if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>>>> - spin_unlock(>lock);
>>>> + spin_unlock_irqrestore(>lock, flags);
>>>> uart_write_wakeup(port);
>>>> - spin_lock(>lock);
>>>> + spin_lock_irqsave(>lock, flags);
>>>
>>> This driver shouldn't be dropping the spin lock at for write wakeup.
>>> If this is causing lock-ups in a line discipline, the line discipline
>>> needs fixed.
>>>
>>
>> Thanks for pointing out.
>> Their is no lock up, just the inconstancy of the spin_lock.
>> Then I will resend this patch dropping the spin_unlock/spin_lock
>> around uart_write_wakeup.
>> Is that ok with you.
>
> Anand, before doing that, can you check Peter's second sentence? I
> mean the "If this is causing lock-ups in a line discipline, the line
> discipline needs fixed.".
> Don't drop the spin-locks "just because". I would be happy to see more
> detailed explanation in changelog.
>
> Best regards,
> Krzysztof
Yes I understood the meaning of the sentence. Already the
s3c24xx_serial_tx_chars function.
holds the lock port->lock for safe IRQ execution.
http://lxr.free-electrons.com/source/drivers/tty/serial/samsung.c#L701
Best Regards
-Anand Moon
Re: [PATCH] serial: samsung: fix the inconsistency in spinlock
Hi Krzysztof,
On 19 February 2016 at 11:39, Krzysztof Kozlowski
wrote:
> 2016-02-19 4:14 GMT+09:00 Anand Moon :
>> Hi Peter,
>>
>> On 18 February 2016 at 23:18, Peter Hurley wrote:
>>> Hi Anand,
>>>
>>> On 02/18/2016 09:40 AM, Anand Moon wrote:
>>>> From: Anand Moon
>>>>
>>>> changes fix the correct order of the spin_lock_irqrestore/save.
>>>>
>>>> Signed-off-by: Anand Moon
>>>> ---
>>>> drivers/tty/serial/samsung.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>>>> index d72cd73..96fe14d 100644
>>>> --- a/drivers/tty/serial/samsung.c
>>>> +++ b/drivers/tty/serial/samsung.c
>>>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq,
>>>> void *id)
>>>> }
>>>>
>>>> if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>>>> - spin_unlock(>lock);
>>>> + spin_unlock_irqrestore(>lock, flags);
>>>> uart_write_wakeup(port);
>>>> - spin_lock(>lock);
>>>> + spin_lock_irqsave(>lock, flags);
>>>
>>> This driver shouldn't be dropping the spin lock at for write wakeup.
>>> If this is causing lock-ups in a line discipline, the line discipline
>>> needs fixed.
>>>
>>
>> Thanks for pointing out.
>> Their is no lock up, just the inconstancy of the spin_lock.
>> Then I will resend this patch dropping the spin_unlock/spin_lock
>> around uart_write_wakeup.
>> Is that ok with you.
>
> Anand, before doing that, can you check Peter's second sentence? I
> mean the "If this is causing lock-ups in a line discipline, the line
> discipline needs fixed.".
> Don't drop the spin-locks "just because". I would be happy to see more
> detailed explanation in changelog.
>
> Best regards,
> Krzysztof
Yes I understood the meaning of the sentence. Already the
s3c24xx_serial_tx_chars function.
holds the lock port->lock for safe IRQ execution.
http://lxr.free-electrons.com/source/drivers/tty/serial/samsung.c#L701
Best Regards
-Anand Moon
Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore
Hi Krzysztof, On 19 February 2016 at 11:36, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > 2016-02-19 2:21 GMT+09:00 Anand Moon <linux.am...@gmail.com>: >> From: Anand Moon <linux.am...@gmail.com> >> >> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking. >> It's safe to initialize pl330_tasklet tasklet after release of the locking. > > This is tasklet init, not tasklet execution (which you are referring > to in first sentence). I don't get how usage of spinlock during > execution guarantees the safeness during init... Please describe why > this is safe. > > Best regards, > Krzysztof > http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972 pl330_tasklet function which is initiated by tasklet_init is trying to lock using same spin_unlock_irqsave/restore pch->lock. So better release the pch->lock and then initialize the tasklet_init. Best Regards, -Anand Moon >> >> Signed-off-by: Anand Moon <linux.am...@gmail.com> >> --- >> drivers/dma/pl330.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c >> index 17ee758..df2cab1 100644 >> --- a/drivers/dma/pl330.c >> +++ b/drivers/dma/pl330.c >> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct >> dma_chan *chan) >> return -ENOMEM; >> } >> >> - tasklet_init(>task, pl330_tasklet, (unsigned long) pch); >> - >> spin_unlock_irqrestore(>lock, flags); >> >> + tasklet_init(>task, pl330_tasklet, (unsigned long) pch); >> + >> return 1; >> } >> >> -- >> 1.9.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe dmaengine" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore
Hi Krzysztof, On 19 February 2016 at 11:36, Krzysztof Kozlowski wrote: > 2016-02-19 2:21 GMT+09:00 Anand Moon : >> From: Anand Moon >> >> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking. >> It's safe to initialize pl330_tasklet tasklet after release of the locking. > > This is tasklet init, not tasklet execution (which you are referring > to in first sentence). I don't get how usage of spinlock during > execution guarantees the safeness during init... Please describe why > this is safe. > > Best regards, > Krzysztof > http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972 pl330_tasklet function which is initiated by tasklet_init is trying to lock using same spin_unlock_irqsave/restore pch->lock. So better release the pch->lock and then initialize the tasklet_init. Best Regards, -Anand Moon >> >> Signed-off-by: Anand Moon >> --- >> drivers/dma/pl330.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c >> index 17ee758..df2cab1 100644 >> --- a/drivers/dma/pl330.c >> +++ b/drivers/dma/pl330.c >> @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct >> dma_chan *chan) >> return -ENOMEM; >> } >> >> - tasklet_init(>task, pl330_tasklet, (unsigned long) pch); >> - >> spin_unlock_irqrestore(>lock, flags); >> >> + tasklet_init(>task, pl330_tasklet, (unsigned long) pch); >> + >> return 1; >> } >> >> -- >> 1.9.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe dmaengine" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup
From: Anand Moon <linux.am...@gmail.com>
drop the spin_unlock/lock around uart_write_wakeup to protect
write wakeup for uart port.
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
changes logs: drop the previous approch of spin_unlock_irqrestore/save
---
drivers/tty/serial/samsung.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d72cd73..0cb70a9 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -758,11 +758,8 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
*id)
goto out;
}
- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
- spin_unlock(>lock);
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
- spin_lock(>lock);
- }
if (uart_circ_empty(xmit))
s3c24xx_serial_stop_tx(port);
--
1.9.1
[PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup
From: Anand Moon
drop the spin_unlock/lock around uart_write_wakeup to protect
write wakeup for uart port.
Signed-off-by: Anand Moon
---
changes logs: drop the previous approch of spin_unlock_irqrestore/save
---
drivers/tty/serial/samsung.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d72cd73..0cb70a9 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -758,11 +758,8 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
*id)
goto out;
}
- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
- spin_unlock(>lock);
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
- spin_lock(>lock);
- }
if (uart_circ_empty(xmit))
s3c24xx_serial_stop_tx(port);
--
1.9.1
Re: [PATCH] serial: samsung: fix the inconsistency in spinlock
Hi Peter,
On 18 February 2016 at 23:18, Peter Hurley <pe...@hurleysoftware.com> wrote:
> Hi Anand,
>
> On 02/18/2016 09:40 AM, Anand Moon wrote:
>> From: Anand Moon <linux.am...@gmail.com>
>>
>> changes fix the correct order of the spin_lock_irqrestore/save.
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>> ---
>> drivers/tty/serial/samsung.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index d72cd73..96fe14d 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
>> *id)
>> }
>>
>> if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>> - spin_unlock(>lock);
>> + spin_unlock_irqrestore(>lock, flags);
>> uart_write_wakeup(port);
>> - spin_lock(>lock);
>> + spin_lock_irqsave(>lock, flags);
>
> This driver shouldn't be dropping the spin lock at for write wakeup.
> If this is causing lock-ups in a line discipline, the line discipline
> needs fixed.
>
Thanks for pointing out.
Their is no lock up, just the inconstancy of the spin_lock.
Then I will resend this patch dropping the spin_unlock/spin_lock
around uart_write_wakeup.
Is that ok with you.
> Regards,
> Peter Hurley
>
>
>> }
>>
>> if (uart_circ_empty(xmit))
>>
>
Best Regards
-Anand Moon
Re: [PATCH] serial: samsung: fix the inconsistency in spinlock
Hi Peter,
On 18 February 2016 at 23:18, Peter Hurley wrote:
> Hi Anand,
>
> On 02/18/2016 09:40 AM, Anand Moon wrote:
>> From: Anand Moon
>>
>> changes fix the correct order of the spin_lock_irqrestore/save.
>>
>> Signed-off-by: Anand Moon
>> ---
>> drivers/tty/serial/samsung.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index d72cd73..96fe14d 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
>> *id)
>> }
>>
>> if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
>> - spin_unlock(>lock);
>> + spin_unlock_irqrestore(>lock, flags);
>> uart_write_wakeup(port);
>> - spin_lock(>lock);
>> + spin_lock_irqsave(>lock, flags);
>
> This driver shouldn't be dropping the spin lock at for write wakeup.
> If this is causing lock-ups in a line discipline, the line discipline
> needs fixed.
>
Thanks for pointing out.
Their is no lock up, just the inconstancy of the spin_lock.
Then I will resend this patch dropping the spin_unlock/spin_lock
around uart_write_wakeup.
Is that ok with you.
> Regards,
> Peter Hurley
>
>
>> }
>>
>> if (uart_circ_empty(xmit))
>>
>
Best Regards
-Anand Moon
[PATCH] serial: samsung: fix the inconsistency in spinlock
From: Anand Moon <linux.am...@gmail.com>
changes fix the correct order of the spin_lock_irqrestore/save.
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
drivers/tty/serial/samsung.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d72cd73..96fe14d 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
*id)
}
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
uart_write_wakeup(port);
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
}
if (uart_circ_empty(xmit))
--
1.9.1
[PATCH] serial: samsung: fix the inconsistency in spinlock
From: Anand Moon
changes fix the correct order of the spin_lock_irqrestore/save.
Signed-off-by: Anand Moon
---
drivers/tty/serial/samsung.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d72cd73..96fe14d 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -759,9 +759,9 @@ static irqreturn_t s3c24xx_serial_tx_chars(int irq, void
*id)
}
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS) {
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, flags);
uart_write_wakeup(port);
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, flags);
}
if (uart_circ_empty(xmit))
--
1.9.1
[PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore
From: Anand Moon <linux.am...@gmail.com> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking. It's safe to initialize pl330_tasklet tasklet after release of the locking. Signed-off-by: Anand Moon <linux.am...@gmail.com> --- drivers/dma/pl330.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 17ee758..df2cab1 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct dma_chan *chan) return -ENOMEM; } - tasklet_init(>task, pl330_tasklet, (unsigned long) pch); - spin_unlock_irqrestore(>lock, flags); + tasklet_init(>task, pl330_tasklet, (unsigned long) pch); + return 1; } -- 1.9.1
[PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore
From: Anand Moon pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ locking. It's safe to initialize pl330_tasklet tasklet after release of the locking. Signed-off-by: Anand Moon --- drivers/dma/pl330.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index 17ee758..df2cab1 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2091,10 +2091,10 @@ static int pl330_alloc_chan_resources(struct dma_chan *chan) return -ENOMEM; } - tasklet_init(>task, pl330_tasklet, (unsigned long) pch); - spin_unlock_irqrestore(>lock, flags); + tasklet_init(>task, pl330_tasklet, (unsigned long) pch); + return 1; } -- 1.9.1
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
Hi Krzysztof
On 18 February 2016 at 07:17, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 18.02.2016 04:53, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 17 February 2016 at 12:25, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
>>> be easily overheated when launching eight CPU-intensive tasks:
>>> thermal thermal_zone3: critical temperature reached(121 C),shutting
>>> down
>>>
>>> This seems to be specific to Odroid XU3-Lite board which officially
>>> supports lower frequencies than regular XU3 or XU4. When working at
>>> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
>>> longer time, the fan fails to cool down the board and it reaches
>>> critical temperature.
>>>
>>> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
>>> degrees of Celsius, the board will slow down by 3 steps (around
>>> 1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41
>>> +++
>>> 1 file changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> index 2b289d7c0d13..66073ce29aee 100644
>>> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> @@ -34,6 +34,16 @@
>>> hysteresis = <5000>; /*
>>> millicelsius */
>>> type = "active";
>>> };
>>> + cpu_alert3: cpu-alert-3 {
>>> + temperature = <95000>; /*
>>> millicelsius */
>>> + hysteresis = <5000>; /*
>>> millicelsius */
>>> + type = "passive";
>>> + };
>>> + cpu_alert4: cpu-alert-4 {
>>> + temperature = <11>; /*
>>> millicelsius */
>>> + hysteresis = <5000>; /*
>>> millicelsius */
>>> + type = "passive";
>>> + };
>>> cpu_crit0: cpu-crit-0 {
>>> temperature = <12>; /*
>>> millicelsius */
>>> hysteresis = <0>; /* millicelsius */
>>> @@ -53,6 +63,37 @@
>>> trip = <_alert2>;
>>> cooling-device = < 2 3>;
>>> };
>>> +
>>> + /*
>>> +* When reaching cpu_alert3, reduce CPU
>>> +* by 3 steps. On Exynos5422/5800 that would
>>> +* be: 1400 MHz and 1000 MHz.
>>> +*/
>>> + map3 {
>>> +trip = <_alert3>;
>>> +cooling-device = < 3 3>;
>>> + };
>>> + map4 {
>>> +trip = <_alert3>;
>>> +cooling-device = < 3 3>;
>>> + };
>>> +
>>> + /*
>>> +* When reaching cpu_alert4, reduce CPU
>>> +* to 600 MHz (11 steps for big, 7 steps for
>>> +* LITTLE).
>>> +* Exynos5420 has less OPPs and reversed
>>> +* numbering of CPUs (big/LITTLE) so this
>>> +* would not match.
>>> +*/
>>> + map5 {
>>> +trip = <_ale
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
Hi Krzysztof
On 18 February 2016 at 07:17, Krzysztof Kozlowski
wrote:
> On 18.02.2016 04:53, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 17 February 2016 at 12:25, Krzysztof Kozlowski
>> wrote:
>>> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
>>> be easily overheated when launching eight CPU-intensive tasks:
>>> thermal thermal_zone3: critical temperature reached(121 C),shutting
>>> down
>>>
>>> This seems to be specific to Odroid XU3-Lite board which officially
>>> supports lower frequencies than regular XU3 or XU4. When working at
>>> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
>>> longer time, the fan fails to cool down the board and it reaches
>>> critical temperature.
>>>
>>> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
>>> degrees of Celsius, the board will slow down by 3 steps (around
>>> 1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>> ---
>>> arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41
>>> +++
>>> 1 file changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> index 2b289d7c0d13..66073ce29aee 100644
>>> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> @@ -34,6 +34,16 @@
>>> hysteresis = <5000>; /*
>>> millicelsius */
>>> type = "active";
>>> };
>>> + cpu_alert3: cpu-alert-3 {
>>> + temperature = <95000>; /*
>>> millicelsius */
>>> + hysteresis = <5000>; /*
>>> millicelsius */
>>> + type = "passive";
>>> + };
>>> + cpu_alert4: cpu-alert-4 {
>>> + temperature = <11>; /*
>>> millicelsius */
>>> + hysteresis = <5000>; /*
>>> millicelsius */
>>> + type = "passive";
>>> + };
>>> cpu_crit0: cpu-crit-0 {
>>> temperature = <12>; /*
>>> millicelsius */
>>> hysteresis = <0>; /* millicelsius */
>>> @@ -53,6 +63,37 @@
>>> trip = <_alert2>;
>>> cooling-device = < 2 3>;
>>> };
>>> +
>>> + /*
>>> +* When reaching cpu_alert3, reduce CPU
>>> +* by 3 steps. On Exynos5422/5800 that would
>>> +* be: 1400 MHz and 1000 MHz.
>>> +*/
>>> + map3 {
>>> +trip = <_alert3>;
>>> +cooling-device = < 3 3>;
>>> + };
>>> + map4 {
>>> +trip = <_alert3>;
>>> +cooling-device = < 3 3>;
>>> + };
>>> +
>>> + /*
>>> +* When reaching cpu_alert4, reduce CPU
>>> +* to 600 MHz (11 steps for big, 7 steps for
>>> +* LITTLE).
>>> +* Exynos5420 has less OPPs and reversed
>>> +* numbering of CPUs (big/LITTLE) so this
>>> +* would not match.
>>> +*/
>>> + map5 {
>>> +trip = <_alert4>;
>>> + cooling-device = < 7 7>;
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
Hi Viresh, On 18 February 2016 at 08:06, Viresh Kumar <viresh.ku...@linaro.org> wrote: > On 18-02-16, 10:47, Krzysztof Kozlowski wrote: >> On 18.02.2016 04:53, Anand Moon wrote: >> > I also got lot's of error. >> > >> > root@odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19 >> > [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create >> > link >> > [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs >> > (-12) >> > [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create >> > link >> > [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs >> > (-12) >> > [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2 >> > [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2 >> > [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2 >> > >> > Tested on Odroid-XU4 >> > >> > Reviewed-by: Anand Moon <linux.am...@gmail.com> >> > Tested-by: Anand Moon <linux.am...@gmail.com> > > What was this Tested-by supposed to mean? You got errors out there ... > I had done some stress testing, as pointed by Krzysztof. I got myself in two minds on this part, please don't consider the Tested-by and Reviewed-by part. Thanks for pointing out. -Anand Moon >> The patch is not sufficient. It does not work the way it should... >> >> BTW, I found the issue. The order of trip points in DT: >> thermal_zone0/trip_point_0_hyst:5000 >> thermal_zone0/trip_point_0_temp:5 >> thermal_zone0/trip_point_0_type:active >> thermal_zone0/trip_point_1_hyst:5000 >> thermal_zone0/trip_point_1_temp:6 >> thermal_zone0/trip_point_1_type:active >> thermal_zone0/trip_point_2_hyst:5000 >> thermal_zone0/trip_point_2_temp:7 >> thermal_zone0/trip_point_2_type:active >> thermal_zone0/trip_point_3_hyst:0 >> thermal_zone0/trip_point_3_temp:12< this should be last one! >> thermal_zone0/trip_point_3_type:critical >> thermal_zone0/trip_point_4_hyst:5000 >> thermal_zone0/trip_point_4_temp:9 >> thermal_zone0/trip_point_4_type:passive >> thermal_zone0/trip_point_5_hyst:5000 >> thermal_zone0/trip_point_5_temp:11 >> thermal_zone0/trip_point_5_type:passive >> >> After fixing the order in DT, the cpu cooler starts working. > > Ahh, nice. > > -- > viresh
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
Hi Viresh, On 18 February 2016 at 08:06, Viresh Kumar wrote: > On 18-02-16, 10:47, Krzysztof Kozlowski wrote: >> On 18.02.2016 04:53, Anand Moon wrote: >> > I also got lot's of error. >> > >> > root@odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19 >> > [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create >> > link >> > [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs >> > (-12) >> > [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create >> > link >> > [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs >> > (-12) >> > [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2 >> > [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2 >> > [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2 >> > >> > Tested on Odroid-XU4 >> > >> > Reviewed-by: Anand Moon >> > Tested-by: Anand Moon > > What was this Tested-by supposed to mean? You got errors out there ... > I had done some stress testing, as pointed by Krzysztof. I got myself in two minds on this part, please don't consider the Tested-by and Reviewed-by part. Thanks for pointing out. -Anand Moon >> The patch is not sufficient. It does not work the way it should... >> >> BTW, I found the issue. The order of trip points in DT: >> thermal_zone0/trip_point_0_hyst:5000 >> thermal_zone0/trip_point_0_temp:5 >> thermal_zone0/trip_point_0_type:active >> thermal_zone0/trip_point_1_hyst:5000 >> thermal_zone0/trip_point_1_temp:6 >> thermal_zone0/trip_point_1_type:active >> thermal_zone0/trip_point_2_hyst:5000 >> thermal_zone0/trip_point_2_temp:7 >> thermal_zone0/trip_point_2_type:active >> thermal_zone0/trip_point_3_hyst:0 >> thermal_zone0/trip_point_3_temp:12< this should be last one! >> thermal_zone0/trip_point_3_type:critical >> thermal_zone0/trip_point_4_hyst:5000 >> thermal_zone0/trip_point_4_temp:9 >> thermal_zone0/trip_point_4_type:passive >> thermal_zone0/trip_point_5_hyst:5000 >> thermal_zone0/trip_point_5_temp:11 >> thermal_zone0/trip_point_5_type:passive >> >> After fixing the order in DT, the cpu cooler starts working. > > Ahh, nice. > > -- > viresh
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
cpu0_thermal: cpu0-thermal {
thermal-sensors = <_cpu0 0>;
- polling-delay-passive = <0>;
- polling-delay = <0>;
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <500>; /* milliseconds */
trips {
cpu_alert0: cpu-alert-0 {
temperature = <5>; /*
millicelsius */
---
On running linaro pm-qa diagnostic tool
--
thermal_01.28: checking 'thermal_zone2'/'trip_point_2_temp' ='11'...Ok
thermal_01.29: checking 'cdev0_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.30: checking 'thermal_zone0/cdev0_trip_point' valid binding... Ok
thermal_01.31: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.32: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.33: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.34: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.35: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.36: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.37: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.38: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01: fail
---
I also got lot's of error.
root@odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
[ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
[ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
[ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
[ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
[ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
Tested on Odroid-XU4
Reviewed-by: Anand Moon <linux.am...@gmail.com>
Tested-by: Anand Moon <linux.am...@gmail.com>
Best Regards
-Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
= <_cpu0 0>;
- polling-delay-passive = <0>;
- polling-delay = <0>;
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <500>; /* milliseconds */
trips {
cpu_alert0: cpu-alert-0 {
temperature = <5>; /*
millicelsius */
---
On running linaro pm-qa diagnostic tool
--
thermal_01.28: checking 'thermal_zone2'/'trip_point_2_temp' ='11'...Ok
thermal_01.29: checking 'cdev0_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.30: checking 'thermal_zone0/cdev0_trip_point' valid binding... Ok
thermal_01.31: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.32: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.33: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.34: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.35: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.36: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01.37: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.38: checking 'thermal_zone0/cdev4_trip_point' valid binding... Err
thermal_01: fail
---
I also got lot's of error.
root@odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
[ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
[ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
[ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
[ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
[ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
Tested on Odroid-XU4
Reviewed-by: Anand Moon
Tested-by: Anand Moon
Best Regards
-Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pwm: avoid holding mutex in interrupt context
Hi Thierry,
On 20 January 2016 at 20:02, Thierry Reding wrote:
> On Wed, Jan 20, 2016 at 08:29:58AM +0900, Krzysztof Kozlowski wrote:
>> On 20.01.2016 00:04, Anand Moon wrote:
>> > Hi Krzysztof,
>> >
>> > On 18 January 2016 at 09:58, Krzysztof Kozlowski
>> >>> Already within function pwm_samsung_set_invert is protected by
>> >>> spin_lock_irqsave(_pwm_lock, flags);
>> >>>
>> >>> So no need to introduce another lock to control pwm_samsung_set_polarity.
>> >>>
>> >>> Best Regards.
>> >>> -Anand Moon
>> >>
>> >> I don't have any clue what is your point here. I don't get what
>> >> pwm_samsung_set_polarity has to do with main pwm core...
>> >>
>> >> Sorry, you need to be more specific.
>> >>
>> >> Best regards,
>> >> Krzysztof
>> >>
>> >>
>> >
>> > Below is the mapping of calls from pwm driver.
>> > I have tried to map the functionality and I am trying to understand
>> > the flow of the driver.
>> >
>> > Also looking in document
>> >
>> > https://www.kernel.org/doc/Documentation/pwm.txt
>> >
>> > pwm-samsung driver controls the LEDS, fans...etc
>> >
>> > Form the dts modes pwmleds
>> >
>> > pwmleds {
>> > compatible = "pwm-leds";
>> >
>> > blueled {
>> > label = "blue:heartbeat";
>> > pwms = < 2 200 0>;
>> > pwm-names = "pwm2";
>> > max_brightness = <255>;
>> > linux,default-trigger = "heartbeat";
>> > };
>> > };
>> >
>> > Following is the map out from the device tree.
>> >
>> > pwms = < 2 200 0>;
>> >
>> >-> pwm: pwm@12dd --->samsung,exynos4210-pwm
>> > 2 -> period
>> > 200-> duty_cycle
>> > 0 -> polarity
>>
>> I do not see any relations between DTS and the problem.
>>
>> >
>> > And here is the mapping of the call of function
>> > Note: This function call are as per my understanding of the flow in
>> > the driver. I might be wrong.
>> >
>> > pwm_samsung_set_polarity(struct pwm_chip *chip, struct pwm_device
>> > *pwm, enum pwm_polarity polarity)
>> > \
>> > pwm_samsung_set_invert(our_chip, pwm->hwpwm, invert);
>> > \
>> > pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
>>
>> No, pwm_samsung_set_invert does not call pwm_set_polarity(). This would
>> result in a circular call - back to pwm_samsung_set_polarity().
>>
>> > \
>> >pwm->chip->ops->set_polarity(pwm->chip, pwm, polarity);
>> > \
>> > pwm_enable(struct pwm_device *pwm) or pwm_disable(struct pwm_device
>> > *pwm)
>> >
>> > pwm_enable or pwm_disable will be triggered on change in pwm->flags by
>> > the pwm core.
>> > before pwm_set_polarity is called form the Samsung driver it hold with
>> > following locks
>> >
>> > Here is the locking
>> >
>> > pwm_samsung_set_polarity(struct pwm_chip *chip, struct pwm_device
>> > *pwm, enum pwm_polarity polarity)
>> > \
>> > pwm_samsung_set_invert(struct samsung_pwm_chip *chip, unsigned int
>> > channel, bool invert)
>> > \
>> > spin_lock_irqsave(_pwm_lock, flags);
>> > \
>> >pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
>> >\
>> > mutex_lock(>lock)
>> >
>> > pwm_enable(struct pwm_device *pwm) or pwm_disable(struct
>> > pwm_device *pwm)
>> > \
>> >mutex_lock(>lock);
>> >
>> > Problem I see that we are holding the lock in interrupt context.
>> > I don't know how the this triggers this bug.
>> >
>> > BUG: sleeping function called from invalid context at
>> > kernel/locking/mutex.c:97
>>
>> So leave it. If your flow of calls was correct, you would spot the
>> problem. But actually it does not matter - I think the flow is not correct.
>
> The reason for the BUG that you're seeing is that the leds-pwm driver
> differentiates betwe
Re: [PATCHv2] pwm: avoid holding mutex in interrupt context
Hi Thierry,
On 20 January 2016 at 20:02, Thierry Reding <thierry.red...@gmail.com> wrote:
> On Wed, Jan 20, 2016 at 08:29:58AM +0900, Krzysztof Kozlowski wrote:
>> On 20.01.2016 00:04, Anand Moon wrote:
>> > Hi Krzysztof,
>> >
>> > On 18 January 2016 at 09:58, Krzysztof Kozlowski
>> >>> Already within function pwm_samsung_set_invert is protected by
>> >>> spin_lock_irqsave(_pwm_lock, flags);
>> >>>
>> >>> So no need to introduce another lock to control pwm_samsung_set_polarity.
>> >>>
>> >>> Best Regards.
>> >>> -Anand Moon
>> >>
>> >> I don't have any clue what is your point here. I don't get what
>> >> pwm_samsung_set_polarity has to do with main pwm core...
>> >>
>> >> Sorry, you need to be more specific.
>> >>
>> >> Best regards,
>> >> Krzysztof
>> >>
>> >>
>> >
>> > Below is the mapping of calls from pwm driver.
>> > I have tried to map the functionality and I am trying to understand
>> > the flow of the driver.
>> >
>> > Also looking in document
>> >
>> > https://www.kernel.org/doc/Documentation/pwm.txt
>> >
>> > pwm-samsung driver controls the LEDS, fans...etc
>> >
>> > Form the dts modes pwmleds
>> >
>> > pwmleds {
>> > compatible = "pwm-leds";
>> >
>> > blueled {
>> > label = "blue:heartbeat";
>> > pwms = < 2 200 0>;
>> > pwm-names = "pwm2";
>> > max_brightness = <255>;
>> > linux,default-trigger = "heartbeat";
>> > };
>> > };
>> >
>> > Following is the map out from the device tree.
>> >
>> > pwms = < 2 200 0>;
>> >
>> >-> pwm: pwm@12dd --->samsung,exynos4210-pwm
>> > 2 -> period
>> > 200-> duty_cycle
>> > 0 -> polarity
>>
>> I do not see any relations between DTS and the problem.
>>
>> >
>> > And here is the mapping of the call of function
>> > Note: This function call are as per my understanding of the flow in
>> > the driver. I might be wrong.
>> >
>> > pwm_samsung_set_polarity(struct pwm_chip *chip, struct pwm_device
>> > *pwm, enum pwm_polarity polarity)
>> > \
>> > pwm_samsung_set_invert(our_chip, pwm->hwpwm, invert);
>> > \
>> > pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
>>
>> No, pwm_samsung_set_invert does not call pwm_set_polarity(). This would
>> result in a circular call - back to pwm_samsung_set_polarity().
>>
>> > \
>> >pwm->chip->ops->set_polarity(pwm->chip, pwm, polarity);
>> > \
>> > pwm_enable(struct pwm_device *pwm) or pwm_disable(struct pwm_device
>> > *pwm)
>> >
>> > pwm_enable or pwm_disable will be triggered on change in pwm->flags by
>> > the pwm core.
>> > before pwm_set_polarity is called form the Samsung driver it hold with
>> > following locks
>> >
>> > Here is the locking
>> >
>> > pwm_samsung_set_polarity(struct pwm_chip *chip, struct pwm_device
>> > *pwm, enum pwm_polarity polarity)
>> > \
>> > pwm_samsung_set_invert(struct samsung_pwm_chip *chip, unsigned int
>> > channel, bool invert)
>> > \
>> > spin_lock_irqsave(_pwm_lock, flags);
>> > \
>> >pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity)
>> >\
>> > mutex_lock(>lock)
>> >
>> > pwm_enable(struct pwm_device *pwm) or pwm_disable(struct
>> > pwm_device *pwm)
>> > \
>> >mutex_lock(>lock);
>> >
>> > Problem I see that we are holding the lock in interrupt context.
>> > I don't know how the this triggers this bug.
>> >
>> > BUG: sleeping function called from invalid context at
>> > kernel/locking/mutex.c:97
>>
>> So leave it. If your flow of calls was correct, you would spot the
>> problem. But actually it does not matter - I think the flow is not correct.
>
> The reason for the BUG that you're seeing is that t
Re: [PATCH 2/2] ARM: exynos_defconfig: Enable s5p-secss driver
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski wrote: > The Exynos SoC provides a Security SubSystem block for accelerating some > cryptographic operations. Enable the driver for it - s5p-secss to > utilize the hardware acceleration. > > Currently the s5p-secss driver supports AES in CBC and ECB modes. > However on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412) boards this > change introduces one booting error: > > alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: > ret=22 > > The cbc-aes-s5p properly registers itself and passes self-tests. > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/configs/exynos_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 0aee1e035be9..c47c7e069873 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -240,6 +240,7 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > +CONFIG_CRYPTO_DEV_S5P=y > CONFIG_ARM_CRYPTO=y > CONFIG_CRYPTO_SHA1_ARM_NEON=m > CONFIG_CRYPTO_SHA256_ARM=m > -- > 1.9.1 > Reviewed-by: Anand Moon Best Regards, -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski wrote: > Enable the kernel NEON mode and asm/NEON accelerated crypto algorithms > which should bring performance benefits on Exynos SoCs. Enable these as > modules because they are optional, not essential anyhow for platform > booting nor related directly to Exynos Soc. All accelerated algorithms > pass booting self-tests on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412). > > Additionally enable cpufreq statistics as they are useful for debugging. > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/configs/exynos_defconfig | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 24dcd2bb1215..0aee1e035be9 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -26,12 +26,14 @@ CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M > console=ttySAC1,115200 init=/linuxrc mem=256M" > CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_STAT_DETAILS=y > CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > CONFIG_CPUFREQ_DT=y > CONFIG_CPU_IDLE=y > CONFIG_ARM_EXYNOS_CPUIDLE=y > CONFIG_VFP=y > CONFIG_NEON=y > +CONFIG_KERNEL_MODE_NEON=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > @@ -238,7 +240,11 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > -CONFIG_CRYPTO_SHA256=y > +CONFIG_ARM_CRYPTO=y > +CONFIG_CRYPTO_SHA1_ARM_NEON=m > +CONFIG_CRYPTO_SHA256_ARM=m > +CONFIG_CRYPTO_SHA512_ARM=m > +CONFIG_CRYPTO_AES_ARM_BS=m > CONFIG_CRC_CCITT=y > CONFIG_FONTS=y > CONFIG_FONT_7x14=y > -- > 1.9.1 > Reviewed-by: Anand Moon Best Regards, -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: exynos_defconfig: Enable s5p-secss driver
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > The Exynos SoC provides a Security SubSystem block for accelerating some > cryptographic operations. Enable the driver for it - s5p-secss to > utilize the hardware acceleration. > > Currently the s5p-secss driver supports AES in CBC and ECB modes. > However on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412) boards this > change introduces one booting error: > > alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: > ret=22 > > The cbc-aes-s5p properly registers itself and passes self-tests. > > Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> > --- > arch/arm/configs/exynos_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 0aee1e035be9..c47c7e069873 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -240,6 +240,7 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > +CONFIG_CRYPTO_DEV_S5P=y > CONFIG_ARM_CRYPTO=y > CONFIG_CRYPTO_SHA1_ARM_NEON=m > CONFIG_CRYPTO_SHA256_ARM=m > -- > 1.9.1 > Reviewed-by: Anand Moon <linux.am...@gmail.com> Best Regards, -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats
Hi Krzysztof, On 7 January 2016 at 07:45, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > Enable the kernel NEON mode and asm/NEON accelerated crypto algorithms > which should bring performance benefits on Exynos SoCs. Enable these as > modules because they are optional, not essential anyhow for platform > booting nor related directly to Exynos Soc. All accelerated algorithms > pass booting self-tests on Odroid XU4 (Exynos5422) and Trats2 (Exynos4412). > > Additionally enable cpufreq statistics as they are useful for debugging. > > Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> > --- > arch/arm/configs/exynos_defconfig | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 24dcd2bb1215..0aee1e035be9 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -26,12 +26,14 @@ CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M > console=ttySAC1,115200 init=/linuxrc mem=256M" > CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_STAT_DETAILS=y > CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y > CONFIG_CPUFREQ_DT=y > CONFIG_CPU_IDLE=y > CONFIG_ARM_EXYNOS_CPUIDLE=y > CONFIG_VFP=y > CONFIG_NEON=y > +CONFIG_KERNEL_MODE_NEON=y > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > @@ -238,7 +240,11 @@ CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_USER=y > -CONFIG_CRYPTO_SHA256=y > +CONFIG_ARM_CRYPTO=y > +CONFIG_CRYPTO_SHA1_ARM_NEON=m > +CONFIG_CRYPTO_SHA256_ARM=m > +CONFIG_CRYPTO_SHA512_ARM=m > +CONFIG_CRYPTO_AES_ARM_BS=m > CONFIG_CRC_CCITT=y > CONFIG_FONTS=y > CONFIG_FONT_7x14=y > -- > 1.9.1 > Reviewed-by: Anand Moon <linux.am...@gmail.com> Best Regards, -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: genpd: fix lockdep issue for all subdomains
Hi Marek,
On 4 January 2016 at 16:09, Marek Szyprowski wrote:
> During genpd_poweron, genpd->lock is acquired recursively for each
> parent (master) domain, which are separate obejcts. This confuses
> lockdep, which considers every operation on genpd->lock as being done on
> the same lock class. This leads to the following false positive warning:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.4.0-rc4-xu3s #32 Not tainted
> -
> swapper/0/1 is trying to acquire lock:
> (>lock){+.+...}, at: [] __genpd_poweron+0x64/0x108
>
> but task is already holding lock:
> (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(>lock);
> lock(>lock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by swapper/0/1:
> #0: (>mutex){..}, at: [] __driver_attach+0x48/0x98
> #1: (>mutex){..}, at: [] __driver_attach+0x58/0x98
> #2: (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> stack backtrace:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0xc4)
> [] (dump_stack) from [] (__lock_acquire+0x1f88/0x215c)
> [] (__lock_acquire) from [] (lock_acquire+0xa4/0xd0)
> [] (lock_acquire) from [] (mutex_lock_nested+0x70/0x4d4)
> [] (mutex_lock_nested) from []
> (__genpd_poweron+0x64/0x108)
> [] (__genpd_poweron) from []
> (genpd_dev_pm_attach+0x170/0x1b8)
> [] (genpd_dev_pm_attach) from []
> (platform_drv_probe+0x2c/0xac)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x208/0x2fc)
> [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from []
> (exynos_drm_register_drivers+0x28/0x74)
> [] (exynos_drm_register_drivers) from []
> (exynos_drm_init+0x6c/0xc4)
> [] (exynos_drm_init) from [] (do_one_initcall+0x90/0x1dc)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x158/0x1f8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
>
> This patch replaces mutex_lock with mutex_lock_nested() and uses
> recursion depth to annotate each genpd->lock operation with separate
> lockdep subclass.
>
> Reported-by: Anand Moon
> Signed-off-by: Marek Szyprowski
> ---
> drivers/base/power/domain.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index b803790..e02ddf6 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -170,16 +170,15 @@ static void genpd_queue_power_off_work(struct
> generic_pm_domain *genpd)
> queue_work(pm_wq, >power_off_work);
> }
>
> -static int genpd_poweron(struct generic_pm_domain *genpd);
> -
> /**
> * __genpd_poweron - Restore power to a given PM domain and its masters.
> * @genpd: PM domain to power up.
> + * @depth: nesting count for lockdep.
> *
> * Restore power to @genpd and all of its masters so that it is possible to
> * resume a device belonging to it.
> */
> -static int __genpd_poweron(struct generic_pm_domain *genpd)
> +static int __genpd_poweron(struct generic_pm_domain *genpd, unsigned int
> depth)
> {
> struct gpd_link *link;
> int ret = 0;
> @@ -194,11 +193,16 @@ static int __genpd_poweron(struct generic_pm_domain
> *genpd)
> * with it.
> */
> list_for_each_entry(link, >slave_links, slave_node) {
> - genpd_sd_counter_inc(link->master);
> + struct generic_pm_domain *master = link->master;
> +
> + genpd_sd_counter_inc(master);
> +
> + mutex_lock_nested(>lock, depth + 1);
> + ret = __genpd_poweron(master, depth + 1);
> + mutex_unlock(>lock);
>
> - ret = genpd_poweron(link->master);
> if (ret) {
> - genpd_sd_counter_dec(link->master);
> + genpd_sd_counter_dec(master);
> goto err;
> }
> }
> @@ -230,11 +234,12 @@ static int genpd_poweron(struct generic_pm_domain
>
Re: [PATCH] power: genpd: fix lockdep issue for all subdomains
Hi Marek,
On 4 January 2016 at 16:09, Marek Szyprowski <m.szyprow...@samsung.com> wrote:
> During genpd_poweron, genpd->lock is acquired recursively for each
> parent (master) domain, which are separate obejcts. This confuses
> lockdep, which considers every operation on genpd->lock as being done on
> the same lock class. This leads to the following false positive warning:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.4.0-rc4-xu3s #32 Not tainted
> -
> swapper/0/1 is trying to acquire lock:
> (>lock){+.+...}, at: [] __genpd_poweron+0x64/0x108
>
> but task is already holding lock:
> (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(>lock);
> lock(>lock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by swapper/0/1:
> #0: (>mutex){..}, at: [] __driver_attach+0x48/0x98
> #1: (>mutex){..}, at: [] __driver_attach+0x58/0x98
> #2: (>lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
>
> stack backtrace:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0xc4)
> [] (dump_stack) from [] (__lock_acquire+0x1f88/0x215c)
> [] (__lock_acquire) from [] (lock_acquire+0xa4/0xd0)
> [] (lock_acquire) from [] (mutex_lock_nested+0x70/0x4d4)
> [] (mutex_lock_nested) from []
> (__genpd_poweron+0x64/0x108)
> [] (__genpd_poweron) from []
> (genpd_dev_pm_attach+0x170/0x1b8)
> [] (genpd_dev_pm_attach) from []
> (platform_drv_probe+0x2c/0xac)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x208/0x2fc)
> [] (driver_probe_device) from []
> (__driver_attach+0x94/0x98)
> [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from []
> (exynos_drm_register_drivers+0x28/0x74)
> [] (exynos_drm_register_drivers) from []
> (exynos_drm_init+0x6c/0xc4)
> [] (exynos_drm_init) from [] (do_one_initcall+0x90/0x1dc)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x158/0x1f8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
>
> This patch replaces mutex_lock with mutex_lock_nested() and uses
> recursion depth to annotate each genpd->lock operation with separate
> lockdep subclass.
>
> Reported-by: Anand Moon <linux.am...@gmail.com>
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> ---
> drivers/base/power/domain.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index b803790..e02ddf6 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -170,16 +170,15 @@ static void genpd_queue_power_off_work(struct
> generic_pm_domain *genpd)
> queue_work(pm_wq, >power_off_work);
> }
>
> -static int genpd_poweron(struct generic_pm_domain *genpd);
> -
> /**
> * __genpd_poweron - Restore power to a given PM domain and its masters.
> * @genpd: PM domain to power up.
> + * @depth: nesting count for lockdep.
> *
> * Restore power to @genpd and all of its masters so that it is possible to
> * resume a device belonging to it.
> */
> -static int __genpd_poweron(struct generic_pm_domain *genpd)
> +static int __genpd_poweron(struct generic_pm_domain *genpd, unsigned int
> depth)
> {
> struct gpd_link *link;
> int ret = 0;
> @@ -194,11 +193,16 @@ static int __genpd_poweron(struct generic_pm_domain
> *genpd)
> * with it.
> */
> list_for_each_entry(link, >slave_links, slave_node) {
> - genpd_sd_counter_inc(link->master);
> + struct generic_pm_domain *master = link->master;
> +
> + genpd_sd_counter_inc(master);
> +
> + mutex_lock_nested(>lock, depth + 1);
> + ret = __genpd_poweron(master, depth + 1);
> + mutex_unlock(>lock);
>
> - ret = genpd_poweron(link->master);
> if (ret) {
> - genpd_sd_counter_dec(link->master);
> + genpd_sd_counter_dec(master);
> goto err;
> }
>
Re: Odroid U3 mutex deadlock.
Hi Krzysztof
On 14 December 2015 at 05:15, Krzysztof Kozlowski
wrote:
> On 12.12.2015 13:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>
> This is not a deadlock yet, just a report from lockdep. Could be a real
> issue, could be false positive, maybe some locks miss nesting annotations.
>
> Typical information for bug report would be useful, like the exact
> version (it is mentioned in lockdep report but is it really correct?)
> and reproducibility. And of course git-bisect would be nice to have, see:
> Documentation/BUG-HUNTING
>
> Best regards,
> Krzysztof
>
>
Thanks for your inputs. I narrowed down to this commit.
--
commit ec459c0c77faca53cf161830cb264e51bb1abba6
Author: Marek Szyprowski
Date: Wed Feb 4 23:44:15 2015 +0900
ARM: dts: add dependency between TV and LCD0 power domains for exynos4
TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
This dependency is modelled by making TV power domains a sub-domain of
LCD0 power domain.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kukjin Kim
-
After reverting this I am not observing below lockdep warning report.
But after reverting this patch I observer another bug.
Best regards.
-Anand Moon
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [3.201396] [] (kernel_init_freeable) from []
>> (kernel_init+0x8/0xe8)
>> [3.209469] [] (kernel_i
Re: Odroid U3 mutex deadlock.
Hi Krzysztof
On 14 December 2015 at 05:15, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.12.2015 13:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>
> This is not a deadlock yet, just a report from lockdep. Could be a real
> issue, could be false positive, maybe some locks miss nesting annotations.
>
> Typical information for bug report would be useful, like the exact
> version (it is mentioned in lockdep report but is it really correct?)
> and reproducibility. And of course git-bisect would be nice to have, see:
> Documentation/BUG-HUNTING
>
> Best regards,
> Krzysztof
>
>
Thanks for your inputs. I narrowed down to this commit.
--
commit ec459c0c77faca53cf161830cb264e51bb1abba6
Author: Marek Szyprowski <m.szyprow...@samsung.com>
Date: Wed Feb 4 23:44:15 2015 +0900
ARM: dts: add dependency between TV and LCD0 power domains for exynos4
TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
This dependency is modelled by making TV power domains a sub-domain of
LCD0 power domain.
Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
Signed-off-by: Kukjin Kim <kg...@kernel.org>
-
After reverting this I am not observing below lockdep warning report.
But after reverting this patch I observer another bug.
Best regards.
-Anand Moon
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [
Re: Odroid U3 mutex deadlock.
Hi Thomas,
On 12 December 2015 at 16:58, Thomas Pietrowski wrote:
> I'm also using 4.4.0-rc4 here on my U3+. And so far it is working well. I
> just had a freeze yesterday, but I didn't had the UART connected, so
> couldn't catch the reason. The curious thing was that the heartbeat LED was
> still blinking, but USB keyboard and Ethernet/SSH (but LEDs still on) were
> not working.
>
> Could you upload your .config? Maybe it could be useful for others :)
>
> Regards
>
> Am 12.12.2015 05:33 schrieb "Anand Moon" :
>>
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>>
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s
>> #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [3.201396] [] (kernel_init_freeable) from []
>> (kernel_init+0x8/0xe8)
>> [3.209469] [] (kernel_init) from []
>> (ret_from_fork+0x14/0x24)
>> [3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
>> [3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO
>> lookup
>> [3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
>> property of node '/hdmi@12D0[0]'
>> [3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
>> node '/hdmi@12D0[0]' - status (0)
>> [ 3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
>> mixer_component_ops)
>> [3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
>> hdmi_component_ops)
>> [3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [3.269812] [drm] No driver support f
Re: Odroid U3 mutex deadlock.
Hi Thomas,
On 12 December 2015 at 16:58, Thomas Pietrowski <thopie...@gmail.com> wrote:
> I'm also using 4.4.0-rc4 here on my U3+. And so far it is working well. I
> just had a freeze yesterday, but I didn't had the UART connected, so
> couldn't catch the reason. The curious thing was that the heartbeat LED was
> still blinking, but USB keyboard and Ethernet/SSH (but LEDs still on) were
> not working.
>
> Could you upload your .config? Maybe it could be useful for others :)
>
> Regards
>
> Am 12.12.2015 05:33 schrieb "Anand Moon" <linux.am...@gmail.com>:
>>
>> Hi Krzysztof,
>>
>> I am just observing this deadlock om my Odroid U3.
>>
>> --
>>
>> [2.937531] =
>> [2.938733] [ INFO: possible recursive locking detected ]
>> [2.944117] 4.4.0-rc4-xu3s #32 Not tainted
>> [2.948195] -
>> [2.953577] swapper/0/1 is trying to acquire lock:
>> [2.958351] (>lock){+.+...}, at: []
>> __genpd_poweron+0x64/0x108
>> [2.965727]
>> [2.965727] but task is already holding lock:
>> [2.971543] (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [2.979355]
>> [2.979355] other info that might help us debug this:
>> [2.985865] Possible unsafe locking scenario:
>> [2.985865]
>> [2.991768]CPU0
>> [2.994198]
>> [2.996628] lock(>lock);
>> [2.26] lock(>lock);
>> [3.003225]
>> [3.003225] *** DEADLOCK ***
>> [3.003225]
>> [3.009128] May be due to missing lock nesting notation
>> [3.009128]
>> [3.015900] 3 locks held by swapper/0/1:
>> [3.019804] #0: (>mutex){..}, at: []
>> __driver_attach+0x48/0x98
>> [3.027442] #1: (>mutex){..}, at: []
>> __driver_attach+0x58/0x98
>> [3.035081] #2: (>lock){+.+...}, at: []
>> genpd_dev_pm_attach+0x168/0x1b8
>> [3.043326]
>> [3.043326] stack backtrace:
>> [3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s
>> #32
>> [3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.060444] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [3.068163] [] (show_stack) from []
>> (dump_stack+0x84/0xc4)
>> [3.075367] [] (dump_stack) from []
>> (__lock_acquire+0x1f88/0x215c)
>> [3.083262] [] (__lock_acquire) from []
>> (lock_acquire+0xa4/0xd0)
>> [3.090990] [] (lock_acquire) from []
>> (mutex_lock_nested+0x70/0x4d4)
>> [3.099061] [] (mutex_lock_nested) from []
>> (__genpd_poweron+0x64/0x108)
>> [3.107393] [] (__genpd_poweron) from []
>> (genpd_dev_pm_attach+0x170/0x1b8)
>> [3.115986] [] (genpd_dev_pm_attach) from []
>> (platform_drv_probe+0x2c/0xac)
>> [3.124667] [] (platform_drv_probe) from []
>> (driver_probe_device+0x208/0x2fc)
>> [3.133519] [] (driver_probe_device) from []
>> (__driver_attach+0x94/0x98)
>> [3.141939] [] (__driver_attach) from []
>> (bus_for_each_dev+0x68/0x9c)
>> [3.150097] [] (bus_for_each_dev) from []
>> (bus_add_driver+0x1a0/0x218)
>> [3.158344] [] (bus_add_driver) from []
>> (driver_register+0x78/0xf8)
>> [3.166330] [] (driver_register) from []
>> (exynos_drm_register_drivers+0x28/0x74)
>> [3.175441] [] (exynos_drm_register_drivers) from
>> [] (exynos_drm_init+0x6c/0xc4)
>> [3.184556] [] (exynos_drm_init) from []
>> (do_one_initcall+0x90/0x1dc)
>> [3.192718] [] (do_one_initcall) from []
>> (kernel_init_freeable+0x158/0x1f8)
>> [3.201396] [] (kernel_init_freeable) from []
>> (kernel_init+0x8/0xe8)
>> [3.209469] [] (kernel_init) from []
>> (ret_from_fork+0x14/0x24)
>> [3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
>> [3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO
>> lookup
>> [3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
>> property of node '/hdmi@12D0[0]'
>> [3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
>> node '/hdmi@12D0[0]' - status (0)
>> [3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
>> mixer_component_ops)
>> [3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
>> hdmi_component_ops)
>> [3.263245] [drm] Supports vblank timestamp cachi
Odroid U3 mutex deadlock.
Hi Krzysztof,
I am just observing this deadlock om my Odroid U3.
--
[2.937531] =
[2.938733] [ INFO: possible recursive locking detected ]
[2.944117] 4.4.0-rc4-xu3s #32 Not tainted
[2.948195] -
[2.953577] swapper/0/1 is trying to acquire lock:
[2.958351] (>lock){+.+...}, at: []
__genpd_poweron+0x64/0x108
[2.965727]
[2.965727] but task is already holding lock:
[2.971543] (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[2.979355]
[2.979355] other info that might help us debug this:
[2.985865] Possible unsafe locking scenario:
[2.985865]
[2.991768]CPU0
[2.994198]
[2.996628] lock(>lock);
[2.26] lock(>lock);
[3.003225]
[3.003225] *** DEADLOCK ***
[3.003225]
[3.009128] May be due to missing lock nesting notation
[3.009128]
[3.015900] 3 locks held by swapper/0/1:
[3.019804] #0: (>mutex){..}, at: []
__driver_attach+0x48/0x98
[3.027442] #1: (>mutex){..}, at: []
__driver_attach+0x58/0x98
[3.035081] #2: (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[3.043326]
[3.043326] stack backtrace:
[3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
[3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.060444] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.068163] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[3.075367] [] (dump_stack) from []
(__lock_acquire+0x1f88/0x215c)
[3.083262] [] (__lock_acquire) from []
(lock_acquire+0xa4/0xd0)
[3.090990] [] (lock_acquire) from []
(mutex_lock_nested+0x70/0x4d4)
[3.099061] [] (mutex_lock_nested) from []
(__genpd_poweron+0x64/0x108)
[3.107393] [] (__genpd_poweron) from []
(genpd_dev_pm_attach+0x170/0x1b8)
[3.115986] [] (genpd_dev_pm_attach) from []
(platform_drv_probe+0x2c/0xac)
[3.124667] [] (platform_drv_probe) from []
(driver_probe_device+0x208/0x2fc)
[3.133519] [] (driver_probe_device) from []
(__driver_attach+0x94/0x98)
[3.141939] [] (__driver_attach) from []
(bus_for_each_dev+0x68/0x9c)
[3.150097] [] (bus_for_each_dev) from []
(bus_add_driver+0x1a0/0x218)
[3.158344] [] (bus_add_driver) from []
(driver_register+0x78/0xf8)
[3.166330] [] (driver_register) from []
(exynos_drm_register_drivers+0x28/0x74)
[3.175441] [] (exynos_drm_register_drivers) from
[] (exynos_drm_init+0x6c/0xc4)
[3.184556] [] (exynos_drm_init) from []
(do_one_initcall+0x90/0x1dc)
[3.192718] [] (do_one_initcall) from []
(kernel_init_freeable+0x158/0x1f8)
[3.201396] [] (kernel_init_freeable) from []
(kernel_init+0x8/0xe8)
[3.209469] [] (kernel_init) from []
(ret_from_fork+0x14/0x24)
[3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
[3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO lookup
[3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
property of node '/hdmi@12D0[0]'
[3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
node '/hdmi@12D0[0]' - status (0)
[3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
mixer_component_ops)
[3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
hdmi_component_ops)
[3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.269812] [drm] No driver support for vblank timestamp query.
[3.323251] exynos-drm exynos-drm: fb0: frame buffer device
[3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
---
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Odroid U3 mutex deadlock.
Hi Krzysztof,
I am just observing this deadlock om my Odroid U3.
--
[2.937531] =
[2.938733] [ INFO: possible recursive locking detected ]
[2.944117] 4.4.0-rc4-xu3s #32 Not tainted
[2.948195] -
[2.953577] swapper/0/1 is trying to acquire lock:
[2.958351] (>lock){+.+...}, at: []
__genpd_poweron+0x64/0x108
[2.965727]
[2.965727] but task is already holding lock:
[2.971543] (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[2.979355]
[2.979355] other info that might help us debug this:
[2.985865] Possible unsafe locking scenario:
[2.985865]
[2.991768]CPU0
[2.994198]
[2.996628] lock(>lock);
[2.26] lock(>lock);
[3.003225]
[3.003225] *** DEADLOCK ***
[3.003225]
[3.009128] May be due to missing lock nesting notation
[3.009128]
[3.015900] 3 locks held by swapper/0/1:
[3.019804] #0: (>mutex){..}, at: []
__driver_attach+0x48/0x98
[3.027442] #1: (>mutex){..}, at: []
__driver_attach+0x58/0x98
[3.035081] #2: (>lock){+.+...}, at: []
genpd_dev_pm_attach+0x168/0x1b8
[3.043326]
[3.043326] stack backtrace:
[3.047671] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
[3.054351] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.060444] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.068163] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[3.075367] [] (dump_stack) from []
(__lock_acquire+0x1f88/0x215c)
[3.083262] [] (__lock_acquire) from []
(lock_acquire+0xa4/0xd0)
[3.090990] [] (lock_acquire) from []
(mutex_lock_nested+0x70/0x4d4)
[3.099061] [] (mutex_lock_nested) from []
(__genpd_poweron+0x64/0x108)
[3.107393] [] (__genpd_poweron) from []
(genpd_dev_pm_attach+0x170/0x1b8)
[3.115986] [] (genpd_dev_pm_attach) from []
(platform_drv_probe+0x2c/0xac)
[3.124667] [] (platform_drv_probe) from []
(driver_probe_device+0x208/0x2fc)
[3.133519] [] (driver_probe_device) from []
(__driver_attach+0x94/0x98)
[3.141939] [] (__driver_attach) from []
(bus_for_each_dev+0x68/0x9c)
[3.150097] [] (bus_for_each_dev) from []
(bus_add_driver+0x1a0/0x218)
[3.158344] [] (bus_add_driver) from []
(driver_register+0x78/0xf8)
[3.166330] [] (driver_register) from []
(exynos_drm_register_drivers+0x28/0x74)
[3.175441] [] (exynos_drm_register_drivers) from
[] (exynos_drm_init+0x6c/0xc4)
[3.184556] [] (exynos_drm_init) from []
(do_one_initcall+0x90/0x1dc)
[3.192718] [] (do_one_initcall) from []
(kernel_init_freeable+0x158/0x1f8)
[3.201396] [] (kernel_init_freeable) from []
(kernel_init+0x8/0xe8)
[3.209469] [] (kernel_init) from []
(ret_from_fork+0x14/0x24)
[3.217932] exynos-hdmi 12d0.hdmi: GPIO lookup for consumer hpd
[3.223293] exynos-hdmi 12d0.hdmi: using device tree for GPIO lookup
[3.229980] of_get_named_gpiod_flags: can't parse 'hpd-gpios'
property of node '/hdmi@12D0[0]'
[3.238945] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of
node '/hdmi@12D0[0]' - status (0)
[3.253430] exynos-drm exynos-drm: bound 12c1.mixer (ops
mixer_component_ops)
[3.256216] exynos-drm exynos-drm: bound 12d0.hdmi (ops
hdmi_component_ops)
[3.263245] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.269812] [drm] No driver support for vblank timestamp query.
[3.323251] exynos-drm exynos-drm: fb0: frame buffer device
[3.341464] [drm] Initialized exynos 1.0.0 20110530 on minor 0
---
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof
On 11 December 2015 at 09:53, Krzysztof Kozlowski
wrote:
> On 11.12.2015 13:07, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 22 November 2015 at 05:43, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>>>> Hi Krzysztof,
>
> [...]
>
>>> Yes, now you pasted the same warning I did...
>>>
>>> This is still the same issue. I already wrote it:
>>>> 1. BUG: sleeping function called from invalid context
>>>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> We can repeat it many times but that won't change anything...
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Would you consider below changes to fix the above issue.
>> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
>> And I don't observed issue.
>>
>> 1. BUG: sleeping function called from invalid context
>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> Please share your thought on this changes.
>>
>> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index d24ca5f..f3f6cf9 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
>> if (!pwm)
>> return -EINVAL;
>>
>> + if (!mutex_is_locked(>lock))
>> + return -EINVAL;
>> +
>> mutex_lock(>lock);
>>
>> if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
>
> First of all, Thierry suggested way of fixing this:
> "Any objections to simply removing it and make all users use a workqueue
> or some such if they need to control a PWM as a result of an interrupt
> trigger?"
You are correct, current design need to be changes.
> what is wrong with his approach?
>
pwm->lock is locked but it never get unlocked, although the code looks correct.
> Second, you are writing something that looks like mutex-try-lock...
> which will fail the pwm_enable(). IMHO this *hides* the real issue and
> does not solve anything (except hiding also the warning).
Thanks for the inputs. I have realized my mistake.
>
> Best regards,
> Krzysztof
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 11 December 2015 at 09:37, Anand Moon wrote:
> Hi Krzysztof,
>
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>>> Hi Krzysztof,
>>>
>>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>>> wrote:
>>>> 2015-11-21 21:11 GMT+09:00 Anand Moon :
>>>>> hi Krzysztof,
>>>>>
>>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>>> wrote:
>>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>>>>>>> hi Krzysztof,
>>>>>>>
>>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>>> >
>>>>>>>> > Changes fix the following debug lock warning.
>>>>>>>> >
>>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>>
>>>>>>>> Hi Anand!
>>>>>>>>
>>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>>> locking in atomic context (if you build with debug sleep atomic you
>>>>>>>> will
>>>>>>>> see different warning). More over you are partially reverting the
>>>>>>>> commit
>>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to
>>>>>>>> enable")
>>>>>>>> without proper explanation:
>>>>>>>> 1. why this locking is inappropriate;
>>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>>
>>>>>>>> Please find the real problem, fix the real problem and throughly
>>>>>>>> explain
>>>>>>>> the real issue.
>>>>>>>>
>>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>>> should be scheduled from function called by timer?
>>>>>>>>
>>>>>>>> Warning with debug atomic sleep:
>>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>>> swapper/0
>>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>>> [ 16.070524]
>>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>>> (show_stack+0x10/0x14)
>>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>>>>> (call_timer_fn+0x6c/0xf4)
>>>>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>>>>> (run_timer_softirq+0x1a8/0x230)
>>>
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 22 November 2015 at 05:43, Krzysztof Kozlowski
wrote:
> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>> Hi Krzysztof,
>>
>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-21 21:11 GMT+09:00 Anand Moon :
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>> wrote:
>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>>>>>> hi Krzysztof,
>>>>>>
>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>> >
>>>>>>> > Changes fix the following debug lock warning.
>>>>>>> >
>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>
>>>>>>> Hi Anand!
>>>>>>>
>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>>>> see different warning). More over you are partially reverting the commit
>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>>>> without proper explanation:
>>>>>>> 1. why this locking is inappropriate;
>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>
>>>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>>>> the real issue.
>>>>>>>
>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>> should be scheduled from function called by timer?
>>>>>>>
>>>>>>> Warning with debug atomic sleep:
>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>> swapper/0
>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>> [ 16.070524]
>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>> (show_stack+0x10/0x14)
>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>>>> (call_timer_fn+0x6c/0xf4)
>>>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>>>> (__do_softirq+0x134/0x2c0)
>>>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>>>> (irq_exit+0xd0/0x114)
>>>>>>> [ 16.157255] [] (irq_exit) from []
>>>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>>>> (gic_handle_irq+0x4c/0x94
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 22 November 2015 at 05:43, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> Hi Krzysztof,
>>
>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>> <k.kozlow...@samsung.com> wrote:
>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>>> hi Krzysztof,
>>>>>>
>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>> <k.kozlow...@samsung.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>> >
>>>>>>> > Changes fix the following debug lock warning.
>>>>>>> >
>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>
>>>>>>> Hi Anand!
>>>>>>>
>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>>>> see different warning). More over you are partially reverting the commit
>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>>>> without proper explanation:
>>>>>>> 1. why this locking is inappropriate;
>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>
>>>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>>>> the real issue.
>>>>>>>
>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>> should be scheduled from function called by timer?
>>>>>>>
>>>>>>> Warning with debug atomic sleep:
>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>> swapper/0
>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>> [ 16.070524]
>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>> (show_stack+0x10/0x14)
>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>>>> (call_timer_fn+0x6c/0xf4)
>>>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>>>> (__do_softirq+0x134/0x2c0)
>>>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>>>> (irq_exit+0xd0/0x114)
>>>>>>> [ 16.157255] [] (irq
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 11 December 2015 at 09:37, Anand Moon <linux.am...@gmail.com> wrote:
> Hi Krzysztof,
>
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>> Hi Krzysztof,
>>>
>>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>>> <k.kozlow...@samsung.com> wrote:
>>>> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>> hi Krzysztof,
>>>>>
>>>>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>>>>> <k.kozlow...@samsung.com> wrote:
>>>>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>>>>> hi Krzysztof,
>>>>>>>
>>>>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>>>>> <k.kozlow...@samsung.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>>>>> > introduce double lock of mutex on pwm_enable
>>>>>>>> >
>>>>>>>> > Changes fix the following debug lock warning.
>>>>>>>> >
>>>>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>>>>
>>>>>>>> Hi Anand!
>>>>>>>>
>>>>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>>>>> locking in atomic context (if you build with debug sleep atomic you
>>>>>>>> will
>>>>>>>> see different warning). More over you are partially reverting the
>>>>>>>> commit
>>>>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to
>>>>>>>> enable")
>>>>>>>> without proper explanation:
>>>>>>>> 1. why this locking is inappropriate;
>>>>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>>>>
>>>>>>>> Please find the real problem, fix the real problem and throughly
>>>>>>>> explain
>>>>>>>> the real issue.
>>>>>>>>
>>>>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>>>>> should be scheduled from function called by timer?
>>>>>>>>
>>>>>>>> Warning with debug atomic sleep:
>>>>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>>>>> ../kernel/locking/mutex.c:617
>>>>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>>>>>>> swapper/0
>>>>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>>>>> [ 16.070524]
>>>>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>>>>> (show_stack+0x10/0x14)
>>>>>>>> [ 16.093938] [] (show_stack) from []
>>>>>>>> (dump_stack+0x70/0xbc)
>>>>>>>> [ 16.101122] [] (dump_stack) from []
>>>>>>>> (mutex_lock_nested+0x24/0x474)
>>>>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>>>>> (pwm_enable+0x20/0x7c)
>>>>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>>>>> [ 16.125119] []
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof
On 11 December 2015 at 09:53, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 11.12.2015 13:07, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 22 November 2015 at 05:43, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-22 3:14 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> Hi Krzysztof,
>
> [...]
>
>>> Yes, now you pasted the same warning I did...
>>>
>>> This is still the same issue. I already wrote it:
>>>> 1. BUG: sleeping function called from invalid context
>>>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> We can repeat it many times but that won't change anything...
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Would you consider below changes to fix the above issue.
>> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
>> And I don't observed issue.
>>
>> 1. BUG: sleeping function called from invalid context
>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> Please share your thought on this changes.
>>
>> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index d24ca5f..f3f6cf9 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
>> if (!pwm)
>> return -EINVAL;
>>
>> + if (!mutex_is_locked(>lock))
>> + return -EINVAL;
>> +
>> mutex_lock(>lock);
>>
>> if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
>
> First of all, Thierry suggested way of fixing this:
> "Any objections to simply removing it and make all users use a workqueue
> or some such if they need to control a PWM as a result of an interrupt
> trigger?"
You are correct, current design need to be changes.
> what is wrong with his approach?
>
pwm->lock is locked but it never get unlocked, although the code looks correct.
> Second, you are writing something that looks like mutex-try-lock...
> which will fail the pwm_enable(). IMHO this *hides* the real issue and
> does not solve anything (except hiding also the warning).
Thanks for the inputs. I have realized my mistake.
>
> Best regards,
> Krzysztof
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Chanwoo Choi,
On 10 December 2015 at 05:42, Chanwoo Choi wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
>>> This patch-set includes the two features as following. The generic exynos
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>> when executing regulator_disable() because of only parent
>>> devfreq device has the regulator instance. After fixing it,
>>> the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>> after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>> DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>> on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>> There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>> In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> clocks = <_dmc CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> status = "disabled";
>>> };
>>>
>>> bus_dmc_opp_table: opp_table0 {
>>> compatible = "operating-points-v2";
>>> opp-shared;
>>>
>>> opp00 {
>>> opp-hz = /bits/ 64 <5000>;
>>> opp-microvolt = <80>;
>>> };
>>> opp01 {
>>> opp-hz = /bits/ 64 <1>;
>>> opp-microvolt = <80>;
>>> };
>>> opp02 {
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>> opp03 {
>>> opp-hz = /bits/ 64 <2>;
>>> opp-microvolt = <80>;
>>> };
>>> opp04 {
>>> opp-hz = /bits/ 64 <4>;
>>> opp-microvolt = <875000>;
>>>
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
184 > drivers/devfreq/Kconfig| 37 +- > drivers/devfreq/Makefile |2 + > drivers/devfreq/devfreq.c | 120 ++- > drivers/devfreq/exynos/Makefile|3 +- > drivers/devfreq/exynos/exynos-bus.c| 549 ++ > drivers/devfreq/exynos/exynos4_bus.c | 1055 > > drivers/devfreq/exynos/exynos4_bus.h | 110 -- > drivers/devfreq/exynos/exynos5_bus.c | 431 > drivers/devfreq/exynos/exynos_ppmu.c | 119 --- > drivers/devfreq/exynos/exynos_ppmu.h | 86 -- > drivers/devfreq/governor.h |7 + > drivers/devfreq/governor_passive.c | 109 ++ > drivers/devfreq/governor_performance.c |1 + > drivers/devfreq/governor_powersave.c |1 + > drivers/devfreq/governor_simpleondemand.c |1 + > drivers/devfreq/governor_userspace.c |1 + > include/linux/devfreq.h| 28 + > 25 files changed, 1958 insertions(+), 1828 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > create mode 100644 drivers/devfreq/exynos/exynos-bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h > delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h > create mode 100644 drivers/devfreq/governor_passive.c > > -- > 1.9.1 > I could not get this series to work with my Odroid U3. [4.602768] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [4.605527] devfreq bus_leftbus: Couldn't update frequency transition information. [4.607319] devfreq bus_dmc: Couldn't update frequency transition information. [4.625096] usb 1-3: New USB device found, idVendor=0424, idProduct=3503 -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
ts/exynos4x12.dtsi | 184 > drivers/devfreq/Kconfig| 37 +- > drivers/devfreq/Makefile |2 + > drivers/devfreq/devfreq.c | 120 ++- > drivers/devfreq/exynos/Makefile|3 +- > drivers/devfreq/exynos/exynos-bus.c| 549 ++ > drivers/devfreq/exynos/exynos4_bus.c | 1055 > > drivers/devfreq/exynos/exynos4_bus.h | 110 -- > drivers/devfreq/exynos/exynos5_bus.c | 431 > drivers/devfreq/exynos/exynos_ppmu.c | 119 --- > drivers/devfreq/exynos/exynos_ppmu.h | 86 -- > drivers/devfreq/governor.h |7 + > drivers/devfreq/governor_passive.c | 109 ++ > drivers/devfreq/governor_performance.c |1 + > drivers/devfreq/governor_powersave.c |1 + > drivers/devfreq/governor_simpleondemand.c |1 + > drivers/devfreq/governor_userspace.c |1 + > include/linux/devfreq.h| 28 + > 25 files changed, 1958 insertions(+), 1828 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > create mode 100644 drivers/devfreq/exynos/exynos-bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h > delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h > create mode 100644 drivers/devfreq/governor_passive.c > > -- > 1.9.1 > I could not get this series to work with my Odroid U3. [4.602768] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [4.605527] devfreq bus_leftbus: Couldn't update frequency transition information. [4.607319] devfreq bus_dmc: Couldn't update frequency transition information. [4.625096] usb 1-3: New USB device found, idVendor=0424, idProduct=3503 -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Chanwoo Choi,
On 10 December 2015 at 05:42, Chanwoo Choi <cw00.c...@samsung.com> wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi <cw00.c...@samsung.com> wrote:
>>> This patch-set includes the two features as following. The generic exynos
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>> when executing regulator_disable() because of only parent
>>> devfreq device has the regulator instance. After fixing it,
>>> the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>> after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>> DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>> on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>> There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>> In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> clocks = <_dmc CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> status = "disabled";
>>> };
>>>
>>> bus_dmc_opp_table: opp_table0 {
>>> compatible = "operating-points-v2";
>>> opp-shared;
>>>
>>> opp00 {
>>> opp-hz = /bits/ 64 <5000>;
>>> opp-microvolt = <80>;
>>> };
>>> opp01 {
>>> opp-hz = /bits/ 64 <1>;
>>> opp-microvolt = <80>;
>>> };
>>> opp02 {
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>> opp03 {
>>> opp-hz = /bits/ 64 <2>;
>>> opp-microvolt = <80>;
>>> };
>>> opp04 {
>>> opp-hz = /bits/ 64 <4>;
>>>
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 9 December 2015 at 09:41, Chanwoo Choi wrote: > Hi Anand, > > On 2015년 11월 27일 09:34, Chanwoo Choi wrote: >> Hi Anand, >> >> On 2015년 11월 27일 02:17, Anand Moon wrote: >>> Hi Chanwoo, >>> >>> On 26 November 2015 at 21:42, Chanwoo Choi wrote: >>>> On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham >>>> wrote: >>>>> On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi >>>>> wrote: >>>>>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>>>>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos >>>>>> SoC >>>>>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>>>>> This driver can support the generic bus frequency driver for Exynos SoCs. >>>>>> >>>>>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>>>>> and devfreq-event devices which measure the utilization of each bus >>>>>> block. >>>>>> >>>>>> Signed-off-by: Chanwoo Choi >>>>>> --- >>>>>> drivers/devfreq/Kconfig | 15 ++ >>>>>> drivers/devfreq/Makefile| 1 + >>>>>> drivers/devfreq/exynos/Makefile | 1 + >>>>>> drivers/devfreq/exynos/exynos-bus.c | 443 >>>>>> >>>>>> 4 files changed, 460 insertions(+) >>>>>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>>>>> >>>>> >>>>> Are we finally getting a common Exynos bus driver with full DT support? >>>>> (can this replace both Exynos4/5 drivers and support Exynos7 series?) >>>> >>>> Yes. >>>> This patch-set would support all Exynos SoCs for bus frequency driver. >>>> To make sure the support for Exynos7 series, I need to check the TRM >>>> document of Exynos7. I think it is possible for support Exynos7. >>>> >>>> I'm going to test this driver on various Exynos-based board. >>>> >>>> Regards, >>>> Chanwoo Choi >>> >>> Please do consider Exynos 542x series as well. >> >> Sure. I'll to test it on Exynos5422-based Odroid-XU3. > > I send the v2 patchset but this patchset don't include > the support of Odroid-XU3 because of only Exynos542x has the > special addtional sequence to change the source clock > of DRAM. So, I'm going to support the bus frequency on Exynos542x. > After completing it, I'll send the separate patches. > > Thanks, > Chanwoo Choi > Not an issue. Thanks for the update. -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 9 December 2015 at 09:41, Chanwoo Choi <cw00.c...@samsung.com> wrote: > Hi Anand, > > On 2015년 11월 27일 09:34, Chanwoo Choi wrote: >> Hi Anand, >> >> On 2015년 11월 27일 02:17, Anand Moon wrote: >>> Hi Chanwoo, >>> >>> On 26 November 2015 at 21:42, Chanwoo Choi <cwcho...@gmail.com> wrote: >>>> On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham <myungjoo@samsung.com> >>>> wrote: >>>>> On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi <cw00.c...@samsung.com> >>>>> wrote: >>>>>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>>>>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos >>>>>> SoC >>>>>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>>>>> This driver can support the generic bus frequency driver for Exynos SoCs. >>>>>> >>>>>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>>>>> and devfreq-event devices which measure the utilization of each bus >>>>>> block. >>>>>> >>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com> >>>>>> --- >>>>>> drivers/devfreq/Kconfig | 15 ++ >>>>>> drivers/devfreq/Makefile| 1 + >>>>>> drivers/devfreq/exynos/Makefile | 1 + >>>>>> drivers/devfreq/exynos/exynos-bus.c | 443 >>>>>> >>>>>> 4 files changed, 460 insertions(+) >>>>>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>>>>> >>>>> >>>>> Are we finally getting a common Exynos bus driver with full DT support? >>>>> (can this replace both Exynos4/5 drivers and support Exynos7 series?) >>>> >>>> Yes. >>>> This patch-set would support all Exynos SoCs for bus frequency driver. >>>> To make sure the support for Exynos7 series, I need to check the TRM >>>> document of Exynos7. I think it is possible for support Exynos7. >>>> >>>> I'm going to test this driver on various Exynos-based board. >>>> >>>> Regards, >>>> Chanwoo Choi >>> >>> Please do consider Exynos 542x series as well. >> >> Sure. I'll to test it on Exynos5422-based Odroid-XU3. > > I send the v2 patchset but this patchset don't include > the support of Odroid-XU3 because of only Exynos542x has the > special addtional sequence to change the source clock > of DRAM. So, I'm going to support the bus frequency on Exynos542x. > After completing it, I'll send the separate patches. > > Thanks, > Chanwoo Choi > Not an issue. Thanks for the update. -Anand Moon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support
luster);
> + cpu_devs[cluster] = cpu_dev;
> +
> + /*
> +* Disable any OPPs where the connected regulator isn't able
> to
> +* provide the specified voltage and record minimum and
> maximum
> +* voltage levels.
> +*/
> + while (1) {
> + struct dev_pm_opp *opp;
> + unsigned long opp_uV;
> +
> + rcu_read_lock();
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, _freq);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + break;
> + }
> + opp_uV = dev_pm_opp_get_voltage(opp);
> + rcu_read_unlock();
> +
> + if (regulator_is_supported_voltage(reg[cluster],
> opp_uV,
> + opp_uV)) {
> + if (opp_uV < min_uV)
> + min_uV = opp_uV;
> + if (opp_uV > max_uV)
> + max_uV = opp_uV;
> + } else {
> + dev_pm_opp_disable(cpu_dev, opp_freq);
> + }
> +
> + opp_freq++;
> + }
> +
> + ret = regulator_set_voltage_time(reg[cluster], min_uV,
> max_uV);
> + if (ret > 0)
> + transition_latencies[cluster] = ret * 1000;
> + }
> +
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table[cluster]);
> if (ret) {
> dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d,
> err: %d\n",
> @@ -483,6 +599,11 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> else
> policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>
> + if (cur_cluster < MAX_CLUSTERS &&
> + policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
> + policy->cpuinfo.transition_latency
> + += transition_latencies[cur_cluster];
> +
> if (is_bL_switching_enabled())
> per_cpu(cpu_last_req_freq, policy->cpu) =
> clk_get_cpu_rate(policy->cpu);
>
> --
> 2.6.2
>
I am getting following warning when I am trying to use git am
root@odroidxu4:/usr/src/odroidxu3-4.y-final# git am -s cpuf1.patch
Applying: cpufreq: arm_big_little: add cluster regulator support
/usr/src/odroidxu3-4.y-final/.git/rebase-apply/patch:144: trailing whitespace.
}
warning: 1 line adds whitespace errors.
---
Also I have disabled and enabled following config options.
-CONFIG_BL_SWITCHER=y
-CONFIG_BL_SWITCHER_DUMMY_IF=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_DT_BL_CPUFREQ=y
But I could not see the cpu frequency working on my Odroid XU4. Am I
missing some thing.
Every 2.0s: cpupower -c 4 frequency-info
Thu Dec
3 04:02:36 2015
analyzing CPU 4:
driver: arm-big-little
CPUs which run at the same hardware frequency: 4 5 6 7
CPUs which need to have their frequency coordinated by software: 4 5 6 7
maximum transition latency: 0.00 ms.
hardware limits: 200 MHz - 1.80 GHz
available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600
MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30
GHz, 1.40 GHz, 1.50 GH
z, 1.60 GHz, 1.70 GHz, 1.80 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 200 MHz and 1.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.80 GHz (asserted by call to hardware).
cpufreq stats: 200 MHz:0.00%, 300 MHz:0.00%, 400 MHz:0.00%, 500
MHz:0.00%, 600 MHz:0.00%, 700 MHz:0.00%, 800 MHz:0.00%, 900 MHz:0.00%,
1000 MHz:0.00%, 1.10
GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:0.00%, 1.40 GHz:0.00%, 1.50
GHz:0.00%, 1.60 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:100.00% (1)
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/12] cpufreq: arm_big_little: add cluster regulator support
uster + '0';
> + reg[cluster] = regulator_get_optional(cpu_dev, name);
> + if (!IS_ERR(reg[cluster])) {
> + unsigned long opp_freq = 0;
> +
> + dev_dbg(cpu_dev, "%s: reg: %p, cluster: %d\n",
> + __func__, reg[cluster], cluster);
> + cpu_devs[cluster] = cpu_dev;
> +
> + /*
> +* Disable any OPPs where the connected regulator isn't able
> to
> +* provide the specified voltage and record minimum and
> maximum
> +* voltage levels.
> +*/
> + while (1) {
> + struct dev_pm_opp *opp;
> + unsigned long opp_uV;
> +
> + rcu_read_lock();
> + opp = dev_pm_opp_find_freq_ceil(cpu_dev, _freq);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + break;
> + }
> + opp_uV = dev_pm_opp_get_voltage(opp);
> + rcu_read_unlock();
> +
> + if (regulator_is_supported_voltage(reg[cluster],
> opp_uV,
> + opp_uV)) {
> + if (opp_uV < min_uV)
> + min_uV = opp_uV;
> + if (opp_uV > max_uV)
> + max_uV = opp_uV;
> + } else {
> + dev_pm_opp_disable(cpu_dev, opp_freq);
> + }
> +
> + opp_freq++;
> + }
> +
> + ret = regulator_set_voltage_time(reg[cluster], min_uV,
> max_uV);
> + if (ret > 0)
> + transition_latencies[cluster] = ret * 1000;
> + }
> +
> ret = dev_pm_opp_init_cpufreq_table(cpu_dev, _table[cluster]);
> if (ret) {
> dev_err(cpu_dev, "%s: failed to init cpufreq table, cpu: %d,
> err: %d\n",
> @@ -483,6 +599,11 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> else
> policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
>
> + if (cur_cluster < MAX_CLUSTERS &&
> + policy->cpuinfo.transition_latency != CPUFREQ_ETERNAL)
> + policy->cpuinfo.transition_latency
> + += transition_latencies[cur_cluster];
> +
> if (is_bL_switching_enabled())
> per_cpu(cpu_last_req_freq, policy->cpu) =
> clk_get_cpu_rate(policy->cpu);
>
> --
> 2.6.2
>
I am getting following warning when I am trying to use git am
root@odroidxu4:/usr/src/odroidxu3-4.y-final# git am -s cpuf1.patch
Applying: cpufreq: arm_big_little: add cluster regulator support
/usr/src/odroidxu3-4.y-final/.git/rebase-apply/patch:144: trailing whitespace.
}
warning: 1 line adds whitespace errors.
---
Also I have disabled and enabled following config options.
-CONFIG_BL_SWITCHER=y
-CONFIG_BL_SWITCHER_DUMMY_IF=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_DT_BL_CPUFREQ=y
But I could not see the cpu frequency working on my Odroid XU4. Am I
missing some thing.
Every 2.0s: cpupower -c 4 frequency-info
Thu Dec
3 04:02:36 2015
analyzing CPU 4:
driver: arm-big-little
CPUs which run at the same hardware frequency: 4 5 6 7
CPUs which need to have their frequency coordinated by software: 4 5 6 7
maximum transition latency: 0.00 ms.
hardware limits: 200 MHz - 1.80 GHz
available frequency steps: 200 MHz, 300 MHz, 400 MHz, 500 MHz, 600
MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30
GHz, 1.40 GHz, 1.50 GH
z, 1.60 GHz, 1.70 GHz, 1.80 GHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 200 MHz and 1.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.80 GHz (asserted by call to hardware).
cpufreq stats: 200 MHz:0.00%, 300 MHz:0.00%, 400 MHz:0.00%, 500
MHz:0.00%, 600 MHz:0.00%, 700 MHz:0.00%, 800 MHz:0.00%, 900 MHz:0.00%,
1000 MHz:0.00%, 1.10
GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:0.00%, 1.40 GHz:0.00%, 1.50
GHz:0.00%, 1.60 GHz:0.00%, 1.70 GHz:0.00%, 1.80 GHz:100.00% (1)
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 30 November 2015 at 11:12, Krzysztof Kozlowski
wrote:
> On 27.11.2015 15:42, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 22 October 2015 at 18:34, Anand Moon wrote:
>>> hi Krzysztof,
>>>
>>> On 22 October 2015 at 06:31, Krzysztof Kozlowski
>>> wrote:
>>>> On 20.10.2015 21:56, Anand Moon wrote:
>>>>> Changes need for host controller to detect UHS-I highspeed cards.
>>>>> Changes in VDDQ_MMC2 voltage range help scale
>>>>> the required voltage to detect and load the microSD cards.
>>>>
>>>> Thanks for updating description of commit.
>>>>
>>>>>
>>>>> Signed-off-by: Anand Moon
>>>>> ---
>>>>> Changes based on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> v4.4-next/dt-samsung branch
>>>>>
>>>>> Changes:
>>>>> Drop the ranp_delay for LDO9.
>>>>>
>>>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>>>> me out figure out the mmc core requirement.
>>>>>
>>>>> Also drop the previous changes:
>>>>> use cd-gpio method to detect sd-card.
>>>>> Added UHS-I bus speed support.
>>>>>
>>>>> [4.713553] random: nonblocking pool is initialized
>>>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy
>>>>> regulator
>>>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>>>> fimd_component_ops)
>>>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>>>> mixer_component_ops)
>>>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>>>> hdmi_component_ops)
>>>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>>>> [5.054571] usb 2-1: new full-speed USB device number 2 using
>>>>> exynos-ohci
>>>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg
>>>>> 0x0 status 0x0)
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> index 1af5bdc..a4be3e0 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> @@ -182,9 +182,10 @@
>>>>>
>>>>> ldo13_reg: LDO13 {
>>>>> regulator-name = "vdd_ldo13";
>>>>> - regulator-min-microvolt = <280>;
>>>>> + regulator-min-microvolt = <180>;
>>>>
>>>> You did not convinced me in previous discussion about the change to
>>>> 1.8V. I said that:
>>>>> On the same diagram few lines below:
>>>>> VDDQ_MMC2: 2.8V 250mA
>>>>
>>>> You responded:
>>>>> You are correct.
>>>>
>>>> So I am confused. Are you sure that this SD card block can/should
>>>> operate on 1.8V? Have you actually tried this?
>>>>
>>>
>>> Look like I missed this point. Here is the link I would like to share.
>>>
>>> http://www.hjreggel.net/cardspeed/cs_sdxc.html
>>> Section: Summary of SD modes
>>>
>>> https://en.wikipedia.org/wiki/Secure_Digital
>>> Section: Power consumption
>>>
>>> Their different requirement for voltage requirement for UHS-I, the max
>>> value is around 3.3V
>>
>> Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
> I asked whether you tried this, whether setting real 1.8V works fine.
> You did not respond. As you can see on Odroid schematics, the VDDQ for
> MMC[01] operates under 1.8V.
>
> The VDDQ for MMC2 - under 2.8V.
>
> In commit description you mentioned that this voltage "helps scale the
> required voltage to detect and load the microSD cards". What does it
> mean "help"? I would expect that detecting and loading of microSD cards
> either works or does not work. I am not sure how does it help.
>
> Best regards,
> Krzysztof
I will fix the commit message.
Earlier around v4.2 detection of UHS-I card was not working,but now it
seen to work in v4.4 kernel.
May be some driver issue which might have been fixed.
I am just trying to set the voltage range for LDO13 from 1.8V (min) to
2.8V (max).
If setting this is wrong according to datasheet then I will drop this setting.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 30 November 2015 at 11:12, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 27.11.2015 15:42, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 22 October 2015 at 18:34, Anand Moon <linux.am...@gmail.com> wrote:
>>> hi Krzysztof,
>>>
>>> On 22 October 2015 at 06:31, Krzysztof Kozlowski
>>> <k.kozlow...@samsung.com> wrote:
>>>> On 20.10.2015 21:56, Anand Moon wrote:
>>>>> Changes need for host controller to detect UHS-I highspeed cards.
>>>>> Changes in VDDQ_MMC2 voltage range help scale
>>>>> the required voltage to detect and load the microSD cards.
>>>>
>>>> Thanks for updating description of commit.
>>>>
>>>>>
>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>> ---
>>>>> Changes based on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> v4.4-next/dt-samsung branch
>>>>>
>>>>> Changes:
>>>>> Drop the ranp_delay for LDO9.
>>>>>
>>>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>>>> me out figure out the mmc core requirement.
>>>>>
>>>>> Also drop the previous changes:
>>>>> use cd-gpio method to detect sd-card.
>>>>> Added UHS-I bus speed support.
>>>>>
>>>>> [4.713553] random: nonblocking pool is initialized
>>>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy
>>>>> regulator
>>>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>>>> fimd_component_ops)
>>>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>>>> mixer_component_ops)
>>>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>>>> hdmi_component_ops)
>>>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>>>> [5.054571] usb 2-1: new full-speed USB device number 2 using
>>>>> exynos-ohci
>>>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg
>>>>> 0x0 status 0x0)
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> index 1af5bdc..a4be3e0 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> @@ -182,9 +182,10 @@
>>>>>
>>>>> ldo13_reg: LDO13 {
>>>>> regulator-name = "vdd_ldo13";
>>>>> - regulator-min-microvolt = <280>;
>>>>> + regulator-min-microvolt = <180>;
>>>>
>>>> You did not convinced me in previous discussion about the change to
>>>> 1.8V. I said that:
>>>>> On the same diagram few lines below:
>>>>> VDDQ_MMC2: 2.8V 250mA
>>>>
>>>> You responded:
>>>>> You are correct.
>>>>
>>>> So I am confused. Are you sure that this SD card block can/should
>>>> operate on 1.8V? Have you actually tried this?
>>>>
>>>
>>> Look like I missed this point. Here is the link I would like to share.
>>>
>>> http://www.hjreggel.net/cardspeed/cs_sdxc.html
>>> Section: Summary of SD modes
>>>
>>> https://en.wikipedia.org/wiki/Secure_Digital
>>> Section: Power consumption
>>>
>>> Their different requirement for voltage requirement for UHS-I, the max
>>> value is around 3.3V
>>
>> Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
> I asked whether you tried this, whether setting real 1.8V works fine.
> You did not respond. As you can see on Odroid schematics, the VDDQ for
> MMC[01] operates under 1.8V.
>
> The VDDQ for MMC2 - under 2.8V.
>
> In commit description you mentioned that this voltage "helps scale the
> required voltage to detect and load the microSD cards". What does it
> mean "help"? I would expect that detecting and loading of microSD cards
> either works or does not work. I am not sure how does it help.
>
> Best regards,
> Krzysztof
I will fix the commit message.
Earlier around v4.2 detection of UHS-I card was not working,but now it
seen to work in v4.4 kernel.
May be some driver issue which might have been fixed.
I am just trying to set the voltage range for LDO13 from 1.8V (min) to
2.8V (max).
If setting this is wrong according to datasheet then I will drop this setting.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 18:34, Anand Moon wrote:
> hi Krzysztof,
>
> On 22 October 2015 at 06:31, Krzysztof Kozlowski
> wrote:
>> On 20.10.2015 21:56, Anand Moon wrote:
>>> Changes need for host controller to detect UHS-I highspeed cards.
>>> Changes in VDDQ_MMC2 voltage range help scale
>>> the required voltage to detect and load the microSD cards.
>>
>> Thanks for updating description of commit.
>>
>>>
>>> Signed-off-by: Anand Moon
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes:
>>> Drop the ranp_delay for LDO9.
>>>
>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>> me out figure out the mmc core requirement.
>>>
>>> Also drop the previous changes:
>>> use cd-gpio method to detect sd-card.
>>> Added UHS-I bus speed support.
>>>
>>> [4.713553] random: nonblocking pool is initialized
>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>> fimd_component_ops)
>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>> mixer_component_ops)
>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>> hdmi_component_ops)
>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>>> status 0x0)
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1af5bdc..a4be3e0 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -182,9 +182,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> - regulator-min-microvolt = <280>;
>>> + regulator-min-microvolt = <180>;
>>
>> You did not convinced me in previous discussion about the change to
>> 1.8V. I said that:
>>> On the same diagram few lines below:
>>> VDDQ_MMC2: 2.8V 250mA
>>
>> You responded:
>>> You are correct.
>>
>> So I am confused. Are you sure that this SD card block can/should
>> operate on 1.8V? Have you actually tried this?
>>
>
> Look like I missed this point. Here is the link I would like to share.
>
> http://www.hjreggel.net/cardspeed/cs_sdxc.html
> Section: Summary of SD modes
>
> https://en.wikipedia.org/wiki/Secure_Digital
> Section: Power consumption
>
> Their different requirement for voltage requirement for UHS-I, the max
> value is around 3.3V
Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> + regulator-ramp-delay = <12000>;
>>
>> NAK
>>
>> We've been talking about this. Sooo mn times.
>>
>> If you are going to send v3 please come up with detailed reasoning,
>> which will convince my stubborn mind.
>>
>
> Look like I missed this point. my typo. Will drop this in next version.
> No matter I try hard, it turn out I make silly and annoying mistake.
>
> -Anand Moon
>
Well I will drop this.
>> Best regards,
>> Krzysztof
>>
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +214,7 @@
>>> regulator-min-
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 26 November 2015 at 21:42, Chanwoo Choi wrote: > On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham > wrote: >> On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi wrote: >>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC >>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>> This driver can support the generic bus frequency driver for Exynos SoCs. >>> >>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>> and devfreq-event devices which measure the utilization of each bus block. >>> >>> Signed-off-by: Chanwoo Choi >>> --- >>> drivers/devfreq/Kconfig | 15 ++ >>> drivers/devfreq/Makefile| 1 + >>> drivers/devfreq/exynos/Makefile | 1 + >>> drivers/devfreq/exynos/exynos-bus.c | 443 >>> >>> 4 files changed, 460 insertions(+) >>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>> >> >> Are we finally getting a common Exynos bus driver with full DT support? >> (can this replace both Exynos4/5 drivers and support Exynos7 series?) > > Yes. > This patch-set would support all Exynos SoCs for bus frequency driver. > To make sure the support for Exynos7 series, I need to check the TRM > document of Exynos7. I think it is possible for support Exynos7. > > I'm going to test this driver on various Exynos-based board. > > Regards, > Chanwoo Choi Please do consider Exynos 542x series as well. -Anand Moon > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 18:34, Anand Moon <linux.am...@gmail.com> wrote:
> hi Krzysztof,
>
> On 22 October 2015 at 06:31, Krzysztof Kozlowski
> <k.kozlow...@samsung.com> wrote:
>> On 20.10.2015 21:56, Anand Moon wrote:
>>> Changes need for host controller to detect UHS-I highspeed cards.
>>> Changes in VDDQ_MMC2 voltage range help scale
>>> the required voltage to detect and load the microSD cards.
>>
>> Thanks for updating description of commit.
>>
>>>
>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes:
>>> Drop the ranp_delay for LDO9.
>>>
>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>> me out figure out the mmc core requirement.
>>>
>>> Also drop the previous changes:
>>> use cd-gpio method to detect sd-card.
>>> Added UHS-I bus speed support.
>>>
>>> [4.713553] random: nonblocking pool is initialized
>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>> fimd_component_ops)
>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>> mixer_component_ops)
>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>> hdmi_component_ops)
>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>>> status 0x0)
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1af5bdc..a4be3e0 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -182,9 +182,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> - regulator-min-microvolt = <280>;
>>> + regulator-min-microvolt = <180>;
>>
>> You did not convinced me in previous discussion about the change to
>> 1.8V. I said that:
>>> On the same diagram few lines below:
>>> VDDQ_MMC2: 2.8V 250mA
>>
>> You responded:
>>> You are correct.
>>
>> So I am confused. Are you sure that this SD card block can/should
>> operate on 1.8V? Have you actually tried this?
>>
>
> Look like I missed this point. Here is the link I would like to share.
>
> http://www.hjreggel.net/cardspeed/cs_sdxc.html
> Section: Summary of SD modes
>
> https://en.wikipedia.org/wiki/Secure_Digital
> Section: Power consumption
>
> Their different requirement for voltage requirement for UHS-I, the max
> value is around 3.3V
Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> + regulator-ramp-delay = <12000>;
>>
>> NAK
>>
>> We've been talking about this. Sooo mn times.
>>
>> If you are going to send v3 please come up with detailed reasoning,
>> which will convince my stubborn mind.
>>
>
> Look like I missed this point. my typo. Will drop this in next version.
> No matter I try hard, it turn out I make silly and annoying mistake.
>
> -Anand Moon
>
Well I will drop this.
>> Best regards,
>> Krzysztof
>>
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>
Re: [RFC PATCH 01/15] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi Chanwoo, On 26 November 2015 at 21:42, Chanwoo Choi <cwcho...@gmail.com> wrote: > On Thu, Nov 26, 2015 at 11:00 PM, MyungJoo Ham <myungjoo@samsung.com> > wrote: >> On Thu, Nov 26, 2015 at 10:47 PM, Chanwoo Choi <cw00.c...@samsung.com> wrote: >>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC >>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>> This driver can support the generic bus frequency driver for Exynos SoCs. >>> >>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>> and devfreq-event devices which measure the utilization of each bus block. >>> >>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com> >>> --- >>> drivers/devfreq/Kconfig | 15 ++ >>> drivers/devfreq/Makefile| 1 + >>> drivers/devfreq/exynos/Makefile | 1 + >>> drivers/devfreq/exynos/exynos-bus.c | 443 >>> >>> 4 files changed, 460 insertions(+) >>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>> >> >> Are we finally getting a common Exynos bus driver with full DT support? >> (can this replace both Exynos4/5 drivers and support Exynos7 series?) > > Yes. > This patch-set would support all Exynos SoCs for bus frequency driver. > To make sure the support for Exynos7 series, I need to check the TRM > document of Exynos7. I think it is possible for support Exynos7. > > I'm going to test this driver on various Exynos-based board. > > Regards, > Chanwoo Choi Please do consider Exynos 542x series as well. -Anand Moon > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon :
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c)
>>>>> [ 16.217661] [] (arch_cpu_idle) from []
>>>>> (cpu_startup_entry+0x17c/0x26c)
>>>>> [ 16.225
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon :
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c)
>>>>> [ 16.217661] [] (arch_cpu_idle) from []
>>>>> (cpu_startup_entry+0x17c/0x26c)
>>>>> [ 16.225
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
hi Krzysztof,
On 21 November 2015 at 15:22, Krzysztof Kozlowski
wrote:
> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>> hi Krzysztof,
>>
>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>> wrote:
>>>
>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>> > (pwm: Set enable state properly on failed call to enable)
>>> > introduce double lock of mutex on pwm_enable
>>> >
>>> > Changes fix the following debug lock warning.
>>> >
>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> Hi Anand!
>>>
>>> Yeah, I am hitting this as well. Annoying. However your description is
>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>> locking in atomic context (if you build with debug sleep atomic you will
>>> see different warning). More over you are partially reverting the commit
>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>> without proper explanation:
>>> 1. why this locking is inappropriate;
>>> 2. why it is safe to remove the mutex_lock().
>>>
>>> Please find the real problem, fix the real problem and throughly explain
>>> the real issue.
>>>
>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>> should be scheduled from function called by timer?
>>>
>>> Warning with debug atomic sleep:
>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>> ../kernel/locking/mutex.c:617
>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>> [ 16.061402] INFO: lockdep is turned off.
>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>> [ 16.070524]
>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 16.086215] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [ 16.093938] [] (show_stack) from []
>>> (dump_stack+0x70/0xbc)
>>> [ 16.101122] [] (dump_stack) from []
>>> (mutex_lock_nested+0x24/0x474)
>>> [ 16.109009] [] (mutex_lock_nested) from []
>>> (pwm_enable+0x20/0x7c)
>>> [ 16.116799] [] (pwm_enable) from []
>>> (led_heartbeat_function+0xdc/0x140)
>>> [ 16.125119] [] (led_heartbeat_function) from []
>>> (call_timer_fn+0x6c/0xf4)
>>> [ 16.133606] [] (call_timer_fn) from []
>>> (run_timer_softirq+0x1a8/0x230)
>>> [ 16.141846] [] (run_timer_softirq) from []
>>> (__do_softirq+0x134/0x2c0)
>>> [ 16.149982] [] (__do_softirq) from []
>>> (irq_exit+0xd0/0x114)
>>> [ 16.157255] [] (irq_exit) from []
>>> (__handle_domain_irq+0x70/0xe4)
>>> [ 16.165056] [] (__handle_domain_irq) from []
>>> (gic_handle_irq+0x4c/0x94)
>>> [ 16.173376] [] (gic_handle_irq) from []
>>> (__irq_svc+0x58/0x98)
>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>> [ 16.185823] df40:
>>>c0010dcc
>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>> c08ce4bc c08c7364 c08ce4b4
>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>> c0010dd0 600f0013
>>> [ 16.210291] [] (__irq_svc) from []
>>> (arch_cpu_idle+0x20/0x3c)
>>> [ 16.217661] [] (arch_cpu_idle) from []
>>> (cpu_startup_entry+0x17c/0x26c)
>>> [ 16.225899] [] (cpu_startup_entry) from []
>>> (start_kernel+0x368/0x3d0)
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> > [2.701737] Modules linked in:
>>> > [2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f
>>> > #24
>>> > [2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> > [2.701787] [] (unwind_backtrace) from []
>>> > (show_stack+0x10/0x14)
>>> > [2.701808] [] (show_stack) from []
>>> > (dump_stack+0x84/0xc4)
>>> > [2.701824] [] (dump_stack) from []
>>> > (warn_slowpath_common+0x80/0xb0)
>>> > [2.701836] [] (warn_slowpath_common) from []
>>>
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 21 November 2015 at 18:37, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 21:11 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 15:22, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>>>> hi Krzysztof,
>>>>
>>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>> wrote:
>>>>>
>>>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>>>> > (pwm: Set enable state properly on failed call to enable)
>>>>> > introduce double lock of mutex on pwm_enable
>>>>> >
>>>>> > Changes fix the following debug lock warning.
>>>>> >
>>>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>>>
>>>>> Hi Anand!
>>>>>
>>>>> Yeah, I am hitting this as well. Annoying. However your description is
>>>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>>>> locking in atomic context (if you build with debug sleep atomic you will
>>>>> see different warning). More over you are partially reverting the commit
>>>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>>>> without proper explanation:
>>>>> 1. why this locking is inappropriate;
>>>>> 2. why it is safe to remove the mutex_lock().
>>>>>
>>>>> Please find the real problem, fix the real problem and throughly explain
>>>>> the real issue.
>>>>>
>>>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>>>> should be scheduled from function called by timer?
>>>>>
>>>>> Warning with debug atomic sleep:
>>>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>>>> ../kernel/locking/mutex.c:617
>>>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>>>> [ 16.061402] INFO: lockdep is turned off.
>>>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>>>> [ 16.070524]
>>>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>>>> [ 16.086215] [] (unwind_backtrace) from []
>>>>> (show_stack+0x10/0x14)
>>>>> [ 16.093938] [] (show_stack) from []
>>>>> (dump_stack+0x70/0xbc)
>>>>> [ 16.101122] [] (dump_stack) from []
>>>>> (mutex_lock_nested+0x24/0x474)
>>>>> [ 16.109009] [] (mutex_lock_nested) from []
>>>>> (pwm_enable+0x20/0x7c)
>>>>> [ 16.116799] [] (pwm_enable) from []
>>>>> (led_heartbeat_function+0xdc/0x140)
>>>>> [ 16.125119] [] (led_heartbeat_function) from []
>>>>> (call_timer_fn+0x6c/0xf4)
>>>>> [ 16.133606] [] (call_timer_fn) from []
>>>>> (run_timer_softirq+0x1a8/0x230)
>>>>> [ 16.141846] [] (run_timer_softirq) from []
>>>>> (__do_softirq+0x134/0x2c0)
>>>>> [ 16.149982] [] (__do_softirq) from []
>>>>> (irq_exit+0xd0/0x114)
>>>>> [ 16.157255] [] (irq_exit) from []
>>>>> (__handle_domain_irq+0x70/0xe4)
>>>>> [ 16.165056] [] (__handle_domain_irq) from []
>>>>> (gic_handle_irq+0x4c/0x94)
>>>>> [ 16.173376] [] (gic_handle_irq) from []
>>>>> (__irq_svc+0x58/0x98)
>>>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>>>> [ 16.185823] df40:
>>>>>c0010dcc
>>>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>>>> c08ce4bc c08c7364 c08ce4b4
>>>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>>>> c0010dd0 600f0013
>>>>> [ 16.210291] [] (__irq_svc) from []
>>>>> (arch_cpu_idle+0x20/0x3c
Re: [PATCH] pwm: Avoid double mutex lock on pwm_enable
hi Krzysztof,
On 21 November 2015 at 15:22, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> 2015-11-21 18:40 GMT+09:00 Anand Moon <linux.am...@gmail.com>:
>> hi Krzysztof,
>>
>> On 21 November 2015 at 09:56, Krzysztof Kozlowski <k.kozlow...@samsung.com>
>> wrote:
>>>
>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>> > (pwm: Set enable state properly on failed call to enable)
>>> > introduce double lock of mutex on pwm_enable
>>> >
>>> > Changes fix the following debug lock warning.
>>> >
>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> Hi Anand!
>>>
>>> Yeah, I am hitting this as well. Annoying. However your description is
>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>> locking in atomic context (if you build with debug sleep atomic you will
>>> see different warning). More over you are partially reverting the commit
>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>> without proper explanation:
>>> 1. why this locking is inappropriate;
>>> 2. why it is safe to remove the mutex_lock().
>>>
>>> Please find the real problem, fix the real problem and throughly explain
>>> the real issue.
>>>
>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>> should be scheduled from function called by timer?
>>>
>>> Warning with debug atomic sleep:
>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>> ../kernel/locking/mutex.c:617
>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
>>> [ 16.061402] INFO: lockdep is turned off.
>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>> [ 16.070524]
>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 16.086215] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [ 16.093938] [] (show_stack) from []
>>> (dump_stack+0x70/0xbc)
>>> [ 16.101122] [] (dump_stack) from []
>>> (mutex_lock_nested+0x24/0x474)
>>> [ 16.109009] [] (mutex_lock_nested) from []
>>> (pwm_enable+0x20/0x7c)
>>> [ 16.116799] [] (pwm_enable) from []
>>> (led_heartbeat_function+0xdc/0x140)
>>> [ 16.125119] [] (led_heartbeat_function) from []
>>> (call_timer_fn+0x6c/0xf4)
>>> [ 16.133606] [] (call_timer_fn) from []
>>> (run_timer_softirq+0x1a8/0x230)
>>> [ 16.141846] [] (run_timer_softirq) from []
>>> (__do_softirq+0x134/0x2c0)
>>> [ 16.149982] [] (__do_softirq) from []
>>> (irq_exit+0xd0/0x114)
>>> [ 16.157255] [] (irq_exit) from []
>>> (__handle_domain_irq+0x70/0xe4)
>>> [ 16.165056] [] (__handle_domain_irq) from []
>>> (gic_handle_irq+0x4c/0x94)
>>> [ 16.173376] [] (gic_handle_irq) from []
>>> (__irq_svc+0x58/0x98)
>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>> [ 16.185823] df40:
>>>c0010dcc
>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>> c08ce4bc c08c7364 c08ce4b4
>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>> c0010dd0 600f0013
>>> [ 16.210291] [] (__irq_svc) from []
>>> (arch_cpu_idle+0x20/0x3c)
>>> [ 16.217661] [] (arch_cpu_idle) from []
>>> (cpu_startup_entry+0x17c/0x26c)
>>> [ 16.225899] [] (cpu_startup_entry) from []
>>> (start_kernel+0x368/0x3d0)
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> > [2.701737] Modules linked in:
>>> > [2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f
>>> > #24
>>> > [2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> > [2.701787] [] (unwind_backtrace) from []
>>> > (show_stack+0x10/0x14)
>>> > [2.701808] [] (show_stack) from []
>>> > (dump_stack+0x84/0xc4)
>>> > [2.701824] [] (dump_stack) from []
>>> > (warn_slowpath_co
[PATCH] pwm: Avoid double mutex lock on pwm_enable
Commit d1cd21427747f15920cd726f5f67a07880e7dee4
(pwm: Set enable state properly on failed call to enable)
introduce double lock of mutex on pwm_enable
Changes fix the following debug lock warning.
[2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
__mutex_lock_slowpath+0x3bc/0x404()
[2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
[2.701737] Modules linked in:
[2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f #24
[2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[2.701787] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.701808] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[2.701824] [] (dump_stack) from []
(warn_slowpath_common+0x80/0xb0)
[2.701836] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x30/0x40)
[2.701849] [] (warn_slowpath_fmt) from []
(__mutex_lock_slowpath+0x3bc/0x404)
[2.701864] [] (__mutex_lock_slowpath) from []
(mutex_lock+0xc/0x24)
[2.701884] [] (mutex_lock) from []
(pwm_enable+0x20/0x7c)
[2.701903] [] (pwm_enable) from []
(led_heartbeat_function+0x74/0x144)
[2.701919] [] (led_heartbeat_function) from []
(call_timer_fn+0x24/0x98)
[2.701932] [] (call_timer_fn) from []
(run_timer_softirq+0x160/0x21c)
[2.701946] [] (run_timer_softirq) from []
(__do_softirq+0x110/0x228)
[2.701959] [] (__do_softirq) from []
(irq_exit+0xc0/0xfc)
[2.701976] [] (irq_exit) from []
(__handle_domain_irq+0x80/0xec)
[2.701990] [] (__handle_domain_irq) from []
(gic_handle_irq+0x54/0x94)
[2.702001] [] (gic_handle_irq) from []
(__irq_svc+0x54/0x90)
[2.702008] Exception stack(0xee8bdf88 to 0xee8bdfd0)
[2.702019] df80: 0001 c001b720
ee8bc000 c0573354
[2.702031] dfa0: ee8bdfe0 c07f92e4 c08004b4 c08004bc
f0806640 ee8bdfd8
[2.702039] dfc0: c0010180 c0010184 6013
[2.702053] [] (__irq_svc) from []
(arch_cpu_idle+0x38/0x3c)
[2.702073] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x1ec/0x270)
[2.702086] [] (cpu_startup_entry) from [<4000956c>] (0x4000956c)
[2.702093] ---[ end trace 539af70491f4f1a9 ]---
Signed-off-by: Anand Moon
---
drivers/pwm/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..b8f035a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -506,16 +506,12 @@ int pwm_enable(struct pwm_device *pwm)
if (!pwm)
return -EINVAL;
- mutex_lock(>lock);
-
if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
if (err)
clear_bit(PWMF_ENABLED, >flags);
}
- mutex_unlock(>lock);
-
return err;
}
EXPORT_SYMBOL_GPL(pwm_enable);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: Avoid double mutex lock on pwm_enable
Commit d1cd21427747f15920cd726f5f67a07880e7dee4
(pwm: Set enable state properly on failed call to enable)
introduce double lock of mutex on pwm_enable
Changes fix the following debug lock warning.
[2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
__mutex_lock_slowpath+0x3bc/0x404()
[2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
[2.701737] Modules linked in:
[2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-rc1-xu4f #24
[2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[2.701787] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.701808] [] (show_stack) from []
(dump_stack+0x84/0xc4)
[2.701824] [] (dump_stack) from []
(warn_slowpath_common+0x80/0xb0)
[2.701836] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x30/0x40)
[2.701849] [] (warn_slowpath_fmt) from []
(__mutex_lock_slowpath+0x3bc/0x404)
[2.701864] [] (__mutex_lock_slowpath) from []
(mutex_lock+0xc/0x24)
[2.701884] [] (mutex_lock) from []
(pwm_enable+0x20/0x7c)
[2.701903] [] (pwm_enable) from []
(led_heartbeat_function+0x74/0x144)
[2.701919] [] (led_heartbeat_function) from []
(call_timer_fn+0x24/0x98)
[2.701932] [] (call_timer_fn) from []
(run_timer_softirq+0x160/0x21c)
[2.701946] [] (run_timer_softirq) from []
(__do_softirq+0x110/0x228)
[2.701959] [] (__do_softirq) from []
(irq_exit+0xc0/0xfc)
[2.701976] [] (irq_exit) from []
(__handle_domain_irq+0x80/0xec)
[2.701990] [] (__handle_domain_irq) from []
(gic_handle_irq+0x54/0x94)
[2.702001] [] (gic_handle_irq) from []
(__irq_svc+0x54/0x90)
[2.702008] Exception stack(0xee8bdf88 to 0xee8bdfd0)
[2.702019] df80: 0001 c001b720
ee8bc000 c0573354
[2.702031] dfa0: ee8bdfe0 c07f92e4 c08004b4 c08004bc
f0806640 ee8bdfd8
[2.702039] dfc0: c0010180 c0010184 6013
[2.702053] [] (__irq_svc) from []
(arch_cpu_idle+0x38/0x3c)
[2.702073] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x1ec/0x270)
[2.702086] [] (cpu_startup_entry) from [<4000956c>] (0x4000956c)
[2.702093] ---[ end trace 539af70491f4f1a9 ]---
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
drivers/pwm/core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..b8f035a 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -506,16 +506,12 @@ int pwm_enable(struct pwm_device *pwm)
if (!pwm)
return -EINVAL;
- mutex_lock(>lock);
-
if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
if (err)
clear_bit(PWMF_ENABLED, >flags);
}
- mutex_unlock(>lock);
-
return err;
}
EXPORT_SYMBOL_GPL(pwm_enable);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 06:31, Krzysztof Kozlowski
wrote:
> On 20.10.2015 21:56, Anand Moon wrote:
>> Changes need for host controller to detect UHS-I highspeed cards.
>> Changes in VDDQ_MMC2 voltage range help scale
>> the required voltage to detect and load the microSD cards.
>
> Thanks for updating description of commit.
>
>>
>> Signed-off-by: Anand Moon
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes:
>> Drop the ranp_delay for LDO9.
>>
>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>> me out figure out the mmc core requirement.
>>
>> Also drop the previous changes:
>> use cd-gpio method to detect sd-card.
>> Added UHS-I bus speed support.
>>
>> [4.713553] random: nonblocking pool is initialized
>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>> fimd_component_ops)
>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>> mixer_component_ops)
>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>> hdmi_component_ops)
>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [4.753428] [drm] No driver support for vblank timestamp query.
>> [4.940794] Console: switching to colour frame buffer device 274x77
>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>> status 0x0)
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..a4be3e0 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -182,9 +182,10 @@
>>
>> ldo13_reg: LDO13 {
>> regulator-name = "vdd_ldo13";
>> - regulator-min-microvolt = <280>;
>> + regulator-min-microvolt = <180>;
>
> You did not convinced me in previous discussion about the change to
> 1.8V. I said that:
>> On the same diagram few lines below:
>> VDDQ_MMC2: 2.8V 250mA
>
> You responded:
>> You are correct.
>
> So I am confused. Are you sure that this SD card block can/should
> operate on 1.8V? Have you actually tried this?
>
Look like I missed this point. Here is the link I would like to share.
http://www.hjreggel.net/cardspeed/cs_sdxc.html
Section: Summary of SD modes
https://en.wikipedia.org/wiki/Secure_Digital
Section: Power consumption
Their different requirement for voltage requirement for UHS-I, the max
value is around 3.3V
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>
> NAK
>
> We've been talking about this. Sooo mn times.
>
> If you are going to send v3 please come up with detailed reasoning,
> which will convince my stubborn mind.
>
Look like I missed this point. my typo. Will drop this in next version.
No matter I try hard, it turn out I make silly and annoying mistake.
-Anand Moon
> Best regards,
> Krzysztof
>
>> };
>>
>> ldo15_reg: LDO15 {
>> @@ -213,6 +214,7 @@
>> regulator-min-microvolt = <280>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>> };
>>
>> ldo24_reg: LDO24 {
>> @@ -338,6 +340,7 @@
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> samsung,dw-mshc-hs400-timing = <0 2>;
>> samsung,read-strobe-delay = <90>;
>> + vmmc-supply = <_reg>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>> _rclk>;
>> bus-width = <8>;
>> @@ -355,6 +358,8 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
>> bus-width = <4>;
>> + vmmc-supply = <_reg>;
>> + vqmmc-supply = <_reg>;
>> cap-sd-highspeed;
>> };
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 14:06, Javier Martinez Canillas wrote: > Hello Anand, > > On 10/22/2015 07:03 AM, Anand Moon wrote: >> Hi Javier, >> >> On 22 October 2015 at 08:22, Javier Martinez Canillas >> wrote: >>> Hello Krzysztof, >>> >>> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>>>> >>>>> Thanks for your feedback. >>>>> >>>>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>>>> logic) to be able to read the second stage from the eMMC. >>>>>>> >>>>>>> But this has to be called before a system reboot handler and while most >>>>>>> of them use the priority 128, there are other restart handlers (such as >>>>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>>>> >>>>>>> Signed-off-by: Javier Martinez Canillas >>>>>>> Tested-by: Markus Reichl >>>>>>> Tested-by: Anand Moon >>>>>>> Reviewed-by: Alim Akhtar >>>>>>> >>>>>>> --- >>>>>>> Hello, >>>>>>> >>>>>>> This patch was needed since a recent series from Alim [0] added >>>>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>>>> >>>>>>> But the PMU and syscon-reboot restart handler have a different >>>>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>>>> >>>>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>>>> >>>>>>> So this patch must be merged before [0] to avoid regressions. >>>>>>> >>>>>>> Best regards, >>>>>>> Javier >>>>>>> >>>>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>>>> mmc_host *host, >>>>>>> >>>>>>>/* >>>>>>> * register reset handler to ensure emmc reset also from >>>>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>>>> - * system reboot >>>>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>>>> + * so it will be executed before any system reboot handler. >>>>>>> */ >>>>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>>>> - pwrseq->reset_nb.priority = 129; >>>>>>> + pwrseq->reset_nb.priority = 255; >>>>>> >>>>>> I see the problem which you are trying to solve but this may be tricker >>>>>> then just kicking the number. Some of restart handlers are registered >>>>>> with priority 192. I found few of such, like: at91_restart_nb, >>>>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>>>> much). >>>>>> >>>>> >>>>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>>>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>>>> handler priority is 128. >>>>> >>>>>> I guess they chose the "192" priority on purpose. >>>>>> >>>>> >>>>> I tried to understand what's the polic
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 14:06, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Anand, > > On 10/22/2015 07:03 AM, Anand Moon wrote: >> Hi Javier, >> >> On 22 October 2015 at 08:22, Javier Martinez Canillas >> <jav...@osg.samsung.com> wrote: >>> Hello Krzysztof, >>> >>> On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>>>> >>>>> Thanks for your feedback. >>>>> >>>>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>>>> logic) to be able to read the second stage from the eMMC. >>>>>>> >>>>>>> But this has to be called before a system reboot handler and while most >>>>>>> of them use the priority 128, there are other restart handlers (such as >>>>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>>>> >>>>>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> >>>>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de> >>>>>>> Tested-by: Anand Moon <linux.am...@gmail.com> >>>>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com> >>>>>>> >>>>>>> --- >>>>>>> Hello, >>>>>>> >>>>>>> This patch was needed since a recent series from Alim [0] added >>>>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>>>> >>>>>>> But the PMU and syscon-reboot restart handler have a different >>>>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>>>> >>>>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>>>> >>>>>>> So this patch must be merged before [0] to avoid regressions. >>>>>>> >>>>>>> Best regards, >>>>>>> Javier >>>>>>> >>>>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>>>> mmc_host *host, >>>>>>> >>>>>>>/* >>>>>>> * register reset handler to ensure emmc reset also from >>>>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>>>> - * system reboot >>>>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>>>> + * so it will be executed before any system reboot handler. >>>>>>> */ >>>>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>>>> - pwrseq->reset_nb.priority = 129; >>>>>>> + pwrseq->reset_nb.priority = 255; >>>>>> >>>>>> I see the problem which you are trying to solve but this may be tricker >>>>>> then just kicking the number. Some of restart handlers are registered >>>>>> with priority 192. I found few of such, like: at91_restart_nb, >>>>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>>>> much). >>>>>> >>>>> >>>>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>>>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>>>> handler priority is 128. >>>>> >&
Re: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 06:31, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 20.10.2015 21:56, Anand Moon wrote:
>> Changes need for host controller to detect UHS-I highspeed cards.
>> Changes in VDDQ_MMC2 voltage range help scale
>> the required voltage to detect and load the microSD cards.
>
> Thanks for updating description of commit.
>
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes:
>> Drop the ranp_delay for LDO9.
>>
>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>> me out figure out the mmc core requirement.
>>
>> Also drop the previous changes:
>> use cd-gpio method to detect sd-card.
>> Added UHS-I bus speed support.
>>
>> [4.713553] random: nonblocking pool is initialized
>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>> fimd_component_ops)
>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>> mixer_component_ops)
>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>> hdmi_component_ops)
>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [4.753428] [drm] No driver support for vblank timestamp query.
>> [4.940794] Console: switching to colour frame buffer device 274x77
>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>> status 0x0)
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..a4be3e0 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -182,9 +182,10 @@
>>
>> ldo13_reg: LDO13 {
>> regulator-name = "vdd_ldo13";
>> - regulator-min-microvolt = <280>;
>> + regulator-min-microvolt = <180>;
>
> You did not convinced me in previous discussion about the change to
> 1.8V. I said that:
>> On the same diagram few lines below:
>> VDDQ_MMC2: 2.8V 250mA
>
> You responded:
>> You are correct.
>
> So I am confused. Are you sure that this SD card block can/should
> operate on 1.8V? Have you actually tried this?
>
Look like I missed this point. Here is the link I would like to share.
http://www.hjreggel.net/cardspeed/cs_sdxc.html
Section: Summary of SD modes
https://en.wikipedia.org/wiki/Secure_Digital
Section: Power consumption
Their different requirement for voltage requirement for UHS-I, the max
value is around 3.3V
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>
> NAK
>
> We've been talking about this. Sooo mn times.
>
> If you are going to send v3 please come up with detailed reasoning,
> which will convince my stubborn mind.
>
Look like I missed this point. my typo. Will drop this in next version.
No matter I try hard, it turn out I make silly and annoying mistake.
-Anand Moon
> Best regards,
> Krzysztof
>
>> };
>>
>> ldo15_reg: LDO15 {
>> @@ -213,6 +214,7 @@
>> regulator-min-microvolt = <280>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> + regulator-ramp-delay = <12000>;
>> };
>>
>> ldo24_reg: LDO24 {
>> @@ -338,6 +340,7 @@
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> samsung,dw-mshc-hs400-timing = <0 2>;
>> samsung,read-strobe-delay = <90>;
>> + vmmc-suppl
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 08:22, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>> >>> Thanks for your feedback. >>> >>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>> logic) to be able to read the second stage from the eMMC. >>>>> >>>>> But this has to be called before a system reboot handler and while most >>>>> of them use the priority 128, there are other restart handlers (such as >>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>> >>>>> Signed-off-by: Javier Martinez Canillas >>>>> Tested-by: Markus Reichl >>>>> Tested-by: Anand Moon >>>>> Reviewed-by: Alim Akhtar >>>>> >>>>> --- >>>>> Hello, >>>>> >>>>> This patch was needed since a recent series from Alim [0] added >>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>> >>>>> But the PMU and syscon-reboot restart handler have a different >>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>> >>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>> >>>>> So this patch must be merged before [0] to avoid regressions. >>>>> >>>>> Best regards, >>>>> Javier >>>>> >>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>> mmc_host *host, >>>>> >>>>>/* >>>>> * register reset handler to ensure emmc reset also from >>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>> - * system reboot >>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>> + * so it will be executed before any system reboot handler. >>>>> */ >>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>> - pwrseq->reset_nb.priority = 129; >>>>> + pwrseq->reset_nb.priority = 255; >>>> >>>> I see the problem which you are trying to solve but this may be tricker >>>> then just kicking the number. Some of restart handlers are registered >>>> with priority 192. I found few of such, like: at91_restart_nb, >>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>> much). >>>> >>> >>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>> handler priority is 128. >>> >>>> I guess they chose the "192" priority on purpose. >>>> >>> >>> I tried to understand what's the policy w.r.t priority numbering for >>> restart handlers but only found this in the register_restart_handler >>> kernel-doc [0]: >>> >>> /** >>> * register_restart_handler - Register function to be called to reset >>> * the system >>> * @nb: Info about handler function to be called >>> * @nb->priority: Handler priority. Handlers should follow the >>> * following guidelines for setting priorities. >>> * 0: Restart handler of last resort, >>> * with limited restart capabilities >>> * 128:Default restart handler; use if no other >>> *
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
Hi Javier, On 22 October 2015 at 08:22, Javier Martinez Canillas <jav...@osg.samsung.com> wrote: > Hello Krzysztof, > > On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: >> On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, >>> >>> Thanks for your feedback. >>> >>> On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: >>>> On 22.10.2015 00:15, Javier Martinez Canillas wrote: >>>>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >>>>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset >>>>> logic) to be able to read the second stage from the eMMC. >>>>> >>>>> But this has to be called before a system reboot handler and while most >>>>> of them use the priority 128, there are other restart handlers (such as >>>>> the syscon-reboot one) that use a higher priority. So, use the highest >>>>> priority to make sure that the eMMC hw is reset before a system reboot. >>>>> >>>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> >>>>> Tested-by: Markus Reichl <m.rei...@fivetechno.de> >>>>> Tested-by: Anand Moon <linux.am...@gmail.com> >>>>> Reviewed-by: Alim Akhtar <alim.akh...@samsung.com> >>>>> >>>>> --- >>>>> Hello, >>>>> >>>>> This patch was needed since a recent series from Alim [0] added >>>>> syscon reboot and poweroff support to Exynos SoCs and removed >>>>> the reset handler in the Exynos Power Management Unit (PMU) code. >>>>> >>>>> But the PMU and syscon-reboot restart handler have a different >>>>> priority so [0] breaks restart when eMMC is used on these boards. >>>>> >>>>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html >>>>> >>>>> So this patch must be merged before [0] to avoid regressions. >>>>> >>>>> Best regards, >>>>> Javier >>>>> >>>>> drivers/mmc/core/pwrseq_emmc.c | 6 +++--- >>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/drivers/mmc/core/pwrseq_emmc.c >>>>> b/drivers/mmc/core/pwrseq_emmc.c >>>>> index 137c97fb7aa8..ad4f94ec7e8d 100644 >>>>> --- a/drivers/mmc/core/pwrseq_emmc.c >>>>> +++ b/drivers/mmc/core/pwrseq_emmc.c >>>>> @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct >>>>> mmc_host *host, >>>>> >>>>>/* >>>>> * register reset handler to ensure emmc reset also from >>>>> - * emergency_reboot(), priority 129 schedules it just before >>>>> - * system reboot >>>>> + * emergency_reboot(), priority 255 is the highest priority >>>>> + * so it will be executed before any system reboot handler. >>>>> */ >>>>>pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; >>>>> - pwrseq->reset_nb.priority = 129; >>>>> + pwrseq->reset_nb.priority = 255; >>>> >>>> I see the problem which you are trying to solve but this may be tricker >>>> then just kicking the number. Some of restart handlers are registered >>>> with priority 192. I found few of such, like: at91_restart_nb, >>>> zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too >>>> much). >>>> >>> >>> Yes, the syscon-reboot restart handler also uses a priority 192 and that >>> is why reboot with eMMC broke with Alim's patches since the PMU restart >>> handler priority is 128. >>> >>>> I guess they chose the "192" priority on purpose. >>>> >>> >>> I tried to understand what's the policy w.r.t priority numbering for >>> restart handlers but only found this in the register_restart_handler >>> kernel-doc [0]: >>> >>> /** >>> * register_restart_handler - Register function to be called to reset >>> * the system >>> * @nb: Info about handler function to be called >>> * @nb->priority: Handler priority. Handlers should follow the >>> * following guidelines for setting priorities. >>> * 0: Restart handler of last resort, >>> *
[PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Changes need for host controller to detect UHS-I highspeed cards.
Changes in VDDQ_MMC2 voltage range help scale
the required voltage to detect and load the microSD cards.
Signed-off-by: Anand Moon
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes:
Drop the ranp_delay for LDO9.
Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
me out figure out the mmc core requirement.
Also drop the previous changes:
use cd-gpio method to detect sd-card.
Added UHS-I bus speed support.
[4.713553] random: nonblocking pool is initialized
[4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
[4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
fimd_component_ops)
[4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
mixer_component_ops)
[4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
hdmi_component_ops)
[4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.753428] [drm] No driver support for vblank timestamp query.
[4.940794] Console: switching to colour frame buffer device 274x77
[4.995344] exynos-drm exynos-drm: fb0: frame buffer device
[5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[5.031164] exynos-dwc3 usb@1200: no suspend clk specified
[5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
[5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
[5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
status 0x0)
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1af5bdc..a4be3e0 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -182,9 +182,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
- regulator-min-microvolt = <280>;
+ regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +214,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo24_reg: LDO24 {
@@ -338,6 +340,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+ vmmc-supply = <_reg>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
_rclk>;
bus-width = <8>;
@@ -355,6 +358,8 @@
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
bus-width = <4>;
+ vmmc-supply = <_reg>;
+ vqmmc-supply = <_reg>;
cap-sd-highspeed;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Changes need for host controller to detect UHS-I highspeed cards.
Changes in VDDQ_MMC2 voltage range help scale
the required voltage to detect and load the microSD cards.
Signed-off-by: Anand Moon <linux.am...@gmail.com>
---
Changes based on
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v4.4-next/dt-samsung branch
Changes:
Drop the ranp_delay for LDO9.
Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
me out figure out the mmc core requirement.
Also drop the previous changes:
use cd-gpio method to detect sd-card.
Added UHS-I bus speed support.
[4.713553] random: nonblocking pool is initialized
[4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
[4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
fimd_component_ops)
[4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
mixer_component_ops)
[4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
hdmi_component_ops)
[4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.753428] [drm] No driver support for vblank timestamp query.
[4.940794] Console: switching to colour frame buffer device 274x77
[4.995344] exynos-drm exynos-drm: fb0: frame buffer device
[5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[5.031164] exynos-dwc3 usb@1200: no suspend clk specified
[5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
[5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
[5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
status 0x0)
---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1af5bdc..a4be3e0 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -182,9 +182,10 @@
ldo13_reg: LDO13 {
regulator-name = "vdd_ldo13";
- regulator-min-microvolt = <280>;
+ regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo15_reg: LDO15 {
@@ -213,6 +214,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
regulator-always-on;
+ regulator-ramp-delay = <12000>;
};
ldo24_reg: LDO24 {
@@ -338,6 +340,7 @@
samsung,dw-mshc-ddr-timing = <0 2>;
samsung,dw-mshc-hs400-timing = <0 2>;
samsung,read-strobe-delay = <90>;
+ vmmc-supply = <_reg>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
_rclk>;
bus-width = <8>;
@@ -355,6 +358,8 @@
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
bus-width = <4>;
+ vmmc-supply = <_reg>;
+ vqmmc-supply = <_reg>;
cap-sd-highspeed;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Doug/ Krzysztof , On 15 October 2015 at 04:10, Doug Anderson wrote: > Hi, > > On Tue, Oct 13, 2015 at 6:06 PM, Alim Akhtar wrote: >> +Doug >> Hello, >> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >> and SDR104 modes. >> >> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >> >> What I remember is, one need to set "broken-cd" property also in order >> to make it work because of the vqmmc and vmmc connection on board. I >> didn't find the link right now, but you can search on the web, there >> was a long discussion about handling this. >> Have not checked it recently, so not sure if this got broken somehow. > > Right. It _shouldn't_ be possible to add "vmmc/vqmmc" supplies to > your DTS (which you do in patch 2/3) and also to use the "gpc2-2" pin > for card detect (even if you configure it as a GPIO). Once you add > "vmmc/vqmmc" then Linux ought to be turning these regulators off when > no card is plugged in. Presumably the "vqmmc" regulator is hooked up > to the "VDDQ_MMC2". If you look in the user manual for 5422 you can > see that "GPC2[2]/SD_2_CDn" has power domain "VDDQ_MMC2". Thus you > really shouldn't be using that pin when vqmmc is off. I think at some > point someone claimed that it still worked for them, but nobody could > ever explain why. Full discussion at > <https://patchwork.kernel.org/patch/4763881/> > > --- > > In case it matters, comments on stuff from earlier in the thread: > > * As people pointed out, exynos5422 certainly supports all these modes > (including DDR50) in the SoC. > > * Just because the SoC supports these modes doesn't mean that the > boards do, which is why the SoC .dtsi doesn't include them. Thus, > this patch is "right" in that it changes a board-specific file. > > * As Krzysztof points out this board doesn't "add" support but rather > "enables" support. The distinction is subtle. > > * You might be able to get DDR50 working, but probably better to just > start with SDR modes. Previously I never attempted to get DDR50 cards > working, so possibly the software needs extra work? > Thanks for clarifying all the background details on the mmc changes. Here is what I would conclude from the previous mail chain's. 1 Drop the cd-gpios changes. pinctrl-0 changes. 2 Fix the regulator changes for vmmc/vqmmc with disable of regulator-always-on; 3 Drop this UHS-I changes as if now. Is this ok with you. -Anand Moon > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Doug/ Krzysztof , On 15 October 2015 at 04:10, Doug Anderson <diand...@chromium.org> wrote: > Hi, > > On Tue, Oct 13, 2015 at 6:06 PM, Alim Akhtar <alim.akh...@gmail.com> wrote: >> +Doug >> Hello, >> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >> and SDR104 modes. >> >> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >> >> What I remember is, one need to set "broken-cd" property also in order >> to make it work because of the vqmmc and vmmc connection on board. I >> didn't find the link right now, but you can search on the web, there >> was a long discussion about handling this. >> Have not checked it recently, so not sure if this got broken somehow. > > Right. It _shouldn't_ be possible to add "vmmc/vqmmc" supplies to > your DTS (which you do in patch 2/3) and also to use the "gpc2-2" pin > for card detect (even if you configure it as a GPIO). Once you add > "vmmc/vqmmc" then Linux ought to be turning these regulators off when > no card is plugged in. Presumably the "vqmmc" regulator is hooked up > to the "VDDQ_MMC2". If you look in the user manual for 5422 you can > see that "GPC2[2]/SD_2_CDn" has power domain "VDDQ_MMC2". Thus you > really shouldn't be using that pin when vqmmc is off. I think at some > point someone claimed that it still worked for them, but nobody could > ever explain why. Full discussion at > <https://patchwork.kernel.org/patch/4763881/> > > --- > > In case it matters, comments on stuff from earlier in the thread: > > * As people pointed out, exynos5422 certainly supports all these modes > (including DDR50) in the SoC. > > * Just because the SoC supports these modes doesn't mean that the > boards do, which is why the SoC .dtsi doesn't include them. Thus, > this patch is "right" in that it changes a board-specific file. > > * As Krzysztof points out this board doesn't "add" support but rather > "enables" support. The distinction is subtle. > > * You might be able to get DDR50 working, but probably better to just > start with SDR modes. Previously I never attempted to get DDR50 cards > working, so possibly the software needs extra work? > Thanks for clarifying all the background details on the mmc changes. Here is what I would conclude from the previous mail chain's. 1 Drop the cd-gpios changes. pinctrl-0 changes. 2 Fix the regulator changes for vmmc/vqmmc with disable of regulator-always-on; 3 Drop this UHS-I changes as if now. Is this ok with you. -Anand Moon > > -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
hi Krzysztof, On 14 October 2015 at 05:29, Krzysztof Kozlowski wrote: > On 14.10.2015 01:27, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 09:13, Krzysztof Kozlowski >> wrote: >>> >>> On 13.10.2015 12:08, Anand Moon wrote: >>>> Hi Krzysztof, >>>> >>>> On 13 October 2015 at 05:44, Krzysztof Kozlowski >>>> wrote: >>>>> On 13.10.2015 00:32, Anand Moon wrote: >>>>>> Hi Krzysztof, >>>>>> >>>>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>>>>> wrote: >>>>>>> On 12.10.2015 00:46, Anand Moon wrote: >>>>>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s >>>>>>>> (SDR104) >>>>>>> >>>>>>> This description is not entirely correct. The MMC driver already >>>>>>> supports these UHS speeds (you did not any code) so you rather enabled >>>>>>> it (description of bindings says "is supported"). >>>>>>> >>>>>>> You mentioned DDR50 but I don't see respective property below. >>>>>>> >>>>>>> How do you know that these modes are really supported? I don't know. Can >>>>>>> you convince me? >>>>>> >>>>>> Setting this DDR50 capability give me this error. That's the reason to >>>>>> drop this capability. >>>>> >>>>> But you mentioned it in commit message! "Added support for UHS-I ... >>>>> (DDR50)" >>>>> >>>>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>>>> and SDR104 are really supported". >>>>> >>>> >>>> These changes are related to the microSD card capabilities. >>>> So SDR50 have better frequency over DDR50. On the same Sandisk card. >>>> >>>> When the card select the capability for DDR50 >>>> --- >>>> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 5000Hz, actual 5000HZ div = 0) >>>> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >>>> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >>>> [4.009179] mmcblk0: error -110 sending status command, retrying >>>> [4.009271] mmcblk0: error -115 sending stop command, original cmd >>>> response 0x900, card status 0x900 >>>> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >>>> cmd response 0x900, card status 0x0 >>>> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 40Hz, actual 396825HZ div = 63) >>>> [4.067770] Console: switching to colour frame buffer device 274x77 >>>> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 5000Hz, actual 5000HZ div = 0) >>>> [4.099692] mmc1: tried to reset card >>>> [4.101332] mmcblk0: p1 p2 >>>> >>>> >>>> When the card select the capability for SDR50 >>>> - >>>> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >>>> 1Hz, actual 1HZ div = 0) >>>> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >>>> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >>>> [ 2.461743] mmcblk0: p1 p2 >>>> >>>> Which will relate to better read/write speed. >>> >>> Which is not an answer to my question. To none of my previous questions. >>> >> >> Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, >> sd-uhs-sdr104) help tune speed supported for mmc >> >> I have tired to compare the speed on high speed UHS-I vs ultra high >> speed UHS-I using izone utility. >> >> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [2.572609] mmc1: new high speed SDHC card at address >> >> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k >> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls >> Output is in kBytes/sec >> Time Resolution = 0.01 seconds. >> Processor cache size set to 32 kBytes. >> Proce
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski wrote: > > On 13.10.2015 12:08, Anand Moon wrote: > > Hi Krzysztof, > > > > On 13 October 2015 at 05:44, Krzysztof Kozlowski > > wrote: > >> On 13.10.2015 00:32, Anand Moon wrote: > >>> Hi Krzysztof, > >>> > >>> On 12 October 2015 at 11:14, Krzysztof Kozlowski > >>> wrote: > >>>> On 12.10.2015 00:46, Anand Moon wrote: > >>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) > >>>> > >>>> This description is not entirely correct. The MMC driver already > >>>> supports these UHS speeds (you did not any code) so you rather enabled > >>>> it (description of bindings says "is supported"). > >>>> > >>>> You mentioned DDR50 but I don't see respective property below. > >>>> > >>>> How do you know that these modes are really supported? I don't know. Can > >>>> you convince me? > >>> > >>> Setting this DDR50 capability give me this error. That's the reason to > >>> drop this capability. > >> > >> But you mentioned it in commit message! "Added support for UHS-I ... > >> (DDR50)" > >> > >> In the same time dropping DDR50 is not an sufficient proof that "SDR50 > >> and SDR104 are really supported". > >> > > > > These changes are related to the microSD card capabilities. > > So SDR50 have better frequency over DDR50. On the same Sandisk card. > > > > When the card select the capability for DDR50 > > --- > > [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 5000Hz, actual 5000HZ div = 0) > > [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address > > [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB > > [4.009179] mmcblk0: error -110 sending status command, retrying > > [4.009271] mmcblk0: error -115 sending stop command, original cmd > > response 0x900, card status 0x900 > > [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, > > cmd response 0x900, card status 0x0 > > [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 40Hz, actual 396825HZ div = 63) > > [4.067770] Console: switching to colour frame buffer device 274x77 > > [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 5000Hz, actual 5000HZ div = 0) > > [4.099692] mmc1: tried to reset card > > [4.101332] mmcblk0: p1 p2 > > > > > > When the card select the capability for SDR50 > > - > > [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req > > 1Hz, actual 1HZ div = 0) > > [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address > > [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB > > [ 2.461743] mmcblk0: p1 p2 > > > > Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. > Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, sd-uhs-sdr104) help tune speed supported for mmc I have tired to compare the speed on high speed UHS-I vs ultra high speed UHS-I using izone utility. [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [2.572609] mmc1: new high speed SDHC card at address Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls Output is in kBytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 32 kBytes. Processor cache line size set to 64 bytes. File stride size set to 17 * record size. random random bkwdrecordstride kB reclenwrite rewritereadrereadread write read rewrite read fwrite frewritefread freread 10240 4 16310 65560 5538 982 10240 64 8828018897017994 303 10240 128 6269020670020128 1096 - [2.613761] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 1HZ div = 0) [2.623573] mm
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
hi Krzysztof, On 14 October 2015 at 05:29, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 14.10.2015 01:27, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 09:13, Krzysztof Kozlowski >> <k.kozlow...@samsung.com> wrote: >>> >>> On 13.10.2015 12:08, Anand Moon wrote: >>>> Hi Krzysztof, >>>> >>>> On 13 October 2015 at 05:44, Krzysztof Kozlowski >>>> <k.kozlow...@samsung.com> wrote: >>>>> On 13.10.2015 00:32, Anand Moon wrote: >>>>>> Hi Krzysztof, >>>>>> >>>>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>>>>> <k.kozlow...@samsung.com> wrote: >>>>>>> On 12.10.2015 00:46, Anand Moon wrote: >>>>>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s >>>>>>>> (SDR104) >>>>>>> >>>>>>> This description is not entirely correct. The MMC driver already >>>>>>> supports these UHS speeds (you did not any code) so you rather enabled >>>>>>> it (description of bindings says "is supported"). >>>>>>> >>>>>>> You mentioned DDR50 but I don't see respective property below. >>>>>>> >>>>>>> How do you know that these modes are really supported? I don't know. Can >>>>>>> you convince me? >>>>>> >>>>>> Setting this DDR50 capability give me this error. That's the reason to >>>>>> drop this capability. >>>>> >>>>> But you mentioned it in commit message! "Added support for UHS-I ... >>>>> (DDR50)" >>>>> >>>>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>>>> and SDR104 are really supported". >>>>> >>>> >>>> These changes are related to the microSD card capabilities. >>>> So SDR50 have better frequency over DDR50. On the same Sandisk card. >>>> >>>> When the card select the capability for DDR50 >>>> --- >>>> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 5000Hz, actual 5000HZ div = 0) >>>> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >>>> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >>>> [4.009179] mmcblk0: error -110 sending status command, retrying >>>> [4.009271] mmcblk0: error -115 sending stop command, original cmd >>>> response 0x900, card status 0x900 >>>> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >>>> cmd response 0x900, card status 0x0 >>>> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 40Hz, actual 396825HZ div = 63) >>>> [4.067770] Console: switching to colour frame buffer device 274x77 >>>> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >>>> req 5000Hz, actual 5000HZ div = 0) >>>> [4.099692] mmc1: tried to reset card >>>> [4.101332] mmcblk0: p1 p2 >>>> >>>> >>>> When the card select the capability for SDR50 >>>> - >>>> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >>>> 1Hz, actual 1HZ div = 0) >>>> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >>>> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >>>> [ 2.461743] mmcblk0: p1 p2 >>>> >>>> Which will relate to better read/write speed. >>> >>> Which is not an answer to my question. To none of my previous questions. >>> >> >> Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, >> sd-uhs-sdr104) help tune speed supported for mmc >> >> I have tired to compare the speed on high speed UHS-I vs ultra high >> speed UHS-I using izone utility. >> >> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [2.572609] mmc1: new high speed SDHC card at address >> >> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k >> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls >> Output is in kBytes/se
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > > On 13.10.2015 12:08, Anand Moon wrote: > > Hi Krzysztof, > > > > On 13 October 2015 at 05:44, Krzysztof Kozlowski > > <k.kozlow...@samsung.com> wrote: > >> On 13.10.2015 00:32, Anand Moon wrote: > >>> Hi Krzysztof, > >>> > >>> On 12 October 2015 at 11:14, Krzysztof Kozlowski > >>> <k.kozlow...@samsung.com> wrote: > >>>> On 12.10.2015 00:46, Anand Moon wrote: > >>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) > >>>> > >>>> This description is not entirely correct. The MMC driver already > >>>> supports these UHS speeds (you did not any code) so you rather enabled > >>>> it (description of bindings says "is supported"). > >>>> > >>>> You mentioned DDR50 but I don't see respective property below. > >>>> > >>>> How do you know that these modes are really supported? I don't know. Can > >>>> you convince me? > >>> > >>> Setting this DDR50 capability give me this error. That's the reason to > >>> drop this capability. > >> > >> But you mentioned it in commit message! "Added support for UHS-I ... > >> (DDR50)" > >> > >> In the same time dropping DDR50 is not an sufficient proof that "SDR50 > >> and SDR104 are really supported". > >> > > > > These changes are related to the microSD card capabilities. > > So SDR50 have better frequency over DDR50. On the same Sandisk card. > > > > When the card select the capability for DDR50 > > --- > > [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 5000Hz, actual 5000HZ div = 0) > > [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address > > [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB > > [4.009179] mmcblk0: error -110 sending status command, retrying > > [4.009271] mmcblk0: error -115 sending stop command, original cmd > > response 0x900, card status 0x900 > > [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, > > cmd response 0x900, card status 0x0 > > [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 40Hz, actual 396825HZ div = 63) > > [4.067770] Console: switching to colour frame buffer device 274x77 > > [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot > > req 5000Hz, actual 5000HZ div = 0) > > [4.099692] mmc1: tried to reset card > > [4.101332] mmcblk0: p1 p2 > > > > > > When the card select the capability for SDR50 > > - > > [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req > > 1Hz, actual 1HZ div = 0) > > [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address > > [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB > > [ 2.461743] mmcblk0: p1 p2 > > > > Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. > Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, sd-uhs-sdr104) help tune speed supported for mmc I have tired to compare the speed on high speed UHS-I vs ultra high speed UHS-I using izone utility. [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [2.572609] mmc1: new high speed SDHC card at address Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls Output is in kBytes/sec Time Resolution = 0.01 seconds. Processor cache size set to 32 kBytes. Processor cache line size set to 64 bytes. File stride size set to 17 * record size. random random bkwdrecordstride kB reclenwrite rewritereadrereadread write read rewrite read fwrite frewritefread freread 10240 4 16310 65560 5538 982 10240 64 8828018897017994 303 10240 128 6269020670020128 1096 - [2.613761] mmc_host mmc1: Bus speed (slo
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
Looks like my changes have introduce another bug so please ignore this changes.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski wrote: > On 13.10.2015 12:08, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 05:44, Krzysztof Kozlowski >> wrote: >>> On 13.10.2015 00:32, Anand Moon wrote: >>>> Hi Krzysztof, >>>> >>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>>> wrote: >>>>> On 12.10.2015 00:46, Anand Moon wrote: >>>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>>>> >>>>> This description is not entirely correct. The MMC driver already >>>>> supports these UHS speeds (you did not any code) so you rather enabled >>>>> it (description of bindings says "is supported"). >>>>> >>>>> You mentioned DDR50 but I don't see respective property below. >>>>> >>>>> How do you know that these modes are really supported? I don't know. Can >>>>> you convince me? >>>> >>>> Setting this DDR50 capability give me this error. That's the reason to >>>> drop this capability. >>> >>> But you mentioned it in commit message! "Added support for UHS-I ... >>> (DDR50)" >>> >>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>> and SDR104 are really supported". >>> >> >> These changes are related to the microSD card capabilities. >> So SDR50 have better frequency over DDR50. On the same Sandisk card. >> >> When the card select the capability for DDR50 >> --- >> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >> [4.009179] mmcblk0: error -110 sending status command, retrying >> [4.009271] mmcblk0: error -115 sending stop command, original cmd >> response 0x900, card status 0x900 >> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >> cmd response 0x900, card status 0x0 >> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 40Hz, actual 396825HZ div = 63) >> [4.067770] Console: switching to colour frame buffer device 274x77 >> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.099692] mmc1: tried to reset card >> [4.101332] mmcblk0: p1 p2 >> >> >> When the card select the capability for SDR50 >> - >> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >> 1Hz, actual 1HZ div = 0) >> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >> [ 2.461743] mmcblk0: p1 p2 >> >> Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. OK, you are correct.Just ignore these changes. -Anand Moon > > Best regards, > Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
My mistake, I will drop the changes. Sorry for the whole mess.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: >>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 1HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. -Anand Moon > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Jaehoon Chung,
On 13 October 2015 at 08:09, Jaehoon Chung wrote:
> On 10/13/2015 11:29 AM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:40, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 23:33, Anand Moon wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>>>> wrote:
>>>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>>>>> wrote:
>>>>>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>>>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>>>>>
>>>>>>>> I can't see the description of a problem which is fixed. If you fix
>>>>>>>> something, then please describe what is wrong.
>>>>>>>>
>>>>>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anand Moon
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Changes based on
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>>>>> v4.4-next/dt-samsung branch
>>>>>>>>>
>>>>>>>>> Note:
>>>>>>>>> Changes need for support of UHS-I highspeed cards.
>>>>>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>>>>>
>>>>>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> index 26decbd..58c06d3 100644
>>>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> @@ -157,6 +157,7 @@
>>>>>>>>> regulator-min-microvolt = <300>;
>>>>>>>>> regulator-max-microvolt = <300>;
>>>>>>>>> regulator-always-on;
>>>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> ldo10_reg: LDO10 {
>>>>>>>>> @@ -182,9 +183,10 @@
>>>>>>>>>
>>>>>>>>> ldo13_reg: LDO13 {
>>>>>>>>> regulator-name = "vdd_ldo13";
>>>>>>>>> -regulator-min-microvolt = <280>;
>>>>>>>>> +regulator-min-microvolt = <180>;
>>>>>>>>> regulator-max-microvolt = <280>;
>>>>>>>>> regulator-always-on;
>>>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> ldo15_reg: LDO15 {
>>>>>>>>> @@ -213,6 +215,7 @@
>>>>>>>>> regulator-min-microvolt = <280>;
>>>>&g
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
Sorry But I did not change it right way. By looking at the diff.
If the changes are wrong I will drop that changes.
I have to dig in my logs to find out why I have changes this setting.
Here is the log below, I will check If I am able to reproduce this bug
in the current kernel.
Sorry for the mess I have created.
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559940]
==
Oct 6 08:23:21 odroidxu4 kernel: [6.559943] [ INFO: possible
circular locking dependency detected ]
Oct 6 08:23:21 odroidxu4 kernel: [6.559947] 4.2.0-xu4hkdn #7 Not tainted
Oct 6 08:23:21 odroidxu4 kernel: [6.559950]
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559954] swapper/0/1 is trying
to acquire lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559972]
(>mutex){+.+...}, at: [] regmap_lock_mutex+0x1c/0x20
Oct 6 08:23:21 odroidxu4 kernel: [6.559975]
Oct 6 08:23:21 odroidxu4 kernel: [6.559975] but task is already
holding lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559987]
(prepare_lock){+.+.+.}, at: [] clk_prepare_lock+0x20/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559990] which lock already
depends on the new lock.
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993] the existing
dependency chain (in reverse order) is:
Oct 6 08:23:21 odroidxu4 kernel: [6.560004]
Oct 6 08:23:21 odroidxu4 kernel: [6.560004] -> #1 (prepare_lock){+.+.+.}:
Oct 6 08:23:21 odroidxu4 kernel: [6.560019][]
mutex_lock_nested+0x84/0x4e4
Oct 6 08:23:21 odroidxu4 kernel: [6.560026][]
clk_prepare_lock+0x60/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560033][]
clk_unprepare+0x28/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560044][]
exynos5_i2c_xfer+0x2dc/0x3a4
Oct 6 08:23:21 odroidxu4 kernel: [6.560051][]
__i2c_transfer+0x160/0xc60
Oct 6 08:23:21 odroidxu4 kernel: [6.560057][]
i2c_transfer+0x74/0xa0
Oct 6 08:23:21 odroidxu4 kernel: [6.560065][]
regmap_i2c_read+0x58/0x74
Oct 6 08:23:21 odroidxu4 kernel: [6.560072][]
_regmap_raw_read+0x130/0x654
Oct 6 08:23:21 odroidxu4 kernel: [6.560078][]
_regmap_bus_read+0x34/0x6c
Oct 6 08:23:21 odroidxu4 kernel: [6.560083][]
_regmap_read+0x7c/0x350
Oct 6 08:23:21 odroidxu4 kernel: [6.560090][]
regmap_read+0x50/0x70
Oct 6 08:23:21 odroidxu4 kernel: [6.560100][]
regulator_is_enabled_regmap+0x30/0xa4
Oct 6 08:23:21 odroidxu4 kernel: [6.560107][]
_regulator_is_enabled.part.10+0x2c/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560113][]
_regulator_do_set_voltage+0x720/0x9d0
Oct 6 08:23:21 odroidxu4 kernel: [6.560119][]
regulator_set_voltage+0xc4/0x150
Oct 6 08:23:21 odroidxu4 kernel: [6.560129][]
dw_mci_switch_voltage+0x98/0xbc
Oct 6 08:23:21 odroidxu4 kernel: [6.560136][]
mmc_power_up.part.16+0x6c/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560143][]
mmc_start_host+0x54/0x78
Oct 6 08:23:21 odroidxu4 kernel: [6.560149][]
mmc_add_host+0x6c/0x90
Oct 6 08:23:21 odroidxu4 kernel: [6.560156][]
dw_mci_probe+0x660/0xc98
Oct 6 08:23:21 odroidxu4 kernel: [6.560162][]
dw_mci_pltfm_register+0x9c/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560168][]
dw_mci_exynos_probe+0x30/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560176][]
platform_drv_probe+0x54/0xb4
Oct 6 08:23:21 odroidxu4 kernel: [6.560183][]
driver_probe_device+0x184/0
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>>> Hi Krzysztof,
>>>>
>>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>>> wrote:
>>>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>>>
>>>>>> I can't see the description of a problem which is fixed. If you fix
>>>>>> something, then please describe what is wrong.
>>>>>>
>>>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>>>
>>>>>>> Signed-off-by: Anand Moon
>>>>>>>
>>>>>>> ---
>>>>>>> Changes based on
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>>> v4.4-next/dt-samsung branch
>>>>>>>
>>>>>>> Note:
>>>>>>> Changes need for support of UHS-I highspeed cards.
>>>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>>>
>>>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> index 26decbd..58c06d3 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> @@ -157,6 +157,7 @@
>>>>>>> regulator-min-microvolt = <300>;
>>>>>>> regulator-max-microvolt = <300>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo10_reg: LDO10 {
>>>>>>> @@ -182,9 +183,10 @@
>>>>>>>
>>>>>>> ldo13_reg: LDO13 {
>>>>>>> regulator-name = "vdd_ldo13";
>>>>>>> -regulator-min-microvolt = <280>;
>>>>>>> +regulator-min-microvolt = <180>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo15_reg: LDO15 {
>>>>>>> @@ -213,6 +215,7 @@
>>>>>>> regulator-min-microvolt = <280>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>
>>>>>> Where did you get this value from? It looks wrong... My datasheet does
>>>>>> not have 12000 uV/uS.
>>>>>
>>>>
>>>>> Anand,
>>>>>
>>>>> We have actually been here:
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>>>
>>>>&
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
Setting this DDR50 capability give me this error. That's the reason to
drop this capability.
Sep 24 09:37:04 odroidxu4 kernel: [4.138418] mmc_host mmc1: Bus
speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ
div = 0)
Sep 24 09:37:04 odroidxu4 kernel: [4.138546] mmc1: new ultra high
speed DDR50 SDHC card at address
Sep 24 09:37:04 odroidxu4 kernel: [4.141585] mmcblk0: mmc1:
SL32G 29.7 GiB
Sep 24 09:37:04 odroidxu4 kernel: [4.146477] mmcblk0: error -110
sending status command, retrying
Sep 24 09:37:04 odroidxu4 kernel: [4.146577] mmcblk0: error -115
sending stop command, original cmd response 0x900, card status 0x900
Sep 24 09:37:04 odroidxu4 kernel: [4.146581] mmcblk0: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 17:43, Krzysztof Kozlowski
wrote:
> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>
>>>> I can't see the description of a problem which is fixed. If you fix
>>>> something, then please describe what is wrong.
>>>>
>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>
>>>>> Signed-off-by: Anand Moon
>>>>>
>>>>> ---
>>>>> Changes based on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> v4.4-next/dt-samsung branch
>>>>>
>>>>> Note:
>>>>> Changes need for support of UHS-I highspeed cards.
>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>
>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> index 26decbd..58c06d3 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> @@ -157,6 +157,7 @@
>>>>> regulator-min-microvolt = <300>;
>>>>> regulator-max-microvolt = <300>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>> };
>>>>>
>>>>> ldo10_reg: LDO10 {
>>>>> @@ -182,9 +183,10 @@
>>>>>
>>>>> ldo13_reg: LDO13 {
>>>>> regulator-name = "vdd_ldo13";
>>>>> -regulator-min-microvolt = <280>;
>>>>> +regulator-min-microvolt = <180>;
>>>>> regulator-max-microvolt = <280>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>> };
>>>>>
>>>>> ldo15_reg: LDO15 {
>>>>> @@ -213,6 +215,7 @@
>>>>> regulator-min-microvolt = <280>;
>>>>> regulator-max-microvolt = <280>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>
>>>> Where did you get this value from? It looks wrong... My datasheet does
>>>> not have 12000 uV/uS.
>>>
>>
>>> Anand,
>>>
>>> We have actually been here:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>
>>> That time you used 8000. I asked the same question - how did you figure
>>> out the exact value.
>>>
>>> Now we have the same question - why 12000?
>>>
>>> It is completely fine to make a mistake (I do a lot of them) but please
>>> try not to make the same mistake again.
>>>
>>> BR,
>>> Krzysztof
>>
>> I will focus more in the future to clamp down my mistakes to minimal.
>>
>>>
>>>>
>>>>> };
>>>>>
>>>>> ldo24_reg: LDO24 {
>>>>> @@ -338,6 +341,7 @@
>>>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>>>>
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Jaehoon Chung
On 12 October 2015 at 16:21, Jaehoon Chung wrote:
> On 10/12/2015 07:46 PM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>> Looks like I missed it, I will add this in the next patch,
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>>
>>
>>>>
>>>> Signed-off-by: Anand Moon
>>>>
>>>> ---
>>>> Changes based on
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>> v4.4-next/dt-samsung branch
>>>>
>>>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>>
>>> I don't get what is exactly fixed here. What was the error? What is the
>>> outcome of this fix? The log below is before or after?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>>
>>>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>>>> 1Hz, actual 1HZ div = 0)
>>>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>>>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>>>> [2.461743] mmcblk0: p1 p2
>>>
>>>> ---
>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> index 58c06d3..ba4a87b 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> @@ -364,6 +364,10 @@
>>>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>>>> bus-width = <4>;
>>>> cap-sd-highspeed;
>>>> + sd-uhs-sdr12;
>>>> + sd-uhs-sdr25;
>>>> + sd-uhs-sdr50;
>>>> + sd-uhs-sdr104;
>>>> };
>>>>
>>>> _0 {
>>>>
>>>
>>
>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>> OdroidXU3/XU4 board would not boot up using this card.
>>
>> Depending on the capability of the UHS-I card, the speed of the card
>> is selected.
>> I have just added the enhance capability feature to support them.
>>
>> On warm boot: i.e reboot of the board.
>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [4.657555] mmc1: new high speed SDHC card at address
>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.669206] mmcblk0: p1 p2
>>
>> On cold boot:: ie: power on the board.
>>
>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 1Hz, actual 1HZ div = 0)
>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.650293] IRQ56 no longer affine to CPU7
>> [4.650581] CPU7: shutdown
>> [4.658293] mmcblk0: p1 p2
>>
>> Note: Their is need to reset the PMIC
>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>> to support this feature consistently on every reboot.
>
> I don't understand...why needs to reset?
> I know it needs to switch the voltage, doesn't it?
>
I was referring to this code.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/regulator/s2mps11.c#L451
I am not sure if this need to fixed in u-boot of hardkernel or
shutdown function.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> -Anand Moon
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>>> _rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <_reg>;
>>> +vqmmc-supply = <_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>> Best regards,
>> Krzysztof
>>
>>> cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
>>> cd-inverted;
>>> pinctrl-names = "default";
>>>
>>
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req 1Hz, actual 1HZ div = 0)
[4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
[4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
[4.650293] IRQ56 no longer affine to CPU7
[4.650581] CPU7: shutdown
[4.658293] mmcblk0: p1 p2
Note: Their is need to reset the PMIC
S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
to support this feature consistently on every reboot.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
Looks like I missed it, I will add this in the next patch,
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
>
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
Changes were made to support Sandisk Ultra UHS-I class 10 card support.
OdroidXU3/XU4 board would not boot up using this card.
Depending on the capability of the UHS-I card, the speed of the card
is selected.
I have just added the enhance capability feature to support them.
On warm boot: i.e reboot of the board.
[4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[4.657555] mmc1: new high speed SDHC card at address
[4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
[4.669206] mmcblk0: p1 p2
On cold boot:: ie: power on the board.
[4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
req 1Hz, actual 1HZ div = 0)
[4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
[ 4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
[4.650293] IRQ56 no longer affine to CPU7
[4.650581] CPU7: shutdown
[4.658293] mmcblk0: p1 p2
Note: Their is need to reset the PMIC
S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
to support this feature consistently on every reboot.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 11:19, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>> On 12.10.2015 00:46, Anand Moon wrote:
>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>
>> I can't see the description of a problem which is fixed. If you fix
>> something, then please describe what is wrong.
>>
>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>
>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Note:
>>> Changes need for support of UHS-I highspeed cards.
>>> changes for vqmmc-supply for emmc is not supported.
>>>
>>> [1.831136] vdd_ldo9: ramp_delay not set
>>> [1.843049] vdd_ldo13: ramp_delay not set
>>> [1.850975] vdd_ldo15: ramp_delay not set
>>> [1.862816] vdd_sd: ramp_delay not set
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 26decbd..58c06d3 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -157,6 +157,7 @@
>>> regulator-min-microvolt = <300>;
>>> regulator-max-microvolt = <300>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo10_reg: LDO10 {
>>> @@ -182,9 +183,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> -regulator-min-microvolt = <280>;
>>> +regulator-min-microvolt = <180>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +215,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> +regulator-ramp-delay = <12000>;
>>
>> Where did you get this value from? It looks wrong... My datasheet does
>> not have 12000 uV/uS.
>
> Anand,
>
> We have actually been here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>
> That time you used 8000. I asked the same question - how did you figure
> out the exact value.
>
> Now we have the same question - why 12000?
>
> It is completely fine to make a mistake (I do a lot of them) but please
> try not to make the same mistake again.
>
> BR,
> Krzysztof
I will focus more in the future to clamp down my mistakes to minimal.
>
>>
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +341,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> +vmmc-supply = <_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>>> _rclk>;
>>> bus-width = <8>;
>>> @@ -352,6 +356,8 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> +vmmc-supply = <_reg>;
>>> +vqmmc-supply = <_reg>;
>>
>> It looks wrong. LDO13 is used in one place as VQMMC and in other as
>> VMMC. How did you figure out which regulator supplies which power domain?
>>
I refer Schematics diagram to XU4_MAIN_REV0.1.pdf
>From the PWR_PMCI_S2MPS11_LDO_CTRL document it LDO13 point to VDDQ_MMC2.
>> Best regards,
>> Krzysztof
>>
>>> cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
>>> cd-inverted;
>>> pinctrl-names = "default";
>>>
>>
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>
> This description is not entirely correct. The MMC driver already
> supports these UHS speeds (you did not any code) so you rather enabled
> it (description of bindings says "is supported").
>
> You mentioned DDR50 but I don't see respective property below.
>
> How do you know that these modes are really supported? I don't know. Can
> you convince me?
Setting this DDR50 capability give me this error. That's the reason to
drop this capability.
Sep 24 09:37:04 odroidxu4 kernel: [4.138418] mmc_host mmc1: Bus
speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ
div = 0)
Sep 24 09:37:04 odroidxu4 kernel: [4.138546] mmc1: new ultra high
speed DDR50 SDHC card at address
Sep 24 09:37:04 odroidxu4 kernel: [4.141585] mmcblk0: mmc1:
SL32G 29.7 GiB
Sep 24 09:37:04 odroidxu4 kernel: [4.146477] mmcblk0: error -110
sending status command, retrying
Sep 24 09:37:04 odroidxu4 kernel: [4.146577] mmcblk0: error -115
sending stop command, original cmd response 0x900, card status 0x900
Sep 24 09:37:04 odroidxu4 kernel: [4.146581] mmcblk0: error -84
transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
>>
>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>
> I don't get what is exactly fixed here. What was the error? What is the
> outcome of this fix? The log below is before or after?
>
> Best regards,
> Krzysztof
>
>>
>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>> 1Hz, actual 1HZ div = 0)
>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>> [2.461743] mmcblk0: p1 p2
>
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 58c06d3..ba4a87b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -364,6 +364,10 @@
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> bus-width = <4>;
>> cap-sd-highspeed;
>> + sd-uhs-sdr12;
>> + sd-uhs-sdr25;
>> + sd-uhs-sdr50;
>> + sd-uhs-sdr104;
>> };
>>
>> _0 {
>>
>
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Jaehoon Chung
On 12 October 2015 at 16:21, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> On 10/12/2015 07:46 PM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>> Looks like I missed it, I will add this in the next patch,
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>>
>>
>>>>
>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>
>>>> ---
>>>> Changes based on
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>> v4.4-next/dt-samsung branch
>>>>
>>>> Changes Fixed the UHS-I bus speed detedtion on cold boot.
>>>
>>> I don't get what is exactly fixed here. What was the error? What is the
>>> outcome of this fix? The log below is before or after?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>>
>>>> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
>>>> 1Hz, actual 1HZ div = 0)
>>>> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
>>>> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
>>>> [2.461743] mmcblk0: p1 p2
>>>
>>>> ---
>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> index 58c06d3..ba4a87b 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>> @@ -364,6 +364,10 @@
>>>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>>>> bus-width = <4>;
>>>> cap-sd-highspeed;
>>>> + sd-uhs-sdr12;
>>>> + sd-uhs-sdr25;
>>>> + sd-uhs-sdr50;
>>>> + sd-uhs-sdr104;
>>>> };
>>>>
>>>> _0 {
>>>>
>>>
>>
>> Changes were made to support Sandisk Ultra UHS-I class 10 card support.
>> OdroidXU3/XU4 board would not boot up using this card.
>>
>> Depending on the capability of the UHS-I card, the speed of the card
>> is selected.
>> I have just added the enhance capability feature to support them.
>>
>> On warm boot: i.e reboot of the board.
>> [4.649073] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [4.657555] mmc1: new high speed SDHC card at address
>> [4.663787] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.669206] mmcblk0: p1 p2
>>
>> On cold boot:: ie: power on the board.
>>
>> [4.630237] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 10000Hz, actual 1HZ div = 0)
>> [4.639820] mmc1: new ultra high speed SDR50 SDHC card at address
>> [4.646266] mmcblk0: mmc1: SL32G 29.7 GiB
>> [4.650293] IRQ56 no longer affine to CPU7
>> [4.650581] CPU7: shutdown
>> [4.658293] mmcblk0: p1 p2
>>
>> Note: Their is need to reset the PMIC
>> S2MPS11_REG_L13CTRL/S2MPS11_REG_L19CTRL registers
>> to support this feature consistently on every reboot.
>
> I don't understand...why needs to reset?
> I know it needs to switch the voltage, doesn't it?
>
I was referring to this code.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/regulator/s2mps11.c#L451
I am not sure if this need to fixed in u-boot of hardkernel or
shutdown function.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> -Anand Moon
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 12 October 2015 at 17:43, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>
>>>> I can't see the description of a problem which is fixed. If you fix
>>>> something, then please describe what is wrong.
>>>>
>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>
>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>>
>>>>> ---
>>>>> Changes based on
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>> v4.4-next/dt-samsung branch
>>>>>
>>>>> Note:
>>>>> Changes need for support of UHS-I highspeed cards.
>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>
>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> index 26decbd..58c06d3 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>> @@ -157,6 +157,7 @@
>>>>> regulator-min-microvolt = <300>;
>>>>> regulator-max-microvolt = <300>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>> };
>>>>>
>>>>> ldo10_reg: LDO10 {
>>>>> @@ -182,9 +183,10 @@
>>>>>
>>>>> ldo13_reg: LDO13 {
>>>>> regulator-name = "vdd_ldo13";
>>>>> -regulator-min-microvolt = <280>;
>>>>> +regulator-min-microvolt = <180>;
>>>>> regulator-max-microvolt = <280>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>> };
>>>>>
>>>>> ldo15_reg: LDO15 {
>>>>> @@ -213,6 +215,7 @@
>>>>> regulator-min-microvolt = <280>;
>>>>> regulator-max-microvolt = <280>;
>>>>> regulator-always-on;
>>>>> +regulator-ramp-delay = <12000>;
>>>>
>>>> Where did you get this value from? It looks wrong... My datasheet does
>>>> not have 12000 uV/uS.
>>>
>>
>>> Anand,
>>>
>>> We have actually been here:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
>>>
>>> That time you used 8000. I asked the same question - how did you figure
>>> out the exact value.
>>>
>>> Now we have the same question - why 12000?
>>>
>>> It is completely fine to make a mistake (I do a lot of them) but please
>>> try not to make the same mistake again.
>>>
>>> BR,
>>> Krzysztof
>>
>> I will focus more in the future to clamp down my mistakes to minimal.
>>
>>>
>>>>
>>>>> };
>>>>>
>>>>> ldo24_reg: LDO24 {
>>>>> @@ -338,6 +341,7 @
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 09:13, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 13.10.2015 12:08, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 05:44, Krzysztof Kozlowski >> <k.kozlow...@samsung.com> wrote: >>> On 13.10.2015 00:32, Anand Moon wrote: >>>> Hi Krzysztof, >>>> >>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski >>>> <k.kozlow...@samsung.com> wrote: >>>>> On 12.10.2015 00:46, Anand Moon wrote: >>>>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>>>> >>>>> This description is not entirely correct. The MMC driver already >>>>> supports these UHS speeds (you did not any code) so you rather enabled >>>>> it (description of bindings says "is supported"). >>>>> >>>>> You mentioned DDR50 but I don't see respective property below. >>>>> >>>>> How do you know that these modes are really supported? I don't know. Can >>>>> you convince me? >>>> >>>> Setting this DDR50 capability give me this error. That's the reason to >>>> drop this capability. >>> >>> But you mentioned it in commit message! "Added support for UHS-I ... >>> (DDR50)" >>> >>> In the same time dropping DDR50 is not an sufficient proof that "SDR50 >>> and SDR104 are really supported". >>> >> >> These changes are related to the microSD card capabilities. >> So SDR50 have better frequency over DDR50. On the same Sandisk card. >> >> When the card select the capability for DDR50 >> --- >> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address >> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB >> [4.009179] mmcblk0: error -110 sending status command, retrying >> [4.009271] mmcblk0: error -115 sending stop command, original cmd >> response 0x900, card status 0x900 >> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, >> cmd response 0x900, card status 0x0 >> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 40Hz, actual 396825HZ div = 63) >> [4.067770] Console: switching to colour frame buffer device 274x77 >> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [4.099692] mmc1: tried to reset card >> [4.101332] mmcblk0: p1 p2 >> >> >> When the card select the capability for SDR50 >> - >> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req >> 1Hz, actual 1HZ div = 0) >> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address >> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB >> [ 2.461743] mmcblk0: p1 p2 >> >> Which will relate to better read/write speed. > > Which is not an answer to my question. To none of my previous questions. OK, you are correct.Just ignore these changes. -Anand Moon > > Best regards, > Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski <k.kozlow...@samsung.com> wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> <k.kozlow...@samsung.com> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: >>>> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 10000HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. -Anand Moon > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Jaehoon Chung,
On 13 October 2015 at 08:09, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> On 10/13/2015 11:29 AM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:40, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> On 12.10.2015 23:33, Anand Moon wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>>>> <k.kozlow...@samsung.com> wrote:
>>>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>>>>> <k.kozlow...@samsung.com> wrote:
>>>>>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>>>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>>>>>
>>>>>>>> I can't see the description of a problem which is fixed. If you fix
>>>>>>>> something, then please describe what is wrong.
>>>>>>>>
>>>>>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>>>>>
>>>>>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> Changes based on
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>>>>> v4.4-next/dt-samsung branch
>>>>>>>>>
>>>>>>>>> Note:
>>>>>>>>> Changes need for support of UHS-I highspeed cards.
>>>>>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>>>>>
>>>>>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> index 26decbd..58c06d3 100644
>>>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>>>> @@ -157,6 +157,7 @@
>>>>>>>>> regulator-min-microvolt = <300>;
>>>>>>>>> regulator-max-microvolt = <300>;
>>>>>>>>> regulator-always-on;
>>>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> ldo10_reg: LDO10 {
>>>>>>>>> @@ -182,9 +183,10 @@
>>>>>>>>>
>>>>>>>>> ldo13_reg: LDO13 {
>>>>>>>>> regulator-name = "vdd_ldo13";
>>>>>>>>> -regulator-min-microvolt = <280>;
>>>>>>>>> +regulator-min-microvolt = <180>;
>>>>>>>>> regulator-max-microvolt = <280>;
>>>>>>>>> regulator-always-on;
>>>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> ldo15_reg: LDO15 {
>>>>>&g
Re: [PATCH 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> <k.kozlow...@samsung.com> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
>>>> Hi Krzysztof,
>>>>
>>>> On 12 October 2015 at 11:19, Krzysztof Kozlowski
>>>> <k.kozlow...@samsung.com> wrote:
>>>>> On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
>>>>>> On 12.10.2015 00:46, Anand Moon wrote:
>>>>>>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>>>>>>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>>>>>>
>>>>>> I can't see the description of a problem which is fixed. If you fix
>>>>>> something, then please describe what is wrong.
>>>>>>
>>>>>>> Added ramp-delay for LDO9(VDD33_USB3_0).
>>>>>>> Added ramp-delay for LDO13(VDDQ_MMC2).
>>>>>>> Added ramp-delay for LDO15(ETH_P3V3).
>>>>>>>
>>>>>>> Signed-off-by: Anand Moon <linux.am...@gmail.com>
>>>>>>>
>>>>>>> ---
>>>>>>> Changes based on
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>>>>>> v4.4-next/dt-samsung branch
>>>>>>>
>>>>>>> Note:
>>>>>>> Changes need for support of UHS-I highspeed cards.
>>>>>>> changes for vqmmc-supply for emmc is not supported.
>>>>>>>
>>>>>>> [1.831136] vdd_ldo9: ramp_delay not set
>>>>>>> [1.843049] vdd_ldo13: ramp_delay not set
>>>>>>> [1.850975] vdd_ldo15: ramp_delay not set
>>>>>>> [1.862816] vdd_sd: ramp_delay not set
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> index 26decbd..58c06d3 100644
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> @@ -157,6 +157,7 @@
>>>>>>> regulator-min-microvolt = <300>;
>>>>>>> regulator-max-microvolt = <300>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo10_reg: LDO10 {
>>>>>>> @@ -182,9 +183,10 @@
>>>>>>>
>>>>>>> ldo13_reg: LDO13 {
>>>>>>> regulator-name = "vdd_ldo13";
>>>>>>> -regulator-min-microvolt = <280>;
>>>>>>> +regulator-min-microvolt = <180>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>> };
>>>>>>>
>>>>>>> ldo15_reg: LDO15 {
>>>>>>> @@ -213,6 +215,7 @@
>>>>>>> regulator-min-microvolt = <280>;
>>>>>>> regulator-max-microvolt = <280>;
>>>>>>> regulator-always-on;
>>>>>>> +regulator-ramp-delay = <12000>;
>>>>>>
>>>>>> Where did you get this value from? It looks wrong... My datasheet does
>>>>>> not have 12000 uV/uS.
>>>>>
>>>>
>>>>> Anand,
>>>>>
>>>>> We have actually been here:
>>&
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
<k.kozlow...@samsung.com> wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit message about this.
>>
>> I don't remember to send the patch relevant to this. Hmm...
>> Well, Is this patch really signed-off by me?
>>
>> Best Regards,
>>
>> Jaehoon Chung
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>>
>>
>>
>> Some how I don't receive these mail on my email id.
>>
>> I have picked up these changes from tizen repository for OdroidXU3.
>> I have tested with this changes to detect UHS-I micro cd cards.
>> That's the reason for this email.
>
> ... and you applied it blindly without looking at actual existing
> contents and at previous commits.
>
> That is not how patches from different repositories should be cherry picked.
Sorry But I did not change it right way. By looking at the diff.
If the changes are wrong I will drop that changes.
I have to dig in my logs to find out why I have changes this setting.
Here is the log below, I will check If I am able to reproduce this bug
in the current kernel.
Sorry for the mess I have created.
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559940]
==
Oct 6 08:23:21 odroidxu4 kernel: [6.559943] [ INFO: possible
circular locking dependency detected ]
Oct 6 08:23:21 odroidxu4 kernel: [6.559947] 4.2.0-xu4hkdn #7 Not tainted
Oct 6 08:23:21 odroidxu4 kernel: [6.559950]
---
Oct 6 08:23:21 odroidxu4 kernel: [6.559954] swapper/0/1 is trying
to acquire lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559972]
(>mutex){+.+...}, at: [] regmap_lock_mutex+0x1c/0x20
Oct 6 08:23:21 odroidxu4 kernel: [6.559975]
Oct 6 08:23:21 odroidxu4 kernel: [6.559975] but task is already
holding lock:
Oct 6 08:23:21 odroidxu4 kernel: [6.559987]
(prepare_lock){+.+.+.}, at: [] clk_prepare_lock+0x20/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559990] which lock already
depends on the new lock.
Oct 6 08:23:21 odroidxu4 kernel: [6.559990]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993]
Oct 6 08:23:21 odroidxu4 kernel: [6.559993] the existing
dependency chain (in reverse order) is:
Oct 6 08:23:21 odroidxu4 kernel: [6.560004]
Oct 6 08:23:21 odroidxu4 kernel: [6.560004] -> #1 (prepare_lock){+.+.+.}:
Oct 6 08:23:21 odroidxu4 kernel: [6.560019][]
mutex_lock_nested+0x84/0x4e4
Oct 6 08:23:21 odroidxu4 kernel: [6.560026][]
clk_prepare_lock+0x60/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560033][]
clk_unprepare+0x28/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560044][]
exynos5_i2c_xfer+0x2dc/0x3a4
Oct 6 08:23:21 odroidxu4 kernel: [6.560051][]
__i2c_transfer+0x160/0xc60
Oct 6 08:23:21 odroidxu4 kernel: [6.560057][]
i2c_transfer+0x74/0xa0
Oct 6 08:23:21 odroidxu4 kernel: [6.560065][]
regmap_i2c_read+0x58/0x74
Oct 6 08:23:21 odroidxu4 kernel: [6.560072][]
_regmap_raw_read+0x130/0x654
Oct 6 08:23:21 odroidxu4 kernel: [6.560078][]
_regmap_bus_read+0x34/0x6c
Oct 6 08:23:21 odroidxu4 kernel: [6.560083][]
_regmap_read+0x7c/0x350
Oct 6 08:23:21 odroidxu4 kernel: [6.560090][]
regmap_read+0x50/0x70
Oct 6 08:23:21 odroidxu4 kernel: [6.560100][]
regulator_is_enabled_regmap+0x30/0xa4
Oct 6 08:23:21 odroidxu4 kernel: [6.560107][]
_regulator_is_enabled.part.10+0x2c/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560113][]
_regulator_do_set_voltage+0x720/0x9d0
Oct 6 08:23:21 odroidxu4 kernel: [6.560119][]
regulator_set_voltage+0xc4/0x150
Oct 6 08:23:21 odroidxu4 kernel: [6.560129][]
dw_mci_switch_voltage+0x98/0xbc
Oct 6 08:23:21 odroidxu4 kernel: [6.560136][]
mmc_power_up.part.16+0x6c/0x108
Oct 6 08:23:21 odroidxu4 kernel: [6.560143][]
mmc_start_host+0x54/0x78
Oct 6 08:23:21 odroidxu4 kernel: [6.560149][]
mmc_add_host+0x6c/0x90
Oct 6 08:23:21 odroidxu4 kernel: [6.560156][]
dw_mci_probe+0x660/0xc98
Oct 6 08:23:21 odroidxu4 kernel: [6.560162][]
dw_mci_pltfm_register+0x9c/0xa8
Oct 6 08:23:21 odroidxu4 kernel: [6.560168][]
dw_mci_exynos_probe+0x30/0x38
Oct 6 08:23:21 odroidxu4 kernel: [6.560176][]
platform_drv_probe+0x54/0xb4
Oct 6 08:23:21 odroidxu4 kernel: [6.560183][]
driver
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
Looks like my changes have introduce another bug so please ignore this changes.
-Anand Moon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung <jh80.ch...@samsung.com> wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
>>>>
>>>> Anand,
>>>>
>>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>>> the commit message about this.
>>>
>>> I don't remember to send the patch relevant to this. Hmm...
>>> Well, Is this patch really signed-off by me?
>>>
>>> Best Regards,
>>>
>>> Jaehoon Chung
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>>
>>>
>>>
>>> Some how I don't receive these mail on my email id.
>>>
>>> I have picked up these changes from tizen repository for OdroidXU3.
>>> I have tested with this changes to detect UHS-I micro cd cards.
>>> That's the reason for this email.
>
> It seems to make manually, right?
> I have checked the tizen repository.
>
> The below is
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -335,7 +335,9 @@
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + cd-gpios = < 2 0>;
> + cd-inverted;
> + pinctrl-0 = <_clk _cmd _bus1 _bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> };
>
>
>
> Yours
>
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
> + pinctrl-0 = <_clk _cmd _cd _bus4>;
>
> Did you know what differ? :)
>
My mistake, I will drop the changes. Sorry for the whole mess.
-Anand Moon
> Best Regards,
> Jaehoon Chung
>
>>
>> ... and you applied it blindly without looking at actual existing
>> contents and at previous commits.
>>
>> That is not how patches from different repositories should be cherry picked.
>>
>> Best regards,
>> Krzysztof
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon Reviewed-by: Krzysztof Kozlowski --- Changes: Fixed the commit message thanks to Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 1ff2bfa..5d1937b 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -61,6 +61,7 @@ CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=m CONFIG_NETDEVICES=y CONFIG_SMSC911X=y +CONFIG_USB_RTL8152=y CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 2/2] ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
Odroid XU4 has a RTL8153-CG gigabit Ethernet adapter, connected over USB 3.0. Signed-off-by: Anand Moon Reviewed-by: Krzysztof Kozlowski --- Changes: Fixed the commit message thanks to Krzysztof KozlowskAdded reviewed by Krzysztof Kozlowski Added reviewed by Krzysztof Kozlowski Build as r8152 as module --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 03deb7f..966ffc1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -221,6 +221,7 @@ CONFIG_BROADCOM_PHY=y CONFIG_ICPLUS_PHY=y CONFIG_MICREL_PHY=y CONFIG_USB_PEGASUS=y +CONFIG_USB_RTL8152=m CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC75XX=y CONFIG_USB_NET_SMSC95XX=y -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
