* [PATCH v4 17/18] watchdog: orion: Enable the build on ARCH_MVEBU
From: Ezequiel Garcia @ 2014-01-22 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390431915-5115-1-git-send-email-ezequiel.garcia@free-electrons.com>
After adding support for Armada 370/XP SoC let's enable the build on
these platforms.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..8b79012 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -282,7 +282,7 @@ config DAVINCI_WATCHDOG
config ORION_WATCHDOG
tristate "Orion watchdog"
- depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE
+ depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU
select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
--
1.8.1.5
^ permalink raw reply related
* [PATCH v4 18/18] ARM: mvebu: Enable watchdog support in defconfig
From: Ezequiel Garcia @ 2014-01-22 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390431915-5115-1-git-send-email-ezequiel.garcia@free-electrons.com>
Now that we have proper support for Armada 370/XP watchdog
let's enable it in the defconfig.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 594d706..84ec924 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -60,6 +60,8 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_ORION_WATCHDOG=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3 18/24] drm/i2c: tda998x: fix the ENABLE_SPACE register
From: Russell King - ARM Linux @ 2014-01-22 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195845.086be909@armhf>
On Sun, Jan 19, 2014 at 07:58:45PM +0100, Jean-Francois Moine wrote:
> This patch fixes the ENABLE_SPACE register, the value of which was
> inverted.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
I've researched the change to PLL_SERIAL_2, and this is correct. I think
your change to REG_ENABLE_SPACE is also correct. This looks like a bug
fix to me, so maybe consider having it applied to previous kernel
versions as well?
Also... please try putting yourself in the position of a reviewer of your
own patches - read the patch and then read the description, and ask whether
the description is adequate for the patch... the description talks just
about the ENABLE_SPACE register. But what about the PLL_SERIAL_2 register
changes? They're *totally* not described.
Hence...
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
and no acked-by.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 19/24] drm/i2c: tda998x: use global constants
From: Russell King - ARM Linux @ 2014-01-22 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195845.13b8a0e9@armhf>
On Sun, Jan 19, 2014 at 07:58:45PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Might be worth also saying "and tidy up AIP_CLKSEL" since arguably they
were already using global constants. In any case, no one likes single
line patch descriptions. Always try to write something more about the
patch.
I've verified this via inspection, and tested it.
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [GIT PULL]ARM: sirf: machine update for 3.14
From: Kevin Hilman @ 2014-01-22 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4zs7Vcb-Zd4Ds9bAecMdJDonQv1zDJU2=cMk9ecqp5DsA@mail.gmail.com>
Barry Song <21cnbao@gmail.com> writes:
> Hi Olof/Kevin,
> this series was missed?
It was skipped because it came well after the normal cutoff of -rc6
(Dec. 29th) or -rc7 (Jan 4th). This time we extended things a little
due to the end of year holidays, but yours came well after that as well.
If we have time we may try to get it into a late/* branch which might
still make it for v3.13, but it's unlikely at this point.
Kevin
> 2014/1/15 Barry Song <21cnbao@gmail.com>:
>> Hi Kevin/Olof,
>>
>> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
>>
>> Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
>> tags/sirf-soc-for-3.14
>>
>> for you to fetch changes up to dbd1b42baa6ec8082bce6eec37de5e1b46aff19c:
>>
>> ARM: prima2: make sirfsoc_init_late function static (2014-01-15
>> 10:42:26 +0800)
>>
>> ----------------------------------------------------------------
>> ARM: sirf: machine update for 3.14
>>
>> Among them:
>> - ARM: prima2: move to generic reset controller driver framework
>> - MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
>> - ARM: prima2: make sirfsoc_init_late function static
>>
>> ----------------------------------------------------------------
>> Barry Song (3):
>> ARM: prima2: move to generic reset controller driver framework
>> MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
>> ARM: prima2: make sirfsoc_init_late function static
>>
>> .../devicetree/bindings/reset/sirf,rstc.txt | 42 +++++++++
>> MAINTAINERS | 9 +-
>> arch/arm/boot/dts/atlas6.dtsi | 3 +-
>> arch/arm/boot/dts/marco.dtsi | 3 +-
>> arch/arm/boot/dts/prima2.dtsi | 3 +-
>> arch/arm/mach-prima2/Kconfig | 1 +
>> arch/arm/mach-prima2/common.c | 2 +-
>> arch/arm/mach-prima2/rstc.c | 93 +++++++++++++-------
>> 8 files changed, 110 insertions(+), 46 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/reset/sirf,rstc.txt
>>
>> -barry
^ permalink raw reply
* [PATCH v3 20/24] drm/i2c: tda998x: remove the unused variable ca_i2s
From: Russell King - ARM Linux @ 2014-01-22 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195846.368a44e6@armhf>
On Sun, Jan 19, 2014 at 07:58:46PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
"ca_i2s is only ever written to, but never read, so let's get rid of it."
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 21/24] drm/i2c: tda998x: add the active aspect in HDMI AVI frame
From: Russell King - ARM Linux @ 2014-01-22 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195846.0b83e7b1@armhf>
On Sun, Jan 19, 2014 at 07:58:46PM +0100, Jean-Francois Moine wrote:
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
"The picture aspect setting was zero, which is reserved. A setting of
Same As Picture makes more sense."
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Internal error: Oops: 17 [#1] ARM
From: John Tobias @ 2014-01-22 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122164100.GE15937@n2100.arm.linux.org.uk>
Hello all,
Just to confirm that the error I posted previously exist in 3.13
released. Just be noted that some patches related to eMMC/sdhci has
been applied in order to boot the 3.13 on my board.
Addition to that, I was getting additional errors (please see below):
- It happened during the reboot.
Cc'ng Dong Aisheng.
[ 11.229139] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[ 11.237244] pgd = 80004000
[ 11.239956] [00000000] *pgd=00000000
[ 11.243555] Internal error: Oops: 17 [#1] ARM
[ 11.247917] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(PO)
[ 11.253561] CPU: 0 PID: 37 Comm: mmcqd/0 Tainted: P O 3.13.0 #5
[ 11.260355] task: bfb00000 ti: bfb6e000 task.ti: bfb6e000
[ 11.265766] PC is at sg_next+0xc/0x34
[ 11.269440] LR is at sdhci_send_command+0x990/0xf50
[ 11.274323] pc : [<802a3874>] lr : [<803a2bc8>] psr: 200f0093
[ 11.274323] sp : bfb6fd20 ip : bfb6fd30 fp : bfb6fd2c
[ 11.285803] r10: 00000003 r9 : bfa67440 r8 : bf957010
[ 11.291030] r7 : 808487bc r6 : 600f0013 r5 : bfb43d4c r4 : bfb43ce4
[ 11.297560] r3 : 81784e62 r2 : 00000000 r1 : bfb6a800 r0 : 00000000
[ 11.304091] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 11.311490] Control: 10c53c7d Table: beeec059 DAC: 00000015
[ 11.317239] Process mmcqd/0 (pid: 37, stack limit = 0xbfb6e238)
[ 11.323162] Stack: (0xbfb6fd20 to 0xbfb70000)
[ 11.327530] fd20: bfb6fd8c bfb6fd30 803a2bc8 802a3874 00000002
00000000 bfb6fd5c bfb6fd48
[ 11.335713] fd40: 8001d1d0 00000002 80e04788 80845840 bfb6fd8c
bfb6a800 803a7558 8001d190
[ 11.343896] fd60: 803a7418 bfa67000 bfb43c6c bfa67470 600f0013
bfa67440 0000002d bfa67000
[ 11.352079] fd80: bfb6fdb4 bfb6fd90 803a3a48 803a2244 bfb43c6c
bfa67000 8089fed0 bfb43d4c
[ 11.360262] fda0: bfb6fe7c bfb43ec0 bfb6fdec bfb6fdb8 8038d3e0
803a388c bfb6fdd4 bfb6fdc8
[ 11.368444] fdc0: 8005b7c4 bfa673d8 bfb43e18 00000000 00000001
bfb43d8c 00000001 bfb6fe7c
[ 11.376626] fde0: bfb6fe3c bfb6fdf0 8038e538 8038d2c4 bfb6fe3c
bfb43da0 8039d0a4 00000000
[ 11.384809] fe00: bfb00000 8005344c bfb6fe08 bfb6fe08 bfb6fe34
bfbfc000 bfb43c24 bfb6a000
[ 11.392992] fe20: bfb44b60 bfb43c68 bfb6a000 bfb43c6c bfb6feac
bfb6fe40 8039e214 8038e278
[ 11.401175] fe40: bfb44b60 bfb43c24 bfb6fe74 bfb6fe58 80292194
80276c0c bfb4fc00 bef024c0
[ 11.409357] fe60: 00000000 00000000 00000000 bfb6fe78 bfb43c00
bfbfc000 00000002 00000080
[ 11.417541] fe80: 00000000 bfb6a000 bfbfc000 00000000 00000000
bfb43c24 bfb43c00 bfa67000
[ 11.425724] fea0: bfb6feec bfb6feb0 8039edc0 8039e158 00000000
122c8000 bfb6fed4 bfb6fec8
[ 11.433908] fec0: 8005b7c4 bfb44b60 bfb6e000 00000000 122c8000
00000001 bfbfc000 bfb43c24
[ 11.442091] fee0: bfb6ff24 bfb6fef0 8039f830 8039ebf0 bfb6e030
bfb43c2c 8039f780 bfb51a80
[ 11.450273] ff00: 00000000 bfb43c24 8039f780 00000000 00000000
00000000 bfb6ffac bfb6ff28
[ 11.458456] ff20: 80043658 8039f78c bfb6ff44 00000000 8005b7c4
bfb43c24 00000000 00000001
[ 11.466639] ff40: dead4ead ffffffff ffffffff 808a8990 00000000
00000000 807239a4 bfb6ff5c
[ 11.474822] ff60: bfb6ff5c 00000000 00000001 dead4ead ffffffff
ffffffff 808a8990 00000000
[ 11.483006] ff80: 00000000 807239a4 bfb6ff88 bfb6ff88 bfb51a80
80043574 00000000 00000000
[ 11.491188] ffa0: 00000000 bfb6ffb0 8000f348 80043580 00000000
00000000 00000000 00000000
[ 11.499370] ffc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 11.507552] ffe0: 00000000 00000000 00000000 00000000 00000013
00000000 55055703 d17847e7
[ 11.515729] Backtrace:
[ 11.518203] [<802a3868>] (sg_next+0x0/0x34) from [<803a2bc8>]
(sdhci_send_command+0x990/0xf50)
[ 11.526826] [<803a2238>] (sdhci_send_command+0x0/0xf50) from
[<803a3a48>] (sdhci_request+0x1c8/0x278)
[ 11.536056] [<803a3880>] (sdhci_request+0x0/0x278) from
[<8038d3e0>] (mmc_start_request+0x128/0x24c)
[ 11.545190] r9:bfb43ec0 r8:bfb6fe7c r7:bfb43d4c r6:8089fed0 r5:bfa67000
r4:bfb43c6c
[ 11.553118] [<8038d2b8>] (mmc_start_request+0x0/0x24c) from
[<8038e538>] (mmc_start_req+0x2cc/0x378)
[ 11.562251] r8:bfb6fe7c r7:00000001 r6:bfb43d8c r5:00000001 r4:00000000
[ 11.569033] [<8038e26c>] (mmc_start_req+0x0/0x378) from
[<8039e214>] (mmc_blk_issue_rw_rq+0xc8/0xa98)
[ 11.578261] [<8039e14c>] (mmc_blk_issue_rw_rq+0x0/0xa98) from
[<8039edc0>] (mmc_blk_issue_rq+0x1dc/0x4cc)
[ 11.587836] [<8039ebe4>] (mmc_blk_issue_rq+0x0/0x4cc) from
[<8039f830>] (mmc_queue_thread+0xb0/0x14c)
[ 11.597069] [<8039f780>] (mmc_queue_thread+0x0/0x14c) from
[<80043658>] (kthread+0xe4/0xf8)
[ 11.605433] [<80043574>] (kthread+0x0/0xf8) from [<8000f348>]
(ret_from_fork+0x14/0x20)
[ 11.613439] r7:00000000 r6:00000000 r5:80043574 r4:bfb51a80
[ 11.619164] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000)
[ 11.625266] ---[ end trace e52024b248222184 ]---
[ 11.629889] Kernel panic - not syncing: Fatal exception
[ 32.238311] BUG: spinlock lockup suspected on CPU#0, mmcqd/0/37
[ 32.244246] lock: 0xbfa67470, .magic: dead4ead, .owner:
mmcqd/0/37, .owner_cpu: 0
[ 32.251825] CPU: 0 PID: 37 Comm: mmcqd/0 Tainted: P D O 3.13.0 #5
[ 32.258616] Backtrace:
[ 32.261096] [<80012ef8>] (dump_backtrace+0x0/0x118) from
[<80013238>] (show_stack+0x20/0x24)
[ 32.269536] r6:3b4181c0 r5:bfa67470 r4:bfb00000 r3:00000000
[ 32.275265] [<80013218>] (show_stack+0x0/0x24) from [<805b4cdc>]
(dump_stack+0x24/0x28)
[ 32.283287] [<805b4cb8>] (dump_stack+0x0/0x28) from [<805b2680>]
(spin_dump+0x94/0x9c)
[ 32.291215] [<805b25ec>] (spin_dump+0x0/0x9c) from [<800603fc>]
(do_raw_spin_lock+0x118/0x14c)
[ 32.299827] r5:00000000 r4:3b4181c0
[ 32.303442] [<800602e4>] (do_raw_spin_lock+0x0/0x14c) from
[<805bb8a0>] (_raw_spin_lock_irqsave+0x58/0x64)
[ 32.313109] [<805bb848>] (_raw_spin_lock_irqsave+0x0/0x64) from
[<803a4c40>] (sdhci_timeout_timer+0x24/0xd0)
[ 32.322936] r6:bfb6f918 r5:bfa67470 r4:bfa67440
[ 32.327612] [<803a4c1c>] (sdhci_timeout_timer+0x0/0xd0) from
[<8002ef6c>] (call_timer_fn+0x94/0x17c)
[ 32.336745] r6:bfb6f918 r5:bfa67528 r4:80898454 r3:00000000
[ 32.342471] [<8002eed8>] (call_timer_fn+0x0/0x17c) from
[<8002f594>] (run_timer_softirq+0x1b0/0x258)
[ 32.351614] [<8002f3e4>] (run_timer_softirq+0x0/0x258) from
[<80027bd0>] (__do_softirq+0x148/0x314)
[ 32.360666] [<80027a88>] (__do_softirq+0x0/0x314) from [<800281b8>]
(irq_exit+0xc8/0x110)
[ 32.368852] [<800280f0>] (irq_exit+0x0/0x110) from [<8000fc64>]
(handle_IRQ+0x4c/0x94)
[ 32.376770] r4:80872034 r3:00000120
[ 32.380384] [<8000fc18>] (handle_IRQ+0x0/0x94) from [<800085a0>]
(gic_handle_irq+0x3c/0x64)
[ 32.388736] r6:bfb6fa68 r5:80842e64 r4:c080e10c r3:000000a0
[ 32.394461] [<80008564>] (gic_handle_irq+0x0/0x64) from
[<80013d84>] (__irq_svc+0x44/0x58)
[ 32.402729] Exception stack(0xbfb6fa68 to 0xbfb6fab0)
[ 32.407789] fa60: 000355f9 ffffffff 000025ed
80295740 00000048 80871ff4
[ 32.415974] fa80: 00002580 00002648 00000001 808a6448 808a5fc4
bfb6fad4 bfb6fab0 bfb6fab0
[ 32.424154] faa0: 805b145c 80295770 200f0113 ffffffff
[ 32.429207] r7:bfb6fa9c r6:ffffffff r5:200f0113 r4:80295770
[ 32.434937] [<805b1294>] (panic+0x0/0x1dc) from [<800135c8>]
(die+0x38c/0x3a0)
[ 32.442160] r3:00000001 r2:00000000 r1:00000001 r0:80720a90
[ 32.447879] r7:bfb6e000
[ 32.450438] [<8001323c>] (die+0x0/0x3a0) from [<805b1284>]
(__do_kernel_fault.part.11+0x74/0x84)
[ 32.459239] [<805b1210>] (__do_kernel_fault.part.11+0x0/0x84) from
[<80019d8c>] (do_page_fault+0x1cc/0x3d4)
[ 32.468981] r7:00000017 r3:bfb6fcd8
[ 32.472594] [<80019bc0>] (do_page_fault+0x0/0x3d4) from
[<80008440>] (do_DataAbort+0x48/0xa8)
[ 32.481127] [<800083f8>] (do_DataAbort+0x0/0xa8) from [<80013d1c>]
(__dabt_svc+0x3c/0x60)
[ 32.489307] Exception stack(0xbfb6fcd8 to 0xbfb6fd20)
[ 32.494362] fcc0:
00000000 bfb6a800
[ 32.502545] fce0: 00000000 81784e62 bfb43ce4 bfb43d4c 600f0013
808487bc bf957010 bfa67440
[ 32.510730] fd00: 00000003 bfb6fd2c bfb6fd30 bfb6fd20 803a2bc8
802a3874 200f0093 ffffffff
[ 32.518908] r8:bf957010 r7:bfb6fd0c r6:ffffffff r5:200f0093 r4:802a3874
[ 32.525696] [<802a3868>] (sg_next+0x0/0x34) from [<803a2bc8>]
(sdhci_send_command+0x990/0xf50)
[ 32.534317] [<803a2238>] (sdhci_send_command+0x0/0xf50) from
[<803a3a48>] (sdhci_request+0x1c8/0x278)
[ 32.543548] [<803a3880>] (sdhci_request+0x0/0x278) from
[<8038d3e0>] (mmc_start_request+0x128/0x24c)
[ 32.552681] r9:bfb43ec0 r8:bfb6fe7c r7:bfb43d4c r6:8089fed0 r5:bfa67000
r4:bfb43c6c
[ 32.560605] [<8038d2b8>] (mmc_start_request+0x0/0x24c) from
[<8038e538>] (mmc_start_req+0x2cc/0x378)
[ 32.569738] r8:bfb6fe7c r7:00000001 r6:bfb43d8c r5:00000001 r4:00000000
[ 32.576520] [<8038e26c>] (mmc_start_req+0x0/0x378) from
[<8039e214>] (mmc_blk_issue_rw_rq+0xc8/0xa98)
[ 32.585749] [<8039e14c>] (mmc_blk_issue_rw_rq+0x0/0xa98) from
[<8039edc0>] (mmc_blk_issue_rq+0x1dc/0x4cc)
[ 32.595324] [<8039ebe4>] (mmc_blk_issue_rq+0x0/0x4cc) from
[<8039f830>] (mmc_queue_thread+0xb0/0x14c)
[ 32.604556] [<8039f780>] (mmc_queue_thread+0x0/0x14c) from
[<80043658>] (kthread+0xe4/0xf8)
[ 32.612916] [<80043574>] (kthread+0x0/0xf8) from [<8000f348>]
(ret_from_fork+0x14/0x20)
[ 32.620922] r7:00000000 r6:00000000 r5:80043574 r4:bfb51a80
[ 32.626642] mmc0: Timeout waiting for hardware interrupt.
[ 32.632066] Unable to handle kernel NULL pointer dereference at
virtual address 0000000c
[ 32.640161] pgd = 80004000
[ 32.642871] [0000000c] *pgd=00000000
[ 32.646468] Internal error: Oops: 17 [#2] ARM
[ 32.650830] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(PO)
[ 32.656474] CPU: 0 PID: 37 Comm: mmcqd/0 Tainted: P D O 3.13.0 #5
[ 32.663266] task: bfb00000 ti: bfb6e000 task.ti: bfb6e000
[ 32.668674] PC is at arm_dma_sync_sg_for_cpu+0x44/0x8c
[ 32.673817] LR is at arm_dma_sync_sg_for_cpu+0x68/0x8c
[ 32.678961] pc : [<80018f7c>] lr : [<80018fa0>] psr: 800f0193
[ 32.678961] sp : bfb6f870 ip : bfb6f870 fp : bfb6f894
[ 32.690442] r10: bfa67440 r9 : 00000002 r8 : bf957010
[ 32.695670] r7 : 600f0013 r6 : 808487bc r5 : 00000002 r4 : 00000000
[ 32.702199] r3 : 81784e62 r2 : 0003bdf8 r1 : 81009000 r0 : 00000000
[ 32.708732] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 32.716130] Control: 10c53c7d Table: beeec059 DAC: 00000015
[ 32.721878] Process mmcqd/0 (pid: 37, stack limit = 0xbfb6e238)
[ 32.727800] Stack: (0xbfb6f870 to 0xbfb70000)
[ 32.732164] f860: bfa67440
bfb43d4c 600f0113 bfb6e000
[ 32.740348] f880: 00000100 00000002 bfb6f8dc bfb6f898 803a3d70
80018f44 00000000 bfa67440
[ 32.748533] f8a0: bfb6f8cc bfb6f8b0 805b27a8 800651e4 807765b4
bfa67440 bfa67470 600f0113
[ 32.756717] f8c0: bfb6e000 00000100 803a4c1c bfa67440 bfb6f8fc
bfb6f8e0 803a4ca0 803a3b04
[ 32.764902] f8e0: 00000000 80898454 bfa67528 bfb6f918 bfb6f954
bfb6f900 8002ef6c 803a4c28
[ 32.773086] f900: 00000002 00000000 8002eed8 800a657c 808a6a80
bfa67440 80e1030c 00000000
[ 32.781271] f920: 00000000 80776904 8005b7c4 808a6a80 bfa67528
808a6908 00000000 bfb6f970
[ 32.789455] f940: 803a4c1c bfa67440 bfb6f9a4 bfb6f958 8002f594
8002eee4 808a76b0 808a74b0
[ 32.797639] f960: 808a72b0 8084c550 00200200 80898454 bfb6f970
bfb6f970 bfb6e000 00000001
[ 32.805823] f980: 00000004 808a6908 808a6904 bfb6e000 808a6448
00000001 bfb6fa0c bfb6f9a8
[ 32.814007] f9a0: 80027bd0 8002f3f0 805bb750 800602f0 00208840
8084ab98 ffff931d 8084c550
[ 32.822191] f9c0: bfb6e028 808a68c0 0000000a 80852688 00000004
00000100 808a6900 808983f0
[ 32.830375] f9e0: c080e100 bfb6e010 00000057 00000000 c080e100
00000001 808a6448 808a5fc4
[ 32.838560] fa00: bfb6fa24 bfb6fa10 800281b8 80027a94 00000120
80872034 bfb6fa44 bfb6fa28
[ 32.846744] fa20: 8000fc64 800280fc 000000a0 c080e10c 80842e64
bfb6fa68 bfb6fa64 bfb6fa48
[ 32.854928] fa40: 800085a0 8000fc24 80295770 200f0113 ffffffff
bfb6fa9c bfb6fad4 bfb6fa68
[ 32.863112] fa60: 80013d84 80008570 000355f9 ffffffff 000025ed
80295740 00000048 80871ff4
[ 32.871296] fa80: 00002580 00002648 00000001 808a6448 808a5fc4
bfb6fad4 bfb6fab0 bfb6fab0
[ 32.879480] faa0: 805b145c 80295770 200f0113 ffffffff 80847c88
0000000b 80847c88 bfb6fadc
[ 32.887664] fac0: 00000001 bfb6e000 bfb6fb6c bfb6fae8 800135c8
805b12a4 80720a90 00000001
[ 32.895848] fae0: 00000000 00000001 bfb6e238 0000000b 00000000
00000008 00000000 807209e4
[ 32.904032] fb00: 600f0193 807209ec 65b00000 61643938 20303038
30613165 64303063 32396520
[ 32.912218] fb20: 30386464 32652030 30626334 28203430 30393565
30303033 80002029 805b2774
[ 32.920403] fb40: 80796d74 00000000 00000017 00000000 bfb6fcd8
00000000 bfb00000 00000003
[ 32.928587] fb60: bfb6fb84 bfb6fb70 805b1284 80013248 bfb6fcd8
00000017 bfb6fc24 bfb6fb88
[ 32.936771] fb80: 80019d8c 805b121c 80058e68 800a669c c0804730
a00f0193 80848d94 bfa67440
[ 32.944956] fba0: bfb6fbbc bfb6fbb0 80058f30 80058e48 bfb6fbd4
bfb6fbc0 805bba30 80058f28
[ 32.953140] fbc0: 80848d90 80842050 bfb6fbec bfb6fbd8 8001d1d0
803a4030 00000000 bfa67470
[ 32.961324] fbe0: 00000000 bfa67440 c080e100 bfb6e030 00000000
bfa67470 00000000 00000017
[ 32.969508] fc00: 80019bc0 808488ac 00000000 bfb6fcd8 bfa67440
00000003 bfb6fcd4 bfb6fc28
[ 32.977692] fc20: 80008440 80019bcc 00000000 00000000 00000000
8001d284 bfb6fc94 bfb6fc48
[ 32.985876] fc40: 8005df6c 8005ba94 00000002 00000080 00000000
8001d284 00000000 bfb00000
[ 32.994060] fc60: bfb6e000 805bba30 a00f0093 bfa67440 bfb6fc9c
bfb6fc80 80058e68 800a669c
[ 33.002244] fc80: c0804730 bfb00000 bfb6e000 80013d14 bfb6fd0c
bf957010 bfb6fcc4 bfb6fca8
[ 33.010428] fca0: 80058e68 800a669c 803a2bc8 802a3874 200f0093
802a3874 200f0093 ffffffff
[ 33.018612] fcc0: bfb6fd0c bf957010 bfb6fd2c bfb6fcd8 80013d1c
80008404 00000000 bfb6a800
[ 33.026796] fce0: 00000000 81784e62 bfb43ce4 bfb43d4c 600f0013
808487bc bf957010 bfa67440
[ 33.034980] fd00: 00000003 bfb6fd2c bfb6fd30 bfb6fd20 803a2bc8
802a3874 200f0093 ffffffff
[ 33.043164] fd20: bfb6fd8c bfb6fd30 803a2bc8 802a3874 00000002
00000000 bfb6fd5c bfb6fd48
[ 33.051348] fd40: 8001d1d0 00000002 80e04788 80845840 bfb6fd8c
bfb6a800 803a7558 8001d190
[ 33.059532] fd60: 803a7418 bfa67000 bfb43c6c bfa67470 600f0013
bfa67440 0000002d bfa67000
[ 33.067716] fd80: bfb6fdb4 bfb6fd90 803a3a48 803a2244 bfb43c6c
bfa67000 8089fed0 bfb43d4c
[ 33.075900] fda0: bfb6fe7c bfb43ec0 bfb6fdec bfb6fdb8 8038d3e0
803a388c bfb6fdd4 bfb6fdc8
[ 33.084085] fdc0: 8005b7c4 bfa673d8 bfb43e18 00000000 00000001
bfb43d8c 00000001 bfb6fe7c
[ 33.092269] fde0: bfb6fe3c bfb6fdf0 8038e538 8038d2c4 bfb6fe3c
bfb43da0 8039d0a4 00000000
[ 33.100453] fe00: bfb00000 8005344c bfb6fe08 bfb6fe08 bfb6fe34
bfbfc000 bfb43c24 bfb6a000
[ 33.108637] fe20: bfb44b60 bfb43c68 bfb6a000 bfb43c6c bfb6feac
bfb6fe40 8039e214 8038e278
[ 33.116821] fe40: bfb44b60 bfb43c24 bfb6fe74 bfb6fe58 80292194
80276c0c bfb4fc00 bef024c0
[ 33.125005] fe60: 00000000 00000000 00000000 bfb6fe78 bfb43c00
bfbfc000 00000002 00000080
[ 33.133189] fe80: 00000000 bfb6a000 bfbfc000 00000000 00000000
bfb43c24 bfb43c00 bfa67000
[ 33.141373] fea0: bfb6feec bfb6feb0 8039edc0 8039e158 00000000
122c8000 bfb6fed4 bfb6fec8
[ 33.149557] fec0: 8005b7c4 bfb44b60 bfb6e000 00000000 122c8000
00000001 bfbfc000 bfb43c24
[ 33.157741] fee0: bfb6ff24 bfb6fef0 8039f830 8039ebf0 bfb6e030
bfb43c2c 8039f780 bfb51a80
[ 33.165926] ff00: 00000000 bfb43c24 8039f780 00000000 00000000
00000000 bfb6ffac bfb6ff28
[ 33.174109] ff20: 80043658 8039f78c bfb6ff44 00000000 8005b7c4
bfb43c24 00000000 00000001
[ 33.182293] ff40: dead4ead ffffffff ffffffff 808a8990 00000000
00000000 807239a4 bfb6ff5c
[ 33.190477] ff60: bfb6ff5c 00000000 00000001 dead4ead ffffffff
ffffffff 808a8990 00000000
[ 33.198662] ff80: 00000000 807239a4 bfb6ff88 bfb6ff88 bfb51a80
80043574 00000000 00000000
[ 33.206846] ffa0: 00000000 bfb6ffb0 8000f348 80043580 00000000
00000000 00000000 00000000
[ 33.215029] ffc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 33.223212] ffe0: 00000000 00000000 00000000 00000000 00000013
00000000 55055703 d17847e7
[ 33.231390] Backtrace:
[ 33.233862] [<80018f38>] (arm_dma_sync_sg_for_cpu+0x0/0x8c) from
[<803a3d70>] (sdhci_finish_data+0x278/0x380)
[ 33.243779] r9:00000002 r8:00000100 r7:bfb6e000 r6:600f0113 r5:bfb43d4c
r4:bfa67440
[ 33.251706] [<803a3af8>] (sdhci_finish_data+0x0/0x380) from
[<803a4ca0>] (sdhci_timeout_timer+0x84/0xd0)
[ 33.261197] [<803a4c1c>] (sdhci_timeout_timer+0x0/0xd0) from
[<8002ef6c>] (call_timer_fn+0x94/0x17c)
[ 33.270330] r6:bfb6f918 r5:bfa67528 r4:80898454 r3:00000000
[ 33.276056] [<8002eed8>] (call_timer_fn+0x0/0x17c) from
[<8002f594>] (run_timer_softirq+0x1b0/0x258)
[ 33.285197] [<8002f3e4>] (run_timer_softirq+0x0/0x258) from
[<80027bd0>] (__do_softirq+0x148/0x314)
[ 33.294248] [<80027a88>] (__do_softirq+0x0/0x314) from [<800281b8>]
(irq_exit+0xc8/0x110)
[ 33.302435] [<800280f0>] (irq_exit+0x0/0x110) from [<8000fc64>]
(handle_IRQ+0x4c/0x94)
[ 33.310353] r4:80872034 r3:00000120
[ 33.313965] [<8000fc18>] (handle_IRQ+0x0/0x94) from [<800085a0>]
(gic_handle_irq+0x3c/0x64)
[ 33.322317] r6:bfb6fa68 r5:80842e64 r4:c080e10c r3:000000a0
[ 33.328040] [<80008564>] (gic_handle_irq+0x0/0x64) from
[<80013d84>] (__irq_svc+0x44/0x58)
[ 33.336306] Exception stack(0xbfb6fa68 to 0xbfb6fab0)
[ 33.341365] fa60: 000355f9 ffffffff 000025ed
80295740 00000048 80871ff4
[ 33.349548] fa80: 00002580 00002648 00000001 808a6448 808a5fc4
bfb6fad4 bfb6fab0 bfb6fab0
[ 33.357728] faa0: 805b145c 80295770 200f0113 ffffffff
[ 33.362781] r7:bfb6fa9c r6:ffffffff r5:200f0113 r4:80295770
[ 33.368513] [<805b1294>] (panic+0x0/0x1dc) from [<800135c8>]
(die+0x38c/0x3a0)
[ 33.375738] r3:00000001 r2:00000000 r1:00000001 r0:80720a90
[ 33.381456] r7:bfb6e000
[ 33.384012] [<8001323c>] (die+0x0/0x3a0) from [<805b1284>]
(__do_kernel_fault.part.11+0x74/0x84)
[ 33.392808] [<805b1210>] (__do_kernel_fault.part.11+0x0/0x84) from
[<80019d8c>] (do_page_fault+0x1cc/0x3d4)
[ 33.402549] r7:00000017 r3:bfb6fcd8
[ 33.406163] [<80019bc0>] (do_page_fault+0x0/0x3d4) from
[<80008440>] (do_DataAbort+0x48/0xa8)
[ 33.414694] [<800083f8>] (do_DataAbort+0x0/0xa8) from [<80013d1c>]
(__dabt_svc+0x3c/0x60)
[ 33.422874] Exception stack(0xbfb6fcd8 to 0xbfb6fd20)
[ 33.427928] fcc0:
00000000 bfb6a800
[ 33.436113] fce0: 00000000 81784e62 bfb43ce4 bfb43d4c 600f0013
808487bc bf957010 bfa67440
[ 33.444297] fd00: 00000003 bfb6fd2c bfb6fd30 bfb6fd20 803a2bc8
802a3874 200f0093 ffffffff
[ 33.452475] r8:bf957010 r7:bfb6fd0c r6:ffffffff r5:200f0093 r4:802a3874
[ 33.459263] [<802a3868>] (sg_next+0x0/0x34) from [<803a2bc8>]
(sdhci_send_command+0x990/0xf50)
[ 33.467883] [<803a2238>] (sdhci_send_command+0x0/0xf50) from
[<803a3a48>] (sdhci_request+0x1c8/0x278)
[ 33.477112] [<803a3880>] (sdhci_request+0x0/0x278) from
[<8038d3e0>] (mmc_start_request+0x128/0x24c)
[ 33.486247] r9:bfb43ec0 r8:bfb6fe7c r7:bfb43d4c r6:8089fed0 r5:bfa67000
r4:bfb43c6c
[ 33.494172] [<8038d2b8>] (mmc_start_request+0x0/0x24c) from
[<8038e538>] (mmc_start_req+0x2cc/0x378)
[ 33.503307] r8:bfb6fe7c r7:00000001 r6:bfb43d8c r5:00000001 r4:00000000
[ 33.510087] [<8038e26c>] (mmc_start_req+0x0/0x378) from
[<8039e214>] (mmc_blk_issue_rw_rq+0xc8/0xa98)
[ 33.519313] [<8039e14c>] (mmc_blk_issue_rw_rq+0x0/0xa98) from
[<8039edc0>] (mmc_blk_issue_rq+0x1dc/0x4cc)
[ 33.528887] [<8039ebe4>] (mmc_blk_issue_rq+0x0/0x4cc) from
[<8039f830>] (mmc_queue_thread+0xb0/0x14c)
[ 33.538116] [<8039f780>] (mmc_queue_thread+0x0/0x14c) from
[<80043658>] (kthread+0xe4/0xf8)
[ 33.546476] [<80043574>] (kthread+0x0/0xf8) from [<8000f348>]
(ret_from_fork+0x14/0x20)
[ 33.554480] r7:00000000 r6:00000000 r5:80043574 r4:bfb51a80
[ 33.560205] Code: 01a06003 e3570000 d89dabf0 e3a05000 (e594100c)
[ 33.566306] ---[ end trace e52024b248222185 ]--
Regards,
john
On Wed, Jan 22, 2014 at 8:41 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote:
>> Hello all,
>>
>> I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in
>> eMMC running SDR50.
>> Is anyone here encountered these problem and if there's any existing
>> patch that I can get?.
>
> How reproducable is this? I notice you're using 3.13-rc1 too, it could
> be the bug has already been fixed in a later kernel version. -rc1
> kernels are really the "fresh after lots of new feature merging" kernels
> which should always be expected to be rather buggy.
>
> Linux kernel "release candidates" are not "we think this is going to be
> a final kernel, please test it" but -rc1 marks the end of the new
> feature merging and the beginning of the stablisation phase.
>
> --
> FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
> in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
> Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Sebastian Hesselbarth @ 2014-01-22 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122205213.GW18269@obsidianresearch.com>
On 01/22/2014 09:52 PM, Jason Gunthorpe wrote:
>> Clearing BRIDGE_CAUSE will only clear all currently pending upstream
>> IRQs, of course. If WDT IRQ will be re-raised right after that in
>> BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
>> clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
>
> Which is why it makes no sense to clear it one time at kernel start.
>
> Either you only get new edge triggered interrupts after request_irq
> (sane behavior) or you might sometimes get an old pending edge
> triggered interrupt after request_irq (crazy behavior).
>
> Clearing BRIDGE_CAUSE at kernel start only shortens the racy window it
> doesn't eliminate it.
Actually, I missed that we mask all BRIDGE irqs in
orion_bridge_irq_init. If we now also clear already pending irqs, that
will not raise any old interrupts as long as watchdog clears all
reasons for upstream irqs before requesting a BRIDGE irq.
> In the more familiar level triggered world the driver would go to the
> device and ensure it wasn't asserting an IRQ level and then do the
> request_irq. This guarentees it won't get an interrupt callback.
>
> In a edge triggered world the driver should go to the device an ensure
> that it won't create a new IRQ, then do request_irq - confident that
> there will NEVER be a call to the IRQ handler, under any
> circumstances.
>
> So I think edge triggered interrupts need to ack any possible old edge
> trigger in the cause register before the first unmask - eg in the
> setup callback.
>
>> So, you should also clear WDT's irq in the driver yourself to clear a
>> possible pending upstream BRIDGE_CAUSE.
>
> Which isn't possible - the BRIDGE_CAUSE is owned by the irq driver and
> it must be cleared there, and it must only be cleared after the wdt
> has been stopped so it doesn't set it again.
I should have been more precise here: I meant watchdog driver should
clear all sources of possible upstream interrupts in its _own_
registers.
> Notice that Ezequiel has added an IRQ handler that just calls panic,
> so a spurious interrupt call is VERY VERY BAD.
And I understand that he now clears watchdog's register before
requesting an irq. All that is missing is bridge_irq driver clearing
CAUSE register after masking all irqs, right?
I'll stich a patch for that hopefully tomorrow.
Sebastian
^ permalink raw reply
* [PATCH v3 22/24] drm/i2c: tda998x: change the frequence in the audio channel
From: Russell King - ARM Linux @ 2014-01-22 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195847.646a40b0@armhf>
On Sun, Jan 19, 2014 at 07:58:47PM +0100, Jean-Francois Moine wrote:
> This patch sets the frequence as 'not indicated' instead of '48kHz'
> and adds some comments.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Good catch that byte 2 doesn't exist in this set.
sound/asounddef.h has definitions for these:
IEC958_AES0_CON_NOT_COPYRIGHT
IEC958_AES3_CON_FS_NOTID
IEC958_AES4_CON_MAX_WORDLEN_24
IEC958_AES4_CON_ORIGFS_NOTID
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-01-22 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mwin4ozf.fsf@natisbad.org>
On Wed, Jan 22, 2014 at 11:43:16PM +0100, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Cooper <jason@lakedaemon.net> writes:
>
> > On Wed, Jan 22, 2014 at 11:23:23PM +0100, Arnaud Ebalard wrote:
> >> With the patch applied on top of 3.13.0 kernel recompiled w/
> >> CONFIG_PCI_MSI enabled, I cannot reproduce the bug. I guess
> >> you can add my:
> >>
> >> Reported-and-tested-By: Arnaud Ebalard <arno@natisbad.org>
> >>
> >> Since you'll have to push the patch to -stable team at least for 3.13,
> >> I wonder if it would not make sense to extend that at least to 3.12.
> >> and possibly 3.10 (3.2 is still widely used but I wonder if it makes
> >> sense to go that far).
> >
> > Can you pinpoint the commit that introduced the regression?
>
> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts."
>
> Technically, this is not per se the commit which introduced the
> regression but the one that *partially* fixed it by introducing the XHCI
> quirk to skip MSI enabling for Fresco Logic chips. The thing is it
> should have included the FL1009 in the targets. Sarah, can you confirm
> this?
I don't know if it should have included FL1009, it was just a guess,
based on the fact that the 0x1000 and 0x1400 devices did need MSI
disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
not sure if/when I'll get a response back.
That still doesn't necessarily rule out MSI issues in the Marvell PCI
host controller code. Can you attach another PCI device with MSI
support under the host and see if it works?
Sarah Sharp
> Jason, the logic is summarized here, AFAICT:
>
> commit 455f58925247e8a1a1941e159f3636ad6ee4c90b
> Author: Oliver Neukum <oneukum@suse.de>
> Date: Mon Sep 30 15:50:54 2013 +0200
>
> xhci: quirk for extra long delay for S4
>
> It has been reported that this chipset really cannot
> sleep without this extraordinary delay.
>
> This patch should be backported, in order to ensure this host functions
> under stable kernels. The last quirk for Fresco Logic hosts (commit
> bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI
> quirk.") was backported to stable kernels as old as 2.6.36.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Cc: stable at vger.kernel.org
>
>
> commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Wed Oct 17 13:44:06 2012 -0700
>
> xhci: Extend Fresco Logic MSI quirk.
>
> Ali reports that plugging a device into the Fresco Logic xHCI host with
> PCI device ID 1400 produces an IRQ error:
>
> do_IRQ: 3.176 No irq handler for vector (irq -1)
>
> Other early Fresco Logic host revisions don't support MSI, even though
> their PCI config space claims they do. Extend the quirk to disabling
> MSI to this chipset revision. Also enable the short transfer quirk,
> since it's likely this revision also has that quirk, and it should be
> harmless to enable.
>
> <SNIP>
>
> This patch should be backported to stable kernels as old as 2.6.36, that
> contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci:
> Disable MSI for some Fresco Logic hosts."
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Reported-by: A Sh <smr.ash1991@gmail.com>
> Tested-by: A Sh <smr.ash1991@gmail.com>
> Cc: stable at vger.kernel.org
>
>
> commit f5182b4155b9d686c5540a6822486400e34ddd98
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Thu Jun 2 11:33:02 2011 -0700
>
> xhci: Disable MSI for some Fresco Logic hosts.
>
> Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
> advertise MSI, but fail to actually generate MSI interrupts. Add a new
> xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
> Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
> ID 0x1000, regardless of PCI revision ID, do not support MSI.
>
> This should be backported to stable kernels as far back as 2.6.36, which
> was the first kernel to support MSI on xHCI hosts.
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Reported-by: Sergey Galanov <sergey.e.galanov@gmail.com>
> Cc: stable at kernel.org
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Sebastian Hesselbarth @ 2014-01-23 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122223117.GX18269@obsidianresearch.com>
On 01/22/2014 11:31 PM, Jason Gunthorpe wrote:
> On Wed, Jan 22, 2014 at 07:12:38PM -0300, Ezequiel Garcia wrote:
>> On Wed, Jan 22, 2014 at 01:52:13PM -0700, Jason Gunthorpe wrote:
>>>> Clearing BRIDGE_CAUSE will only clear all currently pending upstream
>>>> IRQs, of course. If WDT IRQ will be re-raised right after that in
>>>> BRIDGE_CAUSE depends on the actual HW implementation, i.e. we do no
>>>> clear the causing IRQ itself but just what it raised in BRIDGE_CAUSE.
>>>
>>> Which is why it makes no sense to clear it one time at kernel start.
>>>
>>
>> So, it seems we need to handle irq_startup(), as you suggested.
>> I've just tested the attached patch, and it's working fine: the driver's
>> probe() fully stops the watchdog, and then request_irq() acks and
>> pending interrupts, through the added irq_startup().
>>
>> How does it look?
>
> Looks sane to me.
>
> I looked some more and there are other drivers (eg irq-metag-ext) that
> take this same approach.
>
> Sebastian:
> I looked at the irq-orion driver a bit more and noticed this:
>
> ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
> handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
> ^^^^^^^^^^^^^^^^^^^^^
> Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
> does this work at all? :)
I can tell you that it comes from arch/arm/plat-orion/irq.c and I
blindly copied it. I never really checked the differences in handling
level/edge irqs. Besides, if it wasn't working, we wouldn't get far
in booting the kernel without timer irqs.
From a HW point-of-view, I'd say the difference is that an
edge-triggered irq samples level transitions from e.g. low to high.
It also remains asserted if you clear the actual cause of the interrupt
and is only asserted again on the next low-to-high transition.
A level-triggered irq will be asserted as long as the cause of the irq
is asserted. If you clear the cause, you'll also clear that bit in the
upstream controller.
*BUT*, I will double-check how Linux deals with level/edge irqs and if
Orion SoCs have edge or level triggered cause registers. That should
reveal, if it is more sane to use handle_edge_irq here and possibly in
the main interrupt controller, too.
Sebastian
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Stephen Boyd @ 2014-01-23 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389469372-17199-5-git-send-email-tomasz.figa@gmail.com>
On 01/11, Tomasz Figa wrote:
> +
> +/**
> + * of_genpd_lock() - Lock access to of_genpd_providers list
> + */
> +static void of_genpd_lock(void)
> +{
> + mutex_lock(&of_genpd_mutex);
> +}
> +
> +/**
> + * of_genpd_unlock() - Unlock access to of_genpd_providers list
> + */
> +static void of_genpd_unlock(void)
> +{
> + mutex_unlock(&of_genpd_mutex);
> +}
Why do we need these functions? Can't we just call
mutex_lock/unlock directly?
> +
> +/**
> + * of_genpd_add_provider() - Register a domain provider for a node
> + * @np: Device node pointer associated with domain provider
> + * @genpd_src_get: callback for decoding domain
> + * @data: context pointer for @genpd_src_get callback.
These look a little outdated.
> + */
> +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
> + void *data)
> +{
> + struct of_genpd_provider *cp;
> +
> + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);
Please use sizeof(*cp) instead.
> + if (!cp)
> + return -ENOMEM;
> +
> + cp->node = of_node_get(np);
> + cp->data = data;
> + cp->xlate = xlate;
> +
> + of_genpd_lock();
> + list_add(&cp->link, &of_genpd_providers);
> + of_genpd_unlock();
> + pr_debug("Added domain provider from %s\n", np->full_name);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
> +
[...]
> +
> +/* See of_genpd_get_from_provider(). */
> +static struct generic_pm_domain *__of_genpd_get_from_provider(
> + struct of_phandle_args *genpdspec)
> +{
> + struct of_genpd_provider *provider;
> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
Can this be -EPROBE_DEFER so that we can defer probe until a
later time if the power domain provider hasn't registered yet?
> +
> + /* Check if we have such a provider in our array */
> + list_for_each_entry(provider, &of_genpd_providers, link) {
> + if (provider->node == genpdspec->np)
> + genpd = provider->xlate(genpdspec, provider->data);
> + if (!IS_ERR(genpd))
> + break;
> + }
> +
> + return genpd;
> +}
> +
[...]
> +static int of_genpd_notifier_call(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct device *dev = data;
> + int ret;
> +
> + if (!dev->of_node)
> + return NOTIFY_DONE;
> +
> + switch (event) {
> + case BUS_NOTIFY_BIND_DRIVER:
> + ret = of_genpd_add_to_domain(dev);
> + break;
> +
> + case BUS_NOTIFY_UNBOUND_DRIVER:
> + ret = of_genpd_del_from_domain(dev);
> + break;
> +
> + default:
> + return NOTIFY_DONE;
> + }
> +
> + return notifier_from_errno(ret);
> +}
> +
> +static struct notifier_block of_genpd_notifier_block = {
> + .notifier_call = of_genpd_notifier_call,
> +};
> +
> +static int of_genpd_init(void)
> +{
> + return bus_register_notifier(&platform_bus_type,
> + &of_genpd_notifier_block);
> +}
> +core_initcall(of_genpd_init);
Would it be possible to call the of_genpd_add_to_domain() and
of_genpd_del_from_domain() functions directly in the driver core,
similar to how the pinctrl framework has a hook in there? That
way we're not relying on any initcall ordering for this.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Jason Gunthorpe @ 2014-01-23 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E05C4E.9060709@gmail.com>
On Thu, Jan 23, 2014 at 01:03:26AM +0100, Sebastian Hesselbarth wrote:
> >Sebastian:
> >I looked at the irq-orion driver a bit more and noticed this:
> >
> > ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
> > handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
> > ^^^^^^^^^^^^^^^^^^^^^
> >Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
> >does this work at all? :)
>
> I can tell you that it comes from arch/arm/plat-orion/irq.c and I
> blindly copied it. I never really checked the differences in handling
> level/edge irqs. Besides, if it wasn't working, we wouldn't get far
> in booting the kernel without timer irqs.
Ezequiel found the ack call I missed, so it makes sense it works.
I think the difference in routines only starts to matter when you can
get another incoming edge IRQ while already handling one (due to SMP?
threaded interrupts? RealTime? not sure)
> It also remains asserted if you clear the actual cause of the interrupt
> and is only asserted again on the next low-to-high transition.
Which is why Ezequiel's patch is the right approach: we need to clear
the interrupt latched in the cause register after the watchdog driver
disable but before enabling/unmasking the interrupt.
Remember, the BRIDGE_MASK register has no effect on the BRIDGE_CAUSE,
it only effects which bits propogate to the main cause register.
> *BUT*, I will double-check how Linux deals with level/edge irqs and if
> Orion SoCs have edge or level triggered cause registers. That should
> reveal, if it is more sane to use handle_edge_irq here and possibly in
> the main interrupt controller, too.
There is a mixture.
Any cause bit documented to be clearable is edge triggered, all others
are level.
On Kirkwood this means all of the main interrupt controller bits are
level and all the bridge bits are edge. Which means edge is
definitely correct for the bridge handler, and level correct for the
main handler.
Jason
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Stephen Rothwell @ 2014-01-23 0:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/bcm11351.dtsi between commit 67a57be85e68 ("ARM:
bcm11351: Enable pinctrl for Broadcom Capri SoCs") from Linus' tree and
commit 0bd898b872ac ("ARM: dts: Declare clocks as fixed on bcm11351") and
several following commits from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm/boot/dts/bcm11351.dtsi
index dd8e878741c0,375a2f8eb878..000000000000
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@@ -142,8 -146,159 +146,164 @@@
status = "disabled";
};
+ pinctrl at 35004800 {
+ compatible = "brcm,capri-pinctrl";
+ reg = <0x35004800 0x430>;
+ };
++
+ i2c at 3e016000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e016000 0x80>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc1_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3e017000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e017000 0x80>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc2_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3e018000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3e018000 0x80>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc3_clk>;
+ status = "disabled";
+ };
+
+ i2c at 3500d000 {
+ compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
+ reg = <0x3500d000 0x80>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&pmu_bsc_clk>;
+ status = "disabled";
+ };
+
+ clocks {
+ bsc1_clk: bsc1 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc2_clk: bsc2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc3_clk: bsc3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ pmu_bsc_clk: pmu_bsc {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ hub_timer_clk: hub_timer {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ pwm_clk: pwm {
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio1_clk: sdio1 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio2_clk: sdio2 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio3_clk: sdio3 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio4_clk: sdio4 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ tmon_1m_clk: tmon_1m {
+ compatible = "fixed-clock";
+ clock-frequency = <1000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb_clk: uartb {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb2_clk: uartb2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb3_clk: uartb3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb4_clk: uartb4 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ usb_otg_ahb_clk: usb_otg_ahb {
+ compatible = "fixed-clock";
+ clock-frequency = <52000000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ usbotg: usb at 3f120000 {
+ compatible = "snps,dwc2";
+ reg = <0x3f120000 0x10000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usb_otg_ahb_clk>;
+ clock-names = "otg";
+ phys = <&usbphy>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy at 3f130000 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f130000 0x28>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140123/56f7fd1b/attachment.sig>
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Tomasz Figa @ 2014-01-23 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123001802.GF13785@codeaurora.org>
Hi Stephen,
On 23.01.2014 01:18, Stephen Boyd wrote:
> On 01/11, Tomasz Figa wrote:
>> +
>> +/**
>> + * of_genpd_lock() - Lock access to of_genpd_providers list
>> + */
>> +static void of_genpd_lock(void)
>> +{
>> + mutex_lock(&of_genpd_mutex);
>> +}
>> +
>> +/**
>> + * of_genpd_unlock() - Unlock access to of_genpd_providers list
>> + */
>> +static void of_genpd_unlock(void)
>> +{
>> + mutex_unlock(&of_genpd_mutex);
>> +}
>
> Why do we need these functions? Can't we just call
> mutex_lock/unlock directly?
That would be fine as well, I guess. Just duplicated the pattern used in
CCF, but can remove them in next version if it's found to be better.
>
>> +
>> +/**
>> + * of_genpd_add_provider() - Register a domain provider for a node
>> + * @np: Device node pointer associated with domain provider
>> + * @genpd_src_get: callback for decoding domain
>> + * @data: context pointer for @genpd_src_get callback.
>
> These look a little outdated.
Oops, missed this.
>
>> + */
>> +int of_genpd_add_provider(struct device_node *np, genpd_xlate_t xlate,
>> + void *data)
>> +{
>> + struct of_genpd_provider *cp;
>> +
>> + cp = kzalloc(sizeof(struct of_genpd_provider), GFP_KERNEL);
>
> Please use sizeof(*cp) instead.
Right.
>
>> + if (!cp)
>> + return -ENOMEM;
>> +
>> + cp->node = of_node_get(np);
>> + cp->data = data;
>> + cp->xlate = xlate;
>> +
>> + of_genpd_lock();
>> + list_add(&cp->link, &of_genpd_providers);
>> + of_genpd_unlock();
>> + pr_debug("Added domain provider from %s\n", np->full_name);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(of_genpd_add_provider);
>> +
> [...]
>> +
>> +/* See of_genpd_get_from_provider(). */
>> +static struct generic_pm_domain *__of_genpd_get_from_provider(
>> + struct of_phandle_args *genpdspec)
>> +{
>> + struct of_genpd_provider *provider;
>> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
>
> Can this be -EPROBE_DEFER so that we can defer probe until a
> later time if the power domain provider hasn't registered yet?
Yes, this could be useful. Makes me wonder why clock code (on which I
based this code) doesn't have it done this way.
>
>> +
>> + /* Check if we have such a provider in our array */
>> + list_for_each_entry(provider, &of_genpd_providers, link) {
>> + if (provider->node == genpdspec->np)
>> + genpd = provider->xlate(genpdspec, provider->data);
>> + if (!IS_ERR(genpd))
>> + break;
>> + }
>> +
>> + return genpd;
>> +}
>> +
> [...]
>> +static int of_genpd_notifier_call(struct notifier_block *nb,
>> + unsigned long event, void *data)
>> +{
>> + struct device *dev = data;
>> + int ret;
>> +
>> + if (!dev->of_node)
>> + return NOTIFY_DONE;
>> +
>> + switch (event) {
>> + case BUS_NOTIFY_BIND_DRIVER:
>> + ret = of_genpd_add_to_domain(dev);
>> + break;
>> +
>> + case BUS_NOTIFY_UNBOUND_DRIVER:
>> + ret = of_genpd_del_from_domain(dev);
>> + break;
>> +
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> +
>> + return notifier_from_errno(ret);
>> +}
>> +
>> +static struct notifier_block of_genpd_notifier_block = {
>> + .notifier_call = of_genpd_notifier_call,
>> +};
>> +
>> +static int of_genpd_init(void)
>> +{
>> + return bus_register_notifier(&platform_bus_type,
>> + &of_genpd_notifier_block);
>> +}
>> +core_initcall(of_genpd_init);
>
> Would it be possible to call the of_genpd_add_to_domain() and
> of_genpd_del_from_domain() functions directly in the driver core,
> similar to how the pinctrl framework has a hook in there? That
> way we're not relying on any initcall ordering for this.
Hmm, the initcall here just registers a notifier, which needs to be done
just before any driver registers. So, IMHO, current variant is safe,
given an early enough initcall level is used.
However, doing it the pinctrl way might still have an advantage of not
relying on specific bus type, so this is worth consideration indeed. I'd
like to hear Rafael's and Kevin's opinions on this (and other comments
above too).
Best regards,
Tomasz
^ permalink raw reply
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Stephen Boyd @ 2014-01-23 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD4DB1.2050200@samsung.com>
On 01/20, Tomasz Figa wrote:
> Hi Kevin,
>
> On 14.01.2014 16:42, Kevin Hilman wrote:
> >Tomasz Figa <tomasz.figa@gmail.com> writes:
> >
> >>This patch introduces generic code to perform power domain look-up using
> >>device tree and automatically bind devices to their power domains.
> >>Generic device tree binding is introduced to specify power domains of
> >>devices in their device tree nodes.
> >>
> >>Backwards compatibility with legacy Samsung-specific power domain
> >>bindings is provided, but for now the new code is not compiled when
> >>CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> >>will change as soon as Exynos power domain code gets converted to use
> >>the generic framework in further patch.
> >>
> >>Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> >
> >I haven't read through this in detail yet, but wanted to make sure that
> >the DT representation can handle nested power domains. At least
> >SH-mobile has a hierarchy of power domains and the genpd code can handle
> >that, so wanted to make sure that the DT representation can handle it as
> >well.
>
> The representation of power domains themselves as implied by this
> patch is fully platform-specific. The only generic part is the
> #power-domain-cells property, which defines the number of cells
> needed to identify the power domain of given provider. You are free
> to have any platform-specific properties (or even generic ones,
> added on top of this patch) to let you specify the hierarchy in DT.
>
(Semi-related to this thread, but not really the patchset)
I'd like to have a way to say that this power domain is a
subdomain of another domain provided by a different power domain
provider driver. From what I can tell, the only way to reparent
domains as of today is by name or reference and you have to make
a function call to do it (pm_genpd_add_subdomain_names() or
pm_genpd_add_subdomain()). This is annoying in the case where all
the power domains are not regsitered within the same driver
because we don't know which driver comes first.
It would be great if there was a way to specify this relationship
explicitly when initializing a power domain so that the
reparenting is done automatically without requiring any explicit
function call. Perhaps DT could specify this? Or we could add
another field to the generic_power_domain struct like parent_name?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Sebastian Hesselbarth @ 2014-01-23 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123001934.GY18269@obsidianresearch.com>
On 01/23/2014 01:19 AM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2014 at 01:03:26AM +0100, Sebastian Hesselbarth wrote:
>>> Sebastian:
>>> I looked at the irq-orion driver a bit more and noticed this:
>>>
>>> ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
>>> handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
>>> ^^^^^^^^^^^^^^^^^^^^^
>>> Shouldn't it be handle_edge_irq? Otherwise who is calling irq_ack? How
>>> does this work at all? :)
>>
>> I can tell you that it comes from arch/arm/plat-orion/irq.c and I
>> blindly copied it. I never really checked the differences in handling
>> level/edge irqs. Besides, if it wasn't working, we wouldn't get far
>> in booting the kernel without timer irqs.
>
> Ezequiel found the ack call I missed, so it makes sense it works.
>
> I think the difference in routines only starts to matter when you can
> get another incoming edge IRQ while already handling one (due to SMP?
> threaded interrupts? RealTime? not sure)
>
>> It also remains asserted if you clear the actual cause of the interrupt
>> and is only asserted again on the next low-to-high transition.
>
> Which is why Ezequiel's patch is the right approach: we need to clear
> the interrupt latched in the cause register after the watchdog driver
> disable but before enabling/unmasking the interrupt.
>
> Remember, the BRIDGE_MASK register has no effect on the BRIDGE_CAUSE,
> it only effects which bits propogate to the main cause register.
Yeah, I know. But you don't get new ones if mask them. At least for
edge triggered irqs, you can also clear them without clearing the
cause of the interrupt. Nevertheless, I think we agree here.
>> *BUT*, I will double-check how Linux deals with level/edge irqs and if
>> Orion SoCs have edge or level triggered cause registers. That should
>> reveal, if it is more sane to use handle_edge_irq here and possibly in
>> the main interrupt controller, too.
>
> There is a mixture.
>
> Any cause bit documented to be clearable is edge triggered, all others
> are level.
>
> On Kirkwood this means all of the main interrupt controller bits are
> level and all the bridge bits are edge. Which means edge is
> definitely correct for the bridge handler, and level correct for the
> main handler.
Just checked that for Dove, it is the same there. Main IRQ_CAUSE is
RO, BRIDGE_CAUSE is RW0C, and PMU_CAUSE is RW *sigh*.
I need to remember that when Dove moves over to mach-mvebu, as we need
a different chained irq handler for PMU that deals with that broken RW
register.
Sebastian
^ permalink raw reply
* [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-01-23 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122180023.dd90d34cba38d9f9ac516349@canb.auug.org.au>
[Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>] On 22/01/2014 (Wed 18:00) Stephen Rothwell wrote:
> Hi Paul,
>
> On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> >
> > Where: This work exists as a queue of patches that I apply to
> > linux-next; since the changes are fixing some things that currently
> > can only be found there. The patch series can be found at:
> >
> > http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
> >
> > I've avoided annoying Stephen with another queue of patches for
> > linux-next while the development content was in flux, but now that
> > the merge window has opened, and new additions are fewer, perhaps he
> > wouldn't mind tacking it on the end... Stephen?
>
> OK, I have added this to the end of linux-next today - we will see how we
> go. It is called "init".
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
- spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
^ permalink raw reply related
* [PATCH 1/1] gic: change access of gicc_ctrl register to read modify write.
From: Feng Kan @ 2014-01-23 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386534157-17366-1-git-send-email-fkan@apm.com>
Just checking to see anyone had time to take a look at this and comment.
On Sun, Dec 8, 2013 at 12:22 PM, Feng Kan <fkan@apm.com> wrote:
> This change is made to preserve the GIC v2 releated bits in the
> GIC_CPU_CTRL register (also known as the GICC_CTLR register in spec).
> The original code only set the enable/disable group bit in this register.
> This code will preserve all other bits configured by the bootload except
> the enable/disable bit. The main reason for this change is to allow the
> bypass bits specified in the v2 spec to remain untouched by the current
> GIC code. In the X-Gene platform, the bypass functionality is not used
> and bypass must be disabled at all time.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> Acked-by: Anup Patel <apatel@apm.com>
> Signed-off-by: Feng Kan <fkan@apm.com>
> ---
> drivers/irqchip/irq-gic.c | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d0e9480..6550ac9 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -419,6 +419,7 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> void __iomem *dist_base = gic_data_dist_base(gic);
> void __iomem *base = gic_data_cpu_base(gic);
> unsigned int cpu_mask, cpu = smp_processor_id();
> + unsigned int ctrl_mask;
> int i;
>
> /*
> @@ -450,13 +451,21 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);
>
> writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, base + GIC_CPU_CTRL);
> }
>
> void gic_cpu_if_down(void)
> {
> + unsigned int ctrl_mask;
> +
> void __iomem *cpu_base = gic_data_cpu_base(&gic_data[0]);
> - writel_relaxed(0, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask &= 0xfffffffe;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> #ifdef CONFIG_CPU_PM
> @@ -567,6 +576,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
> {
> int i;
> u32 *ptr;
> + unsigned int ctrl_mask;
> void __iomem *dist_base;
> void __iomem *cpu_base;
>
> @@ -591,7 +601,10 @@ static void gic_cpu_restore(unsigned int gic_nr)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
>
> writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> static int gic_notifier(struct notifier_block *self, unsigned long cmd, void *v)
> --
> 1.7.6.1
>
^ permalink raw reply
* [PATCH 1/1] gic: change access of gicc_ctrl register to read modify write.
From: Feng Kan @ 2014-01-23 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386534157-17366-1-git-send-email-fkan@apm.com>
Just checking to see anyone had time to take a look at this and comment.
Thanks
On Sun, Dec 8, 2013 at 12:22 PM, Feng Kan <fkan@apm.com> wrote:
> This change is made to preserve the GIC v2 releated bits in the
> GIC_CPU_CTRL register (also known as the GICC_CTLR register in spec).
> The original code only set the enable/disable group bit in this register.
> This code will preserve all other bits configured by the bootload except
> the enable/disable bit. The main reason for this change is to allow the
> bypass bits specified in the v2 spec to remain untouched by the current
> GIC code. In the X-Gene platform, the bypass functionality is not used
> and bypass must be disabled at all time.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> Acked-by: Anup Patel <apatel@apm.com>
> Signed-off-by: Feng Kan <fkan@apm.com>
> ---
> drivers/irqchip/irq-gic.c | 19 ++++++++++++++++---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d0e9480..6550ac9 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -419,6 +419,7 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> void __iomem *dist_base = gic_data_dist_base(gic);
> void __iomem *base = gic_data_cpu_base(gic);
> unsigned int cpu_mask, cpu = smp_processor_id();
> + unsigned int ctrl_mask;
> int i;
>
> /*
> @@ -450,13 +451,21 @@ static void gic_cpu_init(struct gic_chip_data *gic)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 / 4);
>
> writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, base + GIC_CPU_CTRL);
> }
>
> void gic_cpu_if_down(void)
> {
> + unsigned int ctrl_mask;
> +
> void __iomem *cpu_base = gic_data_cpu_base(&gic_data[0]);
> - writel_relaxed(0, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask &= 0xfffffffe;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> #ifdef CONFIG_CPU_PM
> @@ -567,6 +576,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
> {
> int i;
> u32 *ptr;
> + unsigned int ctrl_mask;
> void __iomem *dist_base;
> void __iomem *cpu_base;
>
> @@ -591,7 +601,10 @@ static void gic_cpu_restore(unsigned int gic_nr)
> writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
>
> writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
> - writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
> +
> + ctrl_mask = readl(base + GIC_CPU_CTRL);
> + ctrl_mask |= 0x1;
> + writel_relaxed(ctrl_mask, cpu_base + GIC_CPU_CTRL);
> }
>
> static int gic_notifier(struct notifier_block *self, unsigned long cmd, void *v)
> --
> 1.7.6.1
>
^ permalink raw reply
* [PATCH] ARM: exynos_defconfig: Update EHCI config entry
From: kgene at kernel.org @ 2014-01-23 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000101cf1297$fef674c0$fce35e40$%han@samsung.com>
Jingoo Han wrote:
>
> On Thursday, January 16, 2014 5:34 PM, Tushar Behera wrote:
> >
> > Commit 29824c167bea ("USB: host: Rename ehci-s5p to ehci-exynos")
> > renamed the config entry of EHCI host driver. Similar change needs
> > to be done in exynos_defconfig as well.
> >
> > Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
>
> (+cc Vivek Gautam, Yulgon Kim, Julius Werner)
>
> Reviewed-by: Jingoo Han <jg1.han@samsung.com>
>
> Yes, right.
> I overlooked 'exynos_defconfig', when I changed the name of
> Exynos EHCI driver. Thank you for sending the patch. :-)
>
> Best regards,
> Jingoo Han
>
> > ---
> > arch/arm/configs/exynos_defconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> > index dbe1f1c..4ce7b70 100644
> > --- a/arch/arm/configs/exynos_defconfig
> > +++ b/arch/arm/configs/exynos_defconfig
> > @@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
> > CONFIG_LOGO=y
> > CONFIG_USB=y
> > CONFIG_USB_EHCI_HCD=y
> > -CONFIG_USB_EHCI_S5P=y
> > +CONFIG_USB_EHCI_EXYNOS=y
> > CONFIG_USB_STORAGE=y
> > CONFIG_USB_DWC3=y
> > CONFIG_USB_PHY=y
> > --
> > 1.7.9.5
OK, applied into -fixes.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH v4 00/36] mtd: st_spi_fsm: Add new driver
From: Brian Norris @ 2014-01-23 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122125049.GA8586@lee--X1>
Hi Lee,
On Wed, Jan 22, 2014 at 12:50:49PM +0000, Lee Jones wrote:
> > Version 4:
> > Tended to Brian's previous review comments
> > - Checkpatch acceptance
> > - MODULE_DEVICE_TABLE() name slip correction
> > - Timeout issue(s) resolved
> > - Potential infinite loop mitigated
> > - Code clarity suggests heeded
> > - Duplication with MTD core code removed
> > - Upgraded to using ROUND_UP() helper
> > - Moved non-shared header code into main driver
> > - Relocated dynamic msg sequence stores into main struct
> > - Averted adaption of static (table) data
> > - Basic whitespace/spelling/data type/dev_err suggestions accepted
> >
> > Version 3:
> > Okay, this thing should be fully functional now. Identify a chip
> > based on it's JEDEC ID, Read, Write, Erase (all or by sector).
> > Support for various chip quirks added too.
> >
> > Version 2:
> > The first bunch of these patches have been on the MLs before, but
> > didn't receive a great deal of attention for the most part. We are
> > a little more featureful this time however. We can now successfully
> > setup and configure the N25Q256. We still can't read/write/erase
> > it though. I'll start work on that next week and will provide it in
> > the next instalment.
> >
> > Version 1:
> > First stab at getting this thing Mainlined. It doesn't do a great deal
> > yet, but we are able to initialise the device and dynamically set it up
> > correctly based on an extracted JEDEC ID.
> >
> > Documentation/devicetree/bindings/mtd/st-fsm.txt | 26 ++
> > arch/arm/boot/dts/stih416-b2105.dts | 14 +
> > arch/arm/boot/dts/stih416-pinctrl.dtsi | 12 +
> > drivers/mtd/devices/Kconfig | 8 +
> > drivers/mtd/devices/Makefile | 1 +
> > drivers/mtd/devices/serial_flash_cmds.h | 81 ++++
> > drivers/mtd/devices/st_spi_fsm.c | 2124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 7 files changed, 2266 insertions(+)
>
> Can you confirm receipt of this set, or would you like me to resend?
Well, I personally have the patch set but haven't had a chance to review
it. Can you resend with MTD in the CC, since we haven't had any comments
anyway? I believe MTD people are much less likely to look at it if you
forget the CC :)
You can just title it [PATCH RESEND v4 X/Y], possibly with a LKML
link back to the original v4, if you want to help avoid confusion.
Brian
^ permalink raw reply
* [PATCH v5 7/8] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Marc C @ 2014-01-23 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGVrzcbPyaSe0aEHt157kz=quvsrBCPOUriCVG27fJfasa45jg@mail.gmail.com>
Hi Florian,
> Do not we also need to update drivers/irqchip/irq-gic.c to look for
> this compatible property? Alternatively should the example DTS contain
> the following:
>
> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
Patch #8 [1] of this series has the "compatible" string set exactly that way. I was
following the pattern seen in the other reference DTS files, where "arm,cortex-a15-gic" is
used as the fall-back.
Thanks,
Marc C
[1] https://lkml.org/lkml/2014/1/21/649
On 01/22/2014 02:40 PM, Florian Fainelli wrote:
> Hi Marc,
>
> 2014/1/21 Marc Carino <marc.ceeeee@gmail.com>:
>> Document the Broadcom Brahma B15 GIC implementation as compatible
>> with the ARM GIC standard.
>>
>> Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Do not we also need to update drivers/irqchip/irq-gic.c to look for
> this compatible property? Alternatively should the example DTS contain
> the following:
>
> compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic"?
>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..d7409fd 100644
>> --- a/Documentation/devicetree/bindings/arm/gic.txt
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -15,6 +15,7 @@ Main node required properties:
>> "arm,cortex-a9-gic"
>> "arm,cortex-a7-gic"
>> "arm,arm11mp-gic"
>> + "brcm,brahma-b15-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>> interrupt source. The type shall be a <u32> and the value shall be 3.
>> --
>> 1.7.1
>>
>
>
>
^ permalink raw reply
* [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: Brian Norris @ 2014-01-23 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389190924-26226-2-git-send-email-b.brezillon@overkiz.com>
+ Huang
Hi Boris,
On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote:
> The Hynix nand flashes store their ECC requirements in byte 4 of its id
> (returned on READ ID command).
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
I haven't verified yet (perhaps Huang can confirm?), but this may be
similar to a patch Huang submitted recently. In his case, we found that
this table is actually quite unreliable and is likely hard to maintain.
Why do you need this ECC information, for my reference?
Brian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox