OMAP 4430 SDP: rather sick with recent kernels

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

Tony,

As the IOMMU stuff was merged last night, which removed a really quite
horrid conflict resolution, I updated my nightly build tree from its
previous state last Thursday.

Now, SDP4430 seems to be really quite broken.

ti_dt_clocks_register: failed to lookup clock node dss_fck
ti_dt_clocks_register: failed to lookup clock node dss_fck
ti_dt_clocks_register: failed to lookup clock node div_ts_ck
ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk
...
omap_hwmod: l3_main_3 using broken dt data from ocp
omap_hwmod: l3_main_2 using broken dt data from ocp
...
irq: no irq domain found for /ocp/pinmux at 4a100040 !
irq: no irq domain found for /ocp/pinmux at 4a100040 !
irq: no irq domain found for /ocp/pinmux at 4a100040 !
platform 4b501000.aes: Cannot lookup hwmod 'aes'
platform 480a5000.des: Cannot lookup hwmod 'des'
...
twl: not initialized
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 Vs max 1316660
omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
omap2_set_init_voltage: unable to set vdd_mpu
omap2_set_init_voltage: unable to find boot up OPP for vdd_core
omap2_set_init_voltage: unable to set vdd_core
omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
omap2_set_init_voltage: unable to set vdd_iva
...

>From there, the system crash'n'burns badly due to an ASoC DAPM oops.

The "combined" kernel boot follows a similar pattern, but yets a bit
further before oopsing, with ASoC DAPM code printing random bits of
kernel memory.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

Hi,

* Russell King - ARM Linux <linux@arm.linux.org.uk> [141217 01:55]:
> Tony,
> 
> As the IOMMU stuff was merged last night, which removed a really quite
> horrid conflict resolution, I updated my nightly build tree from its
> previous state last Thursday.
> 
> Now, SDP4430 seems to be really quite broken.

Sigh, things are just break left and right every merge window :(

Anyways, I've added a bunch of ti.com people to Cc, let's fix up 
the noisy dmesg --level=err and dmesg --level=warn output too so we
can notice the real issues easier, see below.
 
> ti_dt_clocks_register: failed to lookup clock node dss_fck
> ti_dt_clocks_register: failed to lookup clock node dss_fck
> ti_dt_clocks_register: failed to lookup clock node div_ts_ck
> ti_dt_clocks_register: failed to lookup clock node bandgap_ts_fclk

And then there are these too in the current mainline that are
clock related:

omap4xxx_dt_clk_init: failed to configure ABE DPLL!
...
clock: dpll_abe_ck failed transition to 'locked'
clock: dpll_abe_ck failed transition to 'locked'
clock: dpll_abe_ck failed transition to 'locked'
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699
Hardware name: Generic OMAP4 (Flattened Device Tree)
[<c00154b4>] (unwind_backtrace) from [<c0011b7c>] (show_stack+0x10/0x14)
[<c0011b7c>] (show_stack) from [<c05d5068>] (dump_stack+0x80/0x9c)
[<c05d5068>] (dump_stack) from [<c003e104>] (warn_slowpath_common+0x78/0xb4)
[<c003e104>] (warn_slowpath_common) from [<c003e15c>] (warn_slowpath_null+ 0x1c/0x24)
[<c003e15c>] (warn_slowpath_null) from [<c04dfc1c>] (clk_disable+0x24/0x30)
[<c04dfc1c>] (clk_disable) from [<c0024ea0>] (_disable_clocks+0x18/0x68)
[<c0024ea0>] (_disable_clocks) from [<c0026410>] (_idle+0x15c/0x240)
[<c0026410>] (_idle) from [<c086fc48>] (_setup+0x174/0x22c)
[<c086fc48>] (_setup) from [<c002684c>] (omap_hwmod_for_each+0x30/0x5c)
[<c002684c>] (omap_hwmod_for_each) from [<c0870054>] (__omap_hwmod_setup_all+0x30/0x40)
[<c0870054>] (__omap_hwmod_setup_all) from [<c00089e4>] (do_one_initcall+0x80/0x1d8)
[<c00089e4>] (do_one_initcall) from [<c0862ea4>] (kernel_init_freeable+0x1f4/0x2cc)
[<c0862ea4>] (kernel_init_freeable) from [<c05cf184>] (kernel_init+0x8/0xe4)
[<c05cf184>] (kernel_init) from [<c000e8e8>] (ret_from_fork+0x14/0x2c)
---[ end trace f0d1b75165d8ef11 ]---
clock: dpll_abe_ck failed transition to 'locked'
clock: dpll_abe_ck failed transition to 'locked'
...

Tero & Tomi, can you please look into these clock issues above?

> omap_hwmod: l3_main_3 using broken dt data from ocp
> omap_hwmod: l3_main_2 using broken dt data from ocp

This is a known issue that will take a while to get fixed to
get things match with compatible and ti,hwmods and the hwmod
data we have.

> irq: no irq domain found for /ocp/pinmux at 4a100040 !
> irq: no irq domain found for /ocp/pinmux at 4a100040 !
> irq: no irq domain found for /ocp/pinmux at 4a100040 !

All these deferred probe issues should go away when we can
remove the custom initcall levels for drivers once omap3 is
DT only. Some of that we may be able to do already by making
all the GPIO usage in the remaining board-*.c files happen
later.

> platform 4b501000.aes: Cannot lookup hwmod 'aes'
> platform 480a5000.des: Cannot lookup hwmod 'des'

Looks like Joel added the .dts entries for aes and des, but somehow
the related omap_hwmod_data_44xx.c entries never made it. Probably
because Paul was not in Cc for the thread "[PATCH 00/10] ARM: OMAP:
dts and HWMOD entries for crypto modules"

Joel, can you please update that series, and repost with Paul also
in Cc? Looks like there there's a dependency to omap_hwmod_sysc_type4
for aes and des for the des and aes hwmod data.

> twl: not initialized
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 Vs max 1316660

This seems to be some twl related init order issue, I'll take a
look at this one.

> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
> omap2_set_init_voltage: unable to set vdd_mpu
> omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> omap2_set_init_voltage: unable to set vdd_core
> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
> omap2_set_init_voltage: unable to set vdd_iva

I believe Nishanth has some plans for these?

> From there, the system crash'n'burns badly due to an ASoC DAPM oops.
> 
> The "combined" kernel boot follows a similar pattern, but yets a bit
> further before oopsing, with ASoC DAPM code printing random bits of
> kernel memory.

Jyri, Tomi & Peter, can you please take a look at ASoC DAPM issue? 

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Nishanth Menon]

On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren <tony@atomide.com> wrote:
>
>> twl: not initialized
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 Vs max 1316660
>
> This seems to be some twl related init order issue, I'll take a
> look at this one.
>
>> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
>> omap2_set_init_voltage: unable to set vdd_mpu
>> omap2_set_init_voltage: unable to find boot up OPP for vdd_core
>> omap2_set_init_voltage: unable to set vdd_core
>> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
>> omap2_set_init_voltage: unable to set vdd_iva
>
> I believe Nishanth has some plans for these?


Not in the near future. looks like converting VC/VP into regulator and
fit inside DT world has gone no where..

Regards,
Nishanth Menon

-- 
---
Regards,
Nishanth Menon

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [141217 09:35]:
> On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> >> twl: not initialized
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 Vs max 1316660
> >
> > This seems to be some twl related init order issue, I'll take a
> > look at this one.
> >
> >> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
> >> omap2_set_init_voltage: unable to set vdd_mpu
> >> omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> >> omap2_set_init_voltage: unable to set vdd_core
> >> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
> >> omap2_set_init_voltage: unable to set vdd_iva
> >
> > I believe Nishanth has some plans for these?
> 
> 
> Not in the near future. looks like converting VC/VP into regulator and
> fit inside DT world has gone no where..

Looks like also the "twl: not initialized" error is caused by this:

omap2_common_pm_late_init
omap_voltage_late_init
omap_vc_init_channel
omap_vc_calc_vsel
twl6030_uv_to_vsel
twl_i2c_read
twl_get_regmap

Can't we fix it with pdata-quirks.c as this error is now showing up
on at least omap3 and 4?

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141217 01:55]:
> > Tony,
> > 
> > As the IOMMU stuff was merged last night, which removed a really quite
> > horrid conflict resolution, I updated my nightly build tree from its
> > previous state last Thursday.
> > 
> > Now, SDP4430 seems to be really quite broken.
> 
> Sigh, things are just break left and right every merge window :(

Some of these things were present before the merge window, so they're
less of a concern.  The biggest problem though is the ABE ASoC stuff
exploding, which prevents my test system getting anywhere near mounting
its rootfs.

It's fine in the "combined" case, because we end up totally dead as
far as serial console goes, but the "omap4430" kernel boot test never
ends because the kernel doesn't stop spewing "rcu_sched stall" messages.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [141217 10:54]:
> On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [141217 01:55]:
> > > Tony,
> > > 
> > > As the IOMMU stuff was merged last night, which removed a really quite
> > > horrid conflict resolution, I updated my nightly build tree from its
> > > previous state last Thursday.
> > > 
> > > Now, SDP4430 seems to be really quite broken.
> > 
> > Sigh, things are just break left and right every merge window :(
> 
> Some of these things were present before the merge window, so they're
> less of a concern.  The biggest problem though is the ABE ASoC stuff
> exploding, which prevents my test system getting anywhere near mounting
> its rootfs.

Right.
 
> It's fine in the "combined" case, because we end up totally dead as
> far as serial console goes, but the "omap4430" kernel boot test never
> ends because the kernel doesn't stop spewing "rcu_sched stall" messages.

Yeah and there are some new clock issues for sure like I posted.

Also, in your 3430-LDP logs, the DMA setup_irq related "In-band Error"
is a mystery. I'm not seeing that with omap2plus_defconfig, but can
reproduce it here with your LDP .config file. Got any ideas on that one?

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [141217 11:14]:
> 
> Also, in your 3430-LDP logs, the DMA setup_irq related "In-band Error"
> is a mystery. I'm not seeing that with omap2plus_defconfig, but can
> reproduce it here with your LDP .config file. Got any ideas on that one?

Hmm it looks like that's some CONFIG_PREEMPT related regression..
Disablig CONFIG_PREEMPT makes it go away.

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Jyri Sarha]

On 12/17/2014 08:51 PM, Russell King - ARM Linux wrote:
> On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
>> Hi,
>>
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141217 01:55]:
>>> Tony,
>>>
>>> As the IOMMU stuff was merged last night, which removed a really quite
>>> horrid conflict resolution, I updated my nightly build tree from its
>>> previous state last Thursday.
>>>
>>> Now, SDP4430 seems to be really quite broken.
>>
>> Sigh, things are just break left and right every merge window :(
>
> Some of these things were present before the merge window, so they're
> less of a concern.  The biggest problem though is the ABE ASoC stuff
> exploding, which prevents my test system getting anywhere near mounting
> its rootfs.
>
> It's fine in the "combined" case, because we end up totally dead as
> far as serial console goes, but the "omap4430" kernel boot test never
> ends because the kernel doesn't stop spewing "rcu_sched stall" messages.
>

I tried booting my 4460 Panda - which is the closest thing to 4430SDP 
that I've got - on next-20141217, but I could not get it to the point 
where the omap-abe-twl6040 probed. It probably is the problem you are 
talking about as the hang does not happen if I disable ASoC ABE all 
together, right?

I'll take a deeper look at it tomorrow, as Peter is not working ATM.

Best regards,
Jyri

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

On Wed, Dec 17, 2014 at 11:08:06PM +0200, Jyri Sarha wrote:
> I tried booting my 4460 Panda - which is the closest thing to 4430SDP that
> I've got - on next-20141217, but I could not get it to the point where the
> omap-abe-twl6040 probed. It probably is the problem you are talking about as
> the hang does not happen if I disable ASoC ABE all together, right?
> 
> I'll take a deeper look at it tomorrow, as Peter is not working ATM.

Digging into this at my end:

[<c02c8698>] (snd_soc_instantiate_card) from [<c02c95f0>] (snd_soc_register_card+0x344/0x424)
 r10:0000005c r9:00000000 r8:00000620 r7:ce437630 r6:ce437630 r5:00000002
 r4:c05cae58

c02c95e8:       e1a00004        mov     r0, r4
c02c95ec:       ebfffc29        bl      c02c8698 <snd_soc_instantiate_card>

So 'card' is 0xc05cae58, which is correct: c05cae58 d omap_abe_card

[<c02cc0ec>] (snd_soc_dapm_add_routes) from [<c02c8f40>] (snd_soc_instantiate_card+0x8a8/0xc14)
 r10:00000000 r9:00000000 r8:ce437010 r7:ce437630 r6:00000002 r5:c05cb0bc
 r4:c05cae58

c02c8f28:       e594110c        ldr     r1, [r4, #268]  ; 0x10c
c02c8f2c:       e3510000        cmp     r1, #0
c02c8f30:       0a000002        beq     c02c8f40 <snd_soc_instantiate_card+0x8a8>
c02c8f34:       e51b0044        ldr     r0, [fp, #-68]  ; 0x44
c02c8f38:       e5942110        ldr     r2, [r4, #272]  ; 0x110
c02c8f3c:       eb000c6a        bl      c02cc0ec <snd_soc_dapm_add_routes>

This corresponds with:

        if (card->dapm_routes)
                snd_soc_dapm_add_routes(&card->dapm, card->dapm_routes,
                                        card->num_dapm_routes);

Again, we see r4 is the omap_abe_card, and the code is loading dapm_routes
and num_dapm_routes.  The dump of this in the vmlinux file gives:

c05cae58 <omap_abe_card>:
        ...
c05caf5c:       c045d098        umaalgt sp, r5, r8, r0
c05caf60:       0000000a        andeq   r0, r0, sl
c05caf64:       c045d6a4        subgt   sp, r5, r4, lsr #13
c05caf68:       00000011        andeq   r0, r0, r1, lsl r0

and 0x10c/0x110 gives 0xc045d6a4  / 17.  c045d6a4 r audio_map
So that looks fine.

[<c02cbf08>] (snd_soc_dapm_add_route) from [<c02cc134>] (snd_soc_dapm_add_routes+0x48/0xac)
 r10:c0458801 r9:00000000 r8:00000037 r7:00000000 r6:00000000 r5:c05cafb8
 r4:ce57b420

c02cc0ec <snd_soc_dapm_add_routes>:
c02cc0fc:       e1a05000        mov     r5, r0
c02cc104:       e1a04001        mov     r4, r1
c02cc108:       e3a07000        mov     r7, #0
c02cc114:       e1a08002        mov     r8, r2
c02cc118:       e2844010        add     r4, r4, #16
c02cc120:       e1a06007        mov     r6, r7
c02cc128:       ea00000f        b       c02cc16c <snd_soc_dapm_add_routes+0x80>

c02cc12c:       e1a00005        mov     r0, r5
c02cc130:       ebffff74        bl      c02cbf08 <snd_soc_dapm_add_route>
c02cc134:       e2509000        subs    r9, r0, #0
c02cc138:       aa000009        bge     c02cc164 <snd_soc_dapm_add_routes+0x78>
...
c02cc168:       e2844010        add     r4, r4, #16
c02cc16c:       e1560008        cmp     r6, r8
c02cc170:       e2441010        sub     r1, r4, #16
c02cc174:       baffffec        blt     c02cc12c <snd_soc_dapm_add_routes+0x40>

Here, r5 is &card->dapm.  r4 should be card->dapm_routes, possibly
incremented by 16 up to 17 times, which should be in the range of
0xc045d6a4 - 0xc045d7b4, but it isn't, it's 0xce57b420.

Also, r8 is card->num_dapm_routes, which should be 17, but it's 0x37
(55).  The index is r6, and at least that's sensibly at zero.

Now, we have this call to snd_soc_of_parse_audio_routing(), which
allocates some memory, copies the old routes into it, and then adds
to them from DT.  That explains why the pointer and number of routes
are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36.
So that doesn't work - but importantly, it does point towards a
possible culpret - snd_soc_of_parse_audio_routing().

This is obvious when you stop and think about what it's doing, this is
truely where this bug lies, and it /is/ in generic ASoC code.

The problem is that this function doesn't consider the implications of
deferred probing.  Let's see what happens if we defer, and re-do the
ABE initialisation, including calling this function:

17 + 19 = 36. - first probe
17 + 19 + 19 = 55. - second probe

Oh - that works in terms of the number, and it would also explain why
the table has been screwed - because the second time we memcpy(), we're
memcpy()ing from data which was allocated via devm_kzalloc(), and thus
would have been freed after the first failed probe.

Mark - this is a core ASoC problem.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

OMAP 4430 SDP: rather sick with recent kernels

[Peter Rosin]

Russel King wrote:
*snip*
> Now, we have this call to snd_soc_of_parse_audio_routing(), which
> allocates some memory, copies the old routes into it, and then adds
> to them from DT.  That explains why the pointer and number of routes
> are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36.
> So that doesn't work - but importantly, it does point towards a
> possible culpret - snd_soc_of_parse_audio_routing().
> 
> This is obvious when you stop and think about what it's doing, this is
> truely where this bug lies, and it /is/ in generic ASoC code.
> 
> The problem is that this function doesn't consider the implications of
> deferred probing.  Let's see what happens if we defer, and re-do the
> ABE initialisation, including calling this function:
> 
> 17 + 19 = 36. - first probe
> 17 + 19 + 19 = 55. - second probe
> 
> Oh - that works in terms of the number, and it would also explain why
> the table has been screwed - because the second time we memcpy(), we're
> memcpy()ing from data which was allocated via devm_kzalloc(), and thus
> would have been freed after the first failed probe.
> 
> Mark - this is a core ASoC problem.

Sorry about this, I wasn't even aware of deferred probing when I wrote
f8781db8aeb1. From my point of view, it is certainly possible to solve this
in the card driver which needs to add card dapm routes instead. So, a
revert is fine by me, if no better solution comes up.

Cheers,
Peter

OMAP 4430 SDP: rather sick with recent kernels

[Jyri Sarha]

On 12/18/2014 01:48 PM, Peter Rosin wrote:
> Russel King wrote:
> *snip*
>> Now, we have this call to snd_soc_of_parse_audio_routing(), which
>> allocates some memory, copies the old routes into it, and then adds
>> to them from DT.  That explains why the pointer and number of routes
>> are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36.
>> So that doesn't work - but importantly, it does point towards a
>> possible culpret - snd_soc_of_parse_audio_routing().
>>
>> This is obvious when you stop and think about what it's doing, this is
>> truely where this bug lies, and it /is/ in generic ASoC code.
>>
>> The problem is that this function doesn't consider the implications of
>> deferred probing.  Let's see what happens if we defer, and re-do the
>> ABE initialisation, including calling this function:
>>
>> 17 + 19 = 36. - first probe
>> 17 + 19 + 19 = 55. - second probe
>>
>> Oh - that works in terms of the number, and it would also explain why
>> the table has been screwed - because the second time we memcpy(), we're
>> memcpy()ing from data which was allocated via devm_kzalloc(), and thus
>> would have been freed after the first failed probe.
>>
>> Mark - this is a core ASoC problem.
>
> Sorry about this, I wasn't even aware of deferred probing when I wrote
> f8781db8aeb1. From my point of view, it is certainly possible to solve this
> in the card driver which needs to add card dapm routes instead. So, a
> revert is fine by me, if no better solution comes up.
>

Looks to me that for this feature we would need a separate function, 
something like:
int snd_soc_of_parse_audio_routing_append(struct snd_soc_card *card,
				   	const char *propname);

even if the implementation behind would be the same. But I guess it is 
little late for new designs at this phase.

Best regards,
Jyri

OMAP 4430 SDP: rather sick with recent kernels

[Mark Brown]

On Thu, Dec 18, 2014 at 10:16:18AM +0000, Russell King - ARM Linux wrote:

> So that doesn't work - but importantly, it does point towards a
> possible culpret - snd_soc_of_parse_audio_routing().

> This is obvious when you stop and think about what it's doing, this is
> truely where this bug lies, and it /is/ in generic ASoC code.

> The problem is that this function doesn't consider the implications of
> deferred probing.  Let's see what happens if we defer, and re-do the
> ABE initialisation, including calling this function:

Right, spot on - I'll send a revert for that upstream.  Thanks for
tracking this down.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141218/d29f4884/attachment.sig>

OMAP 4430 SDP: rather sick with recent kernels

[Peter Ujfalusi]

On 12/18/2014 01:49 PM, Mark Brown wrote:
> On Thu, Dec 18, 2014 at 10:16:18AM +0000, Russell King - ARM Linux wrote:
> 
>> So that doesn't work - but importantly, it does point towards a
>> possible culpret - snd_soc_of_parse_audio_routing().
> 
>> This is obvious when you stop and think about what it's doing, this is
>> truely where this bug lies, and it /is/ in generic ASoC code.
> 
>> The problem is that this function doesn't consider the implications of
>> deferred probing.  Let's see what happens if we defer, and re-do the
>> ABE initialisation, including calling this function:
> 
> Right, spot on - I'll send a revert for that upstream.  Thanks for
> tracking this down.

Mark, can you send the e3b1e6a19e09877b91517dfe304a2b3f6b2138fc (found it in
linux-next) for 3.19 if it not yet done? With that applied mainline boots up
on my Blaze.

-- 
P?ter

OMAP 4430 SDP: rather sick with recent kernels

[Mark Brown]

On Wed, Dec 31, 2014 at 04:00:14PM +0200, Peter Ujfalusi wrote:
> On 12/18/2014 01:49 PM, Mark Brown wrote:

> > Right, spot on - I'll send a revert for that upstream.  Thanks for
> > tracking this down.

> Mark, can you send the e3b1e6a19e09877b91517dfe304a2b3f6b2138fc (found it in
> linux-next) for 3.19 if it not yet done? With that applied mainline boots up
> on my Blaze.

Already done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141231/e6e2d202/attachment-0001.sig>

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [141217 09:28]:
> 
> And then there are these too in the current mainline that are
> clock related:
> 
> omap4xxx_dt_clk_init: failed to configure ABE DPLL!
> ...
> clock: dpll_abe_ck failed transition to 'locked'
> clock: dpll_abe_ck failed transition to 'locked'
> clock: dpll_abe_ck failed transition to 'locked'
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699
> Hardware name: Generic OMAP4 (Flattened Device Tree)
> [<c00154b4>] (unwind_backtrace) from [<c0011b7c>] (show_stack+0x10/0x14)
> [<c0011b7c>] (show_stack) from [<c05d5068>] (dump_stack+0x80/0x9c)
> [<c05d5068>] (dump_stack) from [<c003e104>] (warn_slowpath_common+0x78/0xb4)
> [<c003e104>] (warn_slowpath_common) from [<c003e15c>] (warn_slowpath_null+ 0x1c/0x24)
> [<c003e15c>] (warn_slowpath_null) from [<c04dfc1c>] (clk_disable+0x24/0x30)
> [<c04dfc1c>] (clk_disable) from [<c0024ea0>] (_disable_clocks+0x18/0x68)
> [<c0024ea0>] (_disable_clocks) from [<c0026410>] (_idle+0x15c/0x240)
> [<c0026410>] (_idle) from [<c086fc48>] (_setup+0x174/0x22c)
> [<c086fc48>] (_setup) from [<c002684c>] (omap_hwmod_for_each+0x30/0x5c)
> [<c002684c>] (omap_hwmod_for_each) from [<c0870054>] (__omap_hwmod_setup_all+0x30/0x40)
> [<c0870054>] (__omap_hwmod_setup_all) from [<c00089e4>] (do_one_initcall+0x80/0x1d8)
> [<c00089e4>] (do_one_initcall) from [<c0862ea4>] (kernel_init_freeable+0x1f4/0x2cc)
> [<c0862ea4>] (kernel_init_freeable) from [<c05cf184>] (kernel_init+0x8/0xe4)
> [<c05cf184>] (kernel_init) from [<c000e8e8>] (ret_from_fork+0x14/0x2c)
> ---[ end trace f0d1b75165d8ef11 ]---
> clock: dpll_abe_ck failed transition to 'locked'
> clock: dpll_abe_ck failed transition to 'locked'
> ...
> 
> Tero & Tomi, can you please look into these clock issues above?

FYI, looks like merging Mike's pending clk-next to current mainline
somehow fixes the clock issues above. It seems the audio changes
depended on changes in clk-next?

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Peter Ujfalusi]

On 12/18/2014 06:41 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [141217 09:28]:
>>
>> And then there are these too in the current mainline that are
>> clock related:
>>
>> omap4xxx_dt_clk_init: failed to configure ABE DPLL!
>> ...
>> clock: dpll_abe_ck failed transition to 'locked'
>> clock: dpll_abe_ck failed transition to 'locked'
>> clock: dpll_abe_ck failed transition to 'locked'
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:851 clk_disable+0x24/0x30()
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-09274-g53c5279 #699
>> Hardware name: Generic OMAP4 (Flattened Device Tree)
>> [<c00154b4>] (unwind_backtrace) from [<c0011b7c>] (show_stack+0x10/0x14)
>> [<c0011b7c>] (show_stack) from [<c05d5068>] (dump_stack+0x80/0x9c)
>> [<c05d5068>] (dump_stack) from [<c003e104>] (warn_slowpath_common+0x78/0xb4)
>> [<c003e104>] (warn_slowpath_common) from [<c003e15c>] (warn_slowpath_null+ 0x1c/0x24)
>> [<c003e15c>] (warn_slowpath_null) from [<c04dfc1c>] (clk_disable+0x24/0x30)
>> [<c04dfc1c>] (clk_disable) from [<c0024ea0>] (_disable_clocks+0x18/0x68)
>> [<c0024ea0>] (_disable_clocks) from [<c0026410>] (_idle+0x15c/0x240)
>> [<c0026410>] (_idle) from [<c086fc48>] (_setup+0x174/0x22c)
>> [<c086fc48>] (_setup) from [<c002684c>] (omap_hwmod_for_each+0x30/0x5c)
>> [<c002684c>] (omap_hwmod_for_each) from [<c0870054>] (__omap_hwmod_setup_all+0x30/0x40)
>> [<c0870054>] (__omap_hwmod_setup_all) from [<c00089e4>] (do_one_initcall+0x80/0x1d8)
>> [<c00089e4>] (do_one_initcall) from [<c0862ea4>] (kernel_init_freeable+0x1f4/0x2cc)
>> [<c0862ea4>] (kernel_init_freeable) from [<c05cf184>] (kernel_init+0x8/0xe4)
>> [<c05cf184>] (kernel_init) from [<c000e8e8>] (ret_from_fork+0x14/0x2c)
>> ---[ end trace f0d1b75165d8ef11 ]---
>> clock: dpll_abe_ck failed transition to 'locked'
>> clock: dpll_abe_ck failed transition to 'locked'
>> ...
>>
>> Tero & Tomi, can you please look into these clock issues above?
> 
> FYI, looks like merging Mike's pending clk-next to current mainline
> somehow fixes the clock issues above. It seems the audio changes
> depended on changes in clk-next?

I'm not aware of any audio changes around here.
BTW: today's linux-next boots fine on Blaze with audio working.

> 
> Regards,
> 
> Tony
> 


-- 
P?ter

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

On Wed, Dec 17, 2014 at 09:52:52AM +0000, Russell King - ARM Linux wrote:
> The "combined" kernel boot follows a similar pattern, but yets a bit
> further before oopsing, with ASoC DAPM code printing random bits of
> kernel memory.

Note that the "combined" kernel (which is OMAP4 + Versatile Express)
has for a while now also spat out this:

WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1
Hardware name: Generic OMAP4 (Flattened Device Tree)
Backtrace:
[<c0011bdc>] (dump_backtrace) from [<c0011e9c>] (show_stack+0x18/0x1c)
 r6:c04c073e r5:00000009 r4:00000000 r3:00200040
[<c0011e84>] (show_stack) from [<c0466380>] (dump_stack+0x78/0x94)
[<c0466308>] (dump_stack) from [<c00379ec>] (warn_slowpath_common+0x8c/0xb8)
 r4:ce461b38 r3:ce458000
[<c0037960>] (warn_slowpath_common) from [<c0037abc>] (warn_slowpath_fmt+0x38/0x40)
 r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400
[<c0037a88>] (warn_slowpath_fmt) from [<c02098f8>] (l3_interrupt_handler+0x218/0x2f0)
 r3:ce54ad40 r2:c04c0772
[<c02096e0>] (l3_interrupt_handler) from [<c0076444>] (handle_irq_event_percpu+0x38/0x13c)
 r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7:00000000 r6:00000000 r5:00000013
 r4:ce54f480
[<c007640c>] (handle_irq_event_percpu) from [<c007658c>] (handle_irq_event+0x44/0x64)
 r10:00000000 r9:ce5b1938 r8:ce5b1960 r7:00000001 r6:ce54f480 r5:ce440760
 r4:ce440700
[<c0076548>] (handle_irq_event) from [<c00795f4>] (handle_fasteoi_irq+0xb0/0x128)
 r6:ce440760 r5:c06c5fec r4:ce440700 r3:00000000
[<c0079544>] (handle_fasteoi_irq) from [<c0075d60>] (generic_handle_irq+0x28/0x38)
 r6:ce408000 r5:00000000 r4:00000013 r3:c0079544
[<c0075d38>] (generic_handle_irq) from [<c0075ebc>] (__handle_domain_irq+0x90/0xb8)
 r4:00000000 r3:00000110
[<c0075e2c>] (__handle_domain_irq) from [<c0008858>] (gic_handle_irq+0x44/0x68)
 r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100
[<c0008814>] (gic_handle_irq) from [<c00129c4>] (__irq_svc+0x44/0x5c)
Exception stack(0xce461cd8 to 0xce461d20)
1cc0:                                                       00000001 ce458508
1ce0: 00000000 00000000 60000113 ce5b1960 0000002c 00000000 ce5b1960 ce5b1938
1d00: 00000000 ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 20000113 ffffffff
 r6:ffffffff r5:20000113 r4:c046df64 r3:ce458000
[<c046df1c>] (_raw_spin_unlock_irqrestore) from [<c0077dd0>] (__setup_irq+0x3bc/0x4e4)
 r5:c06b7c00 r4:ce5b1900
[<c0077a14>] (__setup_irq) from [<c00780ec>] (setup_irq+0x50/0x90)
 r10:c06ea338 r9:20000113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:0000002c
 r4:ce5b1900
[<c007809c>] (setup_irq) from [<c0032768>] (omap_system_dma_probe+0x20c/0x2a4)
 r6:ce67ec10 r5:0000002c r4:00000020 r3:00000002
[<c003255c>] (omap_system_dma_probe) from [<c0298788>] (platform_drv_probe+0x50/0x98)
 r10:c066d8b0 r9:00000000 r8:00000000 r7:c02971b8 r6:c06b7b94 r5:ffffffed
 r4:ce67ec10
[<c0298738>] (platform_drv_probe) from [<c0296fa8>] (driver_probe_device+0x13c/0x34c)
 r6:00000000 r5:c06b7b94 r4:ce67ec10 r3:c0298738
[<c0296e6c>] (driver_probe_device) from [<c0297230>] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10
[<c02971b8>] (__driver_attach) from [<c0295424>] (bus_for_each_dev+0x5c/0x98)
 r6:c06b7b94 r5:ce461e48 r4:00000000 r3:c02971b8
[<c02953c8>] (bus_for_each_dev) from [<c02969c0>] (driver_attach+0x20/0x28)
 r7:00000000 r6:c06ce978 r5:ce61c100 r4:c06b7b94
[<c02969a0>] (driver_attach) from [<c02965ec>] (bus_add_driver+0xf8/0x1fc)
[<c02964f4>] (bus_add_driver) from [<c0297914>] (driver_register+0xa4/0xe8)
 r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94
[<c0297870>] (driver_register) from [<c029861c>] (__platform_driver_register+0x50/0x64)
 r5:c068d0e8 r4:ce621f80
[<c02985cc>] (__platform_driver_register) from [<c0646240>] (omap_system_dma_init+0x18/0x20)
[<c0646228>] (omap_system_dma_init) from [<c0008c44>] (do_one_initcall+0x114/0x1e0)
[<c0008b30>] (do_one_initcall) from [<c0632e3c>] (kernel_init_freeable+0x110/0x1dc)
 r10:c066d8b0 r9:00000000 r8:0000007d r7:c06e9040 r6:c067ddf0 r5:c066d898
 r4:00000003
[<c0632d2c>] (kernel_init_freeable) from [<c0460840>] (kernel_init+0x10/0xec)
 r10:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0460830 r4:00000000
[<c0460830>] (kernel_init) from [<c000f0d0>] (ret_from_fork+0x14/0x24)
 r4:00000000 r3:00000000
---[ end trace bcb85e0273c31888 ]---
OMAP DMA hardware revision 0.0

This does not occur when booting the plain "omap4" kernel.

I thought it may be related to another error which people have been
reporting, but as it's still there, I thought I should report it.

To me, this suggests that Versatile Express code may be initialising
on non-Versatile Express hardware, possibly touching hardware, but
it looks like it's happening within the setup_irq() called from the
legacy OMAP DMA code, though it's possible that could be because
Versatile Express code could be hitting some register which causes
OMAP4 to later to wrong.

I think it's going to be particularly horrid to debug...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150114 09:54]:
> On Wed, Dec 17, 2014 at 09:52:52AM +0000, Russell King - ARM Linux wrote:
> > The "combined" kernel boot follows a similar pattern, but yets a bit
> > further before oopsing, with ASoC DAPM code printing random bits of
> > kernel memory.
> 
> Note that the "combined" kernel (which is OMAP4 + Versatile Express)
> has for a while now also spat out this:
> 
> WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0()
> 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1
> Hardware name: Generic OMAP4 (Flattened Device Tree)
> Backtrace:
> [<c0011bdc>] (dump_backtrace) from [<c0011e9c>] (show_stack+0x18/0x1c)
>  r6:c04c073e r5:00000009 r4:00000000 r3:00200040
> [<c0011e84>] (show_stack) from [<c0466380>] (dump_stack+0x78/0x94)
> [<c0466308>] (dump_stack) from [<c00379ec>] (warn_slowpath_common+0x8c/0xb8)
>  r4:ce461b38 r3:ce458000
> [<c0037960>] (warn_slowpath_common) from [<c0037abc>] (warn_slowpath_fmt+0x38/0x40)
>  r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400
> [<c0037a88>] (warn_slowpath_fmt) from [<c02098f8>] (l3_interrupt_handler+0x218/0x2f0)
>  r3:ce54ad40 r2:c04c0772
> [<c02096e0>] (l3_interrupt_handler) from [<c0076444>] (handle_irq_event_percpu+0x38/0x13c)
>  r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7:00000000 r6:00000000 r5:00000013
>  r4:ce54f480
> [<c007640c>] (handle_irq_event_percpu) from [<c007658c>] (handle_irq_event+0x44/0x64)
>  r10:00000000 r9:ce5b1938 r8:ce5b1960 r7:00000001 r6:ce54f480 r5:ce440760
>  r4:ce440700
> [<c0076548>] (handle_irq_event) from [<c00795f4>] (handle_fasteoi_irq+0xb0/0x128)
>  r6:ce440760 r5:c06c5fec r4:ce440700 r3:00000000
> [<c0079544>] (handle_fasteoi_irq) from [<c0075d60>] (generic_handle_irq+0x28/0x38)
>  r6:ce408000 r5:00000000 r4:00000013 r3:c0079544
> [<c0075d38>] (generic_handle_irq) from [<c0075ebc>] (__handle_domain_irq+0x90/0xb8)
>  r4:00000000 r3:00000110
> [<c0075e2c>] (__handle_domain_irq) from [<c0008858>] (gic_handle_irq+0x44/0x68)
>  r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100
> [<c0008814>] (gic_handle_irq) from [<c00129c4>] (__irq_svc+0x44/0x5c)
> Exception stack(0xce461cd8 to 0xce461d20)
> 1cc0:                                                       00000001 ce458508
> 1ce0: 00000000 00000000 60000113 ce5b1960 0000002c 00000000 ce5b1960 ce5b1938
> 1d00: 00000000 ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 20000113 ffffffff
>  r6:ffffffff r5:20000113 r4:c046df64 r3:ce458000
> [<c046df1c>] (_raw_spin_unlock_irqrestore) from [<c0077dd0>] (__setup_irq+0x3bc/0x4e4)
>  r5:c06b7c00 r4:ce5b1900
> [<c0077a14>] (__setup_irq) from [<c00780ec>] (setup_irq+0x50/0x90)
>  r10:c06ea338 r9:20000113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:0000002c
>  r4:ce5b1900
> [<c007809c>] (setup_irq) from [<c0032768>] (omap_system_dma_probe+0x20c/0x2a4)
>  r6:ce67ec10 r5:0000002c r4:00000020 r3:00000002
> [<c003255c>] (omap_system_dma_probe) from [<c0298788>] (platform_drv_probe+0x50/0x98)
>  r10:c066d8b0 r9:00000000 r8:00000000 r7:c02971b8 r6:c06b7b94 r5:ffffffed
>  r4:ce67ec10
> [<c0298738>] (platform_drv_probe) from [<c0296fa8>] (driver_probe_device+0x13c/0x34c)
>  r6:00000000 r5:c06b7b94 r4:ce67ec10 r3:c0298738
> [<c0296e6c>] (driver_probe_device) from [<c0297230>] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10
> [<c02971b8>] (__driver_attach) from [<c0295424>] (bus_for_each_dev+0x5c/0x98)
>  r6:c06b7b94 r5:ce461e48 r4:00000000 r3:c02971b8
> [<c02953c8>] (bus_for_each_dev) from [<c02969c0>] (driver_attach+0x20/0x28)
>  r7:00000000 r6:c06ce978 r5:ce61c100 r4:c06b7b94
> [<c02969a0>] (driver_attach) from [<c02965ec>] (bus_add_driver+0xf8/0x1fc)
> [<c02964f4>] (bus_add_driver) from [<c0297914>] (driver_register+0xa4/0xe8)
>  r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94
> [<c0297870>] (driver_register) from [<c029861c>] (__platform_driver_register+0x50/0x64)
>  r5:c068d0e8 r4:ce621f80
> [<c02985cc>] (__platform_driver_register) from [<c0646240>] (omap_system_dma_init+0x18/0x20)
> [<c0646228>] (omap_system_dma_init) from [<c0008c44>] (do_one_initcall+0x114/0x1e0)
> [<c0008b30>] (do_one_initcall) from [<c0632e3c>] (kernel_init_freeable+0x110/0x1dc)
>  r10:c066d8b0 r9:00000000 r8:0000007d r7:c06e9040 r6:c067ddf0 r5:c066d898
>  r4:00000003
> [<c0632d2c>] (kernel_init_freeable) from [<c0460840>] (kernel_init+0x10/0xec)
>  r10:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0460830 r4:00000000
> [<c0460830>] (kernel_init) from [<c000f0d0>] (ret_from_fork+0x14/0x24)
>  r4:00000000 r3:00000000
> ---[ end trace bcb85e0273c31888 ]---
> OMAP DMA hardware revision 0.0
> 
> This does not occur when booting the plain "omap4" kernel.
> 
> I thought it may be related to another error which people have been
> reporting, but as it's still there, I thought I should report it.
> 
> To me, this suggests that Versatile Express code may be initialising
> on non-Versatile Express hardware, possibly touching hardware, but
> it looks like it's happening within the setup_irq() called from the
> legacy OMAP DMA code, though it's possible that could be because
> Versatile Express code could be hitting some register which causes
> OMAP4 to later to wrong.
> 
> I think it's going to be particularly horrid to debug...

This seems like it could be a similar issue to what we were seeing on
omap3 where the legacy IRQ mappings went wrong without using the
irq_domain_add_legacy(). Maybe vexpress affects NR_IRQS or something?

Also, I think we could now disable the legacy DMA init completely
except for omap2 and 3.

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [150114 11:16]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150114 09:54]:
> > On Wed, Dec 17, 2014 at 09:52:52AM +0000, Russell King - ARM Linux wrote:
> > > The "combined" kernel boot follows a similar pattern, but yets a bit
> > > further before oopsing, with ASoC DAPM code printing random bits of
> > > kernel memory.
> > 
> > Note that the "combined" kernel (which is OMAP4 + Versatile Express)
> > has for a while now also spat out this:
> > 
> > WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0()
> > 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1
> > Hardware name: Generic OMAP4 (Flattened Device Tree)
> > Backtrace:
> > [<c0011bdc>] (dump_backtrace) from [<c0011e9c>] (show_stack+0x18/0x1c)
> >  r6:c04c073e r5:00000009 r4:00000000 r3:00200040
> > [<c0011e84>] (show_stack) from [<c0466380>] (dump_stack+0x78/0x94)
> > [<c0466308>] (dump_stack) from [<c00379ec>] (warn_slowpath_common+0x8c/0xb8)
> >  r4:ce461b38 r3:ce458000
> > [<c0037960>] (warn_slowpath_common) from [<c0037abc>] (warn_slowpath_fmt+0x38/0x40)
> >  r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400
> > [<c0037a88>] (warn_slowpath_fmt) from [<c02098f8>] (l3_interrupt_handler+0x218/0x2f0)
> >  r3:ce54ad40 r2:c04c0772
> > [<c02096e0>] (l3_interrupt_handler) from [<c0076444>] (handle_irq_event_percpu+0x38/0x13c)
> >  r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7:00000000 r6:00000000 r5:00000013
> >  r4:ce54f480
> > [<c007640c>] (handle_irq_event_percpu) from [<c007658c>] (handle_irq_event+0x44/0x64)
> >  r10:00000000 r9:ce5b1938 r8:ce5b1960 r7:00000001 r6:ce54f480 r5:ce440760
> >  r4:ce440700
> > [<c0076548>] (handle_irq_event) from [<c00795f4>] (handle_fasteoi_irq+0xb0/0x128)
> >  r6:ce440760 r5:c06c5fec r4:ce440700 r3:00000000
> > [<c0079544>] (handle_fasteoi_irq) from [<c0075d60>] (generic_handle_irq+0x28/0x38)
> >  r6:ce408000 r5:00000000 r4:00000013 r3:c0079544
> > [<c0075d38>] (generic_handle_irq) from [<c0075ebc>] (__handle_domain_irq+0x90/0xb8)
> >  r4:00000000 r3:00000110
> > [<c0075e2c>] (__handle_domain_irq) from [<c0008858>] (gic_handle_irq+0x44/0x68)
> >  r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100
> > [<c0008814>] (gic_handle_irq) from [<c00129c4>] (__irq_svc+0x44/0x5c)
> > Exception stack(0xce461cd8 to 0xce461d20)
> > 1cc0:                                                       00000001 ce458508
> > 1ce0: 00000000 00000000 60000113 ce5b1960 0000002c 00000000 ce5b1960 ce5b1938
> > 1d00: 00000000 ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 20000113 ffffffff
> >  r6:ffffffff r5:20000113 r4:c046df64 r3:ce458000
> > [<c046df1c>] (_raw_spin_unlock_irqrestore) from [<c0077dd0>] (__setup_irq+0x3bc/0x4e4)
> >  r5:c06b7c00 r4:ce5b1900
> > [<c0077a14>] (__setup_irq) from [<c00780ec>] (setup_irq+0x50/0x90)
> >  r10:c06ea338 r9:20000113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:0000002c
> >  r4:ce5b1900
> > [<c007809c>] (setup_irq) from [<c0032768>] (omap_system_dma_probe+0x20c/0x2a4)
> >  r6:ce67ec10 r5:0000002c r4:00000020 r3:00000002
> > [<c003255c>] (omap_system_dma_probe) from [<c0298788>] (platform_drv_probe+0x50/0x98)
> >  r10:c066d8b0 r9:00000000 r8:00000000 r7:c02971b8 r6:c06b7b94 r5:ffffffed
> >  r4:ce67ec10
> > [<c0298738>] (platform_drv_probe) from [<c0296fa8>] (driver_probe_device+0x13c/0x34c)
> >  r6:00000000 r5:c06b7b94 r4:ce67ec10 r3:c0298738
> > [<c0296e6c>] (driver_probe_device) from [<c0297230>] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10
> > [<c02971b8>] (__driver_attach) from [<c0295424>] (bus_for_each_dev+0x5c/0x98)
> >  r6:c06b7b94 r5:ce461e48 r4:00000000 r3:c02971b8
> > [<c02953c8>] (bus_for_each_dev) from [<c02969c0>] (driver_attach+0x20/0x28)
> >  r7:00000000 r6:c06ce978 r5:ce61c100 r4:c06b7b94
> > [<c02969a0>] (driver_attach) from [<c02965ec>] (bus_add_driver+0xf8/0x1fc)
> > [<c02964f4>] (bus_add_driver) from [<c0297914>] (driver_register+0xa4/0xe8)
> >  r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94
> > [<c0297870>] (driver_register) from [<c029861c>] (__platform_driver_register+0x50/0x64)
> >  r5:c068d0e8 r4:ce621f80
> > [<c02985cc>] (__platform_driver_register) from [<c0646240>] (omap_system_dma_init+0x18/0x20)
> > [<c0646228>] (omap_system_dma_init) from [<c0008c44>] (do_one_initcall+0x114/0x1e0)
> > [<c0008b30>] (do_one_initcall) from [<c0632e3c>] (kernel_init_freeable+0x110/0x1dc)
> >  r10:c066d8b0 r9:00000000 r8:0000007d r7:c06e9040 r6:c067ddf0 r5:c066d898
> >  r4:00000003
> > [<c0632d2c>] (kernel_init_freeable) from [<c0460840>] (kernel_init+0x10/0xec)
> >  r10:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0460830 r4:00000000
> > [<c0460830>] (kernel_init) from [<c000f0d0>] (ret_from_fork+0x14/0x24)
> >  r4:00000000 r3:00000000
> > ---[ end trace bcb85e0273c31888 ]---
> > OMAP DMA hardware revision 0.0
> > 
> > This does not occur when booting the plain "omap4" kernel.
> > 
> > I thought it may be related to another error which people have been
> > reporting, but as it's still there, I thought I should report it.
> > 
> > To me, this suggests that Versatile Express code may be initialising
> > on non-Versatile Express hardware, possibly touching hardware, but
> > it looks like it's happening within the setup_irq() called from the
> > legacy OMAP DMA code, though it's possible that could be because
> > Versatile Express code could be hitting some register which causes
> > OMAP4 to later to wrong.
> > 
> > I think it's going to be particularly horrid to debug...
> 
> This seems like it could be a similar issue to what we were seeing on
> omap3 where the legacy IRQ mappings went wrong without using the
> irq_domain_add_legacy(). Maybe vexpress affects NR_IRQS or something?
> 
> Also, I think we could now disable the legacy DMA init completely
> except for omap2 and 3.

FYI, started a separate thread on this issue called
"Regression with legacy IRQ numbers caused by 9a1091ef0017".

Regards,

Tony

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150114 09:54]:
> > On Wed, Dec 17, 2014 at 09:52:52AM +0000, Russell King - ARM Linux wrote:
> > > The "combined" kernel boot follows a similar pattern, but yets a bit
> > > further before oopsing, with ASoC DAPM code printing random bits of
> > > kernel memory.
> > 
> > Note that the "combined" kernel (which is OMAP4 + Versatile Express)
> > has for a while now also spat out this:
> > 
> > WARNING: CPU: 0 PID: 1 at .../linux-build/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x218/0x2f0()
> > 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4+ #1
> > Hardware name: Generic OMAP4 (Flattened Device Tree)
> > Backtrace:
> > [<c0011bdc>] (dump_backtrace) from [<c0011e9c>] (show_stack+0x18/0x1c)
> >  r6:c04c073e r5:00000009 r4:00000000 r3:00200040
> > [<c0011e84>] (show_stack) from [<c0466380>] (dump_stack+0x78/0x94)
> > [<c0466308>] (dump_stack) from [<c00379ec>] (warn_slowpath_common+0x8c/0xb8)
> >  r4:ce461b38 r3:ce458000
> > [<c0037960>] (warn_slowpath_common) from [<c0037abc>] (warn_slowpath_fmt+0x38/0x40)
> >  r8:c04c06a6 r7:c04c094c r6:80080003 r5:ce54d218 r4:f8000400
> > [<c0037a88>] (warn_slowpath_fmt) from [<c02098f8>] (l3_interrupt_handler+0x218/0x2f0)
> >  r3:ce54ad40 r2:c04c0772
> > [<c02096e0>] (l3_interrupt_handler) from [<c0076444>] (handle_irq_event_percpu+0x38/0x13c)
> >  r10:ce440700 r9:c06e1c58 r8:ce5b1960 r7:00000000 r6:00000000 r5:00000013
> >  r4:ce54f480
> > [<c007640c>] (handle_irq_event_percpu) from [<c007658c>] (handle_irq_event+0x44/0x64)
> >  r10:00000000 r9:ce5b1938 r8:ce5b1960 r7:00000001 r6:ce54f480 r5:ce440760
> >  r4:ce440700
> > [<c0076548>] (handle_irq_event) from [<c00795f4>] (handle_fasteoi_irq+0xb0/0x128)
> >  r6:ce440760 r5:c06c5fec r4:ce440700 r3:00000000
> > [<c0079544>] (handle_fasteoi_irq) from [<c0075d60>] (generic_handle_irq+0x28/0x38)
> >  r6:ce408000 r5:00000000 r4:00000013 r3:c0079544
> > [<c0075d38>] (generic_handle_irq) from [<c0075ebc>] (__handle_domain_irq+0x90/0xb8)
> >  r4:00000000 r3:00000110
> > [<c0075e2c>] (__handle_domain_irq) from [<c0008858>] (gic_handle_irq+0x44/0x68)
> >  r7:ce461d0c r6:c068b34c r5:ce461cd8 r4:fa240100
> > [<c0008814>] (gic_handle_irq) from [<c00129c4>] (__irq_svc+0x44/0x5c)
> > Exception stack(0xce461cd8 to 0xce461d20)
> > 1cc0:                                                       00000001 ce458508
> > 1ce0: 00000000 00000000 60000113 ce5b1960 0000002c 00000000 ce5b1960 ce5b1938
> > 1d00: 00000000 ce461d34 ce461cf0 ce461d20 c006d4f4 c046df64 20000113 ffffffff
> >  r6:ffffffff r5:20000113 r4:c046df64 r3:ce458000
> > [<c046df1c>] (_raw_spin_unlock_irqrestore) from [<c0077dd0>] (__setup_irq+0x3bc/0x4e4)
> >  r5:c06b7c00 r4:ce5b1900
> > [<c0077a14>] (__setup_irq) from [<c00780ec>] (setup_irq+0x50/0x90)
> >  r10:c06ea338 r9:20000113 r8:c06ea338 r7:ce67ec00 r6:c06b7c00 r5:0000002c
> >  r4:ce5b1900
> > [<c007809c>] (setup_irq) from [<c0032768>] (omap_system_dma_probe+0x20c/0x2a4)
> >  r6:ce67ec10 r5:0000002c r4:00000020 r3:00000002
> > [<c003255c>] (omap_system_dma_probe) from [<c0298788>] (platform_drv_probe+0x50/0x98)
> >  r10:c066d8b0 r9:00000000 r8:00000000 r7:c02971b8 r6:c06b7b94 r5:ffffffed
> >  r4:ce67ec10
> > [<c0298738>] (platform_drv_probe) from [<c0296fa8>] (driver_probe_device+0x13c/0x34c)
> >  r6:00000000 r5:c06b7b94 r4:ce67ec10 r3:c0298738
> > [<c0296e6c>] (driver_probe_device) from [<c0297230>] (__driver_attach+0x78/0x9c) r8:c0646228 r7:c02971b8 r6:c06b7b94 r5:ce67ec44 r4:ce67ec10
> > [<c02971b8>] (__driver_attach) from [<c0295424>] (bus_for_each_dev+0x5c/0x98)
> >  r6:c06b7b94 r5:ce461e48 r4:00000000 r3:c02971b8
> > [<c02953c8>] (bus_for_each_dev) from [<c02969c0>] (driver_attach+0x20/0x28)
> >  r7:00000000 r6:c06ce978 r5:ce61c100 r4:c06b7b94
> > [<c02969a0>] (driver_attach) from [<c02965ec>] (bus_add_driver+0xf8/0x1fc)
> > [<c02964f4>] (bus_add_driver) from [<c0297914>] (driver_register+0xa4/0xe8)
> >  r7:c06e9040 r6:c068d0e8 r5:c068d0e8 r4:c06b7b94
> > [<c0297870>] (driver_register) from [<c029861c>] (__platform_driver_register+0x50/0x64)
> >  r5:c068d0e8 r4:ce621f80
> > [<c02985cc>] (__platform_driver_register) from [<c0646240>] (omap_system_dma_init+0x18/0x20)
> > [<c0646228>] (omap_system_dma_init) from [<c0008c44>] (do_one_initcall+0x114/0x1e0)
> > [<c0008b30>] (do_one_initcall) from [<c0632e3c>] (kernel_init_freeable+0x110/0x1dc)
> >  r10:c066d8b0 r9:00000000 r8:0000007d r7:c06e9040 r6:c067ddf0 r5:c066d898
> >  r4:00000003
> > [<c0632d2c>] (kernel_init_freeable) from [<c0460840>] (kernel_init+0x10/0xec)
> >  r10:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0460830 r4:00000000
> > [<c0460830>] (kernel_init) from [<c000f0d0>] (ret_from_fork+0x14/0x24)
> >  r4:00000000 r3:00000000
> > ---[ end trace bcb85e0273c31888 ]---
> > OMAP DMA hardware revision 0.0
> > 
> > This does not occur when booting the plain "omap4" kernel.
> > 
> > I thought it may be related to another error which people have been
> > reporting, but as it's still there, I thought I should report it.
> > 
> > To me, this suggests that Versatile Express code may be initialising
> > on non-Versatile Express hardware, possibly touching hardware, but
> > it looks like it's happening within the setup_irq() called from the
> > legacy OMAP DMA code, though it's possible that could be because
> > Versatile Express code could be hitting some register which causes
> > OMAP4 to later to wrong.
> > 
> > I think it's going to be particularly horrid to debug...
> 
> This seems like it could be a similar issue to what we were seeing on
> omap3 where the legacy IRQ mappings went wrong without using the
> irq_domain_add_legacy(). Maybe vexpress affects NR_IRQS or something?
> 
> Also, I think we could now disable the legacy DMA init completely
> except for omap2 and 3.

I've added a "cat /proc/interrupts" which should reveal whether the IRQs
have changed between the two different builds.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

OMAP 4430 SDP: rather sick with recent kernels

[Russell King - ARM Linux]

On Wed, Jan 14, 2015 at 11:10:08PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote:
> > This seems like it could be a similar issue to what we were seeing on
> > omap3 where the legacy IRQ mappings went wrong without using the
> > irq_domain_add_legacy(). Maybe vexpress affects NR_IRQS or something?
> > 
> > Also, I think we could now disable the legacy DMA init completely
> > except for omap2 and 3.
> 
> I've added a "cat /proc/interrupts" which should reveal whether the IRQs
> have changed between the two different builds.

Okay, both omap4 and combined kernels indicate that the legacy DMA gets
the same interrupt:

 44:          0          0  4a310000.gpio  18  DMA

so that can't be the issue as the combined kernel spits out the warning,
but the omap4 kernel doesn't.  Something else is going on which causes
this; the hint that it's got something to do with this is just a symptom
of some other problem.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.