After applying this patch, I get compile-time errors in realview_*.c.
E.g.:
arch/arm/mach-realview/realview_pb1176.c:158:1: error: ?AACI? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:159:1: error: ?MMCI0? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:160:1: error: ?KMI0? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:161:1: error: ?KMI1? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:162:1: error: ?PB1176_UART4? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:165:1: error: ?PB1176_SMC? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:166:1: error: ?SCTL? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:167:1: error: ?PB1176_WATCHDOG? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:168:1: error: ?PB1176_GPIO0? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:169:1: error: ?GPIO1? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:170:1: error: ?GPIO2? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:171:1: error: ?PB1176_RTC? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:172:1: error: ?SCI? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:173:1: error: ?PB1176_UART0? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:174:1: error: ?PB1176_UART1? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:175:1: error: ?PB1176_UART2? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:176:1: error: ?PB1176_UART3? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:177:1: error: ?PB1176_SSP? undeclared here (not in a function)
arch/arm/mach-realview/realview_pb1176.c:178:1: error: ?PB1176_CLCD? undeclared here (not in a function)
but then I see a warning during boot:
[ 1.669654] ------------[ cut here ]------------
[ 1.684021] WARNING: at drivers/amba/bus.c:514 amba_device_add+0x1b4/0x1d0()
[ 1.705585] Modules linked in:
[ 1.715195] [<c0013a00>] (unwind_backtrace+0x0/0xfc) from [<c03d1350>] (dump_stack+0x20/0x24)
[ 1.741288] [<c03d1350>] (dump_stack+0x20/0x24) from [<c001f9b8>] (warn_slowpath_common+0x5c/0x74)
[ 1.768689] [<c001f9b8>] (warn_slowpath_common+0x5c/0x74) from [<c001f9fc>] (warn_slowpath_null+0x2c/0x34)
[ 1.798165] [<c001f9fc>] (warn_slowpath_null+0x2c/0x34) from [<c023dcd4>] (amba_device_add+0x1b4/0x1d0)
[ 1.826857] [<c023dcd4>] (amba_device_add+0x1b4/0x1d0) from [<c023dd84>] (amba_device_register+0x94/0xc4)
[ 1.856106] [<c023dd84>] (amba_device_register+0x94/0xc4) from [<c0551934>] (realview_pb1176_init+0x74/0xac)
[ 1.886120] [<c0551934>] (realview_pb1176_init+0x74/0xac) from [<c054d60c>] (customize_machine+0x24/0x30)
[ 1.915340] [<c054d60c>] (customize_machine+0x24/0x30) from [<c000879c>] (do_one_initcall+0x48/0x1a0)
[ 1.943505] [<c000879c>] (do_one_initcall+0x48/0x1a0) from [<c054b870>] (kernel_init+0x80/0x128)
[ 1.970378] [<c054b870>] (kernel_init+0x80/0x128) from [<c000ea78>] (kernel_thread_exit+0x0/0x8)
[ 1.997192] ---[ end trace 1b75b31a2719ed1e ]---
I suspect that comes from PB1176_GPIO0_IRQ being -1.
It seems you've also tested the code which detects -1 IRQs too, which
is good. PB1176 needs that GPIO0_IRQ fixing, but I suspect passing
zero may not be entirely a good thing for it as request_irq(0,...)
probably succeeds there. I think that needs fixing before this warning
can go away.
In the mean time, it's just a warning, and its saying there's something
wrong there which needs fixing but without anything currently broken.
So it's working as designed.
From: Will Deacon <hidden> Date: 2012-01-24 17:26:00
On Tue, Jan 24, 2012 at 04:23:28PM +0000, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 04:00:44PM +0000, Will Deacon wrote:
quoted
but then I see a warning during boot:
[ 1.669654] ------------[ cut here ]------------
[ 1.684021] WARNING: at drivers/amba/bus.c:514 amba_device_add+0x1b4/0x1d0()
[ 1.705585] Modules linked in:
[ 1.715195] [<c0013a00>] (unwind_backtrace+0x0/0xfc) from [<c03d1350>] (dump_stack+0x20/0x24)
[ 1.741288] [<c03d1350>] (dump_stack+0x20/0x24) from [<c001f9b8>] (warn_slowpath_common+0x5c/0x74)
[ 1.768689] [<c001f9b8>] (warn_slowpath_common+0x5c/0x74) from [<c001f9fc>] (warn_slowpath_null+0x2c/0x34)
[ 1.798165] [<c001f9fc>] (warn_slowpath_null+0x2c/0x34) from [<c023dcd4>] (amba_device_add+0x1b4/0x1d0)
[ 1.826857] [<c023dcd4>] (amba_device_add+0x1b4/0x1d0) from [<c023dd84>] (amba_device_register+0x94/0xc4)
[ 1.856106] [<c023dd84>] (amba_device_register+0x94/0xc4) from [<c0551934>] (realview_pb1176_init+0x74/0xac)
[ 1.886120] [<c0551934>] (realview_pb1176_init+0x74/0xac) from [<c054d60c>] (customize_machine+0x24/0x30)
[ 1.915340] [<c054d60c>] (customize_machine+0x24/0x30) from [<c000879c>] (do_one_initcall+0x48/0x1a0)
[ 1.943505] [<c000879c>] (do_one_initcall+0x48/0x1a0) from [<c054b870>] (kernel_init+0x80/0x128)
[ 1.970378] [<c054b870>] (kernel_init+0x80/0x128) from [<c000ea78>] (kernel_thread_exit+0x0/0x8)
[ 1.997192] ---[ end trace 1b75b31a2719ed1e ]---
I suspect that comes from PB1176_GPIO0_IRQ being -1.
It seems you've also tested the code which detects -1 IRQs too, which
is good. PB1176 needs that GPIO0_IRQ fixing, but I suspect passing
zero may not be entirely a good thing for it as request_irq(0,...)
probably succeeds there. I think that needs fixing before this warning
can go away.
Yup, I actually tested this simply by checking out your devel-3.3 branch, so
the whole series has been tested on the boards that I've mentioned.
In the mean time, it's just a warning, and its saying there's something
wrong there which needs fixing but without anything currently broken.
So it's working as designed.
Right. I took a quick look at the TRM for the PB1176, and I think we do have
an interrupt for GPIO0, it's just on the other GIC. This patch should do the
trick, but I'm not sure what I can do to tickle the GPIO stuff anyway:
Right. I took a quick look at the TRM for the PB1176, and I think we do have
an interrupt for GPIO0, it's just on the other GIC. This patch should do the
trick, but I'm not sure what I can do to tickle the GPIO stuff anyway:
For a simple test just insert/remove the MMC card and see it
add/remove the card (appear in console, and /proc/interrupts)
Or do you mean tickle GPIO0? That is more tricky I think...
Yours,
Linus Walleij
From: Russell King - ARM Linux <hidden> Date: 2012-01-24 21:45:31
On Tue, Jan 24, 2012 at 05:26:00PM +0000, Will Deacon wrote:
quoted hunk
Right. I took a quick look at the TRM for the PB1176, and I think we do have
an interrupt for GPIO0, it's just on the other GIC. This patch should do the
trick, but I'm not sure what I can do to tickle the GPIO stuff anyway:
From: Russell King - ARM Linux <hidden> Date: 2012-01-25 10:22:02
On Wed, Jan 25, 2012 at 09:58:00AM +0000, Will Deacon wrote:
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
this -rc independently of the rest of the changes. If it's after,
then it'll probably add a conflict.
So, it'll be much easier to have it before, and I'll update what's
necessary in the amba branch.
From: Will Deacon <hidden> Date: 2012-01-25 10:39:06
On Wed, Jan 25, 2012 at 10:22:02AM +0000, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 09:58:00AM +0000, Will Deacon wrote:
quoted
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
this -rc independently of the rest of the changes. If it's after,
then it'll probably add a conflict.
So, it'll be much easier to have it before, and I'll update what's
necessary in the amba branch.
Okey doke, I've submitted it as 7300/1 against 3.3-rc1.
Will
From: Russell King - ARM Linux <hidden> Date: 2012-01-25 11:06:47
On Wed, Jan 25, 2012 at 10:39:06AM +0000, Will Deacon wrote:
On Wed, Jan 25, 2012 at 10:22:02AM +0000, Russell King - ARM Linux wrote:
quoted
On Wed, Jan 25, 2012 at 09:58:00AM +0000, Will Deacon wrote:
quoted
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
this -rc independently of the rest of the changes. If it's after,
then it'll probably add a conflict.
So, it'll be much easier to have it before, and I'll update what's
necessary in the amba branch.
Okey doke, I've submitted it as 7300/1 against 3.3-rc1.
Right, so with the stack of amba patches on top, it looks like this,
which to me looks sane. I haven't build-tested it though.