kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()

[Paolo Pisati]

I've been experiencing solid hangs on my beaglexm with v3.7 after
kexec:

here is my .config (omap2plus + EHCI/OHCI + CPUFREQ + DEVTMP):

http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/config

here is the diff i added to get some debugging:

http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/dpll-debug.diff

here is a trace of the kexeced kernel:

http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/kexec-boot.txt

Since i'n not familiar with those dplls, can anyone shed some light?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()

[Paolo Pisati]

On Tue, Dec 11, 2012 at 08:20:13PM +, Paul Walmsley wrote:
> On Tue, 11 Dec 2012, Paolo Pisati wrote:
> 
> > I've been experiencing solid hangs on my beaglexm with v3.7 after
> > kexec:
> 
> Does it crash if you boot v3.7 directly from the bootloader, i.e., without 
> kexec?

nope, works perfectly fine when booted from the bootlader.

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()

[Paolo Pisati]

On Tue, Dec 11, 2012 at 08:32:25PM +, Paul Walmsley wrote:
> On Tue, 11 Dec 2012, Paul Walmsley wrote:
> 
> > On Tue, 11 Dec 2012, Paolo Pisati wrote:
> > 
> > > I've been experiencing solid hangs on my beaglexm with v3.7 after
> > > kexec:
> > 
> > Does it crash if you boot v3.7 directly from the bootloader, i.e., without 
> > kexec?
> 
> Also you might want to verify that the voltage on VDD1 is what the kernel 
> thinks it is:
> 
> [5.638183] notification 0 of frequency transition to 80 kHz
> [5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV
> 
> You can probe this with a multimeter on one side of the VDD1 inductor.  
> It's on the underside of the Beagle-XM near the DC input jack - it's 
> marked "L4" on the silkscreen text.

uhm no, my multimeter says it's around 113mV...

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] regulator: core: if voltage scaling fails, restore original voltage values

[Paolo Pisati]

Signed-off-by: Paolo Pisati 
---
 drivers/regulator/core.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
 {
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+   int old_min_uV, old_max_uV;
 
mutex_lock(&rdev->mutex);
 
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, &min_uV, &max_uV);
if (ret < 0)
goto out;
+   
+   /* restore original values in case of error */
+   old_min_uV = regulator->min_uV;
+   old_max_uV = regulator->max_uV;
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;
 
ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
if (ret < 0)
-   goto out;
+   goto out2;
 
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+   if (ret < 0)
+   goto out2;
+   
 out:
mutex_unlock(&rdev->mutex);
return ret;
+out2:
+   regulator->min_uV = old_min_uV;
+   regulator->max_uV = old_max_uV;
+   mutex_unlock(&rdev->mutex);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_voltage);
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] regulator: core: if voltage scaling fails, restore original

[Paolo Pisati]

And after a second look it's clear what's going on:

[...]
[5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV
[5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva
[5.590332] cpu cpu0: omap_target: unable to scale voltage up.
[1]
[5.596649] notification 1 of frequency transition to 30 kHz
[5.603179] FREQ: 30 - CPU: 0
[5.606597] governor: change or update limits
[5.611572] __cpufreq_governor for CPU 0, event 3
[5.616699] setting to 80 kHz because of event 3
[5.622039] target for CPU 0: 80 kHz, relation 1
[5.627441] request for target 80 kHz (relation: 1) for cpu 0
[5.634063] target is 2 (80 kHz, 2)
[5.638183] notification 0 of frequency transition to 80 kHz
[5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV
[2]
[hangs here]

first time[1] it tries to ramp up frequency (and thus voltage),
regulator_set_voltage() returns an error and we exit:

omap-cpufreq.c::omap_target():

...
dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n",
freqs.old / 1000, volt_old ? volt_old / 1000 : -1,
freqs.new / 1000, volt ? volt / 1000 : -1);

/* scaling up?  scale voltage before frequency */
if (mpu_reg && (freqs.new > freqs.old)) {
r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
if (r < 0) {
dev_warn(mpu_dev, "%s: unable to scale voltage up.\n",
 __func__);
freqs.new = freqs.old;
goto done;
}
}

ret = clk_set_rate(mpu_clk, freqs.new * 1000);
...

but inside regulator_set_voltage(), we save the new regulator voltage before
actually ramping up:

core.c::regulator_set_voltage():
...
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;

ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
if (ret < 0)
goto out2;

ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);  <-- ERROR!!!
if (ret < 0)
goto out2;
...


and by the time we try to change frequency again[2], regulator_set_voltage()
is a noop because it thinks we are already at the desired voltage:

core.c::regulator_set_voltage():

...
/* If we're setting the same range as last time the change
 * should be a noop (some cpufreq implementations use the same
 * voltage for multiple frequencies, for example).
 */
if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
goto out;
...

and as a consequence, in omap_target(), we call clk_set_rate() with
the wrong voltage.

The attached patch restore the original regulator voltage values in case
of an error.

CCing stable@ since it predates 2.6.38rc1 when the noop optimization was
introduced:

commit 95a3c23ae620c1b4c499746e70f4034bdc067737
Author: Mark Brown 
Date:   Thu Dec 16 15:49:37 2010 +

regulator: Optimise out noop voltage changes

Paolo Pisati (1):
  regulator: core: if voltage scaling fails, restore original voltage
values

 drivers/regulator/core.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] regulator: core: if voltage scaling fails, restore original

[Paolo Pisati]

On Thu, Dec 13, 2012 at 05:15:33AM +, Mark Brown wrote:
> On Wed, Dec 12, 2012 at 12:45:52PM +0100, Paolo Pisati wrote:
> > And after a second look it's clear what's going on:
> 
> After a second look at what?  You've not provided any context, I've no
> idea what you're talking about here.

forgot the --in-reply-to=..., i'll resend as a new thread.

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [resend] regulator: core: if voltage scaling fails, restore original values

[Paolo Pisati]

 * should be a noop (some cpufreq implementations use the same
 * voltage for multiple frequencies, for example).
 */
if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
goto out;
...

and as a consequence, in omap_target(), we call clk_set_rate() with
the wrong voltage.

The attached patch restore the original regulator voltage values in case
of an error.

CCing stable@ since it predates 2.6.38rc1 when the noop optimization was
introduced:

commit 95a3c23ae620c1b4c499746e70f4034bdc067737
Author: Mark Brown 
Date:   Thu Dec 16 15:49:37 2010 +

regulator: Optimise out noop voltage changes

Paolo Pisati (1):
  regulator: core: if voltage scaling fails, restore original voltage
values

 drivers/regulator/core.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] regulator: core: if voltage scaling fails, restore original voltage values

[Paolo Pisati]

Signed-off-by: Paolo Pisati 
Tested-by: Robert Nelson 
---
 drivers/regulator/core.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..c347fd0 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
 {
struct regulator_dev *rdev = regulator->rdev;
int ret = 0;
+   int old_min_uV, old_max_uV;
 
mutex_lock(&rdev->mutex);
 
@@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, 
int min_uV, int max_uV)
ret = regulator_check_voltage(rdev, &min_uV, &max_uV);
if (ret < 0)
goto out;
+   
+   /* restore original values in case of error */
+   old_min_uV = regulator->min_uV;
+   old_max_uV = regulator->max_uV;
regulator->min_uV = min_uV;
regulator->max_uV = max_uV;
 
ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
if (ret < 0)
-   goto out;
+   goto out2;
 
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
-
+   if (ret < 0)
+   goto out2;
+   
 out:
mutex_unlock(&rdev->mutex);
return ret;
+out2:
+   regulator->min_uV = old_min_uV;
+   regulator->max_uV = old_max_uV;
+   mutex_unlock(&rdev->mutex);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(regulator_set_voltage);
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values

[Paolo Pisati]

On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote:
> On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote:
> > Signed-off-by: Paolo Pisati 
> > Tested-by: Robert Nelson 
> 
> please read Documentation/stable_kernel_rules.txt, you'll see this is
> wrong.

you mean that i should have waited for the commit to hit Linus's tree before
cc-ing stable?

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging/omapdrm: garbage collect OMAP_DSS_DISPLAY_SUSPENDED

[Paolo Pisati]

Compilation fix - leftover from:

commit 998c336d4c7183301ed6a6ca93952f63e3cf694f
Author: Tomi Valkeinen 
Date:   Wed May 30 13:26:00 2012 +0300

OMAPDSS: remove omap_dss_device's suspend/resume

Cc: stable  # v3.7
Signed-off-by: Paolo Pisati 
---
 drivers/staging/omapdrm/omap_connector.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_connector.c 
b/drivers/staging/omapdrm/omap_connector.c
index 91edb3f..ff25467 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -113,9 +113,6 @@ static void omap_connector_dpms(struct drm_connector 
*connector, int mode)
if (mode == DRM_MODE_DPMS_ON) {
/* store resume info for suspended displays */
switch (dssdev->state) {
-   case OMAP_DSS_DISPLAY_SUSPENDED:
-   dssdev->activate_after_resume = true;
-   break;
case OMAP_DSS_DISPLAY_DISABLED: {
int ret = dssdev->driver->enable(dssdev);
if (ret) {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging/omapdrm: garbage collect OMAP_DSS_DISPLAY_SUSPENDED

[Paolo Pisati]

On Thu, Jan 10, 2013 at 09:42:27PM +0100, Paolo Pisati wrote:
> Compilation fix - leftover from:
> 
> commit 998c336d4c7183301ed6a6ca93952f63e3cf694f
> Author: Tomi Valkeinen 
> Date:   Wed May 30 13:26:00 2012 +0300
> 
> OMAPDSS: remove omap_dss_device's suspend/resume
> 
> Cc: stable  # v3.7
> Signed-off-by: Paolo Pisati 

bah, never mind:

https://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=commit;h=f5f9454c2145fa018c9808597739abce67114ac7

fixes the compilation breakagage.
It could be useful for v3.7 stable tough.
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc

[Paolo Pisati]

Hi,

i can't boot my pandaes with 3.8rc4 + cpu_freq + ehci/ohci enabled, as it 
usually
hangs with:

[   26.718322] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 
0, t=2690 jiffies, g=4294967100, c=4294967099, q=749)
[   26.730682] Task dump for CPU 1:
[   26.734069] udevd   R running  0   772  1 0x0002
[   26.740783] [] (__schedule+0x34c/0x728) from [] 
(0xeebbaa70)

complete dmesg with clks warnings and a "BUG: spinlock wrong CPU on CPU#1"
here:

http://paste.ubuntu.com/1563384/

sometimes it randomly oopses around usb:

[4.922180] hub 1-1:1.0: port 1: status 0101 change 0001
[4.936706] Unable to handle kernel NULL pointer dereference at virtual 
address 0004
[4.945220] pgd = c0004000
[4.948059] [0004] *pgd=
[4.951843] Internal error: Oops: 5 [#1] SMP ARM
[4.956695] Modules linked in:
[4.959899] CPU: 1Tainted: GW (3.8.0-rc4-00139-g1d85490 #1)
[4.967224] PC is at _set_bit+0x1c/0x40
[4.971252] LR is at out_of_memory+0x7c/0x2f8
[4.975830] pc : []lr : []psr: 6193
[4.975830] sp : ee839a40  ip :   fp : 
[4.987884] r10: 000e  r9 : c088f5d8  r8 : c07ab33c
[4.993377] r7 : ee8373c0  r6 : c07d1014  r5 : c1547e90  r4 : 
[5.000244] r3 : 0004  r2 : 0001  r1 : 0004  r0 : 
[5.007080] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[5.014862] Control: 10c53c7d  Table: 8000404a  DAC: 0017
[5.020904] Process swapper/0 (pid: 1, stack limit = 0xee838240)
[5.023437] usb 1-1: link qh256-0001/eeda8b00 start 1 [1/0 us]
[5.023468] hub 1-1:1.0: state 7 ports 5 chg 0002 evt 
[5.023773] hub 1-1:1.0: port 1, status 0101, change , 12 Mb/s

Complete dmesg here:

http://paste.ubuntu.com/1563423/

Or:

[4.927307] Unable to handle kernel NULL pointer dereference at virtual 
address 0014
[4.935821] pgd = c0004000
[4.938659] [0014] *pgd=
[4.942413] Internal error: Oops: 5 [#1] SMP ARM
[4.947265] Modules linked in:
[4.950469] CPU: 1Tainted: GW (3.8.0-rc4 #1)
[4.956420] PC is at rcu_irq_exit+0x20/0xc4
[4.960845] LR is at irq_enter+0x18/0x70
[4.964965] pc : []lr : []psr: a193
[4.964965] sp : ee87de90  ip : fff2  fp : ee87df54
[4.977020] r10: c07491d0  r9 :   r8 : 0001
[4.982482] r7 : c073ae80  r6 : a193  r5 : 0001  r4 : ee87c000
[4.989349] r3 : c0745d88  r2 :   r1 : 0560  r0 : c0049a0c
[4.992736] usb 1-1: link qh256-0001/eedb0f80 start 1 [1/0 us]
[4.992767] hub 1-1:1.0: state 7 ports 5 chg 0002 evt 
[4.993255] hub 1-1:1.0: port 1, status 0101, change , 12 Mb/s

Complete dmesg here:

http://paste.ubuntu.com/1563483/

Same happens with latest linus/master:

1d85490 Merge tag '3.8-pci-fixes-2' of ...

Config can be found here:

http://people.canonical.com/~ppisati/38rc4/config.omap2plus_cpufreq

Disabling cpufreq i can get my board to boot, and 3.7.y is working fine.

Any clue?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()

[Paolo Pisati]

I keep getting this BUG() when there's IPV6 traffic in in my lan on a panda 
board
with these configs:

-start from a vanilla omap config
(make ARCH=arm omap2plus_defconfig)

-enable IPV6 and PREEMPT_VOLUNTARY

-turn off

CONFIG_DEBUG_SPINLOCK
CONFIG_DEBUG_MUTEXES
CONFIG_DEBUG_LOCK_ALLOC
CONFIG_PROVE_LOCKING
CONFIG_LOCKDEP
CONFIG_TRACE_IRQFLAGS

(or apply this patch fragment:
http://people.canonical.com/~ppisati/panda_ipv6/config_lock_off.patch)

-enable some useful options (like EHCI for my usb disk, etcetc)

-finish off the build

make ARCH=arm olddefconfig
make ARCH=arm zImage

-boot the board, wait for some ipv6 traffic:

IP6 fe80::213:20ff:fefb:6364.mdns > ff02::fb.mdns: 0 PTR (QM)? 
_mumble._tcp.local. (36)

and enjoy:

[Thu Feb 21 10:23:07 2013] BUG: scheduling while atomic: swapper/0/0/0x4100
[Thu Feb 21 10:23:07 2013] Modules linked in:
[Thu Feb 21 10:23:07 2013] [] (unwind_backtrace+0x0/0xf0) from 
[] (__schedule_bug+0x48/0x5c)
[Thu Feb 21 10:23:07 2013] [] (__schedule_bug+0x48/0x5c) from 
[] (__schedule+0x700/0x740)
[Thu Feb 21 10:23:07 2013] [] (__schedule+0x700/0x740) from 
[] (__cond_resched+0x24/0x34)
[Thu Feb 21 10:23:07 2013] [] (__cond_resched+0x24/0x34) from 
[] (_cond_resched+0x3c/0x44)
[Thu Feb 21 10:23:07 2013] [] (_cond_resched+0x3c/0x44) from 
[] (do_alignment+0x178/0x78c)
[Thu Feb 21 10:23:07 2013] [] (do_alignment+0x178/0x78c) from 
[] (do_DataAbort+0x34/0x98)
[Thu Feb 21 10:23:07 2013] [] (do_DataAbort+0x34/0x98) from 
[] (__dabt_svc+0x40/0x60)
[Thu Feb 21 10:23:07 2013] Exception stack(0xc0763d70 to 0xc0763db8)
[Thu Feb 21 10:23:07 2013] 3d60: e97e805e 
e97e806e 2c00 1100
[Thu Feb 21 10:23:07 2013] 3d80: ea86bb00 002c 0011 e97e807e c076d2a8 
e97e805e e97e806e 002c
[Thu Feb 21 10:23:07 2013] 3da0: 3d00 c0763dbc c04b98fc c02a8490 0113 

[Thu Feb 21 10:23:07 2013] [] (__dabt_svc+0x40/0x60) from 
[] (__csum_ipv6_magic+0x8/0xc8)

here you can find a .config for a 3.8 kernel showing this problem:

http://people.canonical.com/~ppisati/panda_ipv6/config

and a precompiled zImage:

http://people.canonical.com/~ppisati/panda_ipv6/zImage

any idea how can i debug this?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()

[Paolo Pisati]

On Fri, Feb 22, 2013 at 12:36:37PM +, Russell King - ARM Linux wrote:
> On Thu, Feb 21, 2013 at 10:48:19AM +0100, Paolo Pisati wrote:
> > any idea how can i debug this?
> 
> Please try this patch, and report back whether it solves your problem.
> Thanks.

yes, it solves my problem: any chance we can see it in 3.9 or 3.8.x?

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()

[Paolo Pisati]

On Mon, Feb 25, 2013 at 04:14:01PM +, Russell King - ARM Linux wrote:
>
> I was just looking to send a chase for this, because I'm about to
> remerge my tree and I wanted this patch committed.
> 
> Can I use your name and email address in the commit for the Reported-by
> and Tested-by tags (which will be published in the kernel repository)
> please?  Thanks.

absolutely:

Reported-by: Paolo Pisati 
Tested-by: Paolo Pisati 

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

3.15+: omap4: mmc: multi_v7: can't boot off mmc

[Paolo Pisati]

I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my
pandaboard:

[1.698272] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517
[1.705139] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[1.712890] omap_hsmmc 480d5000.mmc: unable to get vmmc regulator -517
[1.719787] platform 480d5000.mmc: Driver omap_hsmmc requests probe deferral
[1.727691] sdhci-pltfm: SDHCI platform and OF driver helper
[1.734619] usbcore: registered new interface driver usbhid
[1.740478] usbhid: USB HID core driver
[1.749359] TCP: cubic registered
[1.752838] NET: Registered protocol family 17
[1.757690] Key type dns_resolver registered
[1.762756] Power Management for TI OMAP4+ devices.
[1.767883] Power Management for TI OMAP4.
[1.772186] OMAP4 PM: u-boot >= v2012.07 is required for full PM support
[1.779296] ThumbEE CPU extension supported.
[1.779296] Registering SWP/SWPB emulation handler
[1.790008] vwl1271: 1800 mV 
[1.794952] Skipping twl internal clock init and using bootloader value 
(unknown osc rate)
[1.805358] twl 0-0048: PIH (irq 39) nested IRQs
[1.811340] twl_rtc rtc.14: Power up reset detected.
[1.817260] twl_rtc rtc.14: Enabling TWL-RTC
[1.824249] twl_rtc rtc.14: rtc core: registered rtc.14 as rtc0
[1.831451] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV 
[1.837677] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV 
[1.844024] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV 
[1.850311] VMMC: 1200 <--> 3000 mV at 3000 mV 
[1.855957] VPP: 1800 <--> 2500 mV at 1900 mV 
[1.861572] VUSIM: 1200 <--> 2900 mV at 1800 mV 
[1.866577] VDAC: 1800 mV 
[1.869964] VANA: 2100 mV 
[1.874114] VCXIO: 1800 mV 
[1.877624] VUSB: 3300 mV 
[1.881317] V1V8: 1800 mV 
[1.884979] V2V1: 2100 mV 
[1.967407] usb 1-1: new high-speed USB device number 2 using ehci-omap
[2.094512] omap_i2c 4807.i2c: bus 0 rev0.10 at 400 kHz
[2.104583] omap_i2c 48072000.i2c: bus 1 rev0.10 at 400 kHz
[2.114044] omap_i2c 4806.i2c: bus 2 rev0.10 at 100 kHz
[2.121582] hub 1-1:1.0: USB hub found
[2.125854] hub 1-1:1.0: 5 ports detected
[2.131744] omap_i2c 4835.i2c: bus 3 rev0.10 at 400 kHz
[2.140686] omap_hsmmc 4809c000.mmc: pins are not configured from the driver
[2.321166] twl_rtc rtc.14: setting system clock to 2000-01-01 00:00:00 UTC 
(946684800)
[2.336578] ALSA device list:
[2.339782]   No soundcards found.
[2.339782] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): 
error -6
[2.352478] Please append a correct "root=" boot option; here are the 
available partitions:
[2.361297] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[2.367980] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 
#70
[2.377716] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[2.385864] [] (show_stack) from [] 
(dump_stack+0x88/0x98)
[2.390289] [] (dump_stack) from [] (panic+0xa0/0x208)
[2.400695] [] (panic) from [] 
(mount_block_root+0x1a0/0x230)
[2.408569] [] (mount_block_root) from [] 
(mount_root+0x108/0x110)
[2.408569] [] (mount_root) from [] 
(prepare_namespace+0x158/0x1a0)
[2.425292] [] (prepare_namespace) from [] 
(kernel_init_freeable+0x1cc/0x1dc)
[2.430084] [] (kernel_init_freeable) from [] 
(kernel_init+0x8/0xf0)
[2.443145] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x3c)
[2.447967] CPU0: stopping
[2.451110] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 
#70
[2.451110] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[2.451110] [] (show_stack) from [] 
(dump_stack+0x88/0x98)
[2.451110] [] (dump_stack) from [] 
(handle_IPI+0x148/0x174)
[2.477386] [] (handle_IPI) from [] 
(gic_handle_irq+0x58/0x5c)
[2.477386] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x50)
[2.477386] Exception stack(0xc0b6def0 to 0xc0b6df38)
[2.506256] dee0:  c0b7bf54 
c0b7bf54 004c
[2.506256] df00: 91be7a33  92080d44  eaf94de8 c0c8f2bc 
 ea4bdd94
[2.523437] df20: 0010 c0b6df38 c06bcbf8 c06bcc04 6153 
[2.523437] [] (__irq_svc) from [] 
(cpuidle_enter_state+0x68/0xf8)
[2.523437] [] (cpuidle_enter_state) from [] 
(cpuidle_enter_state_coupled+0x130/0x378)
[2.523437] [] (cpuidle_enter_state_coupled) from [] 
(cpu_startup_entry+0x200/0x230)
[2.558868] [] (cpu_startup_entry) from [] 
(start_kernel+0x348/0x354)
[2.567474] [] (start_kernel) from [<80208074>] (0x80208074)
[2.567474] ---[ end Kernel panic - not syncing: VFS: Unable to mount root 
fs on unknown-block(0,0)

i tracked it down to the "PBIAS on DT" merge in 3.15-rc1:

commit 97e18dc007546fce8e99098480b921a02ebb3037
Merge: 042f7b7 c674801
Author: Linus Torvalds 
Date:   Wed Apr 9 08:39:39 2014 -0700

Merge tag 'mmc-updates-for-3.15-rc1' of 
git://git.kernel.org/

Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc

[Paolo Pisati]

On Wed, Sep 10, 2014 at 11:50:01AM -0500, Nishanth Menon wrote:
> On 17:33-20140910, Paolo Pisati wrote:
> > I'm having an hard time making the vanilla v7_defconfig boot off the mmc on 
> > my
> > pandaboard:
> 
> V3.15:
> https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt
> https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt

are you 100% sure that this is a pure multi_v7_defconfig? because, by default, 
REGULATOR_PBIAS is off.

> You might be interested in using partuuid to be careful about the probe
> order deltas that may take place.

i'm not sure i understood what you mean here.
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc

[Paolo Pisati]

On Thu, Sep 11, 2014 at 10:01:32AM +0200, Paolo Pisati wrote:
> On Wed, Sep 10, 2014 at 11:50:01AM -0500, Nishanth Menon wrote:
> > On 17:33-20140910, Paolo Pisati wrote:
> > > I'm having an hard time making the vanilla v7_defconfig boot off the mmc 
> > > on my
> > > pandaboard:
> > 
> > V3.15:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt
> > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt
> 
> are you 100% sure that this is a pure multi_v7_defconfig? because, by 
> default, 
> REGULATOR_PBIAS is off.
> 
> > You might be interested in using partuuid to be careful about the probe
> > order deltas that may take place.
> 
> i'm not sure i understood what you mean here.

ok, nevermind, i found the problem, i forgot the "rootwait" parameter in 
bootargs.
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

omap_wdt: node present in device-tree but kmod is not autoloaded

[Paolo Pisati]

The question is two-folded, hence the crossposting.

I have a kernel that runs perfectly on my beaglebone black, except for one thing
- the kmod for the watchdog is not autoloaded upon boot albeit the device-tree
node is present:

ubuntu@beaglebone:~$ dmesg | grep wdt
ubuntu@beaglebone:~$ ll /dev/watch* 
ls: cannot access /dev/watch*: No such file or directory
ubuntu@beaglebone:~$ ls -la /proc/device-tree/ocp/wdt\@44e35000/
total 0
drwxr-xr-x  2 root root  0 Aug 25 13:43 .
drwxr-xr-x 54 root root  0 Aug 25 13:43 ..
-r--r--r--  1 root root 13 Aug 25 13:43 compatible
-r--r--r--  1 root root  4 Aug 25 13:43 interrupts
-r--r--r--  1 root root  4 Aug 25 13:43 name
-r--r--r--  1 root root  8 Aug 25 13:43 reg
-r--r--r--  1 root root 10 Aug 25 13:43 ti,hwmods
ubuntu@beaglebone:~$ cat /proc/device-tree/ocp/wdt\@44e35000/compatible 
ti,omap3-wdt
ubuntu@beaglebone:~$ ls -la /sys/bus/platform/devices/ocp/*wdt*
total 0
drwxr-xr-x  3 root root0 Aug 25 13:49 ./
drwxr-xr-x 33 root root0 Aug 25 13:49 ../
-rw-r--r--  1 root root 4096 Aug 25 13:49 driver_override
-r--r--r--  1 root root 4096 Aug 25 13:49 modalias
lrwxrwxrwx  1 root root0 Aug 25 13:49 of_node ->
../../../../firmware/devicetree/base/ocp/wdt@44e35000/
drwxr-xr-x  2 root root0 Aug 25 13:49 power/
lrwxrwxrwx  1 root root0 Aug 25 13:49 subsystem -> ../../../../bus/platform/
-rw-r--r--  1 root root 4096 Aug 25 13:49 uevent

and if i manually load the module:

ubuntu@beaglebone:~$ sudo modprobe omap_wdt
ubuntu@beaglebone:~$ dmesg | grep wdt
[  388.104283] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
ubuntu@beaglebone:~$ ls -la /dev/watchdog*
crw--- 1 root root  10, 130 Aug 25 13:46 /dev/watchdog
crw--- 1 root root 251,   0 Aug 25 13:46 /dev/watchdog0
ubuntu@beaglebone:~$ ls -la /sys/bus/platform/devices/ocp/*wdt* 

total 0
drwxr-xr-x  3 root root0 Aug 25 13:53 .
drwxr-xr-x 33 root root0 Aug 25 13:49 ..
lrwxrwxrwx  1 root root0 Aug 25 13:53 driver ->
../../../../bus/platform/drivers/omap_wdt
-rw-r--r--  1 root root 4096 Aug 25 13:49 driver_override
-r--r--r--  1 root root 4096 Aug 25 13:49 modalias
lrwxrwxrwx  1 root root0 Aug 25 13:49 of_node ->
../../../../firmware/devicetree/base/ocp/wdt@44e35000
drwxr-xr-x  2 root root0 Aug 25 13:49 power
lrwxrwxrwx  1 root root0 Aug 25 13:49 subsystem -> ../../../../bus/platform
-rw-r--r--  1 root root 4096 Aug 25 13:49 uevent

and then the device works as expected.

So here are my questions:

1) My understanding was that, once a device node was present in the device-tree
and there was a compatible driver available, it would have been autoloaded, so 
why it's
not happening here?

2) And more importantly, how do i debug these situations?
Building a kernel with the driver built-in, and comparing the two dmesgs, didn't
show any noticeable difference either.

Any idea?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM/dts: hdmi-codec: panda/es dt entries

[Paolo Pisati]

Signed-off-by: Paolo Pisati 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
 arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
+   ti,audio-codec = <&hdmi_audio>;
 
ti,mclk-freq = <3840>;
 
@@ -57,7 +63,8 @@
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
};
 
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
 };
 
 /* PandaboardES has external pullups on SCL & SDA */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [RESEND] ARM/dts: hdmi-codec: panda/es dt entries

[Paolo Pisati]

Signed-off-by: Paolo Pisati 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
 arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
+   ti,audio-codec = <&hdmi_audio>;
 
ti,mclk-freq = <3840>;
 
@@ -57,7 +63,8 @@
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
};
 
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
 };
 
 /* PandaboardES has external pullups on SCL & SDA */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries

[Paolo Pisati]

HDMI codec dummy entries for Panda/ES.

Signed-off-by: Paolo Pisati 
---
Depends on "0f7f3d1 ASoC: hdmi-codec: Add devicetree binding with 
documentation", eligible for a 3.14-rcX fix.

 arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
 arch/arm/boot/dts/omap4-panda-es.dts  |3 ++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,9 +36,15 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
+   ti,audio-codec = <&hdmi_audio>;
 
ti,mclk-freq = <3840>;
 
@@ -57,7 +63,8 @@
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
};
 
/* HS USB Port 1 Power */
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 816d1c9..70152d6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -23,7 +23,8 @@
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
-   "AFMR", "Line In";
+   "AFMR", "Line In",
+   "HDMI Out", "TX";
 };
 
 /* PandaboardES has external pullups on SCL & SDA */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries

[Paolo Pisati]

On Wed, Feb 19, 2014 at 10:15:24AM +0200, Peter Ujfalusi wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
> > b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 88c6a05..f4aeaa1 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -36,9 +36,15 @@
> > };
> > };
> >  
> > +   hdmi_audio: hdmi_audio@0 {
> > +   compatible = "linux,hdmi-audio";
> > +   status = "okay";
> > +   };
> > +
> > sound: sound {
> > compatible = "ti,abe-twl6040";
> > ti,model = "PandaBoard";
> > +   ti,audio-codec = <&hdmi_audio>;
> 
> I don't think this is going to work. The omap-abe-twl6040 machine driver only
> handles mcpdm and dmic right know.
> 'ti,audio-codec' is not even supported and it is kind of misleading naming in
> this context since twl6040 is also a codec, so why only the dummy-hdmi codec
> deserves to be called as codec.

i see what you mean: i thought that hdmi_audio to actually work had to be
referenced inside the sound node (hence my inclusion there) but i was wrong and
it had nothing to do with twl6040,
would this one be ok for you?

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..b6dd458 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -36,6 +36,11 @@
};
};
 
+   hdmi_audio: hdmi_audio@0 {
+   compatible = "linux,hdmi-audio";
+   status = "okay";
+   };
+
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";


> Furthermore: we have the omap-hdmi-card machine driver to handle the HDMI
> audio. It lacks DT support AFAIK but should not be a big deal to add the 
> bindings.
> To get the hdmi audio working you also need to have phandle for the omap-hdmi
> DAI, the codec alone is not enough.
>
 
you mean sound/soc/omap/omap-hdmi-card.c? that's exactly what i'm trying to fix.

With the above patch, plus:

-CONFIG_DISPLAY_CONNECTOR_HDMI=m
+CONFIG_DISPLAY_CONNECTOR_HDMI=y
 CONFIG_DISPLAY_ENCODER_TFP410=m
-CONFIG_DISPLAY_ENCODER_TPD12S015=m
+CONFIG_DISPLAY_ENCODER_TPD12S015=y

to make the omap-hdmi-audio-dai attach (sound/soc/omap/omap-hdmi.c)
and something like this (that is not upstreamable as i understand
but is an unfortunate fallout from the board removal[*]):

--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -335,6 +335,11 @@ static struct platform_device omap_hdmi_audio = {
.id = -1,
 };
 
+static struct platform_device hdmi_audio_codec = {
+   .name   = "hdmi-audio-codec",
+   .id = -1,
+};
+
 static void __init omap_init_hdmi_audio(void)
 {
struct omap_hwmod *oh;
@@ -349,6 +354,7 @@ static void __init omap_init_hdmi_audio(void)
 "Can't build omap_device for omap-hdmi-audio-dai.\n");
 
platform_device_register(&omap_hdmi_audio);
+   platform_device_register(&hdmi_audio_codec);
 }
 #else
 static inline void omap_init_hdmi_audio(void) {}

i finally get my OMAPHDMI device back:

flag@panda:~$ cat /proc/asound/cards 
 0 [OMAPHDMI   ]: OMAPHDMI - OMAPHDMI
  OMAPHDMI
 1 [PandaBoardES   ]: PandaBoardES - PandaBoardES
  PandaBoardES

[*]: in arch/arm/mach-omap2/board-omap4panda.c we had:

-static struct platform_device panda_hdmi_audio_codec = {
-   .name   = "hdmi-audio-codec",
-   .id = -1,
-};

-static struct platform_device *panda_devices[] __initdata = {
...
-   &panda_hdmi_audio_codec,
...
-};

that was registered as part of omap4_panda_init():

-   platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

omap4, panda: 3.11, dtb and wifi

[Paolo Pisati]

i know we switched to dtb-only booting, but what's happened to wifi?

3.5.x:
flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl12xx/
total 0
drwxr-xr-x 5 root root0 set 13 17:26 .
drwxr-xr-x 4 root root0 set 13 17:26 ..
-rw-r--r-- 1 root root 4096 set 13 17:28 bt_coex_state
lrwxrwxrwx 1 root root0 set 13 17:27 driver -> 
../../../../../../../../bus/platform/drivers/wl12xx_driver
-r 1 root root0 set 13 17:28 fwlog
-r--r--r-- 1 root root 4096 set 13 17:28 hw_pg_ver
drwxr-xr-x 3 root root0 set 13 17:27 ieee80211
-r--r--r-- 1 root root 4096 set 13 17:28 modalias
drwxr-xr-x 3 root root0 set 13 17:27 net
drwxr-xr-x 2 root root0 set 13 17:28 power
lrwxrwxrwx 1 root root0 set 13 17:27 subsystem -> 
../../../../../../../../bus/platform
-rw-r--r-- 1 root root 4096 set 13 17:26 uevent

3.11.x:
flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl*
ls: cannot access /sys/bus/platform/devices/wl*: No such file or directory

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

panda, 3.11 and wifi: 'wlcore: ERROR timeout waiting for the hardware to complete initialization'

[Paolo Pisati]

Dear,

after the inclusion of 851320e:

 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard

wlan0 is back on my pandaes, but it doesn't work and my logs are swamped
with:

[   56.255401] wlcore: ERROR timeout waiting for the hardware to complete 
initialization
[   56.264770] wlcore: ERROR firmware boot failed despite 3 retries
[   58.689971] wlcore: ERROR timeout waiting for the hardware to complete 
initialization
[   61.086730] wlcore: ERROR timeout waiting for the hardware to complete 
initialization
[   63.523223] wlcore: ERROR timeout waiting for the hardware to complete 
initialization
[   63.532592] wlcore: ERROR firmware boot failed despite 3 retries
...

any idea what could be wrong now?

here is a complete dmesg: http://goo.gl/e1ZDVp
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

3.12: omap4: cpuidle: solid hangs at boot

[Paolo Pisati]

Vanilla 3.12 multi_v7_defconfig + cpu_idle result in a solid hang on my pandaes
board: has anyone experienced it before? is cpu_idle safe on omap4?

same kernel boots fine on omap3 and some other arm boards fwiw.
if you want to reproduce it:

config: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/config

zImage: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/zImage

boot log: http://paste.ubuntu.com/6415293/
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

am335x boneblack memory size and dtb: is memory live patched?

[Paolo Pisati]

Lately i've been trying to track down a panic i hit when i pass the "mem=256M"
option to a 3.16 kernel on a bleaglebone black, and i noticed this:

dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb
...
memory {
device_type = "memory";
reg = <0x8000 0x1000>;
};
...

that's 256M of memory while the beaglebone black has 512M, does it mean the dtb
is live patched (by u-boot?) before being passed to the kernel?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

beaglebone black: is mem=... broken?

[Paolo Pisati]

Boot hangs when passing mem=256M to a 3.16 kernel (but i was able to reproduce
it with multi_v7_defconfig on a 3.19rcX kernel too):

80e6d694: 0024  65746e49 6c616e72..$.Internal
80e6d6a4: 72726520 203a726f 73706f4f 2035203a error: Oops: 5 
80e6d6b4: 5d31235b 504d5320 4d524120 [#1] SMP ARM
80e6d6c4:  0012  75646f4dModu
80e6d6d4: 2073656c 6b6e696c 69206465 3a6eles linked in:..
80e6d6e4:    
80e6d6f4:    6f4320300 Co
80e6d704: 203a6d6d 70617773 20726570 20746f4emm: swapper Not 
80e6d714: 6e696174 20646574 36312e33 322d302etainted 3.16.0-2
80e6d724: 65672d38 6972656e 33232063 62552d388-generic #38-Ub
80e6d734: 75746e75   002duntu..-.
80e6d744:  6b736174 3063203a 61313964task: c0d91a
80e6d754: 74203832 63203a69 34386430 2030303028 ti: c0d84000 
80e6d764: 6b736174 3a69742e 64306320 30303438task.ti: c0d8400
80e6d774: 0030   00220.".
80e6d784:  69204350 74612073 74646620PC is at fdt
80e6d794: 6568635f 685f6b63 65646165 78302b72_check_header+0x
80e6d7a4: 78302f30 3437  0/0x74..
80e6d7b4:    74612073s at
80e6d7c4: 755f5f20 616c666e 6e657474 7665645f __unflatten_dev
80e6d7d4: 5f656369 65657274 3778302b 78302f38ice_tree+0x78/0x
80e6d7e4: 00306132   2a0.
80e6d7f4:    65323930092e
80e6d804: 3e383064 2020205d 20726c20 3c5b203ad08>]lr : [<
80e6d814: 64373063 34303335 20205d3e 73702020c07d5304>]ps
80e6d824: 36203a72 30303030 0a333931 3a207073r: 6193.sp :
80e6d834: 64306320 33663538 69202030 203a2070 c0d85f30  ip : 
80e6d844: 31663038 37616638 70662020 63203a2080f18fa7  fp : c
80e6d854: 33666530 00343661  0ef3a64.
80e6d864:    
80e6d874:    36623063c0b6
80e6d884: 30393730 38722020 63203a20 613264300790  r8 : c0d2a
80e6d894: 00383435   548.
80e6d8a4:    
80e6d8b4:    303030355000
80e6d8c4: 35722020 63203a20 33366530 20306330  r5 : c0e630c0 
80e6d8d4: 20347220 3063203a 30333665 3063 r4 : c0e630c0..
80e6d8e4:    
80e6d8f4:    722020300  r
80e6d904: 203a2032 30303030 30303030 317220202 :   r1
80e6d914: 63203a20 30316630 20633231 20307220 : c0f1012c  r0 
80e6d924: 6663203a 3035 3030 : cfff5000..
80e6d934:    67616c46Flag
80e6d944: 6e203a73 2076435a 51524920 666f2073s: nZCv  IRQs of
80e6d954: 46202066 20735149 20206e6f 65646f4df  FIQs on  Mode
80e6d964: 43565320 2032335f 41534920 4d524120 SVC_32  ISA ARM
80e6d974: 65532020 6e656d67 656b2074 6c656e72  Segment kernel

Another thing that i noticed was that we actually pass 256M as the physical
memory, while the beaglebone black has 512M - is the dt live patched by the
bootloader before being passed to the kernel?

dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb
...
memory {
device_type = "memory";
reg = <0x8000 0x1000>;
};
...
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: beaglebone black: is mem=... broken?

[Paolo Pisati]

On Sun, Jan 18, 2015 at 06:38:46PM +0100, Geert Uytterhoeven wrote:
> 
> The boot loader copied the DT to the end of real RAM, not to the end of
> the 256 MiB block? Hence the kernel accesses unmapped memory
> when checking the FDT header?

actually everything is below 256M since physical memory starts at
0x8000:

U-Boot# printenv loadaddr
loadaddr=0x8200
U-Boot# printenv fdtaddr
fdtaddr=0x8800
U-Boot# load mmc 0:1 ${loadaddr} zimage
reading zimage
5694816 bytes read in 318 ms (17.1 MiB/s)
U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb
reading am335x-boneblack.dtb
29985 bytes read in 10 ms (2.9 MiB/s)
U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait debug earlyprintk mem=256M
U-Boot# bootz ${loadaddr} - ${fdtaddr}
Kernel image @ 0x8200 [ 0x00 - 0x56e560 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8fff5000, end 8520 ... OK

Starting kernel ...

hangs there, and after i reset i found the aforementioned oops in __log_buf.

Here is without the mem= argument:

U-Boot SPL 2015.01 (Jan 16 2015 - 10:20:36)
MMC: block number 0x100 exceeds max(0x0)
MMC: block number 0x200 exceeds max(0x0)
*** Error - No Valid Environment Area found
Using default environment



U-Boot 2015.01 (Jan 16 2015 - 10:20:36)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0 
U-Boot# load mmc 0:1 ${loadaddr} zimage
reading zimage
5694816 bytes read in 318 ms (17.1 MiB/s)
U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb
reading am335x-boneblack.dtb
29985 bytes read in 11 ms (2.6 MiB/s)
U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait debug earlyprintk   
U-Boot# bootz ${loadaddr} - ${fdtaddr}
Kernel image @ 0x8200 [ 0x00 - 0x56e560 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8fff5000, end 8520 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.19.0-rc4-1-g45aa0b7 (flag@luxor) (gcc 
version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #1 SMP Fri Jan 16 10:33:22 CET5
...
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

3.1[34]: omap4: panda: hang on reboot?

[Paolo Pisati]

I've been experiencing hangs on reboot on two different panda boards (es rev1
and vanilla rev a1) with v3.14-rc8 (but reproducible in 3.13 too):

toolchanin: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7)

the config is a multi_v7_defconfig plus a couple of codepages:

http://people.canonical.com/~ppisati/omap4_reboot_hangs/config

a prebuilt zImage is available here:

http://people.canonical.com/~ppisati/omap4_reboot_hangs/zImage

sometimes i can hit this two times in a row, others it's a bit less
frequent - put this into your crontab and let it go:

*/5 * * * *   /bin/date >> /reboot.log && /sbin/reboot

it never passed 2hrs of reboot cycles.

I already tried different u-boots but that doesn't make any difference,
am i the only one experiencing this issue?
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.1[34]: omap4: panda: hang on reboot?

[Paolo Pisati]

On Thu, Mar 27, 2014 at 06:54:14PM +0100, Paolo Pisati wrote:
> I've been experiencing hangs on reboot on two different panda boards (es rev1
> and vanilla rev a1) with v3.14-rc8 (but reproducible in 3.13 too):
> 
> toolchanin: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7)
> 
> the config is a multi_v7_defconfig plus a couple of codepages:
> 
> http://people.canonical.com/~ppisati/omap4_reboot_hangs/config
> 
> a prebuilt zImage is available here:
> 
> http://people.canonical.com/~ppisati/omap4_reboot_hangs/zImage
> 
> sometimes i can hit this two times in a row, others it's a bit less
> frequent - put this into your crontab and let it go:
> 
> */5 * * * *   /bin/date >> /reboot.log && /sbin/reboot
> 
> it never passed 2hrs of reboot cycles.
> 
> I already tried different u-boots but that doesn't make any difference,
> am i the only one experiencing this issue?

i bisected it down to this commit:

commit e002264f7e45d7661b237045577052fd0b40f89c
Author: Balaji T K 
Date:   Mon Oct 21 00:25:18 2013 +0530

mmc: omap_hsmmc: Fix pbias_disable for omap4

pbias_disable is set to protect the mmc pbias i/o cells in DT boot
by preventing voltage switch. Currently pbias_disable is enabled only
for omap3 and not for omap4 due to reg_offset difference of 0x100.
Enable pbias_disable for omap4+ too by using res->start
which does not include the reg_offset.

Signed-off-by: Balaji T K 
Signed-off-by: Chris Ball 

with this commit reverted, i can reboot in a loop for hours without any problem,
while if i keep this patch, my pandas don't survive more that two hours (again,
it's really random as it could hang a couple of times in a row and then work
like a charm for ten reboots straight).

Any idea? does it ring any bell?

-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.14

[Paolo Pisati]

On Wed, Apr 02, 2014 at 10:15:13AM -0700, Tony Lindgren wrote:
> > Paul uses MMC filesystem, I use NFS. As Felipe Pointed out as well, I
> > did rootcause MMC filesystem mount issue here:
> > http://marc.info/?l=linux-omap&m=139637044425644&w=2
> 
> Balaji, care to take a look at the issue for MMC? It may
> be already fixed in next with the PBIAS handling?

it may be related (or not), but i'm experiencing reboot issues with 3.13/.14 on
omap4 (panda), and after a bisection i found out that reverting 

commit e002264f7e45d7661b237045577052fd0b40f89c
Author: Balaji T K  ti.com>
Date:   Mon Oct 21 00:25:18 2013 +0530

mmc: omap_hsmmc: Fix pbias_disable for omap4

pbias_disable is set to protect the mmc pbias i/o cells in DT boot
by preventing voltage switch. Currently pbias_disable is enabled only
for omap3 and not for omap4 due to reg_offset difference of 0x100.
Enable pbias_disable for omap4+ too by using res->start
which does not include the reg_offset.

Signed-off-by: Balaji T K  ti.com>
Signed-off-by: Chris Ball  laptop.org>

made it go away: can you point me to those pbias handling patches (i guess
something about dt-booting handling pbias correctly now)?

Root on mmc in my case.
-- 
bye,
p.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html