* [QUESTION] : why is the exynos not using the TWD as local timers ?
From: Daniel Lezcano @ 2013-02-01 16:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
why is the exynos not using the TWD as local timers ?
Probably already asked, but I was not able to find an detailed answer
for that [1]
Thanks
-- Daniel
[1] http://www.spinics.net/lists/arm-kernel/msg218906.html
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Arnd Bergmann @ 2013-02-01 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201094613.38fa2ad0@skate>
On Friday 01 February 2013, Thomas Petazzoni wrote:
> > So while it's obvious that window base address and size shouldn't be
> > static, I wonder if the assignment of a specific window ID to a
> > specific root port ID shouldn be dynamic or static. For example, if
> > your HW configuration leaves you with 6 windows available, you could
> > support 2 PCIe root ports by statically assigning 3 windows to serve
> > each of those 2 root ports. Would that work, or are there systems
> > where over-commit is needed, e.g. if there's no IO space behind a
> > root port, you could get away with two windows per root port, and
> > hence be able to run 3 root ports rather than just 2? Still, if you
> > know which PCIe devices are being the root ports, you could still
> > represent the over-commit statically in DT
>
> For now, I haven't figured out how not to allocate an I/O window if the
> downstream device doesn't use I/O, but I'd like to achieve that, as it
> would save one of the two windows needed per PCIe interface... and many
> PCIe devices don't need the I/O window.
The easiest hack would be to only ever allow one I/O window on exactly
one of the ports, and not do PIO on the other ports at all. Given the
various troubles of making any other combination work, that sounds like
a good enough compromise to me. A lot of the add-on cards would not
work in the remaining ports anyway, and worrying too much about that
legacy hardware may just not be worth it. That way, you only need 11
windows for PCIe (10*mem, 1*IO), which will always fit.
Do you actually have /any/ PCIe cards with PIO BARs that you can test
with?
Arnd
^ permalink raw reply
* [GIT PULL 4/4] ARM: mvebu: dt for v3.9
From: Jason Cooper @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359733918.Bf7ecc0.22262@triton>
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git tags/dt_for_v3.9
for you to fetch changes up to 1bead82fa5a52cd21c30c0c28615157d5c3dac9f:
arm: mvebu: add button for OpenBlocks AX3-4
----------------------------------------------------------------
mvebu dt changes for v3.9
- mvebu
- add rtc support
- add sdio support
- add button support for AX3-4
- kirkwood
- add sdio support
- add twsi1 and nand to 88f6282
- convert openblocks A6 to pinctrl
- convert more of nsa310 to dt
- gpio-poweroff for ns2
- dove
- move led pinctrl to gpio-leds node
- use fixed regulator for usb power
depends on:
- tags/boards_for_v3.9, which pulls in:
- tags/mvebu_fixes_for_v3.8-rc6
- tags/cleanup_for_v3.9_round2
- tags/drivers_for_v3.9
- mmc/mmc-next up to:
d293875 mmc: mvsdio: add pinctrl integration
----------------------------------------------------------------
Andrew Lunn (4):
ARM: Kirkwood: Convert NSA310 to DT based regulators.
ARM: Kirkwood: Convert NSA310 to use gpio-poweroff driver
ARM: Kirkwood: Convert NSA310 I2C to device tree
ARM: Kirkwood: Convert NS2 to gpio-poweroff.
Gregory CLEMENT (1):
arm: mvebu: Add RTC support for Armada 370 and Armada XP
Jason Cooper (1):
Merge tag 'tags/boards_for_v3.9' into mvebu/dt
Nobuhiro Iwamatsu (3):
ARM: Kirkwood: Add pinctrl of TWSI1 to 88f6282
ARM: Kirkwood: Add pinctrl of NAND to 88f6282
ARM: Kirkwood: Convert openblocks A6 board to pinctrl
Sebastian Hesselbarth (2):
ARM: Dove: move CuBox led pinctrl to gpio-leds node
ARM: Dove: add fixed regulator for CuBox USB power
Thomas Petazzoni (11):
arm: mvebu: add DT information for the SDIO interface of Armada 370/XP
arm: mvebu: add pin muxing options for the SDIO interface on Armada 370
arm: mvebu: add pin muxing options for the SDIO interface on Armada XP
arm: mvebu: enable the SD card slot on Armada XP DB board
arm: mvebu: enable the SD card slot on Armada 370 DB board
arm: mvebu: enable the SDIO interface on the Globalscale Mirabox
arm: kirkwood: add Device Tree informations for the SDIO controller
arm: kirkwood: dreamplug: use Device Tree to probe SDIO
arm: kirkwood: mplcec4: use Device Tree to probe SDIO
arm: kirkwood: add pinmux option for the SDIO interface on 88F6282
arm: mvebu: add button for OpenBlocks AX3-4
.../bindings/mmc/brcm,bcm2835-sdhci.txt | 18 ++
.../devicetree/bindings/mmc/orion-sdio.txt | 17 ++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/armada-370-db.dts | 15 +
arch/arm/boot/dts/armada-370-mirabox.dts | 10 +
arch/arm/boot/dts/armada-370-rd.dts | 61 ++++
arch/arm/boot/dts/armada-370-xp.dtsi | 14 +
arch/arm/boot/dts/armada-370.dtsi | 12 +
arch/arm/boot/dts/armada-xp-db.dts | 7 +
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 6 +
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 6 +
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 6 +
.../arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 12 +
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
arch/arm/boot/dts/dove-cubox.dts | 28 +-
arch/arm/boot/dts/dove.dtsi | 2 +
arch/arm/boot/dts/kirkwood-6282.dtsi | 17 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 7 +
.../boot/dts/kirkwood-guruplug-server-plus.dts | 94 +++++++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 11 +-
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 6 +
arch/arm/boot/dts/kirkwood-nsa310.dts | 27 ++
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 116 ++++++++
arch/arm/boot/dts/kirkwood.dtsi | 8 +
arch/arm/configs/dove_defconfig | 28 +-
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/mvebu_defconfig | 16 ++
arch/arm/mach-dove/Kconfig | 7 +
arch/arm/mach-dove/Makefile | 4 +-
arch/arm/mach-dove/board-dt.c | 102 +++++++
arch/arm/mach-dove/common.c | 114 +-------
arch/arm/mach-kirkwood/Kconfig | 7 +
arch/arm/mach-kirkwood/Makefile | 2 +-
arch/arm/mach-kirkwood/board-dreamplug.c | 6 -
arch/arm/mach-kirkwood/board-dt.c | 15 +-
arch/arm/mach-kirkwood/board-guruplug.c | 39 +++
arch/arm/mach-kirkwood/board-ib62x0.c | 1 -
arch/arm/mach-kirkwood/board-mplcec4.c | 8 -
arch/arm/mach-kirkwood/board-ns2.c | 14 -
arch/arm/mach-kirkwood/board-nsa310.c | 51 +---
arch/arm/mach-kirkwood/board-openblocks_a6.c | 44 ---
arch/arm/mach-kirkwood/common.c | 23 ++
arch/arm/mach-kirkwood/common.h | 6 +
arch/arm/mach-kirkwood/dockstar-setup.c | 1 -
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 3 +-
arch/arm/mach-kirkwood/pcie.c | 10 +-
arch/arm/mach-mvebu/irq-armada-370-xp.c | 72 +++++
arch/arm/plat-orion/mpp.c | 2 +-
drivers/cpuidle/Kconfig | 6 +
drivers/cpuidle/Makefile | 1 +
.../cpuidle/cpuidle-kirkwood.c | 45 ++-
drivers/mmc/card/block.c | 30 +-
drivers/mmc/card/queue.c | 32 ++-
drivers/mmc/card/queue.h | 3 +
drivers/mmc/core/bus.c | 1 +
drivers/mmc/core/core.c | 121 +++++++-
drivers/mmc/core/core.h | 1 +
drivers/mmc/core/sdio.c | 33 ++-
drivers/mmc/core/slot-gpio.c | 57 +++-
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/mvsdio.c | 131 +++++----
drivers/mmc/host/sdhci-bcm2835.c | 227 +++++++++++++++
drivers/mmc/host/sdhci-esdhc-imx.c | 59 +---
drivers/mmc/host/sdhci-pxav3.c | 12 +-
drivers/mmc/host/sdhci.c | 117 +++++---
drivers/mmc/host/sh_mmcif.c | 280 +++++++++++--------
drivers/mmc/host/tmio_mmc_pio.c | 8 -
drivers/rtc/Kconfig | 2 +-
include/linux/mmc/card.h | 12 +
include/linux/mmc/core.h | 3 +-
include/linux/mmc/host.h | 25 ++
72 files changed, 1688 insertions(+), 610 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
create mode 100644 Documentation/devicetree/bindings/mmc/orion-sdio.txt
create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
create mode 100644 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
create mode 100644 arch/arm/mach-dove/board-dt.c
create mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
rename arch/arm/mach-kirkwood/cpuidle.c => drivers/cpuidle/cpuidle-kirkwood.c (61%)
create mode 100644 drivers/mmc/host/sdhci-bcm2835.c
^ permalink raw reply
* [GIT PULL 3/4] ARM: mvebu: boards for v3.9
From: Jason Cooper @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359733918.Bf7ecc0.22262@triton>
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git tags/boards_for_v3.9
for you to fetch changes up to c7064904895f69b2e33117b450a05746f75abf3a:
ARM: kirkwood: convert Guruplug Server Plus to use the device tree
----------------------------------------------------------------
mvebu boards for v3.9
- Guruplug Server Plus DT board
- RD-A370-A1 board
- mvebu improved SMP support in interrupt controller
- update defconfigs
- split legacy and DT setup for dove
- remove some redundant clock aliases
depends on:
- tags/mvebu_fixes_for_v3.8-rc6
- tags/cleanup_for_v3.9_round2
- tags/drivers_for_v3.9
- mmc/mmc-next up to:
d293875 mmc: mvsdio: add pinctrl integration
conflicts:
- arm-soc/for-next
- arch/arm/mach-dove/common.c
* remove all DT code (it's now in .../board-dt.c)
build fixes (not merge conflict)
- arm-soc/for-next
- arch/arm/mach-dove/board-dt.c
- .timer no longer used
* s/.timer = &dove_timer/.init_time = dove_timer_init/ (not valid sed)
----------------------------------------------------------------
Andrew Lunn (2):
ARM: Kirkwood: Remove redundent USB clock alias
ARM: Kirkwood: Remove redundent SDIO clock alias
Florian Fainelli (1):
arm: mvebu: add DTS file for Marvell RD-A370-A1 board
Gregory CLEMENT (2):
arm: mvebu: Update defconfig with Marvell RTC support
arm: mvebu: Improve the SMP support of the interrupt controller
Jason Cooper (4):
Merge tag 'tags/mvebu_fixes_for_v3.8-rc6' into mvebu/boards
Merge tag 'tags/cleanup_for_v3.9_round2' into mvebu/boards
Merge tag 'tags/drivers_for_v3.9' into mvebu/boards
Merge commit 'd293875' into mvebu/boards
Olof Johansson (1):
ARM: dove: update dove_defconfig with a few useful options
Sebastian Hesselbarth (1):
ARM: Dove: split legacy and DT setup
Thomas Petazzoni (4):
arm: mvebu: enable SDIO support in mvebu_defconfig
arm: mvebu: enable mwifiex driver in mvebu_defconfig
arm: mvebu: enable btmrvl driver in mvebu_defconfig
arm: mvebu: add LEDs support to defconfig file
Willy Tarreau (1):
ARM: kirkwood: convert Guruplug Server Plus to use the device tree
.../bindings/mmc/brcm,bcm2835-sdhci.txt | 18 ++
.../devicetree/bindings/mmc/orion-sdio.txt | 17 ++
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/armada-370-rd.dts | 61 ++++
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
arch/arm/boot/dts/dove.dtsi | 2 +
.../boot/dts/kirkwood-guruplug-server-plus.dts | 94 +++++++
arch/arm/configs/dove_defconfig | 28 +-
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/mvebu_defconfig | 16 ++
arch/arm/mach-dove/Kconfig | 5 +
arch/arm/mach-dove/Makefile | 4 +-
arch/arm/mach-dove/board-dt.c | 102 +++++++
arch/arm/mach-dove/common.c | 114 +-------
arch/arm/mach-kirkwood/Kconfig | 7 +
arch/arm/mach-kirkwood/Makefile | 2 +-
arch/arm/mach-kirkwood/board-dt.c | 15 +-
arch/arm/mach-kirkwood/board-guruplug.c | 39 +++
arch/arm/mach-kirkwood/board-ib62x0.c | 1 -
arch/arm/mach-kirkwood/board-mplcec4.c | 1 -
arch/arm/mach-kirkwood/board-nsa310.c | 8 +-
arch/arm/mach-kirkwood/common.c | 23 ++
arch/arm/mach-kirkwood/common.h | 6 +
arch/arm/mach-kirkwood/dockstar-setup.c | 1 -
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 3 +-
arch/arm/mach-kirkwood/pcie.c | 10 +-
arch/arm/mach-mvebu/irq-armada-370-xp.c | 72 +++++
arch/arm/plat-orion/mpp.c | 2 +-
drivers/cpuidle/Kconfig | 6 +
drivers/cpuidle/Makefile | 1 +
.../cpuidle/cpuidle-kirkwood.c | 45 ++-
drivers/mmc/card/block.c | 30 +-
drivers/mmc/card/queue.c | 32 ++-
drivers/mmc/card/queue.h | 3 +
drivers/mmc/core/bus.c | 1 +
drivers/mmc/core/core.c | 121 +++++++-
drivers/mmc/core/core.h | 1 +
drivers/mmc/core/sdio.c | 33 ++-
drivers/mmc/core/slot-gpio.c | 57 +++-
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/mvsdio.c | 131 +++++----
drivers/mmc/host/sdhci-bcm2835.c | 227 +++++++++++++++
drivers/mmc/host/sdhci-esdhc-imx.c | 59 +---
drivers/mmc/host/sdhci-pxav3.c | 12 +-
drivers/mmc/host/sdhci.c | 117 +++++---
drivers/mmc/host/sh_mmcif.c | 280 +++++++++++--------
drivers/mmc/host/tmio_mmc_pio.c | 8 -
drivers/rtc/Kconfig | 2 +-
include/linux/mmc/card.h | 12 +
include/linux/mmc/core.h | 3 +-
include/linux/mmc/host.h | 25 ++
52 files changed, 1381 insertions(+), 493 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
create mode 100644 Documentation/devicetree/bindings/mmc/orion-sdio.txt
create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
create mode 100644 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
create mode 100644 arch/arm/mach-dove/board-dt.c
create mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
rename arch/arm/mach-kirkwood/cpuidle.c => drivers/cpuidle/cpuidle-kirkwood.c (61%)
create mode 100644 drivers/mmc/host/sdhci-bcm2835.c
^ permalink raw reply
* [GIT PULL 2/4] ARM: mvebu: drivers for v3.9
From: Jason Cooper @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359733918.Bf7ecc0.22262@triton>
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git tags/drivers_for_v3.9
for you to fetch changes up to 9cfc94eb0f4843af5d1141a37d7b7ca5d3b27220:
cpuidle: kirkwood: Move out of mach directory
----------------------------------------------------------------
mvebu drivers for v3.9
- use rtc-mv in mvebu armv7 SoCs
- add pci-e hotplug for kirkwood
Depends on:
- tags/mvebu_fixes_for_v3.8-rc6
----------------------------------------------------------------
Andrew Lunn (1):
cpuidle: kirkwood: Move out of mach directory
Gregory CLEMENT (1):
rtc: Add support of rtc-mv for MVEBU SoCs
Jason Cooper (1):
Merge tag 'tags/mvebu_fixes_for_v3.8-rc6' into mvebu/drivers
Jason Gunthorpe (1):
ARM: Kirkwood: Support basic hotplug for PCI-E
arch/arm/boot/dts/dove.dtsi | 2 +
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/mvebu_defconfig | 2 +
arch/arm/mach-kirkwood/Makefile | 1 -
arch/arm/mach-kirkwood/board-dt.c | 2 +
arch/arm/mach-kirkwood/common.c | 23 ++++++++++
arch/arm/mach-kirkwood/common.h | 1 +
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 3 +-
arch/arm/mach-kirkwood/pcie.c | 10 ++---
arch/arm/plat-orion/mpp.c | 2 +-
drivers/cpuidle/Kconfig | 6 +++
drivers/cpuidle/Makefile | 1 +
.../cpuidle/cpuidle-kirkwood.c | 45 +++++++++++++++++---
drivers/rtc/Kconfig | 2 +-
14 files changed, 84 insertions(+), 17 deletions(-)
rename arch/arm/mach-kirkwood/cpuidle.c => drivers/cpuidle/cpuidle-kirkwood.c (61%)
^ permalink raw reply
* [GIT PULL 0/4] ARM: mvebu: changes for v3.9
From: Jason Cooper @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 19d23dac1b8f95e4a960fcbbb5687c33b9a2cd01:
Merge branch 'fixes' into for-next
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git mvebu/for-next
for you to fetch changes up to 7d8a7dce24f76242daf1c469878597b8acc4f78f:
Merge tag 'tags/dt_for_v3.9' into mvebu/for-next
Jason Cooper (5):
Merge tag 'tags/mvebu_fixes_for_v3.8-rc6' into mvebu/for-next
Merge tag 'tags/cleanup_for_v3.9_round2' into mvebu/for-next
Merge tag 'tags/drivers_for_v3.9' into mvebu/for-next
Merge tag 'tags/boards_for_v3.9' into mvebu/for-next
Merge tag 'tags/dt_for_v3.9' into mvebu/for-next
.../bindings/mmc/brcm,bcm2835-sdhci.txt | 18 ++
.../devicetree/bindings/mmc/orion-sdio.txt | 17 ++
Documentation/filesystems/f2fs.txt | 18 +-
MAINTAINERS | 2 +-
Makefile | 4 +-
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/armada-370-db.dts | 15 +
arch/arm/boot/dts/armada-370-mirabox.dts | 10 +
arch/arm/boot/dts/armada-370-rd.dts | 61 ++++
arch/arm/boot/dts/armada-370-xp.dtsi | 14 +
arch/arm/boot/dts/armada-370.dtsi | 12 +
arch/arm/boot/dts/armada-xp-db.dts | 7 +
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 6 +
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 6 +
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 6 +
.../arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 12 +
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
arch/arm/boot/dts/dove-cubox.dts | 28 +-
arch/arm/boot/dts/dove.dtsi | 2 +
arch/arm/boot/dts/kirkwood-6282.dtsi | 17 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 7 +
.../boot/dts/kirkwood-guruplug-server-plus.dts | 94 +++++++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 11 +-
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 6 +
arch/arm/boot/dts/kirkwood-nsa310.dts | 27 ++
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 116 ++++++++
arch/arm/boot/dts/kirkwood.dtsi | 8 +
arch/arm/configs/dove_defconfig | 28 +-
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/mvebu_defconfig | 16 ++
arch/arm/kernel/head.S | 5 +-
arch/arm/kernel/hyp-stub.S | 18 +-
arch/arm/mach-dove/Kconfig | 7 +
arch/arm/mach-dove/Makefile | 4 +-
arch/arm/mach-dove/board-dt.c | 102 +++++++
arch/arm/mach-dove/common.c | 114 +-------
arch/arm/mach-imx/clk-imx25.c | 6 +-
arch/arm/mach-imx/clk-imx27.c | 6 +-
arch/arm/mach-imx/clk-imx31.c | 6 +-
arch/arm/mach-imx/clk-imx35.c | 6 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 6 +-
arch/arm/mach-imx/devices/devices-common.h | 1 +
.../mach-imx/devices/platform-fsl-usb2-udc.c | 15 +-
arch/arm/mach-kirkwood/Kconfig | 7 +
arch/arm/mach-kirkwood/Makefile | 2 +-
arch/arm/mach-kirkwood/board-dreamplug.c | 6 -
arch/arm/mach-kirkwood/board-dt.c | 15 +-
arch/arm/mach-kirkwood/board-guruplug.c | 39 +++
arch/arm/mach-kirkwood/board-ib62x0.c | 1 -
arch/arm/mach-kirkwood/board-mplcec4.c | 8 -
arch/arm/mach-kirkwood/board-ns2.c | 14 -
arch/arm/mach-kirkwood/board-nsa310.c | 51 +---
arch/arm/mach-kirkwood/board-openblocks_a6.c | 44 ---
arch/arm/mach-kirkwood/common.c | 23 ++
arch/arm/mach-kirkwood/common.h | 6 +
arch/arm/mach-kirkwood/dockstar-setup.c | 1 -
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 3 +-
arch/arm/mach-kirkwood/pcie.c | 10 +-
arch/arm/mach-mvebu/irq-armada-370-xp.c | 72 +++++
arch/arm/mm/dma-mapping.c | 18 +-
arch/arm/mm/mmu.c | 2 +-
arch/arm/plat-orion/mpp.c | 2 +-
arch/arm/vfp/entry.S | 6 +-
arch/arm/vfp/vfphw.S | 4 +-
arch/arm64/include/asm/elf.h | 5 +-
arch/ia64/kernel/ptrace.c | 27 --
arch/m68k/include/asm/dma-mapping.h | 16 ++
arch/m68k/include/asm/pgtable_no.h | 2 +
arch/m68k/include/asm/unistd.h | 2 +-
arch/m68k/include/uapi/asm/unistd.h | 1 +
arch/m68k/kernel/syscalltable.S | 1 +
arch/m68k/mm/init.c | 8 +-
arch/parisc/kernel/entry.S | 18 +-
arch/parisc/kernel/irq.c | 6 +-
arch/parisc/kernel/ptrace.c | 2 +-
arch/parisc/kernel/signal.c | 4 +-
arch/parisc/math-emu/cnv_float.h | 11 +-
arch/powerpc/kvm/emulate.c | 2 +
arch/x86/kernel/cpu/perf_event.c | 6 -
arch/x86/kernel/entry_32.S | 1 -
arch/x86/kernel/step.c | 9 +-
arch/x86/xen/smp.c | 7 -
drivers/acpi/apei/apei-base.c | 3 +
drivers/acpi/processor_idle.c | 4 +
drivers/acpi/processor_perflib.c | 7 +
drivers/ata/ahci.c | 8 +-
drivers/ata/libahci.c | 6 +-
drivers/ata/libata-core.c | 22 +-
drivers/ata/libata-eh.c | 2 +-
drivers/base/regmap/regmap-debugfs.c | 2 -
drivers/base/regmap/regmap.c | 2 +-
drivers/block/virtio_blk.c | 7 +-
drivers/cpufreq/Kconfig.x86 | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 7 +
drivers/cpufreq/cpufreq-cpu0.c | 5 +
drivers/cpufreq/omap-cpufreq.c | 3 +
drivers/cpuidle/Kconfig | 6 +
drivers/cpuidle/Makefile | 1 +
.../cpuidle/cpuidle-kirkwood.c | 45 ++-
drivers/devfreq/devfreq.c | 5 +
drivers/devfreq/exynos4_bus.c | 94 +++++--
drivers/dma/imx-dma.c | 5 +-
drivers/dma/ioat/dma_v3.c | 2 +-
drivers/dma/tegra20-apb-dma.c | 8 +-
drivers/gpio/gpio-mvebu.c | 6 -
drivers/gpio/gpio-samsung.c | 14 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 ++
drivers/gpu/drm/i915/i915_irq.c | 11 +
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_dp.c | 47 +++-
drivers/gpu/drm/i915/intel_pm.c | 17 +-
drivers/gpu/drm/radeon/evergreen.c | 6 +
drivers/gpu/drm/radeon/ni.c | 6 +
drivers/gpu/drm/radeon/r600.c | 6 +
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_object.c | 18 +-
drivers/gpu/drm/radeon/radeon_ring.c | 2 +
drivers/gpu/drm/radeon/radeon_semaphore.c | 4 +
drivers/gpu/drm/radeon/reg_srcs/rv515 | 2 +
drivers/gpu/drm/radeon/si.c | 6 +
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +-
drivers/hv/hv_balloon.c | 35 ++-
drivers/i2c/busses/i2c-designware-core.c | 4 +
drivers/i2c/busses/i2c-mxs.c | 6 +-
drivers/i2c/busses/i2c-omap.c | 6 +-
drivers/i2c/busses/i2c-sirf.c | 4 +
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
drivers/idle/intel_idle.c | 3 +-
drivers/media/i2c/m5mols/m5mols_core.c | 2 +-
drivers/media/platform/omap3isp/ispvideo.c | 3 -
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 2 +-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 88 +++---
drivers/media/usb/gspca/kinect.c | 1 +
drivers/media/usb/gspca/sonixb.c | 13 +-
drivers/media/usb/gspca/sonixj.c | 1 +
drivers/media/usb/uvc/uvc_ctrl.c | 4 +-
drivers/media/usb/uvc/uvc_v4l2.c | 6 +-
drivers/media/v4l2-core/videobuf2-core.c | 4 +-
drivers/misc/ti-st/st_kim.c | 37 ++-
drivers/mmc/card/block.c | 30 +-
drivers/mmc/card/queue.c | 32 ++-
drivers/mmc/card/queue.h | 3 +
drivers/mmc/core/bus.c | 1 +
drivers/mmc/core/core.c | 121 +++++++-
drivers/mmc/core/core.h | 1 +
drivers/mmc/core/sdio.c | 33 ++-
drivers/mmc/core/slot-gpio.c | 57 +++-
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/mvsdio.c | 131 +++++----
drivers/mmc/host/sdhci-bcm2835.c | 227 +++++++++++++++
drivers/mmc/host/sdhci-esdhc-imx.c | 59 +---
drivers/mmc/host/sdhci-pxav3.c | 12 +-
drivers/mmc/host/sdhci.c | 117 +++++---
drivers/mmc/host/sh_mmcif.c | 280 +++++++++++--------
drivers/mmc/host/tmio_mmc_pio.c | 8 -
drivers/pci/hotplug/pciehp.h | 2 +-
drivers/pci/hotplug/pciehp_core.c | 11 +-
drivers/pci/hotplug/pciehp_ctrl.c | 8 +-
drivers/pci/hotplug/pciehp_hpc.c | 11 +-
drivers/pci/hotplug/shpchp.h | 3 +-
drivers/pci/hotplug/shpchp_core.c | 36 +--
drivers/pci/hotplug/shpchp_ctrl.c | 6 +-
drivers/pci/pcie/Kconfig | 2 +-
drivers/pci/pcie/aer/aerdrv_core.c | 1 +
drivers/pci/pcie/aspm.c | 3 +
drivers/rtc/Kconfig | 2 +-
drivers/staging/iio/adc/mxs-lradc.c | 2 +-
drivers/staging/iio/gyro/adis16080_core.c | 2 +-
drivers/staging/sb105x/sb_pci_mp.c | 2 +-
drivers/staging/vt6656/bssdb.h | 1 -
drivers/staging/vt6656/int.h | 1 -
drivers/staging/vt6656/iocmd.h | 33 ++-
drivers/staging/vt6656/iowpa.h | 8 +-
drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
drivers/tty/pty.c | 2 +
drivers/tty/serial/8250/8250.c | 11 +
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_dw.c | 2 +-
drivers/tty/serial/8250/8250_pci.c | 42 ++-
drivers/tty/serial/ifx6x60.c | 4 +-
drivers/tty/serial/mxs-auart.c | 6 +-
drivers/tty/serial/samsung.c | 1 -
drivers/tty/serial/vt8500_serial.c | 2 +-
drivers/usb/dwc3/gadget.c | 1 +
drivers/usb/gadget/f_fs.c | 6 +-
drivers/usb/gadget/fsl_mxc_udc.c | 40 ++-
drivers/usb/gadget/fsl_udc_core.c | 42 +--
drivers/usb/gadget/fsl_usb2_udc.h | 5 +-
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 12 +-
drivers/usb/host/ehci-mxc.c | 120 ++++----
drivers/usb/host/ehci.h | 7 +
drivers/usb/host/uhci-hcd.c | 15 +-
drivers/usb/musb/cppi_dma.c | 4 +-
drivers/usb/serial/io_ti.c | 3 +
drivers/usb/serial/option.c | 9 +-
drivers/vfio/pci/vfio_pci_rdwr.c | 4 +-
drivers/xen/cpu_hotplug.c | 4 +-
drivers/xen/gntdev.c | 130 ++++++---
drivers/xen/grant-table.c | 48 ++--
drivers/xen/privcmd.c | 89 +++---
drivers/xen/xen-pciback/pciback.h | 2 +-
fs/Kconfig | 10 -
fs/btrfs/extent-tree.c | 6 +-
fs/btrfs/extent_map.c | 13 +-
fs/btrfs/extent_map.h | 1 +
fs/btrfs/file-item.c | 4 +-
fs/btrfs/file.c | 10 +-
fs/btrfs/free-space-cache.c | 20 +-
fs/btrfs/inode.c | 137 ++++++---
fs/btrfs/ioctl.c | 129 ++++++---
fs/btrfs/qgroup.c | 20 +-
fs/btrfs/send.c | 4 +-
fs/btrfs/super.c | 2 +-
fs/btrfs/transaction.c | 19 +-
fs/btrfs/tree-log.c | 10 +-
fs/btrfs/volumes.c | 23 +-
fs/cifs/cifs_dfs_ref.c | 2 +
fs/cifs/connect.c | 2 +-
fs/f2fs/acl.c | 13 +-
fs/f2fs/checkpoint.c | 3 +-
fs/f2fs/data.c | 17 +-
fs/f2fs/debug.c | 50 ++--
fs/f2fs/dir.c | 2 +-
fs/f2fs/f2fs.h | 18 +-
fs/f2fs/file.c | 16 +-
fs/f2fs/gc.c | 68 ++---
fs/f2fs/inode.c | 3 +
fs/f2fs/node.c | 19 +-
fs/f2fs/recovery.c | 10 +-
fs/f2fs/segment.c | 2 +-
fs/f2fs/super.c | 97 +++++--
fs/f2fs/xattr.c | 2 +
fs/fuse/Kconfig | 16 +-
fs/fuse/cuse.c | 36 ++-
fs/fuse/dev.c | 5 -
fs/fuse/file.c | 5 +-
include/asm-generic/dma-mapping-broken.h | 16 ++
include/asm-generic/pgtable.h | 6 +-
include/asm-generic/syscalls.h | 2 +
include/linux/ata.h | 8 +-
include/linux/libata.h | 4 +-
include/linux/mmc/card.h | 12 +
include/linux/mmc/core.h | 3 +-
include/linux/mmc/host.h | 25 ++
include/linux/module.h | 10 +-
include/linux/ptrace.h | 1 -
include/linux/sched.h | 11 +-
include/uapi/linux/serial_core.h | 3 +-
init/do_mounts_initrd.c | 4 +
init/main.c | 4 +-
kernel/async.c | 27 +-
kernel/compat.c | 23 +-
kernel/debug/kdb/kdb_main.c | 2 +
kernel/fork.c | 6 +-
kernel/module.c | 154 +++++++---
kernel/ptrace.c | 74 ++++-
kernel/sched/core.c | 3 +-
kernel/signal.c | 24 +-
kernel/trace/ftrace.c | 2 +-
lib/bug.c | 1 +
security/device_cgroup.c | 2 +
security/integrity/evm/evm_crypto.c | 4 +-
sound/pci/hda/hda_codec.c | 5 +-
sound/pci/hda/patch_conexant.c | 9 +
sound/pci/hda/patch_realtek.c | 2 +
tools/perf/MANIFEST | 10 +
tools/perf/Makefile | 2 +-
274 files changed, 3501 insertions(+), 1617 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
create mode 100644 Documentation/devicetree/bindings/mmc/orion-sdio.txt
create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
create mode 100644 arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
create mode 100644 arch/arm/mach-dove/board-dt.c
create mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
rename arch/arm/mach-kirkwood/cpuidle.c => drivers/cpuidle/cpuidle-kirkwood.c (61%)
create mode 100644 drivers/mmc/host/sdhci-bcm2835.c
^ permalink raw reply
* [GIT PULL 1/4] ARM: mvebu: cleanup for v3.9
From: Jason Cooper @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359733918.Bf7ecc0.22262@triton>
The following changes since commit b96e1b1c3c5319294edb0970b6d5bf099c0e85eb:
ARM: Kirkwood: Cleanup unneeded include files
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git tags/cleanup_for_v3.9_round2
for you to fetch changes up to b3af7a1ffd1e5e9ec536a915393b7e07a8793f2a:
ARM: dove: cleanup includes
----------------------------------------------------------------
cleanup for v3.9 round2
- remove unneeded #includes for mach-dove
- remove unneeded #includes and code for the nsa310
----------------------------------------------------------------
Jason Cooper (1):
ARM: kirkwood: nsa310: cleanup includes and unneeded code
Sebastian Hesselbarth (1):
ARM: dove: cleanup includes
arch/arm/mach-dove/common.c | 29 +++++++++--------------------
arch/arm/mach-kirkwood/board-nsa310.c | 8 +-------
2 files changed, 10 insertions(+), 27 deletions(-)
^ permalink raw reply
* [GIT PULL 5/8] ARM: tegra: SCU base rework
From: Arnd Bergmann @ 2013-02-01 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510B4892.3050900@wwwdotorg.org>
On Friday 01 February 2013, Stephen Warren wrote:
> Hmm. And here I was thinking that I was basing branches on top of
> each-other too much given your previous comments about merge conflicts
> being OK!
IMHO the cleanup branches are special in this regard because they
are primarily meant as a way to resolve the merge conflicts.
If you are able to put all the conflicts between the normal branches
into cleanup patches, you can put them all in one branch and
base your other branches on top of that. Of course that doesn't
always work, but it would solve this particular instance.
Arnd
^ permalink raw reply
* [PATCH] ARM: mxs: Enable cpuidle
From: Fabio Estevam @ 2013-02-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Enable CONFIG_CPU_IDLE, so that suspend/resume can be tested on mxs platforms.
Tested on a mx28evk board:
$ echo enabled > /sys/devices/80000000.apb/80040000.apbx/80074000.serial/tty/ttyAMA0/power/wakeup
$ echo mem > /sys/power/state
[ 507.040000] PM: Syncing filesystems ... done.
[ 507.060000] mmc0: card e624 removed
[ 507.160000] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 507.180000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 507.200000] Suspending console(s) (use no_console_suspend to debug)
(Then send any character via AUART to wakeup the system).
[ 507.220000] PM: suspend of devices complete after 10.468 msecs
[ 507.220000] PM: late suspend of devices complete after 3.531 msecs
[ 507.230000] PM: noirq suspend of devices complete after 5.187 msecs
[ 507.230000] PM: noirq resume of devices complete after 2.312 msecs
[ 507.230000] PM: early resume of devices complete after 2.437 msecs
[ 507.320000] PM: resume of devices complete after 81.312 msecs
[ 507.360000] Restarting tasks ... done.
[ 507.530000] mmc0: new SDHC card at address e624
[ 507.550000] mmcblk0: mmc0:e624 SU04G 3.69 GiB
[ 507.560000] mmcblk0: p1 p2 p3
[ 509.240000] libphy: 800f0000.etherne:01 - Link is Down
[ 511.240000] libphy: 800f0000.etherne:01 - Link is Up
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/mxs_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index 7bf5351..7bf9aba 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -29,6 +29,7 @@ CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_AEABI=y
CONFIG_AUTO_ZRELADDR=y
+CONFIG_CPU_IDLE=y
CONFIG_FPE_NWFPE=y
CONFIG_NET=y
CONFIG_PACKET=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-02-01 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359729096-15371-2-git-send-email-andrew@lunn.ch>
On 1 February 2013 20:01, Andrew Lunn <andrew@lunn.ch> wrote:
> The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
> CPU can either use the a high speed cpu clock, or the slower DDR
> clock. Add a driver to swap between these two clock sources.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [GIT PULL] ARM: LPAE Fixes - Part 1 for v3.9
From: Cyril Chemparathy @ 2013-02-01 15:32 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cchemparathy/linux-keystone.git
upstream/keystone-lpae-v4
for you to fetch changes up to 4dc17a8282221854896a0d6a83c758fde4f9b139:
ARM: fix type of PHYS_PFN_OFFSET to unsigned long (2013-02-01
09:37:53 -0500)
----------------------------------------------------------------
Cyril Chemparathy (10):
ARM: LPAE: use signed arithmetic for mask definitions
ARM: LPAE: use phys_addr_t in switch_mm()
ARM: LPAE: use 64-bit accessors for TTBR registers
ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem
ARM: LPAE: factor out T1SZ and TTBR1 computations
ARM: LPAE: accomodate >32-bit addresses for page table base
ARM: mm: use physical addresses in highmem sanity checks
ARM: mm: cleanup checks for membank overlap with vmalloc area
ARM: mm: clean up membank size limit checks
ARM: fix type of PHYS_PFN_OFFSET to unsigned long
Vitaly Andrianov (3):
ARM: LPAE: use phys_addr_t in alloc_init_pud()
ARM: LPAE: use phys_addr_t in free_memmap()
ARM: LPAE: use phys_addr_t for initrd location
arch/arm/include/asm/memory.h | 20 +++++++++-
arch/arm/include/asm/page.h | 2 +-
arch/arm/include/asm/pgtable-3level-hwdef.h | 20 ++++++++++
arch/arm/include/asm/pgtable-3level.h | 6 +--
arch/arm/include/asm/proc-fns.h | 26 +++++++++----
arch/arm/kernel/head.S | 10 ++---
arch/arm/kernel/smp.c | 11 +++++-
arch/arm/mm/context.c | 9 +----
arch/arm/mm/init.c | 19 +++++-----
arch/arm/mm/mmu.c | 49
+++++++++----------------
arch/arm/mm/proc-v7-3level.S | 53
++++++++++++++-------------
11 files changed, 132 insertions(+), 93 deletions(-)
^ permalink raw reply
* [PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware
From: Russell King - ARM Linux @ 2013-02-01 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71B37E0559AC6849A68C5BA94C509FB45A63D4E47D@SJ-ITMSG02.altera.priv.altera.com>
On Fri, Feb 01, 2013 at 07:27:46AM -0800, Dinh Nguyen wrote:
> Hi Olof,
> On Fri, 2013-02-01 at 11:46 +0100, ZY - pavel wrote:
> > Hi!
> >
> > > > Because the CPU1 start address is different for socfpga-vt and
> > > > socfpga-cyclone5, we add code to use the correct CPU1 start addr.
> >
> > > > @@ -72,6 +73,13 @@ void __init socfpga_sysmgr_init(void)
> > > > struct device_node *np;
> > > >
> > > > np = of_find_compatible_node(NULL, NULL, "altr,sys-mgr");
> > > > +
> > > > + if (of_property_read_u32(np, "cpu1-start-addr",
> > > > + (u32 *) &cpu1start_addr)) {
> > > > + early_printk("Need cpu1-start-addr in device tree.\n");
> > > > + panic("Need cpu1-start-addr in device tree.\n");
> > > > + }
> > > > +
> > > > sys_manager_base_addr = of_iomap(np, 0);
> > >
> > > Wouldn't it be easier to diagnose this failure if you just printed the error
> > > and continued booting without the second CPU? An early panic is usually really
> > > hard to debug since you might not get early console without extra work.
> >
> > I actually thought about that... but could not think of non-ugly way
> > of doing that. I hope dts will normally be "right" for any production
> > system...
>
> I think a panic is better just for the reason that if someone is
> expecting SMP, but missed the warning message, and later finds out that
> the secondary core never came up, it would save some debugging time.
>
> Since I have to send out a v3 from the 1st patch anyways, let me verify
> that I can get the early warning.
The choice is between a panic() at a point where the only way to find
out is to throw in printascii() or a working printk, and ending up with
an unbootable kernel, vs continuing the boot and having an almost
working system which can be logged into and the messages viewed.
If you have an application which relies on the second CPU coming up,
why not have it verify that the second CPU came up (it's quite easy
to do - there's POSIX standard libc calls to get the number of online
CPUs).
^ permalink raw reply
* [PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware
From: Dinh Nguyen @ 2013-02-01 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201104655.GA3124@amd.pavel.ucw.cz>
Hi Olof,
On Fri, 2013-02-01 at 11:46 +0100, ZY - pavel wrote:
> Hi!
>
> > > Because the CPU1 start address is different for socfpga-vt and
> > > socfpga-cyclone5, we add code to use the correct CPU1 start addr.
>
> > > @@ -72,6 +73,13 @@ void __init socfpga_sysmgr_init(void)
> > > struct device_node *np;
> > >
> > > np = of_find_compatible_node(NULL, NULL, "altr,sys-mgr");
> > > +
> > > + if (of_property_read_u32(np, "cpu1-start-addr",
> > > + (u32 *) &cpu1start_addr)) {
> > > + early_printk("Need cpu1-start-addr in device tree.\n");
> > > + panic("Need cpu1-start-addr in device tree.\n");
> > > + }
> > > +
> > > sys_manager_base_addr = of_iomap(np, 0);
> >
> > Wouldn't it be easier to diagnose this failure if you just printed the error
> > and continued booting without the second CPU? An early panic is usually really
> > hard to debug since you might not get early console without extra work.
>
> I actually thought about that... but could not think of non-ugly way
> of doing that. I hope dts will normally be "right" for any production
> system...
I think a panic is better just for the reason that if someone is
expecting SMP, but missed the warning message, and later finds out that
the secondary core never came up, it would save some debugging time.
Since I have to send out a v3 from the 1st patch anyways, let me verify
that I can get the early warning.
Thanks,
Dinh
> Pavel
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.
^ permalink raw reply
* [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
From: Arnd Bergmann @ 2013-02-01 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-5-git-send-email-padma.v@samsung.com>
On Friday 01 February 2013, Padmavathi Venna wrote:
> This patch modify the filter function to filter the required channel
> based on new filter params.
>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
The result of this looks good, but I fear that changing the filter function
like this wil break all drivers that currently use the plat-samsung/dma-ops.c
code. For migration purposes, I think the best way is to change
samsung_dmadev_request() to match the new filter_param format.
After that is done, you can migrate all the drivers using samsung_dma_get_ops
over to the new dma_request_slave_channel interface without breaking
anything when only part of the series is applied.
Arnd
^ permalink raw reply
* [PATCHv2 for soc 1/4] arm: socfpga: Add new device tree source for actual socfpga HW
From: Dinh Nguyen @ 2013-02-01 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201034642.GC4838@quad.lixom.net>
Hi Olof,
On Thu, 2013-01-31 at 19:46 -0800, Olof Johansson wrote:
> On Thu, Jan 31, 2013 at 11:05:40AM -0600, dinguyen at altera.com wrote:
> > From: Dinh Nguyen <dinguyen@altera.com>
> >
> > Up to this point, support for socfpga has only been on a virtual
> > platform. Now that actual hardware is available, we add the appropriate
> > device tree source files.
> >
> > Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> > Tested-by: Pavel Machek <pavel@denx.de>
> > Reviewed-by: Pavel Machek <pavel@denx.de>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Olof Johansson <olof@lixom.net>
>
> Are you planning on sending us a merge request, or do you want us to apply this
> to a branch in arm-soc for you?
If you can apply to arm-soc, that would great. Thanks! Let me address
your comment in a v3.
Dinh
>
> (Note comment below though)
>
> > diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
> > index ab7e4a9..7ad3cc6 100644
> > --- a/arch/arm/boot/dts/socfpga_cyclone5.dts
> > +++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
> > @@ -20,7 +20,7 @@
> >
> > / {
> > model = "Altera SOCFPGA Cyclone V";
> > - compatible = "altr,socfpga-cyclone5";
> > + compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> >
> > chosen {
> > bootargs = "console=ttyS0,57600";
>
> [...]
>
> > diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
> > new file mode 100644
> > index 0000000..a0c6c65
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/socfpga_vt.dts
> [...]
> > +
> > +/ {
> > + model = "Altera SOCFPGA VT";
> > + compatible = "altr,socfpga-vt", "altr,socfpga";
> > +
> > + chosen {
> > + bootargs = "console=ttyS0,57600";
> > + };
> > +
> [...]
> > diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> > index 6732924..198f491 100644
> > --- a/arch/arm/mach-socfpga/socfpga.c
> > +++ b/arch/arm/mach-socfpga/socfpga.c
> > @@ -99,6 +99,7 @@ static void __init socfpga_cyclone5_init(void)
> > static const char *altera_dt_match[] = {
> > "altr,socfpga",
> > "altr,socfpga-cyclone5",
> > + "altr,socfpga-vt",
> > NULL
> > };
>
> Since you have altr,socfpga in the compatible for the new board, you don't need
> to add an explicit check for the more specific one here. Same for cyclone5, you
> should even be able to remove that.
>
>
> -Olof
>
^ permalink raw reply
* [PATCH V2 3/4] ARM: dts: Add #dma-cells for generic dma binding support
From: Arnd Bergmann @ 2013-02-01 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-4-git-send-email-padma.v@samsung.com>
On Friday 01 February 2013, Padmavathi Venna wrote:
>
> This patch adds #dma-cells property to PL330 DMA controller
> nodes for supporting generic dma dt bindings on samsung
> exynos5250 platform.
>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
The generic binding also lists the dma-channels and dma-requests
properties. Those are currently not required by the code, but I think
it would be good to list them anyway, to be future-proof in case
we ever need them.
Otherwise
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v4 00/13] ARM LPAE Fixes - Part 1
From: Russell King - ARM Linux @ 2013-02-01 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BDAED.8060805@ti.com>
On Fri, Feb 01, 2013 at 10:10:37AM -0500, Cyril Chemparathy wrote:
> With this, I ran simple network and filesystem performance tests to
> compare the code-patching vs. non-code-patching variants. These tests
> didn't yield any significant performance difference between the two on
> an ARMv7 (Cortex-A8) platform.
It's not network and fs activity that this kind of stuff is likely to
show up in, but more to do with walking pages tables and the like -
remember that page tables are stored using physical addresses, and any
walks of them have to convert those physical addresses to virtual
addresses and back again.
So, things like page scanning for eviction (eg, page aging, page
faults even those which just re-use a page from the page cache) have
to use the v:p / p:v translation macros.
^ permalink raw reply
* [PATCH v4 00/13] ARM LPAE Fixes - Part 1
From: Cyril Chemparathy @ 2013-02-01 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301312252230.6300@xanadu.home>
Hi Nico,
On 01/31/2013 11:00 PM, Nicolas Pitre wrote:
> On Thu, 31 Jan 2013, Cyril Chemparathy wrote:
>
>> This series is a repost of the LPAE related changes in preparation for the
>> introduction of the Keystone sub-architecture. The original series has now
>> been split, and this particular series excludes the earlier changes to the
>> runtime code patching implementation. Earlier versions of this series can be
>> found at [1], [2], [3] and [4].
>>
>> These patches are also available in git:
>> git://git.kernel.org/pub/scm/linux/kernel/git/cchemparathy/linux-keystone.git upstream/keystone-lpae-v4
>
> This part 1 looks very nice. It received many review cycles already as
> well. It would be about time it goes upstream.
>
> I think it is ready to be merged in Russell's tree. Feel free to send
> him a pull request whenever you're ready.
>
Great. I'll apply your acks and post a pull request.
> Then we'll be free to look at the more controvertial p2v patching stuff.
>
On the P2V patching stuff, I've implemented an alternative approach to
get past this problem. Essentially, the new implementation retains the
kernel location detection part, but avoids the code patching by using
simple inline P2V and V2P functions that use the offset detected early
on in boot.
With this, I ran simple network and filesystem performance tests to
compare the code-patching vs. non-code-patching variants. These tests
didn't yield any significant performance difference between the two on
an ARMv7 (Cortex-A8) platform.
This series is basically operational at this point, but it needs a bit
more test coverage before I post it out.
Thanks
-- Cyril.
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Roger Quadros @ 2013-02-01 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EAA0011@DBDE01.ent.ti.com>
On 02/01/2013 04:35 PM, Mohammed, Afzal wrote:
> Hi Roger,
>
> On Fri, Feb 01, 2013 at 20:01:38, Quadros, Roger wrote:
>
>> but DT boot is not supported for OMAP USB Host. How did you get it to work?
>>
>> Are you testing the Host connector or the OTG connector?
>
> If you see latest changes on musb_dsps.c, you will be able to find
> out.
>
> As beagle bone first instance works only in device, it was tested
> using ether gadget.
>
OK, it seems that you are testing the OTG port. This patchset has nothing to do with
it. These are for getting the USB type A (the bigger) port to work. But for that to work on
beaglebone we need to wait for the DT adaptation.
cheers,
-roger
^ permalink raw reply
* [PATCH V2 2/4] DMA: PL330: Register the DMA controller with the generic DMA helpers
From: Arnd Bergmann @ 2013-02-01 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-3-git-send-email-padma.v@samsung.com>
On Friday 01 February 2013, Padmavathi Venna wrote:
> This patch registers the pl330 dma controller driver with the generic
> device tree dma helper functions.
>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH V2 1/4] DMA: PL330: Add xlate function
From: Arnd Bergmann @ 2013-02-01 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359723116-18173-2-git-send-email-padma.v@samsung.com>
On Friday 01 February 2013, Padmavathi Venna wrote:
>
> Add xlate to translate the device-tree binding information into
> the appropriate format. The filter function requires the dma
> controller device and dma channel number as filter_params.
>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v4 3/3] ARM: mm: use static_vm for managing static mapped areas
From: JoonSoo Kim @ 2013-02-01 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301312306080.6300@xanadu.home>
2013/2/1 Nicolas Pitre <nicolas.pitre@linaro.org>:
> On Thu, 31 Jan 2013, Joonsoo Kim wrote:
>
>> A static mapped area is ARM-specific, so it is better not to use
>> generic vmalloc data structure, that is, vmlist and vmlist_lock
>> for managing static mapped area. And it causes some needless overhead and
>> reducing this overhead is better idea.
>>
>> Now, we have newly introduced static_vm infrastructure.
>> With it, we don't need to iterate all mapped areas. Instead, we just
>> iterate static mapped areas. It helps to reduce an overhead of finding
>> matched area. And architecture dependency on vmalloc layer is removed,
>> so it will help to maintainability for vmalloc layer.
>>
>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> Comments below.
>
>>
>> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
>> index ceb34ae..7fe5b48 100644
>> --- a/arch/arm/mm/ioremap.c
>> +++ b/arch/arm/mm/ioremap.c
>> @@ -269,13 +269,14 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
>> const struct mem_type *type;
>> int err;
>> unsigned long addr;
>> - struct vm_struct * area;
>> + struct vm_struct *area;
>> + phys_addr_t paddr = __pfn_to_phys(pfn);
>>
>> #ifndef CONFIG_ARM_LPAE
>> /*
>> * High mappings must be supersection aligned
>> */
>> - if (pfn >= 0x100000 && (__pfn_to_phys(pfn) & ~SUPERSECTION_MASK))
>> + if (pfn >= 0x100000 && (paddr & ~SUPERSECTION_MASK))
>> return NULL;
>> #endif
>>
>> @@ -291,24 +292,17 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
>> /*
>> * Try to reuse one of the static mapping whenever possible.
>> */
>> - read_lock(&vmlist_lock);
>> - for (area = vmlist; area; area = area->next) {
>> - if (!size || (sizeof(phys_addr_t) == 4 && pfn >= 0x100000))
>> - break;
>> - if (!(area->flags & VM_ARM_STATIC_MAPPING))
>> - continue;
>> - if ((area->flags & VM_ARM_MTYPE_MASK) != VM_ARM_MTYPE(mtype))
>> - continue;
>> - if (__phys_to_pfn(area->phys_addr) > pfn ||
>> - __pfn_to_phys(pfn) + size-1 > area->phys_addr + area->size-1)
>> - continue;
>> - /* we can drop the lock here as we know *area is static */
>> - read_unlock(&vmlist_lock);
>> - addr = (unsigned long)area->addr;
>> - addr += __pfn_to_phys(pfn) - area->phys_addr;
>> - return (void __iomem *) (offset + addr);
>> + if (size && !((sizeof(phys_addr_t) == 4 && pfn >= 0x100000))) {
>> + struct static_vm *svm;
>> +
>> + svm = find_static_vm_paddr(paddr, size,
>> + STATIC_VM_TYPE(STATIC_VM_MEM, mtype));
>> + if (svm) {
>> + addr = (unsigned long)svm->vm.addr;
>> + addr += paddr - svm->vm.phys_addr;
>> + return (void __iomem *) (offset + addr);
>> + }
>> }
>> - read_unlock(&vmlist_lock);
>>
>> /*
>> * Don't allow RAM to be mapped - this causes problems with ARMv6+
>> @@ -320,21 +314,21 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
>> if (!area)
>> return NULL;
>> addr = (unsigned long)area->addr;
>> - area->phys_addr = __pfn_to_phys(pfn);
>> + area->phys_addr = paddr;
>>
>> #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
>> if (DOMAIN_IO == 0 &&
>> (((cpu_architecture() >= CPU_ARCH_ARMv6) && (get_cr() & CR_XP)) ||
>> cpu_is_xsc3()) && pfn >= 0x100000 &&
>> - !((__pfn_to_phys(pfn) | size | addr) & ~SUPERSECTION_MASK)) {
>> + !((paddr | size | addr) & ~SUPERSECTION_MASK)) {
>> area->flags |= VM_ARM_SECTION_MAPPING;
>> err = remap_area_supersections(addr, pfn, size, type);
>> - } else if (!((__pfn_to_phys(pfn) | size | addr) & ~PMD_MASK)) {
>> + } else if (!((paddr | size | addr) & ~PMD_MASK)) {
>> area->flags |= VM_ARM_SECTION_MAPPING;
>> err = remap_area_sections(addr, pfn, size, type);
>> } else
>> #endif
>> - err = ioremap_page_range(addr, addr + size, __pfn_to_phys(pfn),
>> + err = ioremap_page_range(addr, addr + size, paddr,
>> __pgprot(type->prot_pte));
>>
>> if (err) {
>> @@ -418,34 +412,21 @@ __arm_ioremap_exec(unsigned long phys_addr, size_t size, bool cached)
>> void __iounmap(volatile void __iomem *io_addr)
>> {
>> void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
>> - struct vm_struct *vm;
>> + struct static_vm *svm;
>> +
>
> You could salvage the "/* If this is a static mapping we must leave it
> alone */" comment here.
Okay.
>> + svm = find_static_vm_vaddr(addr);
>> + if (svm)
>> + return;
>>
>> - read_lock(&vmlist_lock);
>> - for (vm = vmlist; vm; vm = vm->next) {
>> - if (vm->addr > addr)
>> - break;
>> - if (!(vm->flags & VM_IOREMAP))
>> - continue;
>> - /* If this is a static mapping we must leave it alone */
>> - if ((vm->flags & VM_ARM_STATIC_MAPPING) &&
>> - (vm->addr <= addr) && (vm->addr + vm->size > addr)) {
>> - read_unlock(&vmlist_lock);
>> - return;
>> - }
>> #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
>> - /*
>> - * If this is a section based mapping we need to handle it
>> - * specially as the VM subsystem does not know how to handle
>> - * such a beast.
>> - */
>
> Please don't remove the above comment. It is still relevant.
Yes.
Thanks for comments.
>> - if ((vm->addr == addr) &&
>> - (vm->flags & VM_ARM_SECTION_MAPPING)) {
>> + {
>> + struct vm_struct *vm;
>> +
>> + vm = find_vm_area(addr);
>> + if (vm && (vm->flags & VM_ARM_SECTION_MAPPING))
>> unmap_area_sections((unsigned long)vm->addr, vm->size);
>> - break;
>> - }
>> -#endif
>> }
>> - read_unlock(&vmlist_lock);
>> +#endif
>>
>> vunmap(addr);
>> }
>> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
>> index fb45c79..24c1df4 100644
>> --- a/arch/arm/mm/mm.h
>> +++ b/arch/arm/mm/mm.h
>> @@ -54,16 +54,6 @@ extern void __flush_dcache_page(struct address_space *mapping, struct page *page
>> /* (super)section-mapped I/O regions used by ioremap()/iounmap() */
>> #define VM_ARM_SECTION_MAPPING 0x80000000
>>
>> -/* permanent static mappings from iotable_init() */
>> -#define VM_ARM_STATIC_MAPPING 0x40000000
>> -
>> -/* empty mapping */
>> -#define VM_ARM_EMPTY_MAPPING 0x20000000
>> -
>> -/* mapping type (attributes) for permanent static mappings */
>> -#define VM_ARM_MTYPE(mt) ((mt) << 20)
>> -#define VM_ARM_MTYPE_MASK (0x1f << 20)
>> -
>
> This goes with a related question in my previous email: why didn't you
> keep those flags as they were?
>
>
> Nicolas
^ permalink raw reply
* [PATCH v4 2/3] ARM: ioremap: introduce an infrastructure for static mapped area
From: JoonSoo Kim @ 2013-02-01 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301311722540.6300@xanadu.home>
Hello, Nicolas.
2013/2/1 Nicolas Pitre <nicolas.pitre@linaro.org>:
> On Thu, 31 Jan 2013, Joonsoo Kim wrote:
>
>> In current implementation, we used ARM-specific flag, that is,
>> VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
>> The purpose of static mapped area is to re-use static mapped area when
>> entire physical address range of the ioremap request can be covered
>> by this area.
>>
>> This implementation causes needless overhead for some cases.
>> For example, assume that there is only one static mapped area and
>> vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
>> deciding whether it is matched or not. Moreover, even if there is
>> no static mapped area and vmlist has 300 areas, every time we call
>> ioremap, we check 300 areas in now.
>>
>> If we construct a extra list for static mapped area, we can eliminate
>> above mentioned overhead.
>> With a extra list, if there is one static mapped area,
>> we just check only one area and proceed next operation quickly.
>>
>> In fact, it is not a critical problem, because ioremap is not frequently
>> used. But reducing overhead is better idea.
>>
>> Another reason for doing this work is for removing architecture dependency
>> on vmalloc layer. I think that vmlist and vmlist_lock is internal data
>> structure for vmalloc layer. Some codes for debugging and stat inevitably
>> use vmlist and vmlist_lock. But it is preferable that they are used
>> as least as possible in outside of vmalloc.c
>>
>> Now, I introduce an ARM-specific infrastructure for static mapped area. In
>> the following patch, we will use this and resolve above mentioned problem.
>>
>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> Much better. Comments below.
Thanks.
>> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
>> index 88fd86c..ceb34ae 100644
>> --- a/arch/arm/mm/ioremap.c
>> +++ b/arch/arm/mm/ioremap.c
>> @@ -39,6 +39,78 @@
>> #include <asm/mach/pci.h>
>> #include "mm.h"
>>
>> +
>> +LIST_HEAD(static_vmlist);
>> +static DEFINE_RWLOCK(static_vmlist_lock);
>
> In fact you don't need a lock at all. The only writer is
> add_static_vm_early() and we know it is only used during boot when the
> kernel is still single-threaded.
Yes!
>> +
>> +static struct static_vm *find_static_vm_paddr(phys_addr_t paddr,
>> + size_t size, unsigned long flags)
>> +{
>> + struct static_vm *svm;
>> + struct vm_struct *vm;
>> +
>> + read_lock(&static_vmlist_lock);
>> + list_for_each_entry(svm, &static_vmlist, list) {
>> + if (svm->flags != flags)
>> + continue;
>> +
>> + vm = &svm->vm;
>> + if (vm->phys_addr > paddr ||
>> + paddr + size - 1 > vm->phys_addr + vm->size - 1)
>> + continue;
>> +
>> + read_unlock(&static_vmlist_lock);
>> + return svm;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +struct static_vm *find_static_vm_vaddr(void *vaddr)
>> +{
>> + struct static_vm *svm;
>> + struct vm_struct *vm;
>> +
>> + read_lock(&static_vmlist_lock);
>> + list_for_each_entry(svm, &static_vmlist, list) {
>> + vm = &svm->vm;
>> +
>> + /* static_vmlist is ascending order */
>> + if (vm->addr > vaddr)
>> + break;
>> +
>> + if (vm->addr <= vaddr && vm->addr + vm->size > vaddr) {
>> + read_unlock(&static_vmlist_lock);
>> + return svm;
>> + }
>> + }
>> + read_unlock(&static_vmlist_lock);
>> +
>> + return NULL;
>> +}
>> +
>> +void add_static_vm_early(struct static_vm *svm, unsigned long flags)
>
> This should be marked with __init. This way, it is less likely to be
> used after boot, especially with no locking. And vm_area_add_early() is
> valid only if !vmap_initialized anyway, and also __init.
Okay.
>> +{
>> + struct static_vm *curr_svm;
>> + struct vm_struct *vm;
>> + void *vaddr;
>> +
>> + vm_area_add_early(&svm->vm);
>> +
>> + vaddr = svm->vm.addr;
>> + svm->flags = flags;
>> +
>> + write_lock(&static_vmlist_lock);
>> + list_for_each_entry(curr_svm, &static_vmlist, list) {
>> + vm = &curr_svm->vm;
>> +
>> + if (vm->addr > vaddr)
>> + break;
>> + }
>> + list_add_tail(&svm->list, &curr_svm->list);
>> + write_unlock(&static_vmlist_lock);
>> +}
>> +
>> int ioremap_page(unsigned long virt, unsigned long phys,
>> const struct mem_type *mtype)
>> {
>> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
>> index a8ee92d..fb45c79 100644
>> --- a/arch/arm/mm/mm.h
>> +++ b/arch/arm/mm/mm.h
>> @@ -1,4 +1,6 @@
>> #ifdef CONFIG_MMU
>> +#include <linux/list.h>
>> +#include <linux/vmalloc.h>
>>
>> /* the upper-most page table pointer */
>> extern pmd_t *top_pmd;
>> @@ -65,6 +67,24 @@ extern void __flush_dcache_page(struct address_space *mapping, struct page *page
>> /* consistent regions used by dma_alloc_attrs() */
>> #define VM_ARM_DMA_CONSISTENT 0x20000000
>>
>> +
>> +/* ARM specific static_vm->flags bits */
>> +#define STATIC_VM_MEM 0x00000001
>> +#define STATIC_VM_EMPTY 0x00000002
>> +#define STATIC_VM_MTYPE(mtype) ((mtype) << 20)
>> +
>> +#define STATIC_VM_TYPE(type, mtype) (type | STATIC_VM_MTYPE(mtype))
>> +
>> +struct static_vm {
>> + struct vm_struct vm;
>> + struct list_head list;
>> + unsigned long flags;
>> +};
>
> What is your motivation for having separate flags instead of simply
> keeping the current vm->flags usage?
>
Keeping the current vm->flags is better idea.
I will re-work about all your comments.
Thanks.
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-01 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201144913.GQ23505@n2100.arm.linux.org.uk>
On Friday 01 February 2013 08:19 PM, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 08:13:34PM +0530, Santosh Shilimkar wrote:
>> On Friday 01 February 2013 08:01 PM, Russell King - ARM Linux wrote:
>>> Just to further provide some insight into the reasoning:
>>>
>>> Invalidating data out of a working cache risks data corruption; maybe
>>> the data being invalidated is filesystem metadata which was about to
>>> be cleaned and written back to storage. That risks filesystem
>>> corruption.
>>>
>>> Invalidating fewer levels than are actually required is different: we
>>> may leave dirty cache lines behind which may be evicted, but there's
>>> also the chance that the CPU will end up _reading_ from its
>>> uninitialized caches and may crash before that happens.
>>>
>>> So, the risks are:
>>> 1. invalidate more levels than are necessary and risk discarding data
>>> which other CPUs are using, which may be important data.
>>> 2. invalidate less levels than are necessary and risk writing out
>>> data from the CPU cache, which may or may not happen _before_ the
>>> CPU crashes due to reading invalid data.
>>>
>>> Out of those two, (2) sounds to me to be the safer approach.
>>>
>>> Plus, I can't think of a reason why you'd want to put on a SMP system
>>> more than one layer of CPU local caches... to do so would seem to me to
>>> be an exercise in coherency complexity... So, I suspect that in the
>>> real world, we will _never_ see any system which has more than one
>>> layer of caches local to the CPU. But we may see a system with a
>>> cache architecture similar to the one I drew in my email to Santosh.
>>>
>> I still scratching my head on why you would even have a CPU design
>> with two L2 shared caches for a 4 CPU system.
>>
>> If you ever design such a system, you need to ensure that
>>
>> 1. Both L2 are used in exclusive mode
>> 2. Both L2 cache has coherency hardware connected to keep them in sync
>> for shared data.
>>
>> For 1, one would just increase the size of L2 and have only 1 memory.
>>
>> 2 Doesn't bring much advantage unless and until your L3 is too far
>> away for access in terms of CPU access cycles.
>
> I don't think you quite understood my diagram. There aren't two separate
> L2 data caches (CL1I and CL1D). I'm showing the L2 cache as having a
> harvard structure (separate instruction and data) with no coherency
> between them - and because they're harvard structured, that means the
> unification level must be _below_ that point.
>
Now I get it. Yes I missed the I and D separation in the diagram.
Thanks a lot for drawing.
Regards,
Santosh
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Russell King - ARM Linux @ 2013-02-01 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510BD496.6080305@ti.com>
On Fri, Feb 01, 2013 at 08:13:34PM +0530, Santosh Shilimkar wrote:
> On Friday 01 February 2013 08:01 PM, Russell King - ARM Linux wrote:
>> Just to further provide some insight into the reasoning:
>>
>> Invalidating data out of a working cache risks data corruption; maybe
>> the data being invalidated is filesystem metadata which was about to
>> be cleaned and written back to storage. That risks filesystem
>> corruption.
>>
>> Invalidating fewer levels than are actually required is different: we
>> may leave dirty cache lines behind which may be evicted, but there's
>> also the chance that the CPU will end up _reading_ from its
>> uninitialized caches and may crash before that happens.
>>
>> So, the risks are:
>> 1. invalidate more levels than are necessary and risk discarding data
>> which other CPUs are using, which may be important data.
>> 2. invalidate less levels than are necessary and risk writing out
>> data from the CPU cache, which may or may not happen _before_ the
>> CPU crashes due to reading invalid data.
>>
>> Out of those two, (2) sounds to me to be the safer approach.
>>
>> Plus, I can't think of a reason why you'd want to put on a SMP system
>> more than one layer of CPU local caches... to do so would seem to me to
>> be an exercise in coherency complexity... So, I suspect that in the
>> real world, we will _never_ see any system which has more than one
>> layer of caches local to the CPU. But we may see a system with a
>> cache architecture similar to the one I drew in my email to Santosh.
>>
> I still scratching my head on why you would even have a CPU design
> with two L2 shared caches for a 4 CPU system.
>
> If you ever design such a system, you need to ensure that
>
> 1. Both L2 are used in exclusive mode
> 2. Both L2 cache has coherency hardware connected to keep them in sync
> for shared data.
>
> For 1, one would just increase the size of L2 and have only 1 memory.
>
> 2 Doesn't bring much advantage unless and until your L3 is too far
> away for access in terms of CPU access cycles.
I don't think you quite understood my diagram. There aren't two separate
L2 data caches (CL1I and CL1D). I'm showing the L2 cache as having a
harvard structure (separate instruction and data) with no coherency
between them - and because they're harvard structured, that means the
unification level must be _below_ that point.
^ 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