3.18.1->3.19-rc2: In-band Error seen by MPU

3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2 I see a "In-band ERROR" warning which wasn't present in 3.18.1.
Could it be that I missed some DT updates?

And  should I care of "irq: no irq domain found for /ocp/pinmux@48002030"?

Many thanks!

[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/166/600 MHz
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65536000000000ns
[    0.000030] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000183] Console: colour dummy device 80x30
[    0.000244] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)
[    0.118988] pid_max: default: 32768 minimum: 301
[    0.119140] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.119171] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.119934] CPU: Testing write buffer coherency: ok
[    0.120330] Setting up static identity map for 0x803d5b28 - 0x803d5b80
[    0.121856] devtmpfs: initialized
[    0.122680] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    0.138458] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
[    0.138977] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
[    0.182159] omap_hwmod: mcbsp2: cannot be enabled for reset (3)
[    0.228424] pinctrl core: initialized pinctrl subsystem
[    0.259399] NET: Registered protocol family 16
[    0.260131] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.288696] cpuidle: using governor ladder
[    0.318572] cpuidle: using governor menu
[    0.324981] Reprogramming SDRC clock to 166000000 Hz
[    0.333160] OMAP GPIO hardware version 2.5
[    0.340515] irq: no irq domain found for /ocp/pinmux@48002030 !
[    0.356994] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    0.360015] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
[    0.366882] In-band Error seen by MPU  at address 0
[    0.366912] ------------[ cut here ]------------
[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
[    0.366943] Modules linked in:
[    0.366973] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc2-DM+ #2
[    0.366973] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    0.367004] Backtrace:
[    0.367034] [<c00117a4>] (dump_backtrace) from [<c00119c8>] (show_stack+0x18/0x1c)
[    0.367034]  r6:c0213e50 r5:00000009 r4:00000000 r3:00000000
[    0.367065] [<c00119b0>] (show_stack) from [<c03cf9c8>] (dump_stack+0x24/0x28)
[    0.367095] [<c03cf9a4>] (dump_stack) from [<c002f688>] (warn_slowpath_common+0x8c/0xb8)
[    0.367126] [<c002f5fc>] (warn_slowpath_common) from [<c002f758>] (warn_slowpath_null+0x24/0x2c)
[    0.367126]  r8:00000000 r7:00000000 r6:04001b00 r5:00000000 r4:f8001400
[    0.367156] [<c002f734>] (warn_slowpath_null) from [<c0213e50>] (omap3_l3_app_irq+0x100/0x134)
[    0.367187] [<c0213d50>] (omap3_l3_app_irq) from [<c005b50c>] (handle_irq_event_percpu+0x80/0x148)
[    0.367218]  r9:c3953e00 r8:00000013 r7:00000000 r6:00000000 r5:c39581c0 r4:c39581c0
[    0.367248] [<c005b48c>] (handle_irq_event_percpu) from [<c005b63c>] (handle_irq_event+0x68/0x90)
[    0.367248]  r10:c3856000 r9:80000000 r8:c3803200 r7:00000001 r6:00000000 r5:c39581c0
[    0.367279]  r4:c3953e00
[    0.367279] [<c005b5d4>] (handle_irq_event) from [<c005dfd0>] (handle_level_irq+0xa4/0x160)
[    0.367309]  r5:00000000 r4:c3953e00
[    0.367309] [<c005df2c>] (handle_level_irq) from [<c005ac0c>] (generic_handle_irq+0x34/0x44)
[    0.367340]  r4:00000013 r3:c005df2c
[    0.367370] [<c005abd8>] (generic_handle_irq) from [<c005ae70>] (__handle_domain_irq+0x5c/0xb0)
[    0.367370]  r4:c055db00 r3:00000106
[    0.367401] [<c005ae14>] (__handle_domain_irq) from [<c000866c>] (omap_intc_handle_irq+0xd0/0xd8)
[    0.367401]  r8:60000113 r7:0000000a r6:c05842c0 r5:c3857d00 r4:c055dd20 r3:c3857d00
[    0.367431] [<c000859c>] (omap_intc_handle_irq) from [<c0012500>] (__irq_svc+0x40/0x74)
[    0.367431] Exception stack(0xc3857d00 to 0xc3857d48)
[    0.367462] 7d00: 00000000 0000001c 00000001 00000000 c38b7e00 c0554a80 0000001c 00000000
[    0.367492] 7d20: 60000113 80000000 c3856000 c3857d74 c3857d28 c3857d48 c005e3c0 c005c8f8
[    0.367492] 7d40: 40000113 ffffffff
[    0.367492]  r7:c3857d34 r6:ffffffff r5:40000113 r4:c005c8f8
[    0.367523] [<c005c66c>] (__setup_irq) from [<c005cc3c>] (setup_irq+0x48/0x90)
[    0.367523]  r8:20000113 r7:c39ec400 r6:c0554a80 r5:0000001c r4:c38b7e00
[    0.367553] [<c005cbf4>] (setup_irq) from [<c002a7fc>] (omap_system_dma_probe+0x224/0x2f8)
[    0.367584]  r6:00000600 r5:c057342c r4:0000001c r3:00000030
[    0.367614] [<c002a5d8>] (omap_system_dma_probe) from [<c02875d8>] (platform_drv_probe+0x4c/0xac)
[    0.367614]  r10:00000000 r9:c04ff5f0 r8:00000000 r7:fffffdfb r6:c0554a3c r5:c39ec410
[    0.367645]  r4:c05875f0
[    0.367645] [<c028758c>] (platform_drv_probe) from [<c0285eb8>] (driver_probe_device+0x110/0x244)
[    0.367675]  r7:c0554a3c r6:00000000 r5:c39ec410 r4:c05875f0
[    0.367675] [<c0285da8>] (driver_probe_device) from [<c02860cc>] (__driver_attach+0x94/0x98)
[    0.367706]  r8:0000006a r7:00000000 r6:c39ec444 r5:c0554a3c r4:c39ec410 r3:00000000
[    0.367736] [<c0286038>] (__driver_attach) from [<c0284270>] (bus_for_each_dev+0x74/0xa8)
[    0.367736]  r6:c0286038 r5:c0554a3c r4:00000000 r3:00000000
[    0.367767] [<c02841fc>] (bus_for_each_dev) from [<c02859ac>] (driver_attach+0x24/0x28)
[    0.367797]  r6:c0564448 r5:c39d4c00 r4:c0554a3c
[    0.367828] [<c0285988>] (driver_attach) from [<c0285664>] (bus_add_driver+0x150/0x1f8)
[    0.367828] [<c0285514>] (bus_add_driver) from [<c028655c>] (driver_register+0x80/0x100)
[    0.367828]  r7:c050d4bc r6:c39ed580 r5:c053fba0 r4:c0554a3c
[    0.367858] [<c02864dc>] (driver_register) from [<c028751c>] (__platform_driver_register+0x5c/0x64)
[    0.367889]  r5:c053fba0 r4:c053fba0
[    0.367889] [<c02874c0>] (__platform_driver_register) from [<c050d4d8>] (omap_system_dma_init+0x1c/0x20)
[    0.367919] [<c050d4bc>] (omap_system_dma_init) from [<c0008868>] (do_one_initcall+0x94/0x1dc)
[    0.367950] [<c00087d4>] (do_one_initcall) from [<c04ffdc0>] (kernel_init_freeable+0x12c/0x1d0)
[    0.367950]  r10:c0528b78 r9:c04ff5f0 r8:0000006a r7:c0572880 r6:c0572880 r5:00000003
[    0.367980]  r4:c0535b80
[    0.367980] [<c04ffc94>] (kernel_init_freeable) from [<c03cdd9c>] (kernel_init+0x10/0xf0)
[    0.368011]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c03cdd8c
[    0.368011]  r4:00000000
[    0.368041] [<c03cdd8c>] (kernel_init) from [<c000ea78>] (ret_from_fork+0x14/0x3c)
[    0.368041]  r4:00000000 r3:c3856000
[    0.368103] ---[ end trace 417eab97f066e1a5 ]---

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> Could it be that I missed some DT updates?

> [    0.366882] In-band Error seen by MPU  at address 0
> [    0.366912] ------------[ cut here ]------------
> [    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()

This appears also on N900/N950/N9...

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> Hi,
> 
> On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> > When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > Could it be that I missed some DT updates?
> 
> > [    0.366882] In-band Error seen by MPU  at address 0
> > [    0.366912] ------------[ cut here ]------------
> > [    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> 
> This appears also on N900/N950/N9...

Do you have CONFIG_PREEMPT enabled? It seems there's some
regression related to CONFIG_PREEMPT that started happening
with the merge window?

Regards,

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
>> Hi,
>>
>> On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
>>> When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
>>> I see a "In-band ERROR" warning which wasn't present in 3.18.1.
>>> Could it be that I missed some DT updates?
>>
>>> [    0.366882] In-band Error seen by MPU  at address 0
>>> [    0.366912] ------------[ cut here ]------------
>>> [    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
>>
>> This appears also on N900/N950/N9...
>
> Do you have CONFIG_PREEMPT enabled? It seems there's some
> regression related to CONFIG_PREEMPT that started happening
> with the merge window?

Indeed, when I disable CONFIG_PREEMPT the warning is gone.

Thanks,
Peter

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
> Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> >* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> >>>Could it be that I missed some DT updates?
> >>
> >>>[    0.366882] In-band Error seen by MPU  at address 0
> >>>[    0.366912] ------------[ cut here ]------------
> >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> >>
> >>This appears also on N900/N950/N9...
> >
> >Do you have CONFIG_PREEMPT enabled? It seems there's some
> >regression related to CONFIG_PREEMPT that started happening
> >with the merge window?
> 
> Indeed, when I disable CONFIG_PREEMPT the warning is gone.

Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
thread / patch set for this already; or should we try to bisect this?

Thanks,

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150102 12:21]:
> Hi,
> 
> On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
> > Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> > >* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > >>>Could it be that I missed some DT updates?
> > >>
> > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > >>>[    0.366912] ------------[ cut here ]------------
> > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > >>
> > >>This appears also on N900/N950/N9...
> > >
> > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > >regression related to CONFIG_PREEMPT that started happening
> > >with the merge window?
> > 
> > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> 
> Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> thread / patch set for this already; or should we try to bisect this?

AFAIK I'm not aware of other threads, I noticied it with the
"OMAP 4430 SDP: rather sick with recent kernels" thread, but
never got anywhere with it.

Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
that too should be verified. Sounds like running git bisect on
this one is needed.

Regards,

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 12:21]:
> > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
> > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> > > >* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > >>>Could it be that I missed some DT updates?
> > > >>
> > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > >>>[    0.366912] ------------[ cut here ]------------
> > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > >>
> > > >>This appears also on N900/N950/N9...
> > > >
> > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > >regression related to CONFIG_PREEMPT that started happening
> > > >with the merge window?
> > > 
> > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > 
> > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > thread / patch set for this already; or should we try to bisect this?
> 
> AFAIK I'm not aware of other threads, I noticied it with the
> "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> never got anywhere with it.
> 
> Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> that too should be verified. Sounds like running git bisect on
> this one is needed.

I tried to bisect this on N950, and it resulted in:

aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
commit aa25729cfd9709156661bea0f9293deb7729f57a
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Nov 5 09:21:23 2014 -0800

    ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree

But when I tried to revert this from 3.19-rc2, my board won't boot at
all...

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150102 14:37]:
> Hi,
> 
> On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
> > * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 12:21]:
> > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
> > > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> > > > >* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> > > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > >>>Could it be that I missed some DT updates?
> > > > >>
> > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > >>
> > > > >>This appears also on N900/N950/N9...
> > > > >
> > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > >regression related to CONFIG_PREEMPT that started happening
> > > > >with the merge window?
> > > > 
> > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > 
> > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > thread / patch set for this already; or should we try to bisect this?
> > 
> > AFAIK I'm not aware of other threads, I noticied it with the
> > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > never got anywhere with it.
> > 
> > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > that too should be verified. Sounds like running git bisect on
> > this one is needed.
> 
> I tried to bisect this on N950, and it resulted in:
> 
> aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> commit aa25729cfd9709156661bea0f9293deb7729f57a
> Author: Tony Lindgren <tony@atomide.com>
> Date:   Wed Nov 5 09:21:23 2014 -0800
> 
>     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> 
> But when I tried to revert this from 3.19-rc2, my board won't boot at
> all...

Hmm OK that commit just fixed the omap_l3_smx so we now see
warnings about the unclocked register access.

It seems that probably the CONFIG_PREEMPT issue has been lurking
around for longer but we have not seen any errors because
omap_l3_smx just recently started exposing them.

Does v3.18 + commit aa25729cfd9 manually applied also produce
the CONFIG_PREEMPT errors?

Regards,

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

Am 03.01.2015 um 01:02 schrieb Tony Lindgren:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 14:37]:
>> Hi,
>>
>> On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 12:21]:
>>>> On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
>>>>> Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
>>>>>>> On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
>>>>>>>> When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
>>>>>>>> I see a "In-band ERROR" warning which wasn't present in 3.18.1.
>>>>>>>> Could it be that I missed some DT updates?
>>>>>>>
>>>>>>>> [    0.366882] In-band Error seen by MPU  at address 0
>>>>>>>> [    0.366912] ------------[ cut here ]------------
>>>>>>>> [    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
>>>>>>>
>>>>>>> This appears also on N900/N950/N9...
>>>>>>
>>>>>> Do you have CONFIG_PREEMPT enabled? It seems there's some
>>>>>> regression related to CONFIG_PREEMPT that started happening
>>>>>> with the merge window?
>>>>>
>>>>> Indeed, when I disable CONFIG_PREEMPT the warning is gone.
>>>>
>>>> Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
>>>> thread / patch set for this already; or should we try to bisect this?
>>>
>>> AFAIK I'm not aware of other threads, I noticied it with the
>>> "OMAP 4430 SDP: rather sick with recent kernels" thread, but
>>> never got anywhere with it.
>>>
>>> Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
>>> that too should be verified. Sounds like running git bisect on
>>> this one is needed.
>>
>> I tried to bisect this on N950, and it resulted in:
>>
>> aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
>> commit aa25729cfd9709156661bea0f9293deb7729f57a
>> Author: Tony Lindgren <tony@atomide.com>
>> Date:   Wed Nov 5 09:21:23 2014 -0800
>>
>>      ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
>>
>> But when I tried to revert this from 3.19-rc2, my board won't boot at
>> all...
>
> Hmm OK that commit just fixed the omap_l3_smx so we now see
> warnings about the unclocked register access.
>
> It seems that probably the CONFIG_PREEMPT issue has been lurking
> around for longer but we have not seen any errors because
> omap_l3_smx just recently started exposing them.
>
> Does v3.18 + commit aa25729cfd9 manually applied also produce
> the CONFIG_PREEMPT errors?
>

Yes, same error. I applied it on top of v3.18.1.

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Fri, Jan 02, 2015 at 04:02:21PM -0800, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 14:37]:
> > On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote:
> > > * Aaro Koskinen <aaro.koskinen@iki.fi> [150102 12:21]:
> > > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote:
> > > > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren:
> > > > > >* Aaro Koskinen <aaro.koskinen@iki.fi> [150101 10:23]:
> > > > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel wrote:
> > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > >>>Could it be that I missed some DT updates?
> > > > > >>
> > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > >>
> > > > > >>This appears also on N900/N950/N9...
> > > > > >
> > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > >with the merge window?
> > > > > 
> > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > 
> > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > thread / patch set for this already; or should we try to bisect this?
> > > 
> > > AFAIK I'm not aware of other threads, I noticied it with the
> > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > never got anywhere with it.
> > > 
> > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > that too should be verified. Sounds like running git bisect on
> > > this one is needed.
> > 
> > I tried to bisect this on N950, and it resulted in:
> > 
> > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > Author: Tony Lindgren <tony@atomide.com>
> > Date:   Wed Nov 5 09:21:23 2014 -0800
> > 
> >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > 
> > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > all...
> 
> Hmm OK that commit just fixed the omap_l3_smx so we now see
> warnings about the unclocked register access.
> 
> It seems that probably the CONFIG_PREEMPT issue has been lurking
> around for longer but we have not seen any errors because
> omap_l3_smx just recently started exposing them.
> 
> Does v3.18 + commit aa25729cfd9 manually applied also produce
> the CONFIG_PREEMPT errors?

Yes it does, so I made another bisection between 3.17 and 3.18
using the above patch to trigger the issue, and I got:

55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
commit 55601c9f24670ba926ebdd4d712ac3b177232330
Author: Felipe Balbi <balbi@ti.com>
Date:   Mon Sep 8 17:54:58 2014 -0700

    arm: omap: intc: switch over to linear irq domain

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

Hi,

On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
> > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > > >>>Could it be that I missed some DT updates?
> > > > > > >>
> > > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > > >>
> > > > > > >>This appears also on N900/N950/N9...
> > > > > > >
> > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > > >with the merge window?
> > > > > > 
> > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > > 
> > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > > thread / patch set for this already; or should we try to bisect this?
> > > > 
> > > > AFAIK I'm not aware of other threads, I noticied it with the
> > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > > never got anywhere with it.
> > > > 
> > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > > that too should be verified. Sounds like running git bisect on
> > > > this one is needed.
> > > 
> > > I tried to bisect this on N950, and it resulted in:
> > > 
> > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > > Author: Tony Lindgren <tony@atomide.com>
> > > Date:   Wed Nov 5 09:21:23 2014 -0800
> > > 
> > >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > > 
> > > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > > all...
> > 
> > Hmm OK that commit just fixed the omap_l3_smx so we now see
> > warnings about the unclocked register access.
> > 
> > It seems that probably the CONFIG_PREEMPT issue has been lurking
> > around for longer but we have not seen any errors because
> > omap_l3_smx just recently started exposing them.
> > 
> > Does v3.18 + commit aa25729cfd9 manually applied also produce
> > the CONFIG_PREEMPT errors?
> 
> Yes it does, so I made another bisection between 3.17 and 3.18
> using the above patch to trigger the issue, and I got:
> 
> 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
> commit 55601c9f24670ba926ebdd4d712ac3b177232330
> Author: Felipe Balbi <balbi@ti.com>
> Date:   Mon Sep 8 17:54:58 2014 -0700
> 
>     arm: omap: intc: switch over to linear irq domain

Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
Perhaps this is something related to another OMAP3-only driver ? Perhaps
HSI/SSI ?

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote:
> On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
> > > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > > > >>>Could it be that I missed some DT updates?
> > > > > > > >>
> > > > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > > > >>
> > > > > > > >>This appears also on N900/N950/N9...
> > > > > > > >
> > > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > > > >with the merge window?
> > > > > > > 
> > > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > > > 
> > > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > > > thread / patch set for this already; or should we try to bisect this?
> > > > > 
> > > > > AFAIK I'm not aware of other threads, I noticied it with the
> > > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > > > never got anywhere with it.
> > > > > 
> > > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > > > that too should be verified. Sounds like running git bisect on
> > > > > this one is needed.
> > > > 
> > > > I tried to bisect this on N950, and it resulted in:
> > > > 
> > > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > > > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > > > Author: Tony Lindgren <tony@atomide.com>
> > > > Date:   Wed Nov 5 09:21:23 2014 -0800
> > > > 
> > > >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > > > 
> > > > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > > > all...
> > > 
> > > Hmm OK that commit just fixed the omap_l3_smx so we now see
> > > warnings about the unclocked register access.
> > > 
> > > It seems that probably the CONFIG_PREEMPT issue has been lurking
> > > around for longer but we have not seen any errors because
> > > omap_l3_smx just recently started exposing them.
> > > 
> > > Does v3.18 + commit aa25729cfd9 manually applied also produce
> > > the CONFIG_PREEMPT errors?
> > 
> > Yes it does, so I made another bisection between 3.17 and 3.18
> > using the above patch to trigger the issue, and I got:
> > 
> > 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
> > commit 55601c9f24670ba926ebdd4d712ac3b177232330
> > Author: Felipe Balbi <balbi@ti.com>
> > Date:   Mon Sep 8 17:54:58 2014 -0700
> > 
> >     arm: omap: intc: switch over to linear irq domain
> 
> Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> Perhaps this is something related to another OMAP3-only driver ? Perhaps
> HSI/SSI ?

I did some debugging and it seems the "In-band Error"
occurs when omap_system_dma_probe() is being run, specifically when
the interrupt is enabled. I believe the "DMA" interrupt it's trying
set up is completely wrong:

 28:          0      GPIO   2  DMA

GPIO 2?! Where is that coming from?

With the commit before the "arm: omap: intc: switch over
to linear irq domain" it seems to be more reasonable:

 28:          0      INTC  12  DMA

A.

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150105 15:19]:
> Hi,
> 
> On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote:
> > On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
> > > > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > > > > >>>Could it be that I missed some DT updates?
> > > > > > > > >>
> > > > > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > > > > >>
> > > > > > > > >>This appears also on N900/N950/N9...
> > > > > > > > >
> > > > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > > > > >with the merge window?
> > > > > > > > 
> > > > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > > > > 
> > > > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > > > > thread / patch set for this already; or should we try to bisect this?
> > > > > > 
> > > > > > AFAIK I'm not aware of other threads, I noticied it with the
> > > > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > > > > never got anywhere with it.
> > > > > > 
> > > > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > > > > that too should be verified. Sounds like running git bisect on
> > > > > > this one is needed.
> > > > > 
> > > > > I tried to bisect this on N950, and it resulted in:
> > > > > 
> > > > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > > > > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > > > > Author: Tony Lindgren <tony@atomide.com>
> > > > > Date:   Wed Nov 5 09:21:23 2014 -0800
> > > > > 
> > > > >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > > > > 
> > > > > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > > > > all...
> > > > 
> > > > Hmm OK that commit just fixed the omap_l3_smx so we now see
> > > > warnings about the unclocked register access.
> > > > 
> > > > It seems that probably the CONFIG_PREEMPT issue has been lurking
> > > > around for longer but we have not seen any errors because
> > > > omap_l3_smx just recently started exposing them.
> > > > 
> > > > Does v3.18 + commit aa25729cfd9 manually applied also produce
> > > > the CONFIG_PREEMPT errors?
> > > 
> > > Yes it does, so I made another bisection between 3.17 and 3.18
> > > using the above patch to trigger the issue, and I got:
> > > 
> > > 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
> > > commit 55601c9f24670ba926ebdd4d712ac3b177232330
> > > Author: Felipe Balbi <balbi@ti.com>
> > > Date:   Mon Sep 8 17:54:58 2014 -0700
> > > 
> > >     arm: omap: intc: switch over to linear irq domain
> > 
> > Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> > Perhaps this is something related to another OMAP3-only driver ? Perhaps
> > HSI/SSI ?
> 
> I did some debugging and it seems the "In-band Error"
> occurs when omap_system_dma_probe() is being run, specifically when
> the interrupt is enabled. I believe the "DMA" interrupt it's trying
> set up is completely wrong:
> 
>  28:          0      GPIO   2  DMA
> 
> GPIO 2?! Where is that coming from?
> 
> With the commit before the "arm: omap: intc: switch over
> to linear irq domain" it seems to be more reasonable:
> 
>  28:          0      INTC  12  DMA

Hmm stange. Felipe, chances are this wrong interrupt issue also
exists on am33xx but it's not showing up as the legacy DMA is not
being used.

Note that currently legacy DMA and drivers/dma/omap-dma.c are
using separate interrupts as they are mappable. It seems this
issue is affecting legacy DMA.

Regards,

Tony

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 5010 bytes --]

Hi,

On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote:
> > On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
> > > > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > > > > >>>Could it be that I missed some DT updates?
> > > > > > > > >>
> > > > > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > > > > >>
> > > > > > > > >>This appears also on N900/N950/N9...
> > > > > > > > >
> > > > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > > > > >with the merge window?
> > > > > > > > 
> > > > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > > > > 
> > > > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > > > > thread / patch set for this already; or should we try to bisect this?
> > > > > > 
> > > > > > AFAIK I'm not aware of other threads, I noticied it with the
> > > > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > > > > never got anywhere with it.
> > > > > > 
> > > > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > > > > that too should be verified. Sounds like running git bisect on
> > > > > > this one is needed.
> > > > > 
> > > > > I tried to bisect this on N950, and it resulted in:
> > > > > 
> > > > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > > > > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > > > > Author: Tony Lindgren <tony@atomide.com>
> > > > > Date:   Wed Nov 5 09:21:23 2014 -0800
> > > > > 
> > > > >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > > > > 
> > > > > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > > > > all...
> > > > 
> > > > Hmm OK that commit just fixed the omap_l3_smx so we now see
> > > > warnings about the unclocked register access.
> > > > 
> > > > It seems that probably the CONFIG_PREEMPT issue has been lurking
> > > > around for longer but we have not seen any errors because
> > > > omap_l3_smx just recently started exposing them.
> > > > 
> > > > Does v3.18 + commit aa25729cfd9 manually applied also produce
> > > > the CONFIG_PREEMPT errors?
> > > 
> > > Yes it does, so I made another bisection between 3.17 and 3.18
> > > using the above patch to trigger the issue, and I got:
> > > 
> > > 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
> > > commit 55601c9f24670ba926ebdd4d712ac3b177232330
> > > Author: Felipe Balbi <balbi@ti.com>
> > > Date:   Mon Sep 8 17:54:58 2014 -0700
> > > 
> > >     arm: omap: intc: switch over to linear irq domain
> > 
> > Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> > Perhaps this is something related to another OMAP3-only driver ? Perhaps
> > HSI/SSI ?
> 
> I did some debugging and it seems the "In-band Error"
> occurs when omap_system_dma_probe() is being run, specifically when
> the interrupt is enabled. I believe the "DMA" interrupt it's trying
> set up is completely wrong:
> 
>  28:          0      GPIO   2  DMA
> 
> GPIO 2?! Where is that coming from?

heh, it's probably the linux number used ended up mapping to another irq
domain. Can you add this debugging patch and report dmesg ?

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 24770e5..b3f6dcd 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1380,6 +1380,8 @@ static int omap_system_dma_probe(struct platform_device *pdev)
 	if (dma_omap2plus() && !(d->dev_caps & DMA_ENGINE_HANDLE_IRQ)) {
 		strcpy(irq_name, "0");
 		dma_irq = platform_get_irq_byname(pdev, irq_name);
+		dev_info(&pdev->dev, "legacy DMA IRQ %d\n", dma_irq);
+
 		if (dma_irq < 0) {
 			dev_err(&pdev->dev, "failed: request IRQ %d", dma_irq);
 			ret = dma_irq;
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c0016a6..98fe2d2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1155,6 +1155,8 @@ static int omap_dma_probe(struct platform_device *pdev)
 	}
 
 	irq = platform_get_irq(pdev, 1);
+
+	dev_info(&pdev->dev, "dmaengine IRQ %d\n", irq);
 	if (irq <= 0) {
 		dev_info(&pdev->dev, "failed to get L1 IRQ: %d\n", irq);
 		od->legacy = true;

Note that I need one log post commit and another log pre commit. If any
of the IRQ numbers change, if means that irq_domain_add_linear() ended
up changing IRQ start and we would need some trick to grab the correct
IRQ number again.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]

Hi,

On Mon, Jan 05, 2015 at 04:12:51PM -0800, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150105 15:19]:
> > Hi,
> > 
> > On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote:
> > > On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote:
> > > > > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2
> > > > > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1.
> > > > > > > > > >>>Could it be that I missed some DT updates?
> > > > > > > > > >>
> > > > > > > > > >>>[    0.366882] In-band Error seen by MPU  at address 0
> > > > > > > > > >>>[    0.366912] ------------[ cut here ]------------
> > > > > > > > > >>>[    0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134()
> > > > > > > > > >>
> > > > > > > > > >>This appears also on N900/N950/N9...
> > > > > > > > > >
> > > > > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some
> > > > > > > > > >regression related to CONFIG_PREEMPT that started happening
> > > > > > > > > >with the merge window?
> > > > > > > > > 
> > > > > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone.
> > > > > > > > 
> > > > > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail
> > > > > > > > thread / patch set for this already; or should we try to bisect this?
> > > > > > > 
> > > > > > > AFAIK I'm not aware of other threads, I noticied it with the
> > > > > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but
> > > > > > > never got anywhere with it.
> > > > > > > 
> > > > > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but
> > > > > > > that too should be verified. Sounds like running git bisect on
> > > > > > > this one is needed.
> > > > > > 
> > > > > > I tried to bisect this on N950, and it resulted in:
> > > > > > 
> > > > > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit
> > > > > > commit aa25729cfd9709156661bea0f9293deb7729f57a
> > > > > > Author: Tony Lindgren <tony@atomide.com>
> > > > > > Date:   Wed Nov 5 09:21:23 2014 -0800
> > > > > > 
> > > > > >     ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree
> > > > > > 
> > > > > > But when I tried to revert this from 3.19-rc2, my board won't boot at
> > > > > > all...
> > > > > 
> > > > > Hmm OK that commit just fixed the omap_l3_smx so we now see
> > > > > warnings about the unclocked register access.
> > > > > 
> > > > > It seems that probably the CONFIG_PREEMPT issue has been lurking
> > > > > around for longer but we have not seen any errors because
> > > > > omap_l3_smx just recently started exposing them.
> > > > > 
> > > > > Does v3.18 + commit aa25729cfd9 manually applied also produce
> > > > > the CONFIG_PREEMPT errors?
> > > > 
> > > > Yes it does, so I made another bisection between 3.17 and 3.18
> > > > using the above patch to trigger the issue, and I got:
> > > > 
> > > > 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit
> > > > commit 55601c9f24670ba926ebdd4d712ac3b177232330
> > > > Author: Felipe Balbi <balbi@ti.com>
> > > > Date:   Mon Sep 8 17:54:58 2014 -0700
> > > > 
> > > >     arm: omap: intc: switch over to linear irq domain
> > > 
> > > Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> > > Perhaps this is something related to another OMAP3-only driver ? Perhaps
> > > HSI/SSI ?
> > 
> > I did some debugging and it seems the "In-band Error"
> > occurs when omap_system_dma_probe() is being run, specifically when
> > the interrupt is enabled. I believe the "DMA" interrupt it's trying
> > set up is completely wrong:
> > 
> >  28:          0      GPIO   2  DMA
> > 
> > GPIO 2?! Where is that coming from?
> > 
> > With the commit before the "arm: omap: intc: switch over
> > to linear irq domain" it seems to be more reasonable:
> > 
> >  28:          0      INTC  12  DMA
> 
> Hmm stange. Felipe, chances are this wrong interrupt issue also
> exists on am33xx but it's not showing up as the legacy DMA is not
> being used.

not really, AM335x doesn't use sDMA, only EDMA.

> Note that currently legacy DMA and drivers/dma/omap-dma.c are
> using separate interrupts as they are mappable. It seems this
> issue is affecting legacy DMA.

makes sense now after readin plat-omap/dma.c (that thing needs to go :-)

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

Am 05.01.2015 um 16:43 schrieb Felipe Balbi:

>
> Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> Perhaps this is something related to another OMAP3-only driver ? Perhaps
> HSI/SSI ?
>
> cheers
>

I see a ssi error directly before the IN-Band error:

[    0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
[    0.346893] In-band Error seen by MPU  at address 0
[    0.346923] ------------[ cut here ]------------

Peter

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

Hi,

On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
> Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
> >Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> >Perhaps this is something related to another OMAP3-only driver?
> >Perhaps HSI/SSI ?
> 
> I see a ssi error directly before the IN-Band error:
> 
> [    0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
> [    0.346893] In-band Error seen by MPU  at address 0
> [    0.346923] ------------[ cut here ]------------

mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
should be disabled for those SoCs:

&ssi {
    status = "disabled";
};

From what I can see the following in-tree .dts files should be
fixed, too:

* am3517_mt_ventoux.dts
  Currently includes "omap34xx.dtsi" instead of "am3517.dtsi".

Apart from that the following boards seem to use omap36xx.dtsi
include, but are actually DM37xx, so they should disable the
ssi block:

* omap3-igep.dtsi
* omap3-lilly-a83x.dtsi
* omap3-overo-storm.dtsi

I will prepare a patch for that later.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,
On Mon, Jan 05, 2015 at 08:01:22PM -0600, Felipe Balbi wrote:
> On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote:
> > I did some debugging and it seems the "In-band Error"
> > occurs when omap_system_dma_probe() is being run, specifically when
> > the interrupt is enabled. I believe the "DMA" interrupt it's trying
> > set up is completely wrong:
> > 
> >  28:          0      GPIO   2  DMA
> > 
> > GPIO 2?! Where is that coming from?
> 
> heh, it's probably the linux number used ended up mapping to another irq
> domain. Can you add this debugging patch and report dmesg ?

Post-commit:

[    0.208251] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[    0.216125] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 22

 22:          5      INTC  13  omap-dma-engine
 28:          0      GPIO   2  DMA

Pre-commit:

[    0.208557] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[    0.216461] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 29

 28:          0      INTC  12  DMA
 29:          5      INTC  13  omap-dma-engine

> Note that I need one log post commit and another log pre commit. If any
> of the IRQ numbers change, if means that irq_domain_add_linear() ended
> up changing IRQ start and we would need some trick to grab the correct
> IRQ number again.

So looks like static OMAP_INTC_START cannot be used anymore, but hwmod
data is full of these?

mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c: { .name = "0", .irq = 12 + OMAP_INTC_START, }, /* INT_24XX_SDMA_IRQ0 */

A.

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote:
> On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
> > Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
> > >Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
> > >Perhaps this is something related to another OMAP3-only driver?
> > >Perhaps HSI/SSI ?
> > 
> > I see a ssi error directly before the IN-Band error:
> > 
> > [    0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
> > [    0.346893] In-band Error seen by MPU  at address 0
> > [    0.346923] ------------[ cut here ]------------
> 
> mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.

This log occurs also on 3630, because ssi hwmod stuff is missing from
omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need
to be added since we should get nokia-modem working also on N950/N9...

Peter: if you boot with "initcall_debug", you should see the error
is during the DMA setup.

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

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

Am 06.01.2015 um 12:52 schrieb Sebastian Reichel:
> Hi,
>
> On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
>> Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
>>> Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
>>> Perhaps this is something related to another OMAP3-only driver?
>>> Perhaps HSI/SSI ?
>>
>> I see a ssi error directly before the IN-Band error:
>>
>> [    0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
>> [    0.346893] In-band Error seen by MPU  at address 0
>> [    0.346923] ------------[ cut here ]------------
>
> mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
> Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
> should be disabled for those SoCs:
>
> &ssi {
>      status = "disabled";
> };

Indeed, I include omap36xx.dtsi.
Disabling ssi removes ssi the error.
But the In-Band error is still there, so not related to ssi.


I also see these errors:

omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp2: cannot be enabled for reset (3)

and

irq: no irq domain found for /ocp/pinmux@48002030 !

Could these errors also be fixed by the dts.

Peter

>
>  From what I can see the following in-tree .dts files should be
> fixed, too:
>
> * am3517_mt_ventoux.dts
>    Currently includes "omap34xx.dtsi" instead of "am3517.dtsi".
>
> Apart from that the following boards seem to use omap36xx.dtsi
> include, but are actually DM37xx, so they should disable the
> ssi block:
>
> * omap3-igep.dtsi
> * omap3-lilly-a83x.dtsi
> * omap3-overo-storm.dtsi
>
> I will prepare a patch for that later.
>
> -- Sebastian
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Peter Kümmel]

Am 06.01.2015 um 13:47 schrieb Aaro Koskinen:
> Hi,
>
> On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote:
>> On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
>>> Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
>>>> Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem.
>>>> Perhaps this is something related to another OMAP3-only driver?
>>>> Perhaps HSI/SSI ?
>>>
>>> I see a ssi error directly before the IN-Band error:
>>>
>>> [    0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
>>> [    0.346893] In-band Error seen by MPU  at address 0
>>> [    0.346923] ------------[ cut here ]------------
>>
>> mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
>
> This log occurs also on 3630, because ssi hwmod stuff is missing from
> omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need
> to be added since we should get nokia-modem working also on N950/N9...
>
> Peter: if you boot with "initcall_debug", you should see the error
> is during the DMA setup.

DMA is not a module here thus loaded before the initcall.

I've tried with CONFIG_DMADEVICES_DEBUG but then kernel didn't start at all.
Absolutely no messages.
  
>
> A.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Felipe Balbi]

commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.

Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().

A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.

Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
 	return ret;
 }
 
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
 {
 	int j, irq_base;
 
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
 		irq_base = 0;
 	}
 
-	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
 			&irq_domain_simple_ops, NULL);
 
 	omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
 {
 	int ret;
 
-	if (node)
+	/*
+	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+	 * depends is still not ready for linear IRQ domains; because of that
+	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
+	 * linear IRQ Domain until that driver is finally fixed.
+	 */
+	if (of_device_is_compatible(node, "ti,omap2-intc") ||
+			of_device_is_compatible(node, "ti,omap3-intc")) {
+		struct resource res;
+
+		if (of_address_to_resource(node, 0, &res))
+			return -ENOMEM;
+
+		base = res.start;
+		ret = omap_init_irq_legacy(base, node);
+	} else if (node) {
 		ret = omap_init_irq_of(node);
-	else
-		ret = omap_init_irq_legacy(base);
+	} else {
+		ret = omap_init_irq_legacy(base, NULL);
+	}
 
 	if (ret == 0)
 		omap_irq_enable_protection();
-- 
2.2.0

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Felipe Balbi]

commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.

Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().

A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.

Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
 	return ret;
 }
 
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
 {
 	int j, irq_base;
 
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
 		irq_base = 0;
 	}
 
-	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
 			&irq_domain_simple_ops, NULL);
 
 	omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
 {
 	int ret;
 
-	if (node)
+	/*
+	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+	 * depends is still not ready for linear IRQ domains; because of that
+	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
+	 * linear IRQ Domain until that driver is finally fixed.
+	 */
+	if (of_device_is_compatible(node, "ti,omap2-intc") ||
+			of_device_is_compatible(node, "ti,omap3-intc")) {
+		struct resource res;
+
+		if (of_address_to_resource(node, 0, &res))
+			return -ENOMEM;
+
+		base = res.start;
+		ret = omap_init_irq_legacy(base, node);
+	} else if (node) {
 		ret = omap_init_irq_of(node);
-	else
-		ret = omap_init_irq_legacy(base);
+	} else {
+		ret = omap_init_irq_legacy(base, NULL);
+	}
 
 	if (ret == 0)
 		omap_irq_enable_protection();
-- 
2.2.0

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
> 
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
> 
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
> 
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Signed-off-by: Felipe Balbi <balbi@ti.com>

I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the "In-band Error" is gone.

Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>

BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...

A.

> ---
>  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 3c970259c0eb..6ef88f56cf8d 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
>  	return ret;
>  }
>  
> -static int __init omap_init_irq_legacy(u32 base)
> +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
>  {
>  	int j, irq_base;
>  
> @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
>  		irq_base = 0;
>  	}
>  
> -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
>  			&irq_domain_simple_ops, NULL);
>  
>  	omap_irq_soft_reset();
> @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
>  {
>  	int ret;
>  
> -	if (node)
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.
> +	 */
> +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> +			of_device_is_compatible(node, "ti,omap3-intc")) {
> +		struct resource res;
> +
> +		if (of_address_to_resource(node, 0, &res))
> +			return -ENOMEM;
> +
> +		base = res.start;
> +		ret = omap_init_irq_legacy(base, node);
> +	} else if (node) {
>  		ret = omap_init_irq_of(node);
> -	else
> -		ret = omap_init_irq_legacy(base);
> +	} else {
> +		ret = omap_init_irq_legacy(base, NULL);
> +	}
>  
>  	if (ret == 0)
>  		omap_irq_enable_protection();
> -- 
> 2.2.0
> 

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
> 
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
> 
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
> 
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Signed-off-by: Felipe Balbi <balbi@ti.com>

I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
and also the "In-band Error" is gone.

Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>

BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
so maybe you should consider adding also Cc: stable...

A.

> ---
>  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 3c970259c0eb..6ef88f56cf8d 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
>  	return ret;
>  }
>  
> -static int __init omap_init_irq_legacy(u32 base)
> +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
>  {
>  	int j, irq_base;
>  
> @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
>  		irq_base = 0;
>  	}
>  
> -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
>  			&irq_domain_simple_ops, NULL);
>  
>  	omap_irq_soft_reset();
> @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
>  {
>  	int ret;
>  
> -	if (node)
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.
> +	 */
> +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> +			of_device_is_compatible(node, "ti,omap3-intc")) {
> +		struct resource res;
> +
> +		if (of_address_to_resource(node, 0, &res))
> +			return -ENOMEM;
> +
> +		base = res.start;
> +		ret = omap_init_irq_legacy(base, node);
> +	} else if (node) {
>  		ret = omap_init_irq_of(node);
> -	else
> -		ret = omap_init_irq_legacy(base);
> +	} else {
> +		ret = omap_init_irq_legacy(base, NULL);
> +	}
>  
>  	if (ret == 0)
>  		omap_irq_enable_protection();
> -- 
> 2.2.0
> 

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150106 09:51]:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > commit 55601c9f2467 (arm: omap: intc: switch over
> > to linear irq domain) introduced a regression with
> > SDMA legacy driver because that driver strictly depends
> > on INTC's IRQs starting at NR_IRQs. Aparently
> > irq_domain_add_linear() won't guarantee that, since we see
> > a 7 IRQs difference when booting with and without the
> > commit cited above.
> > 
> > Until arch/arm/plat-omap/dma.c is properly fixed, we
> > must maintain OMAP2/3 using irq_domain_add_legacy().
> > 
> > A FIXME note was added so people know to delete that
> > code once that legacy DMA driver is fixed up.
> > 
> > Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
> and also the "In-band Error" is gone.
> 
> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> 
> BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
> so maybe you should consider adding also Cc: stable...

Yeah this one should be cc stable. Fixes the error for me too:

Tested-by: Tony Lindgren <tony@atomide.com>

> > ---
> >  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
> >  1 file changed, 21 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> > index 3c970259c0eb..6ef88f56cf8d 100644
> > --- a/drivers/irqchip/irq-omap-intc.c
> > +++ b/drivers/irqchip/irq-omap-intc.c
> > @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
> >  	return ret;
> >  }
> >  
> > -static int __init omap_init_irq_legacy(u32 base)
> > +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
> >  {
> >  	int j, irq_base;
> >  
> > @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
> >  		irq_base = 0;
> >  	}
> >  
> > -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> > +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
> >  			&irq_domain_simple_ops, NULL);
> >  
> >  	omap_irq_soft_reset();
> > @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
> >  {
> >  	int ret;
> >  
> > -	if (node)
> > +	/*
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> > +	 */
> > +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> > +			of_device_is_compatible(node, "ti,omap3-intc")) {
> > +		struct resource res;
> > +
> > +		if (of_address_to_resource(node, 0, &res))
> > +			return -ENOMEM;
> > +
> > +		base = res.start;
> > +		ret = omap_init_irq_legacy(base, node);
> > +	} else if (node) {
> >  		ret = omap_init_irq_of(node);
> > -	else
> > -		ret = omap_init_irq_legacy(base);
> > +	} else {
> > +		ret = omap_init_irq_legacy(base, NULL);
> > +	}
> >  
> >  	if (ret == 0)
> >  		omap_irq_enable_protection();
> > -- 
> > 2.2.0
> > 

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [150106 09:51]:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > commit 55601c9f2467 (arm: omap: intc: switch over
> > to linear irq domain) introduced a regression with
> > SDMA legacy driver because that driver strictly depends
> > on INTC's IRQs starting at NR_IRQs. Aparently
> > irq_domain_add_linear() won't guarantee that, since we see
> > a 7 IRQs difference when booting with and without the
> > commit cited above.
> > 
> > Until arch/arm/plat-omap/dma.c is properly fixed, we
> > must maintain OMAP2/3 using irq_domain_add_legacy().
> > 
> > A FIXME note was added so people know to delete that
> > code once that legacy DMA driver is fixed up.
> > 
> > Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> I tested this on N950 with 3.19-rc3, and /proc/interrupts looks sane
> and also the "In-band Error" is gone.
> 
> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> 
> BTW, I guess people still using 3.18.x will get the wrong IRQ for DMA,
> so maybe you should consider adding also Cc: stable...

Yeah this one should be cc stable. Fixes the error for me too:

Tested-by: Tony Lindgren <tony@atomide.com>

> > ---
> >  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
> >  1 file changed, 21 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> > index 3c970259c0eb..6ef88f56cf8d 100644
> > --- a/drivers/irqchip/irq-omap-intc.c
> > +++ b/drivers/irqchip/irq-omap-intc.c
> > @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
> >  	return ret;
> >  }
> >  
> > -static int __init omap_init_irq_legacy(u32 base)
> > +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
> >  {
> >  	int j, irq_base;
> >  
> > @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
> >  		irq_base = 0;
> >  	}
> >  
> > -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> > +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
> >  			&irq_domain_simple_ops, NULL);
> >  
> >  	omap_irq_soft_reset();
> > @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
> >  {
> >  	int ret;
> >  
> > -	if (node)
> > +	/*
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> > +	 */
> > +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> > +			of_device_is_compatible(node, "ti,omap3-intc")) {
> > +		struct resource res;
> > +
> > +		if (of_address_to_resource(node, 0, &res))
> > +			return -ENOMEM;
> > +
> > +		base = res.start;
> > +		ret = omap_init_irq_legacy(base, node);
> > +	} else if (node) {
> >  		ret = omap_init_irq_of(node);
> > -	else
> > -		ret = omap_init_irq_legacy(base);
> > +	} else {
> > +		ret = omap_init_irq_legacy(base, NULL);
> > +	}
> >  
> >  	if (ret == 0)
> >  		omap_irq_enable_protection();
> > -- 
> > 2.2.0
> > 

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Russell King - ARM Linux]

On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.

"finally fixed" or finally killed off like it really needs to be, once
all users of it are killed.

We've been trying to do this for, what, three years now... I finally
pushed a WARN_ON() into that code to make it obvious to anyone who
uses omap_request_dma() that they really need to update their code.

Here's the list of references to that symbol which *still* need to be
fixed so that we can kill the legacy DMA driver:

drivers/media/platform/omap/omap_vout_vrfb.c:   ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
drivers/media/platform/omap3isp/isphist.c:              ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, "DMA_ISP_HIST",
drivers/media/platform/soc_camera/omap1_camera.c:       err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME,
drivers/mtd/onenand/omap2.c:            r = omap_request_dma(0, pdev->dev.driver->name,
drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(chdat->sync_dev, dev_name,
drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(tusb_dma->sync_dev, "TUSB shared",

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

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Russell King - ARM Linux]

On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.

"finally fixed" or finally killed off like it really needs to be, once
all users of it are killed.

We've been trying to do this for, what, three years now... I finally
pushed a WARN_ON() into that code to make it obvious to anyone who
uses omap_request_dma() that they really need to update their code.

Here's the list of references to that symbol which *still* need to be
fixed so that we can kill the legacy DMA driver:

drivers/media/platform/omap/omap_vout_vrfb.c:   ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
drivers/media/platform/omap3isp/isphist.c:              ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, "DMA_ISP_HIST",
drivers/media/platform/soc_camera/omap1_camera.c:       err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME,
drivers/mtd/onenand/omap2.c:            r = omap_request_dma(0, pdev->dev.driver->name,
drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(chdat->sync_dev, dev_name,
drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(tusb_dma->sync_dev, "TUSB shared",

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

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 06:05:32PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> 
> "finally fixed" or finally killed off like it really needs to be, once
> all users of it are killed.
> 
> We've been trying to do this for, what, three years now... I finally
> pushed a WARN_ON() into that code to make it obvious to anyone who
> uses omap_request_dma() that they really need to update their code.

> Here's the list of references to that symbol which *still* need to be
> fixed so that we can kill the legacy DMA driver:
> 
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,

I only learned about this after the WARN_ON() appeared in 3.17
(just couple months ago), and it's on my TODO list...

A.

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Aaro Koskinen]

Hi,

On Tue, Jan 06, 2015 at 06:05:32PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> 
> "finally fixed" or finally killed off like it really needs to be, once
> all users of it are killed.
> 
> We've been trying to do this for, what, three years now... I finally
> pushed a WARN_ON() into that code to make it obvious to anyone who
> uses omap_request_dma() that they really need to update their code.

> Here's the list of references to that symbol which *still* need to be
> fixed so that we can kill the legacy DMA driver:
> 
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,

I only learned about this after the WARN_ON() appeared in 3.17
(just couple months ago), and it's on my TODO list...

A.

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150106 10:08]:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > +	/*
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> 
> "finally fixed" or finally killed off like it really needs to be, once
> all users of it are killed.
> 
> We've been trying to do this for, what, three years now... I finally
> pushed a WARN_ON() into that code to make it obvious to anyone who
> uses omap_request_dma() that they really need to update their code.
> 
> Here's the list of references to that symbol which *still* need to be
> fixed so that we can kill the legacy DMA driver:
> 
> drivers/media/platform/omap/omap_vout_vrfb.c:   ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
> drivers/media/platform/omap3isp/isphist.c:              ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, "DMA_ISP_HIST",
> drivers/media/platform/soc_camera/omap1_camera.c:       err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME,
> drivers/mtd/onenand/omap2.c:            r = omap_request_dma(0, pdev->dev.driver->name,

AFAIK we should just remove DMA support from the drivers above.
Nobody seems to be interested in doing anything about them.

> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,

OK so Aaro picked this one.

> drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(chdat->sync_dev, dev_name,
> drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(tusb_dma->sync_dev, "TUSB shared",

I'll update this one. FYI, I already have some work-in-progress
MUSB DMA patches that allow building in all the MUSB DMA glue
layers. I just need to finish that series for v3.20:

https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=musb-dma-2014-11-25-v2

So converting tusb6010 over to the dmaengine API would be the
next logical step after that series. Probably not going to
happen before v3.21 though..

Regards,

Tony

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150106 10:08]:
> On Tue, Jan 06, 2015 at 10:51:33AM -0600, Felipe Balbi wrote:
> > +	/*
> > +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> > +	 * depends is still not ready for linear IRQ domains; because of that
> > +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> > +	 * linear IRQ Domain until that driver is finally fixed.
> 
> "finally fixed" or finally killed off like it really needs to be, once
> all users of it are killed.
> 
> We've been trying to do this for, what, three years now... I finally
> pushed a WARN_ON() into that code to make it obvious to anyone who
> uses omap_request_dma() that they really need to update their code.
> 
> Here's the list of references to that symbol which *still* need to be
> fixed so that we can kill the legacy DMA driver:
> 
> drivers/media/platform/omap/omap_vout_vrfb.c:   ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
> drivers/media/platform/omap3isp/isphist.c:              ret = omap_request_dma(OMAP24XX_DMA_NO_DEVICE, "DMA_ISP_HIST",
> drivers/media/platform/soc_camera/omap1_camera.c:       err = omap_request_dma(OMAP_DMA_CAMERA_IF_RX, DRIVER_NAME,
> drivers/mtd/onenand/omap2.c:            r = omap_request_dma(0, pdev->dev.driver->name,

AFAIK we should just remove DMA support from the drivers above.
Nobody seems to be interested in doing anything about them.

> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,
> drivers/usb/gadget/udc/omap_udc.c:              status = omap_request_dma(dma_channel,

OK so Aaro picked this one.

> drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(chdat->sync_dev, dev_name,
> drivers/usb/musb/tusb6010_omap.c:               ret = omap_request_dma(tusb_dma->sync_dev, "TUSB shared",

I'll update this one. FYI, I already have some work-in-progress
MUSB DMA patches that allow building in all the MUSB DMA glue
layers. I just need to finish that series for v3.20:

https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=musb-dma-2014-11-25-v2

So converting tusb6010 over to the dmaengine API would be the
next logical step after that series. Probably not going to
happen before v3.21 though..

Regards,

Tony

[PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Felipe Balbi]

commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.

Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().

A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.

Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Cc: <stable@vger.kernel.org> # v3.18
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
 	return ret;
 }
 
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
 {
 	int j, irq_base;
 
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
 		irq_base = 0;
 	}
 
-	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
 			&irq_domain_simple_ops, NULL);
 
 	omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
 {
 	int ret;
 
-	if (node)
+	/*
+	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+	 * depends is still not ready for linear IRQ domains; because of that
+	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
+	 * linear IRQ Domain until that driver is finally fixed.
+	 */
+	if (of_device_is_compatible(node, "ti,omap2-intc") ||
+			of_device_is_compatible(node, "ti,omap3-intc")) {
+		struct resource res;
+
+		if (of_address_to_resource(node, 0, &res))
+			return -ENOMEM;
+
+		base = res.start;
+		ret = omap_init_irq_legacy(base, node);
+	} else if (node) {
 		ret = omap_init_irq_of(node);
-	else
-		ret = omap_init_irq_legacy(base);
+	} else {
+		ret = omap_init_irq_legacy(base, NULL);
+	}
 
 	if (ret == 0)
 		omap_irq_enable_protection();
-- 
2.2.0

[PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Felipe Balbi]

commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.

Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().

A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.

Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Cc: <stable@vger.kernel.org> # v3.18
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 3c970259c0eb..6ef88f56cf8d 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
 	return ret;
 }
 
-static int __init omap_init_irq_legacy(u32 base)
+static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
 {
 	int j, irq_base;
 
@@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
 		irq_base = 0;
 	}
 
-	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
+	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
 			&irq_domain_simple_ops, NULL);
 
 	omap_irq_soft_reset();
@@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
 {
 	int ret;
 
-	if (node)
+	/*
+	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
+	 * depends is still not ready for linear IRQ domains; because of that
+	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
+	 * linear IRQ Domain until that driver is finally fixed.
+	 */
+	if (of_device_is_compatible(node, "ti,omap2-intc") ||
+			of_device_is_compatible(node, "ti,omap3-intc")) {
+		struct resource res;
+
+		if (of_address_to_resource(node, 0, &res))
+			return -ENOMEM;
+
+		base = res.start;
+		ret = omap_init_irq_legacy(base, node);
+	} else if (node) {
 		ret = omap_init_irq_of(node);
-	else
-		ret = omap_init_irq_legacy(base);
+	} else {
+		ret = omap_init_irq_legacy(base, NULL);
+	}
 
 	if (ret == 0)
 		omap_irq_enable_protection();
-- 
2.2.0

Re: [PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Jason Cooper]

On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
> 
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
> 
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
> 
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Cc: <stable@vger.kernel.org> # v3.18
> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)

Applied to irqchip/urgent.  Thanks for taking care of the Fixes and
stable tags!

thx,

Jason.

[PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Jason Cooper]

On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
> 
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
> 
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
> 
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Cc: <stable@vger.kernel.org> # v3.18
> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)

Applied to irqchip/urgent.  Thanks for taking care of the Fixes and
stable tags!

thx,

Jason.

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Peter Kümmel]

Am 06.01.2015 um 17:51 schrieb Felipe Balbi:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
>
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
>
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
>
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>   drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>   1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 3c970259c0eb..6ef88f56cf8d 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
>   	return ret;
>   }
>
> -static int __init omap_init_irq_legacy(u32 base)
> +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
>   {
>   	int j, irq_base;
>
> @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
>   		irq_base = 0;
>   	}
>
> -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
>   			&irq_domain_simple_ops, NULL);
>
>   	omap_irq_soft_reset();
> @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
>   {
>   	int ret;
>
> -	if (node)
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.
> +	 */
> +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> +			of_device_is_compatible(node, "ti,omap3-intc")) {
> +		struct resource res;
> +
> +		if (of_address_to_resource(node, 0, &res))
> +			return -ENOMEM;
> +
> +		base = res.start;
> +		ret = omap_init_irq_legacy(base, node);
> +	} else if (node) {
>   		ret = omap_init_irq_of(node);
> -	else
> -		ret = omap_init_irq_legacy(base);
> +	} else {
> +		ret = omap_init_irq_legacy(base, NULL);
> +	}
>
>   	if (ret == 0)
>   		omap_irq_enable_protection();
>

Thanks, works on DM3730.

Peter

Re: [PATCH] irqchip: omap-intc: fix legacy DMA regression

[Peter Kümmel]

Am 06.01.2015 um 17:51 schrieb Felipe Balbi:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
>
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
>
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
>
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>   drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>   1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 3c970259c0eb..6ef88f56cf8d 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
>   	return ret;
>   }
>
> -static int __init omap_init_irq_legacy(u32 base)
> +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
>   {
>   	int j, irq_base;
>
> @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
>   		irq_base = 0;
>   	}
>
> -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
>   			&irq_domain_simple_ops, NULL);
>
>   	omap_irq_soft_reset();
> @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
>   {
>   	int ret;
>
> -	if (node)
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.
> +	 */
> +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> +			of_device_is_compatible(node, "ti,omap3-intc")) {
> +		struct resource res;
> +
> +		if (of_address_to_resource(node, 0, &res))
> +			return -ENOMEM;
> +
> +		base = res.start;
> +		ret = omap_init_irq_legacy(base, node);
> +	} else if (node) {
>   		ret = omap_init_irq_of(node);
> -	else
> -		ret = omap_init_irq_legacy(base);
> +	} else {
> +		ret = omap_init_irq_legacy(base, NULL);
> +	}
>
>   	if (ret == 0)
>   		omap_irq_enable_protection();
>

Thanks, works on DM3730.

Peter

[PATCH] irqchip: omap-intc: fix legacy DMA regression

[Peter Kümmel]

Am 06.01.2015 um 17:51 schrieb Felipe Balbi:
> commit 55601c9f2467 (arm: omap: intc: switch over
> to linear irq domain) introduced a regression with
> SDMA legacy driver because that driver strictly depends
> on INTC's IRQs starting at NR_IRQs. Aparently
> irq_domain_add_linear() won't guarantee that, since we see
> a 7 IRQs difference when booting with and without the
> commit cited above.
>
> Until arch/arm/plat-omap/dma.c is properly fixed, we
> must maintain OMAP2/3 using irq_domain_add_legacy().
>
> A FIXME note was added so people know to delete that
> code once that legacy DMA driver is fixed up.
>
> Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>   drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
>   1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 3c970259c0eb..6ef88f56cf8d 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -263,7 +263,7 @@ static int __init omap_init_irq_of(struct device_node *node)
>   	return ret;
>   }
>
> -static int __init omap_init_irq_legacy(u32 base)
> +static int __init omap_init_irq_legacy(u32 base, struct device_node *node)
>   {
>   	int j, irq_base;
>
> @@ -277,7 +277,7 @@ static int __init omap_init_irq_legacy(u32 base)
>   		irq_base = 0;
>   	}
>
> -	domain = irq_domain_add_legacy(NULL, omap_nr_irqs, irq_base, 0,
> +	domain = irq_domain_add_legacy(node, omap_nr_irqs, irq_base, 0,
>   			&irq_domain_simple_ops, NULL);
>
>   	omap_irq_soft_reset();
> @@ -301,10 +301,26 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
>   {
>   	int ret;
>
> -	if (node)
> +	/*
> +	 * FIXME legacy OMAP DMA driver sitting under arch/arm/plat-omap/dma.c
> +	 * depends is still not ready for linear IRQ domains; because of that
> +	 * we need to temporarily "blacklist" OMAP2 and OMAP3 devices from using
> +	 * linear IRQ Domain until that driver is finally fixed.
> +	 */
> +	if (of_device_is_compatible(node, "ti,omap2-intc") ||
> +			of_device_is_compatible(node, "ti,omap3-intc")) {
> +		struct resource res;
> +
> +		if (of_address_to_resource(node, 0, &res))
> +			return -ENOMEM;
> +
> +		base = res.start;
> +		ret = omap_init_irq_legacy(base, node);
> +	} else if (node) {
>   		ret = omap_init_irq_of(node);
> -	else
> -		ret = omap_init_irq_legacy(base);
> +	} else {
> +		ret = omap_init_irq_legacy(base, NULL);
> +	}
>
>   	if (ret == 0)
>   		omap_irq_enable_protection();
>

Thanks, works on DM3730.

Peter

Re: [PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Jason Cooper <jason@lakedaemon.net> [150106 19:03]:
> On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote:
> > commit 55601c9f2467 (arm: omap: intc: switch over
> > to linear irq domain) introduced a regression with
> > SDMA legacy driver because that driver strictly depends
> > on INTC's IRQs starting at NR_IRQs. Aparently
> > irq_domain_add_linear() won't guarantee that, since we see
> > a 7 IRQs difference when booting with and without the
> > commit cited above.
> > 
> > Until arch/arm/plat-omap/dma.c is properly fixed, we
> > must maintain OMAP2/3 using irq_domain_add_legacy().
> > 
> > A FIXME note was added so people know to delete that
> > code once that legacy DMA driver is fixed up.
> > 
> > Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> > Cc: <stable@vger.kernel.org> # v3.18
> > Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > Tested-by: Tony Lindgren <tony@atomide.com>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
> >  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> Applied to irqchip/urgent.  Thanks for taking care of the Fixes and
> stable tags!

Jason, I'm not seeing this merged into v3.19-rc5, seems to be
in Linux next though.

Regards,

Tony

[PATCH v2] irqchip: omap-intc: fix legacy DMA regression

[Tony Lindgren]

* Jason Cooper <jason@lakedaemon.net> [150106 19:03]:
> On Tue, Jan 06, 2015 at 02:38:08PM -0600, Felipe Balbi wrote:
> > commit 55601c9f2467 (arm: omap: intc: switch over
> > to linear irq domain) introduced a regression with
> > SDMA legacy driver because that driver strictly depends
> > on INTC's IRQs starting at NR_IRQs. Aparently
> > irq_domain_add_linear() won't guarantee that, since we see
> > a 7 IRQs difference when booting with and without the
> > commit cited above.
> > 
> > Until arch/arm/plat-omap/dma.c is properly fixed, we
> > must maintain OMAP2/3 using irq_domain_add_legacy().
> > 
> > A FIXME note was added so people know to delete that
> > code once that legacy DMA driver is fixed up.
> > 
> > Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
> > Cc: <stable@vger.kernel.org> # v3.18
> > Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> > Tested-by: Tony Lindgren <tony@atomide.com>
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  drivers/irqchip/irq-omap-intc.c | 26 +++++++++++++++++++++-----
> >  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> Applied to irqchip/urgent.  Thanks for taking care of the Fixes and
> stable tags!

Jason, I'm not seeing this merged into v3.19-rc5, seems to be
in Linux next though.

Regards,

Tony