* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-09 22:42 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: arm, linux-arm-kernel, linux-kernel
Hi Linus,
Here's a 2nd round of changes from ARM SoC land.
The main thing of note (or of potential annoyance factor) here is the
handful of conflicts in PULL 2/3 coming from platform changes
conflicting with driver changes going in to the V4L tree. I've listed
them in detail in that pull request, and we will work with the
platform maintainer on the workflow to avoid this in the future.
For future reference, when it comes to these conflicts, do you want to
see a summary of the suggested resolutions, a published branch with
the resolutions, both or neither? Just curious.
Kevin
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-09 22:42 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Here's a 2nd round of changes from ARM SoC land.
The main thing of note (or of potential annoyance factor) here is the
handful of conflicts in PULL 2/3 coming from platform changes
conflicting with driver changes going in to the V4L tree. I've listed
them in detail in that pull request, and we will work with the
platform maintainer on the workflow to avoid this in the future.
For future reference, when it comes to these conflicts, do you want to
see a summary of the suggested resolutions, a published branch with
the resolutions, both or neither? Just curious.
Kevin
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 1/3] ARM: SoC drivers for v3.12
2013-09-09 22:42 ` Kevin Hilman
@ 2013-09-09 22:42 ` Kevin Hilman
-1 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: arm, linux-arm-kernel, linux-kernel
This branch contains ARM SoC related driver updates for v3.12. The
only thing this cycle are core PM updates and CPUidle support for
ARM's TC2 big.LITTLE development platform.
Conflicts:
One cleanup/reorg conflict with a new entry in
drivers/cpuidle/Makefile. Append the new entry after the existing
ones. A follow up patch for v3.12-rc will make the new entry conform
to the cleanup/reorg.
----------------------------------------------------------------
The following changes since commit e5c832d5558826cc6e9a24746cfdec8e7780063a:
vfs: fix dentry RCU to refcounting possibly sleeping dput()
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers-for-linus
for you to fetch changes up to 158a71f83800f07c0da0f0159d2670bdf4bdd852:
Merge tag 'msi-3.12' of git://git.infradead.org/linux-mvebu into next/drivers
----------------------------------------------------------------
Lorenzo Pieralisi (2):
ARM: vexpress: tc2: disable GIC CPU IF in tc2_pm_suspend
cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
Nicolas Pitre (1):
drivers: irq-chip: irq-gic: introduce gic_cpu_if_down()
Olof Johansson (2):
Merge branch 'cpuidle/biglittle' into next/drivers
Merge tag 'msi-3.12' of git://git.infradead.org/linux-mvebu into next/drivers
MAINTAINERS | 9 ++
arch/arm/mach-vexpress/tc2_pm.c | 2 +
drivers/cpuidle/Kconfig | 10 ++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-big_little.c | 209 ++++++++++++++++++++++++++++++
drivers/irqchip/irq-gic.c | 6 +
include/linux/irqchip/arm-gic.h | 1 +
7 files changed, 238 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-big_little.c
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 1/3] ARM: SoC drivers for v3.12
@ 2013-09-09 22:42 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: linux-arm-kernel
This branch contains ARM SoC related driver updates for v3.12. The
only thing this cycle are core PM updates and CPUidle support for
ARM's TC2 big.LITTLE development platform.
Conflicts:
One cleanup/reorg conflict with a new entry in
drivers/cpuidle/Makefile. Append the new entry after the existing
ones. A follow up patch for v3.12-rc will make the new entry conform
to the cleanup/reorg.
----------------------------------------------------------------
The following changes since commit e5c832d5558826cc6e9a24746cfdec8e7780063a:
vfs: fix dentry RCU to refcounting possibly sleeping dput()
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers-for-linus
for you to fetch changes up to 158a71f83800f07c0da0f0159d2670bdf4bdd852:
Merge tag 'msi-3.12' of git://git.infradead.org/linux-mvebu into next/drivers
----------------------------------------------------------------
Lorenzo Pieralisi (2):
ARM: vexpress: tc2: disable GIC CPU IF in tc2_pm_suspend
cpuidle: big.LITTLE: vexpress-TC2 CPU idle driver
Nicolas Pitre (1):
drivers: irq-chip: irq-gic: introduce gic_cpu_if_down()
Olof Johansson (2):
Merge branch 'cpuidle/biglittle' into next/drivers
Merge tag 'msi-3.12' of git://git.infradead.org/linux-mvebu into next/drivers
MAINTAINERS | 9 ++
arch/arm/mach-vexpress/tc2_pm.c | 2 +
drivers/cpuidle/Kconfig | 10 ++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-big_little.c | 209 ++++++++++++++++++++++++++++++
drivers/irqchip/irq-gic.c | 6 +
include/linux/irqchip/arm-gic.h | 1 +
7 files changed, 238 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-big_little.c
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 2/3] ARM: Renesas SoC cleanup, refactoring and more SMP support
2013-09-09 22:42 ` Kevin Hilman
@ 2013-09-09 22:42 ` Kevin Hilman
-1 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: arm, linux-arm-kernel, linux-kernel
Lots of cleanup and refactoring and some SMP additions for Renesas
platforms. Due to some inter-dependencies with other arm-soc
branches, this Renesas stuff was separated out for sending after the
other branches were merged.
Highlights:
- remove unused board support and cleanup of unused headers
- refactoring of init and device registration
- simplify IRQ initialization
Conflicts: Too many. Most of these are because Simon chose to send
some board updates through the V4L tree that ends up colliding with
the main platform changes. We'll work with him on sorting out his
workflow:
arch/arm/boot/dts/r8a7740.dtsi:
- Add/add conflict in a devicetree file (keep both)
arch/arm/mach-shmobile/Makefile:
- Splitting out of clock files collides with intc move to DT.
Keep HEAD version but remove intc-* files for R8A7740 and R8A7779.
arch/arm/mach-shmobile/board-bockw.c:
- Keep HEAD but remove i2c, hspi and mmc device init calls
arch/arm/mach-shmobile/board-marzen.c
- Remove mach/hardware.h include and r8a7779_add_usb_phy_device() call,
everything else stays.
arch/arm/mach-shmobile/include/mach/r8a7778.h:
- From HEAD, Keep camera-rcar.h include and r8a7778_add_vin_device()
- From branch, keep everything
arch/arm/mach-shmobile/include/mach/r8a7779.h:
- From HEAD, Keep only camera-rcar.h include and r8a7779_add_vin_device()
arch/arm/mach-shmobile/setup-r8a7778.c
- Keep HEAD, but drop the MMC section (struct resource + add_mmc_device())
- take the new function name from our side (r8a7778_add_dt_devices())
arch/arm/mach-shmobile/setup-r8a7779.c
- Keep HEAD, but drop r8a7779_add_usb_phy_device()
I've also pushed a test-merge2 branch where you can see how I resolved
them.
----------------------------------------------------------------
The following changes since commit b41cfc8c3745f729393af57400377997b484701c:
Merge tag 'drivers-for-linus' into test-merge2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/renesas-for-linus
for you to fetch changes up to 25475030ec0e2c4c05f3ecb2c068f6e42944fd04:
Merge tag 'renesas-smp-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/renesas
----------------------------------------------------------------
Guennadi Liakhovetski (3):
ARM: shmobile: ape6evm: add DT reference
ARM: shmobile: ape6evm-reference: add CPUFreq support
ARM: shmobile: ape6evm-reference: switch PFC to DT
Kuninori Morimoto (16):
ARM: shmobile: bockw: add DT reference
ARM: shmobile: r8a7779: cleanup registration of usb phy
ARM: shmobile: armadillo800eva: Use DT for GIC
ARM: shmobile: marzen: Use DT for GIC
ARM: shmobile: r8a7778: cleanup registration of mmcif
ARM: shmobile: r8a7778: cleanup registration of usb phy
ARM: shmobile: r8a7778: cleanup registration of sdhi
ARM: shmobile: r8a7778: cleanup registration of i2c
ARM: shmobile: r8a7778: cleanup registration of hspi
ARM: shmobile: r8a7779: add missing __initdata
ARM: shmobile: r8a7790: add missing __initdata
ARM: shmobile: bockw: add missing __initdata
ARM: shmobile: r8a7740: move r8a7740_init_irq_of() to setup
ARM: shmobile: r8a7779: move r8a7779_init_irq_xxx() to setup
ARM: shmobile: armadillo800eva: remove nfsroot settings from bootargs
ARM: shmobile: kzm9d: remove nfsroot settings from bootargs
Laurent Pinchart (4):
ARM: shmobile: lager-reference: Add LED6-LED8 to the device tree
ARM: shmobile: Mount root file systems in r/w mode for all DT platforms
ARM: shmobile: r8a7740: Add TPU node to the device tree
ARM: shmobile: sh73a0: Remove global GPIO_NR definition
Lee Jones (1):
ARM: shmobile: r8a7779: Remove '0x's from R8A7779 DTS file
Magnus Damm (38):
ARM: shmobile: Minor update for the Lager DT reference code
ARM: shmobile: Remove sh73a0 use of <mach/hardware.h>
ARM: shmobile: Remove sh7372 use of <mach/hardware.h>
ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
ARM: shmobile: Remove r8a7779 use of <mach/hardware.h>
ARM: shmobile: Remove Marzen use of <mach/hardware.h>
ARM: shmobile: Remove include <mach/hardware.h>
ARM: shmobile: r8a73a4: Remove ->init_machine() special case
ARM: shmobile: Use pm-rmobile on sh7372 and r8a7740 only
ARM: shmobile: No need to use INTC demux on r8a7740
ARM: shmobile: No need to use INTC header on r8a7779
ARM: shmobile: sh73a0: Rely on DT for SMP CPU info
ARM: shmobile: marzen: Switch to DT_MACHINE_START
ARM: shmobile: r8a7740: add PMU information to r8a7740.dtsi
ARM: shmobile: sh73a0: add PMU information to sh73a0.dtsi
ARM: shmobile: emev2: add PMU information to emev2.dtsi
ARM: shmobile: Use default ->init_time() on r8a73a4
ARM: shmobile: Use default ->init_time() on r8a7740
ARM: shmobile: Use default ->init_time() on r8a7778
ARM: shmobile: Use default ->init_time() on r8a7779
ARM: shmobile: Use default ->init_time() on Bockw
ARM: shmobile: Use default ->init_time() on Bockw DT ref
ARM: shmobile: Use default ->init_time() on Armadillo DT ref
ARM: shmobile: Use default ->init_time() on APE6EVM
ARM: shmobile: Use default ->init_time() on APE6EVM DT ref
ARM: shmobile: Use default ->init_time() on Marzen DT ref
ARM: shmobile: Use default ->init_time() on KZM9G DT ref
ARM: shmobile: Use clocksource_of_init() on r8a7790
ARM: shmobile: Remove unused shmobile_init_time()
ARM: shmobile: Introduce shared SCU SMP boot code
ARM: shmobile: Use shared SCU SMP boot code on sh73a0
ARM: shmobile: Use shared SCU SMP boot code on r8a7779
ARM: shmobile: Use shared SCU SMP boot code on emev2
ARM: shmobile: Add shared SCU CPU Hotplug code
ARM: shmobile: Use shared SCU CPU Hotplug code on sh73a0
ARM: shmobile: Use shared SCU CPU Hotplug code on r8a7779
ARM: shmobile: Introduce per-CPU SMP boot / sleep code
ARM: shmobile: Per-CPU SMP boot / sleep code for SCU SoCs
Olof Johansson (3):
Merge tag 'renesas-cleanup2-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Merge tag 'renesas-cleanup3-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Merge tag 'renesas-smp-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Simon Horman (8):
ARM: shmobile: lager: Add DT reference
Merge branches 'tpu-pwm', 'backlight' and 'soc' into cleanup2-base
ARCH: ARM: shmobile: Remove kota2 board support
ARCH: ARM: shmobile: Remove ag5evm board support
ARM: shmobile: marzen: Add r8a7779-marzen.dtb
ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
ARM: shmobile: lager: enable nfsroot in DTS
Merge branch 'dt2' into cleanup3-base
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/emev2-kzm9d-reference.dts | 2 +-
arch/arm/boot/dts/emev2-kzm9d.dts | 2 +-
arch/arm/boot/dts/emev2.dtsi | 6 +
arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts | 65 ++
arch/arm/boot/dts/r8a73a4-ape6evm.dts | 2 +-
.../dts/r8a7740-armadillo800eva-reference.dts | 2 +-
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
arch/arm/boot/dts/r8a7740.dtsi | 12 +
arch/arm/boot/dts/r8a7778-bockw-reference.dts | 32 +
arch/arm/boot/dts/r8a7778-bockw.dts | 2 +-
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 2 +-
arch/arm/boot/dts/r8a7779-marzen.dts | 27 +
arch/arm/boot/dts/r8a7779.dtsi | 8 +-
arch/arm/boot/dts/r8a7790-lager-reference.dts | 45 ++
arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 2 +-
arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
arch/arm/boot/dts/sh73a0.dtsi | 6 +
arch/arm/configs/ag5evm_defconfig | 83 ---
arch/arm/configs/kota2_defconfig | 121 ----
arch/arm/mach-shmobile/Kconfig | 50 +-
arch/arm/mach-shmobile/Makefile | 23 +-
arch/arm/mach-shmobile/Makefile.boot | 5 +-
arch/arm/mach-shmobile/board-ag5evm.c | 639 -------------------
.../arm/mach-shmobile/board-ape6evm-reference.c | 63 ++
arch/arm/mach-shmobile/board-ape6evm.c | 1 -
.../board-armadillo800eva-reference.c | 1 -
arch/arm/mach-shmobile/board-armadillo800eva.c | 2 +-
arch/arm/mach-shmobile/board-bockw-reference.c | 61 ++
arch/arm/mach-shmobile/board-bockw.c | 49 +-
arch/arm/mach-shmobile/board-kota2.c | 550 ----------------
arch/arm/mach-shmobile/board-kzm9g-reference.c | 1 -
arch/arm/mach-shmobile/board-kzm9g.c | 16 +-
arch/arm/mach-shmobile/board-lager-reference.c | 45 ++
arch/arm/mach-shmobile/board-marzen-reference.c | 1 -
arch/arm/mach-shmobile/board-marzen.c | 36 +-
arch/arm/mach-shmobile/headsmp.S | 49 ++
arch/arm/mach-shmobile/include/mach/common.h | 10 +-
arch/arm/mach-shmobile/include/mach/hardware.h | 4 -
arch/arm/mach-shmobile/include/mach/r8a73a4.h | 1 +
arch/arm/mach-shmobile/include/mach/r8a7740.h | 1 -
arch/arm/mach-shmobile/include/mach/r8a7778.h | 9 +-
arch/arm/mach-shmobile/include/mach/r8a7779.h | 3 -
arch/arm/mach-shmobile/include/mach/r8a7790.h | 1 +
arch/arm/mach-shmobile/include/mach/sh73a0.h | 2 -
arch/arm/mach-shmobile/intc-r8a7740.c | 68 --
arch/arm/mach-shmobile/intc-r8a7779.c | 131 ----
arch/arm/mach-shmobile/platsmp-scu.c | 81 +++
arch/arm/mach-shmobile/platsmp.c | 18 +
arch/arm/mach-shmobile/setup-emev2.c | 1 -
arch/arm/mach-shmobile/setup-r8a73a4.c | 16 +-
arch/arm/mach-shmobile/setup-r8a7740.c | 33 +-
arch/arm/mach-shmobile/setup-r8a7778.c | 71 +--
arch/arm/mach-shmobile/setup-r8a7779.c | 102 ++-
arch/arm/mach-shmobile/setup-r8a7790.c | 16 +-
arch/arm/mach-shmobile/setup-sh7372.c | 1 -
arch/arm/mach-shmobile/setup-sh73a0.c | 1 -
arch/arm/mach-shmobile/smp-emev2.c | 19 +-
arch/arm/mach-shmobile/smp-r8a7779.c | 70 +-
arch/arm/mach-shmobile/smp-sh73a0.c | 72 +--
arch/arm/mach-shmobile/timer.c | 4 -
62 files changed, 856 insertions(+), 1900 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts
create mode 100644 arch/arm/boot/dts/r8a7778-bockw-reference.dts
create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts
create mode 100644 arch/arm/boot/dts/r8a7790-lager-reference.dts
delete mode 100644 arch/arm/configs/ag5evm_defconfig
delete mode 100644 arch/arm/configs/kota2_defconfig
delete mode 100644 arch/arm/mach-shmobile/board-ag5evm.c
create mode 100644 arch/arm/mach-shmobile/board-ape6evm-reference.c
create mode 100644 arch/arm/mach-shmobile/board-bockw-reference.c
delete mode 100644 arch/arm/mach-shmobile/board-kota2.c
create mode 100644 arch/arm/mach-shmobile/board-lager-reference.c
delete mode 100644 arch/arm/mach-shmobile/include/mach/hardware.h
delete mode 100644 arch/arm/mach-shmobile/intc-r8a7740.c
delete mode 100644 arch/arm/mach-shmobile/intc-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/platsmp-scu.c
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 2/3] ARM: Renesas SoC cleanup, refactoring and more SMP support
@ 2013-09-09 22:42 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: linux-arm-kernel
Lots of cleanup and refactoring and some SMP additions for Renesas
platforms. Due to some inter-dependencies with other arm-soc
branches, this Renesas stuff was separated out for sending after the
other branches were merged.
Highlights:
- remove unused board support and cleanup of unused headers
- refactoring of init and device registration
- simplify IRQ initialization
Conflicts: Too many. Most of these are because Simon chose to send
some board updates through the V4L tree that ends up colliding with
the main platform changes. We'll work with him on sorting out his
workflow:
arch/arm/boot/dts/r8a7740.dtsi:
- Add/add conflict in a devicetree file (keep both)
arch/arm/mach-shmobile/Makefile:
- Splitting out of clock files collides with intc move to DT.
Keep HEAD version but remove intc-* files for R8A7740 and R8A7779.
arch/arm/mach-shmobile/board-bockw.c:
- Keep HEAD but remove i2c, hspi and mmc device init calls
arch/arm/mach-shmobile/board-marzen.c
- Remove mach/hardware.h include and r8a7779_add_usb_phy_device() call,
everything else stays.
arch/arm/mach-shmobile/include/mach/r8a7778.h:
- From HEAD, Keep camera-rcar.h include and r8a7778_add_vin_device()
- From branch, keep everything
arch/arm/mach-shmobile/include/mach/r8a7779.h:
- From HEAD, Keep only camera-rcar.h include and r8a7779_add_vin_device()
arch/arm/mach-shmobile/setup-r8a7778.c
- Keep HEAD, but drop the MMC section (struct resource + add_mmc_device())
- take the new function name from our side (r8a7778_add_dt_devices())
arch/arm/mach-shmobile/setup-r8a7779.c
- Keep HEAD, but drop r8a7779_add_usb_phy_device()
I've also pushed a test-merge2 branch where you can see how I resolved
them.
----------------------------------------------------------------
The following changes since commit b41cfc8c3745f729393af57400377997b484701c:
Merge tag 'drivers-for-linus' into test-merge2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/renesas-for-linus
for you to fetch changes up to 25475030ec0e2c4c05f3ecb2c068f6e42944fd04:
Merge tag 'renesas-smp-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/renesas
----------------------------------------------------------------
Guennadi Liakhovetski (3):
ARM: shmobile: ape6evm: add DT reference
ARM: shmobile: ape6evm-reference: add CPUFreq support
ARM: shmobile: ape6evm-reference: switch PFC to DT
Kuninori Morimoto (16):
ARM: shmobile: bockw: add DT reference
ARM: shmobile: r8a7779: cleanup registration of usb phy
ARM: shmobile: armadillo800eva: Use DT for GIC
ARM: shmobile: marzen: Use DT for GIC
ARM: shmobile: r8a7778: cleanup registration of mmcif
ARM: shmobile: r8a7778: cleanup registration of usb phy
ARM: shmobile: r8a7778: cleanup registration of sdhi
ARM: shmobile: r8a7778: cleanup registration of i2c
ARM: shmobile: r8a7778: cleanup registration of hspi
ARM: shmobile: r8a7779: add missing __initdata
ARM: shmobile: r8a7790: add missing __initdata
ARM: shmobile: bockw: add missing __initdata
ARM: shmobile: r8a7740: move r8a7740_init_irq_of() to setup
ARM: shmobile: r8a7779: move r8a7779_init_irq_xxx() to setup
ARM: shmobile: armadillo800eva: remove nfsroot settings from bootargs
ARM: shmobile: kzm9d: remove nfsroot settings from bootargs
Laurent Pinchart (4):
ARM: shmobile: lager-reference: Add LED6-LED8 to the device tree
ARM: shmobile: Mount root file systems in r/w mode for all DT platforms
ARM: shmobile: r8a7740: Add TPU node to the device tree
ARM: shmobile: sh73a0: Remove global GPIO_NR definition
Lee Jones (1):
ARM: shmobile: r8a7779: Remove '0x's from R8A7779 DTS file
Magnus Damm (38):
ARM: shmobile: Minor update for the Lager DT reference code
ARM: shmobile: Remove sh73a0 use of <mach/hardware.h>
ARM: shmobile: Remove sh7372 use of <mach/hardware.h>
ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
ARM: shmobile: Remove r8a7779 use of <mach/hardware.h>
ARM: shmobile: Remove Marzen use of <mach/hardware.h>
ARM: shmobile: Remove include <mach/hardware.h>
ARM: shmobile: r8a73a4: Remove ->init_machine() special case
ARM: shmobile: Use pm-rmobile on sh7372 and r8a7740 only
ARM: shmobile: No need to use INTC demux on r8a7740
ARM: shmobile: No need to use INTC header on r8a7779
ARM: shmobile: sh73a0: Rely on DT for SMP CPU info
ARM: shmobile: marzen: Switch to DT_MACHINE_START
ARM: shmobile: r8a7740: add PMU information to r8a7740.dtsi
ARM: shmobile: sh73a0: add PMU information to sh73a0.dtsi
ARM: shmobile: emev2: add PMU information to emev2.dtsi
ARM: shmobile: Use default ->init_time() on r8a73a4
ARM: shmobile: Use default ->init_time() on r8a7740
ARM: shmobile: Use default ->init_time() on r8a7778
ARM: shmobile: Use default ->init_time() on r8a7779
ARM: shmobile: Use default ->init_time() on Bockw
ARM: shmobile: Use default ->init_time() on Bockw DT ref
ARM: shmobile: Use default ->init_time() on Armadillo DT ref
ARM: shmobile: Use default ->init_time() on APE6EVM
ARM: shmobile: Use default ->init_time() on APE6EVM DT ref
ARM: shmobile: Use default ->init_time() on Marzen DT ref
ARM: shmobile: Use default ->init_time() on KZM9G DT ref
ARM: shmobile: Use clocksource_of_init() on r8a7790
ARM: shmobile: Remove unused shmobile_init_time()
ARM: shmobile: Introduce shared SCU SMP boot code
ARM: shmobile: Use shared SCU SMP boot code on sh73a0
ARM: shmobile: Use shared SCU SMP boot code on r8a7779
ARM: shmobile: Use shared SCU SMP boot code on emev2
ARM: shmobile: Add shared SCU CPU Hotplug code
ARM: shmobile: Use shared SCU CPU Hotplug code on sh73a0
ARM: shmobile: Use shared SCU CPU Hotplug code on r8a7779
ARM: shmobile: Introduce per-CPU SMP boot / sleep code
ARM: shmobile: Per-CPU SMP boot / sleep code for SCU SoCs
Olof Johansson (3):
Merge tag 'renesas-cleanup2-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Merge tag 'renesas-cleanup3-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Merge tag 'renesas-smp-for-v3.12' of git://git.kernel.org/.../horms/renesas into next/renesas
Simon Horman (8):
ARM: shmobile: lager: Add DT reference
Merge branches 'tpu-pwm', 'backlight' and 'soc' into cleanup2-base
ARCH: ARM: shmobile: Remove kota2 board support
ARCH: ARM: shmobile: Remove ag5evm board support
ARM: shmobile: marzen: Add r8a7779-marzen.dtb
ARM: shmobile: r8a7779: Rely on DT for SMP CPU info
ARM: shmobile: lager: enable nfsroot in DTS
Merge branch 'dt2' into cleanup3-base
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/emev2-kzm9d-reference.dts | 2 +-
arch/arm/boot/dts/emev2-kzm9d.dts | 2 +-
arch/arm/boot/dts/emev2.dtsi | 6 +
arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts | 65 ++
arch/arm/boot/dts/r8a73a4-ape6evm.dts | 2 +-
.../dts/r8a7740-armadillo800eva-reference.dts | 2 +-
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
arch/arm/boot/dts/r8a7740.dtsi | 12 +
arch/arm/boot/dts/r8a7778-bockw-reference.dts | 32 +
arch/arm/boot/dts/r8a7778-bockw.dts | 2 +-
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 2 +-
arch/arm/boot/dts/r8a7779-marzen.dts | 27 +
arch/arm/boot/dts/r8a7779.dtsi | 8 +-
arch/arm/boot/dts/r8a7790-lager-reference.dts | 45 ++
arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
arch/arm/boot/dts/sh73a0-kzm9g-reference.dts | 2 +-
arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
arch/arm/boot/dts/sh73a0.dtsi | 6 +
arch/arm/configs/ag5evm_defconfig | 83 ---
arch/arm/configs/kota2_defconfig | 121 ----
arch/arm/mach-shmobile/Kconfig | 50 +-
arch/arm/mach-shmobile/Makefile | 23 +-
arch/arm/mach-shmobile/Makefile.boot | 5 +-
arch/arm/mach-shmobile/board-ag5evm.c | 639 -------------------
.../arm/mach-shmobile/board-ape6evm-reference.c | 63 ++
arch/arm/mach-shmobile/board-ape6evm.c | 1 -
.../board-armadillo800eva-reference.c | 1 -
arch/arm/mach-shmobile/board-armadillo800eva.c | 2 +-
arch/arm/mach-shmobile/board-bockw-reference.c | 61 ++
arch/arm/mach-shmobile/board-bockw.c | 49 +-
arch/arm/mach-shmobile/board-kota2.c | 550 ----------------
arch/arm/mach-shmobile/board-kzm9g-reference.c | 1 -
arch/arm/mach-shmobile/board-kzm9g.c | 16 +-
arch/arm/mach-shmobile/board-lager-reference.c | 45 ++
arch/arm/mach-shmobile/board-marzen-reference.c | 1 -
arch/arm/mach-shmobile/board-marzen.c | 36 +-
arch/arm/mach-shmobile/headsmp.S | 49 ++
arch/arm/mach-shmobile/include/mach/common.h | 10 +-
arch/arm/mach-shmobile/include/mach/hardware.h | 4 -
arch/arm/mach-shmobile/include/mach/r8a73a4.h | 1 +
arch/arm/mach-shmobile/include/mach/r8a7740.h | 1 -
arch/arm/mach-shmobile/include/mach/r8a7778.h | 9 +-
arch/arm/mach-shmobile/include/mach/r8a7779.h | 3 -
arch/arm/mach-shmobile/include/mach/r8a7790.h | 1 +
arch/arm/mach-shmobile/include/mach/sh73a0.h | 2 -
arch/arm/mach-shmobile/intc-r8a7740.c | 68 --
arch/arm/mach-shmobile/intc-r8a7779.c | 131 ----
arch/arm/mach-shmobile/platsmp-scu.c | 81 +++
arch/arm/mach-shmobile/platsmp.c | 18 +
arch/arm/mach-shmobile/setup-emev2.c | 1 -
arch/arm/mach-shmobile/setup-r8a73a4.c | 16 +-
arch/arm/mach-shmobile/setup-r8a7740.c | 33 +-
arch/arm/mach-shmobile/setup-r8a7778.c | 71 +--
arch/arm/mach-shmobile/setup-r8a7779.c | 102 ++-
arch/arm/mach-shmobile/setup-r8a7790.c | 16 +-
arch/arm/mach-shmobile/setup-sh7372.c | 1 -
arch/arm/mach-shmobile/setup-sh73a0.c | 1 -
arch/arm/mach-shmobile/smp-emev2.c | 19 +-
arch/arm/mach-shmobile/smp-r8a7779.c | 70 +-
arch/arm/mach-shmobile/smp-sh73a0.c | 72 +--
arch/arm/mach-shmobile/timer.c | 4 -
62 files changed, 856 insertions(+), 1900 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a73a4-ape6evm-reference.dts
create mode 100644 arch/arm/boot/dts/r8a7778-bockw-reference.dts
create mode 100644 arch/arm/boot/dts/r8a7779-marzen.dts
create mode 100644 arch/arm/boot/dts/r8a7790-lager-reference.dts
delete mode 100644 arch/arm/configs/ag5evm_defconfig
delete mode 100644 arch/arm/configs/kota2_defconfig
delete mode 100644 arch/arm/mach-shmobile/board-ag5evm.c
create mode 100644 arch/arm/mach-shmobile/board-ape6evm-reference.c
create mode 100644 arch/arm/mach-shmobile/board-bockw-reference.c
delete mode 100644 arch/arm/mach-shmobile/board-kota2.c
create mode 100644 arch/arm/mach-shmobile/board-lager-reference.c
delete mode 100644 arch/arm/mach-shmobile/include/mach/hardware.h
delete mode 100644 arch/arm/mach-shmobile/intc-r8a7740.c
delete mode 100644 arch/arm/mach-shmobile/intc-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/platsmp-scu.c
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 3/3] ARM: SoC late changes for v3.12
2013-09-09 22:42 ` Kevin Hilman
@ 2013-09-09 22:42 ` Kevin Hilman
-1 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: arm, linux-arm-kernel, linux-kernel
These are changes that arrived a little late before the merge window,
or had dependencies on previous branches.
Highlights:
- ux500: misc. cleanup, fixup I2C devices
- exynos: DT updates for RTC; PM updates
- at91: DT updates for NAND; new platforms added to generic defconfig
- sunxi: DT updates: cubieboard2, pinctrl driver, gated clocks
- highbank: LPAE fixes, select necessary ARM errata
- omap: PM fixes and improvements; OMAP5 mailbox support
- omap: basic support for new DRA7xx SoCs
----------------------------------------------------------------
The following changes since commit 5d96cd70c979a7b93d8a4806c91a1af329833a64:
Merge tag 'renesas-for-linus' into test-merge2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/late-for-linus
for you to fetch changes up to a2bdc32a527e817fdfa6c56eaa6c70f217da6c6c:
ARM: dts: vexpress: Add CCI node to TC2 device-tree
----------------------------------------------------------------
Aida Mynzhasova (1):
ARM: OMAP: TI81XX: add always-on powerdomain for TI81XX
Ambresh K (7):
ARM: OMAP: DRA7: PRM: Add DRA7XX register definitions
ARM: OMAP: DRA7: CM: Add DRA7XX register defines
ARM: OMAP: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
ARM: OMAP: DRA7: clockdomain: Add DRA7XX data and update header
ARM: OMAP: DRA7: powerdomain: Add DRA7XX data and update header
ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data
ARM: OMAP: DRA7: Enable PM framework initializations
Amit Daniel Kachhap (2):
ARM: EXYNOS: enable ARCH_HAS_BANDGAP
ARM: EXYNOS: Skip C1 cpuidle state for exynos5440
Andre Przywara (2):
DMA: fix AMBA PL08x compilation issue with 64bit DMA address type
DMA: fix printk warning in AMBA PL08x DMA driver
Bartlomiej Zolnierkiewicz (1):
ARM: EXYNOS: always enable PM domains support for EXYNOS4X12
Bo Shen (4):
ARM: at91: sama5d3: add definition for usart base address
ARM: at91: include sama5d3.h into hardware.h
ARM: at91: sama5: enable kernel uncompress info output
ARM: at91: sam9n12: enable kernel uncompress info output
Haojian Zhuang (4):
irqchip: move mmp irq driver
irqchip: mmp: support irqchip
ARM: mmp: avoid to include head file in mach-mmp
irqchip: mmp: avoid to include irqs head file
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: at91_dt_defconfig: enable rm9200 support
Jon Hunter (1):
ARM: OMAP2+: Only write the sysconfig on idle when necessary
Jon Medhurst (Tixy) (1):
ARM: dts: vexpress: Add CCI node to TC2 device-tree
Josh Wu (3):
ARM: at91/dt: sama5d3xek: remove the useless NFC dt parameters
ARM: at91/dt: sama5d3xek: Enable NFC support in dts
ARM: at91/dt: sama5d3xek: reduce the ROM code mapping for pmecc lookup table
Julia Lawall (1):
arch/arm/mach-ux500/cpu-db8500.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
Linus Walleij (2):
ARM: ux500: delete oldschool pin defines
ARM: ux500: fix up the I2C devices
Lokesh Vutla (1):
ARM: OMAP: AM33xx: clock: Add RNG clock data
Maxime Ripard (11):
ARM: sunxi: dt: Add PIO controller to A31 DTSI
ARM: sun6i: Add UART0 muxing options
ARM: sun6i: colombus: Add uart0 muxing
ARM: sun7i: Add the PIO controller node to the DTSI
ARM: sun7i: DT: Add UART muxing options to the DTSI
ARM: sun7i: a20-olinuxino: Enable UARTs muxing
ARM: sun7i: a20-olinuxino: Enable the user LED
ARM: sun7i: Add Cubieboard2 Device Tree
ARM: sun5i: dt: Use the A10s gates in the DTSI
ARM: sun6i: Enable clock support in the DTSI
ARM: sun7i: Enable the A20 clocks in the DTSI
Naveen Krishna Chatradhi (1):
ARM: dts: add ADC device tree node for exynos5420/5250
Olof Johansson (10):
Merge tag 'ux500-core-for-arm-soc-2' of git://git.kernel.org/.../linusw/linux-stericsson into late/all
Merge tag 'mmp-irq' of git://git.kernel.org/.../hzhuang1/linux into late/all
Merge tag 'samsung-dt-2' of git://git.kernel.org/.../kgene/linux-samsung into late/all
Merge tag 'samsung-mach-exynos-v2' of git://git.kernel.org/.../kgene/linux-samsung into late/all
Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into late/all
Merge tag 'sunxi-dt-for-3.12-4' of https://github.com/mripard/linux into late/all
Merge tag 'at91-soc' of git://github.com/at91linux/linux-at91 into late/all
Merge tag 'highbank-for-3.12' of git://sources.calxeda.com/kernel/linux into late/all
Merge tag 'omap-for-v3.12/prcm-signed' of git://git.kernel.org/.../tmlind/linux-omap into late/all
Merge tag 'omap-for-v3.12/dra7xx-prcm' of git://git.kernel.org/.../tmlind/linux-omap into late/all
Paul Walmsley (1):
Merge branches 'hwmod_devel_v3.12', 'prcm_devel_v3.12' and 'am33xx_devel_v3.12' into prcm_a_for_v3.12
Rajendra Nayak (4):
ARM: OMAP: DRA7: CM: Add minimal regbit shifts
ARM: OMAP: DRA7: powerdomain: Handle missing vc/vp
ARM: OMAP: DRA7: Reuse the omap44xx_restart and fix the device instance
ARM: OMAP4: clock: Lock PLLs in the right sequence
Rob Herring (8):
ARM: use phys_addr_t for DMA zone sizes
ARM: highbank: enable DMA zone for LPAE
ARM: highbank: select ARCH_HAS_HOLES_MEMORYMODEL
ARM: highbank: select required errata work-arounds
ARM: highbank: select ARCH_DMA_ADDR_T_64BIT for LPAE
ARM: move outer_cache declaration out of ifdef
ARM: highbank: avoid L2 cache smc calls when PL310 is not present
ARM: highbank: clean-up some unused includes
Suman Anna (1):
ARM: OMAP5: hwmod data: Add mailbox data
Tony Lindgren (2):
Merge tag 'for-v3.12/dra7xx' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.12/soc
Merge tag 'for-v3.12/omap-prcm-hwmod' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.12/prcm
Vaibhav Hiremath (1):
ARM: OMAP: AM33XX: hwmod: Add hwmod data for debugSS
Vikas Sajjan (3):
ARM: dts: Fix the RTC DT node name for Exynos5250
ARM: dts: Update the "status" property of RTC DT node for Exynos5250 SoC
ARM: dts: Add RTC DT node to Exynos5420 SoC
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 4 -
arch/arm/boot/dts/exynos5250-snow.dts | 4 -
arch/arm/boot/dts/exynos5250.dtsi | 14 +-
arch/arm/boot/dts/exynos5420.dtsi | 17 +
arch/arm/boot/dts/sama5d3.dtsi | 19 +-
arch/arm/boot/dts/sama5d3xcm.dtsi | 2 -
arch/arm/boot/dts/sun5i-a10s.dtsi | 36 +-
arch/arm/boot/dts/sun6i-a31-colombus.dts | 2 +
arch/arm/boot/dts/sun6i-a31.dtsi | 161 +-
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 53 +
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +
arch/arm/boot/dts/sun7i-a20.dtsi | 157 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 25 +
arch/arm/configs/at91_dt_defconfig | 4 +-
arch/arm/include/asm/mach/arch.h | 2 +-
arch/arm/include/asm/outercache.h | 4 +-
arch/arm/mach-at91/include/mach/hardware.h | 1 +
arch/arm/mach-at91/include/mach/sama5d3.h | 8 +
arch/arm/mach-at91/include/mach/uncompress.h | 13 +
arch/arm/mach-exynos/Kconfig | 7 +
arch/arm/mach-exynos/cpuidle.c | 3 +
arch/arm/mach-highbank/Kconfig | 6 +
arch/arm/mach-highbank/highbank.c | 20 +-
arch/arm/mach-mmp/Makefile | 2 +-
arch/arm/mach-mmp/common.h | 1 -
arch/arm/mach-mmp/include/mach/entry-macro.S | 26 -
arch/arm/mach-mmp/include/mach/pxa168.h | 1 +
arch/arm/mach-mmp/include/mach/pxa910.h | 1 +
arch/arm/mach-mmp/mmp-dt.c | 8 +-
arch/arm/mach-mmp/mmp2-dt.c | 8 +-
arch/arm/mach-mmp/mmp2.c | 6 +
arch/arm/mach-mmp/pxa910.c | 7 +
arch/arm/mach-omap2/Makefile | 4 +
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/cclock33xx_data.c | 5 +
arch/arm/mach-omap2/cclock44xx_data.c | 20 +-
arch/arm/mach-omap2/clockdomain.h | 1 +
arch/arm/mach-omap2/clockdomains7xx_data.c | 740 +++++
arch/arm/mach-omap2/cm-regbits-7xx.h | 51 +
arch/arm/mach-omap2/cm1_7xx.h | 324 +++
arch/arm/mach-omap2/cm2_7xx.h | 513 ++++
arch/arm/mach-omap2/io.c | 5 +
arch/arm/mach-omap2/omap_hwmod.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 +-
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 42 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2724 ++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 1 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 8 +
arch/arm/mach-omap2/powerdomains7xx_data.c | 454 +++
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prcm44xx.h | 5 +
arch/arm/mach-omap2/prcm_mpu7xx.h | 78 +
arch/arm/mach-omap2/prm44xx.c | 12 +-
arch/arm/mach-omap2/prm7xx.h | 678 +++++
arch/arm/mach-omap2/prminst44xx.c | 20 +-
arch/arm/mach-ux500/board-mop500-audio.c | 1 -
arch/arm/mach-ux500/board-mop500-pins.c | 1 -
arch/arm/mach-ux500/board-mop500.c | 33 +-
arch/arm/mach-ux500/cpu-db8500.c | 3 +-
arch/arm/mach-ux500/pins-db8500.h | 746 -----
arch/arm/mm/init.c | 2 +-
drivers/dma/amba-pl08x.c | 23 +-
drivers/irqchip/Makefile | 1 +
.../mach-mmp/irq.c => drivers/irqchip/irq-mmp.c | 338 ++-
include/linux/irqchip/mmp.h | 6 +
69 files changed, 6486 insertions(+), 1082 deletions(-)
create mode 100644 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
delete mode 100644 arch/arm/mach-mmp/include/mach/entry-macro.S
create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c
create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h
create mode 100644 arch/arm/mach-omap2/cm1_7xx.h
create mode 100644 arch/arm/mach-omap2/cm2_7xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c
create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c
create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h
create mode 100644 arch/arm/mach-omap2/prm7xx.h
delete mode 100644 arch/arm/mach-ux500/pins-db8500.h
rename arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c (63%)
create mode 100644 include/linux/irqchip/mmp.h
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 3/3] ARM: SoC late changes for v3.12
@ 2013-09-09 22:42 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-09 22:42 UTC (permalink / raw)
To: linux-arm-kernel
These are changes that arrived a little late before the merge window,
or had dependencies on previous branches.
Highlights:
- ux500: misc. cleanup, fixup I2C devices
- exynos: DT updates for RTC; PM updates
- at91: DT updates for NAND; new platforms added to generic defconfig
- sunxi: DT updates: cubieboard2, pinctrl driver, gated clocks
- highbank: LPAE fixes, select necessary ARM errata
- omap: PM fixes and improvements; OMAP5 mailbox support
- omap: basic support for new DRA7xx SoCs
----------------------------------------------------------------
The following changes since commit 5d96cd70c979a7b93d8a4806c91a1af329833a64:
Merge tag 'renesas-for-linus' into test-merge2
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/late-for-linus
for you to fetch changes up to a2bdc32a527e817fdfa6c56eaa6c70f217da6c6c:
ARM: dts: vexpress: Add CCI node to TC2 device-tree
----------------------------------------------------------------
Aida Mynzhasova (1):
ARM: OMAP: TI81XX: add always-on powerdomain for TI81XX
Ambresh K (7):
ARM: OMAP: DRA7: PRM: Add DRA7XX register definitions
ARM: OMAP: DRA7: CM: Add DRA7XX register defines
ARM: OMAP: DRA7: PRCM: Add DRA7XX local MPU PRCM regsiters
ARM: OMAP: DRA7: clockdomain: Add DRA7XX data and update header
ARM: OMAP: DRA7: powerdomain: Add DRA7XX data and update header
ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data
ARM: OMAP: DRA7: Enable PM framework initializations
Amit Daniel Kachhap (2):
ARM: EXYNOS: enable ARCH_HAS_BANDGAP
ARM: EXYNOS: Skip C1 cpuidle state for exynos5440
Andre Przywara (2):
DMA: fix AMBA PL08x compilation issue with 64bit DMA address type
DMA: fix printk warning in AMBA PL08x DMA driver
Bartlomiej Zolnierkiewicz (1):
ARM: EXYNOS: always enable PM domains support for EXYNOS4X12
Bo Shen (4):
ARM: at91: sama5d3: add definition for usart base address
ARM: at91: include sama5d3.h into hardware.h
ARM: at91: sama5: enable kernel uncompress info output
ARM: at91: sam9n12: enable kernel uncompress info output
Haojian Zhuang (4):
irqchip: move mmp irq driver
irqchip: mmp: support irqchip
ARM: mmp: avoid to include head file in mach-mmp
irqchip: mmp: avoid to include irqs head file
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: at91_dt_defconfig: enable rm9200 support
Jon Hunter (1):
ARM: OMAP2+: Only write the sysconfig on idle when necessary
Jon Medhurst (Tixy) (1):
ARM: dts: vexpress: Add CCI node to TC2 device-tree
Josh Wu (3):
ARM: at91/dt: sama5d3xek: remove the useless NFC dt parameters
ARM: at91/dt: sama5d3xek: Enable NFC support in dts
ARM: at91/dt: sama5d3xek: reduce the ROM code mapping for pmecc lookup table
Julia Lawall (1):
arch/arm/mach-ux500/cpu-db8500.c: Avoid using ARRAY_AND_SIZE(e) as a function argument
Linus Walleij (2):
ARM: ux500: delete oldschool pin defines
ARM: ux500: fix up the I2C devices
Lokesh Vutla (1):
ARM: OMAP: AM33xx: clock: Add RNG clock data
Maxime Ripard (11):
ARM: sunxi: dt: Add PIO controller to A31 DTSI
ARM: sun6i: Add UART0 muxing options
ARM: sun6i: colombus: Add uart0 muxing
ARM: sun7i: Add the PIO controller node to the DTSI
ARM: sun7i: DT: Add UART muxing options to the DTSI
ARM: sun7i: a20-olinuxino: Enable UARTs muxing
ARM: sun7i: a20-olinuxino: Enable the user LED
ARM: sun7i: Add Cubieboard2 Device Tree
ARM: sun5i: dt: Use the A10s gates in the DTSI
ARM: sun6i: Enable clock support in the DTSI
ARM: sun7i: Enable the A20 clocks in the DTSI
Naveen Krishna Chatradhi (1):
ARM: dts: add ADC device tree node for exynos5420/5250
Olof Johansson (10):
Merge tag 'ux500-core-for-arm-soc-2' of git://git.kernel.org/.../linusw/linux-stericsson into late/all
Merge tag 'mmp-irq' of git://git.kernel.org/.../hzhuang1/linux into late/all
Merge tag 'samsung-dt-2' of git://git.kernel.org/.../kgene/linux-samsung into late/all
Merge tag 'samsung-mach-exynos-v2' of git://git.kernel.org/.../kgene/linux-samsung into late/all
Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into late/all
Merge tag 'sunxi-dt-for-3.12-4' of https://github.com/mripard/linux into late/all
Merge tag 'at91-soc' of git://github.com/at91linux/linux-at91 into late/all
Merge tag 'highbank-for-3.12' of git://sources.calxeda.com/kernel/linux into late/all
Merge tag 'omap-for-v3.12/prcm-signed' of git://git.kernel.org/.../tmlind/linux-omap into late/all
Merge tag 'omap-for-v3.12/dra7xx-prcm' of git://git.kernel.org/.../tmlind/linux-omap into late/all
Paul Walmsley (1):
Merge branches 'hwmod_devel_v3.12', 'prcm_devel_v3.12' and 'am33xx_devel_v3.12' into prcm_a_for_v3.12
Rajendra Nayak (4):
ARM: OMAP: DRA7: CM: Add minimal regbit shifts
ARM: OMAP: DRA7: powerdomain: Handle missing vc/vp
ARM: OMAP: DRA7: Reuse the omap44xx_restart and fix the device instance
ARM: OMAP4: clock: Lock PLLs in the right sequence
Rob Herring (8):
ARM: use phys_addr_t for DMA zone sizes
ARM: highbank: enable DMA zone for LPAE
ARM: highbank: select ARCH_HAS_HOLES_MEMORYMODEL
ARM: highbank: select required errata work-arounds
ARM: highbank: select ARCH_DMA_ADDR_T_64BIT for LPAE
ARM: move outer_cache declaration out of ifdef
ARM: highbank: avoid L2 cache smc calls when PL310 is not present
ARM: highbank: clean-up some unused includes
Suman Anna (1):
ARM: OMAP5: hwmod data: Add mailbox data
Tony Lindgren (2):
Merge tag 'for-v3.12/dra7xx' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.12/soc
Merge tag 'for-v3.12/omap-prcm-hwmod' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.12/prcm
Vaibhav Hiremath (1):
ARM: OMAP: AM33XX: hwmod: Add hwmod data for debugSS
Vikas Sajjan (3):
ARM: dts: Fix the RTC DT node name for Exynos5250
ARM: dts: Update the "status" property of RTC DT node for Exynos5250 SoC
ARM: dts: Add RTC DT node to Exynos5420 SoC
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos5.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-arndale.dts | 4 -
arch/arm/boot/dts/exynos5250-snow.dts | 4 -
arch/arm/boot/dts/exynos5250.dtsi | 14 +-
arch/arm/boot/dts/exynos5420.dtsi | 17 +
arch/arm/boot/dts/sama5d3.dtsi | 19 +-
arch/arm/boot/dts/sama5d3xcm.dtsi | 2 -
arch/arm/boot/dts/sun5i-a10s.dtsi | 36 +-
arch/arm/boot/dts/sun6i-a31-colombus.dts | 2 +
arch/arm/boot/dts/sun6i-a31.dtsi | 161 +-
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 53 +
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +
arch/arm/boot/dts/sun7i-a20.dtsi | 157 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 25 +
arch/arm/configs/at91_dt_defconfig | 4 +-
arch/arm/include/asm/mach/arch.h | 2 +-
arch/arm/include/asm/outercache.h | 4 +-
arch/arm/mach-at91/include/mach/hardware.h | 1 +
arch/arm/mach-at91/include/mach/sama5d3.h | 8 +
arch/arm/mach-at91/include/mach/uncompress.h | 13 +
arch/arm/mach-exynos/Kconfig | 7 +
arch/arm/mach-exynos/cpuidle.c | 3 +
arch/arm/mach-highbank/Kconfig | 6 +
arch/arm/mach-highbank/highbank.c | 20 +-
arch/arm/mach-mmp/Makefile | 2 +-
arch/arm/mach-mmp/common.h | 1 -
arch/arm/mach-mmp/include/mach/entry-macro.S | 26 -
arch/arm/mach-mmp/include/mach/pxa168.h | 1 +
arch/arm/mach-mmp/include/mach/pxa910.h | 1 +
arch/arm/mach-mmp/mmp-dt.c | 8 +-
arch/arm/mach-mmp/mmp2-dt.c | 8 +-
arch/arm/mach-mmp/mmp2.c | 6 +
arch/arm/mach-mmp/pxa910.c | 7 +
arch/arm/mach-omap2/Makefile | 4 +
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/cclock33xx_data.c | 5 +
arch/arm/mach-omap2/cclock44xx_data.c | 20 +-
arch/arm/mach-omap2/clockdomain.h | 1 +
arch/arm/mach-omap2/clockdomains7xx_data.c | 740 +++++
arch/arm/mach-omap2/cm-regbits-7xx.h | 51 +
arch/arm/mach-omap2/cm1_7xx.h | 324 +++
arch/arm/mach-omap2/cm2_7xx.h | 513 ++++
arch/arm/mach-omap2/io.c | 5 +
arch/arm/mach-omap2/omap_hwmod.c | 4 +-
arch/arm/mach-omap2/omap_hwmod.h | 1 +
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 +-
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 42 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2724 ++++++++++++++++++
arch/arm/mach-omap2/powerdomain.h | 1 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 8 +
arch/arm/mach-omap2/powerdomains7xx_data.c | 454 +++
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prcm44xx.h | 5 +
arch/arm/mach-omap2/prcm_mpu7xx.h | 78 +
arch/arm/mach-omap2/prm44xx.c | 12 +-
arch/arm/mach-omap2/prm7xx.h | 678 +++++
arch/arm/mach-omap2/prminst44xx.c | 20 +-
arch/arm/mach-ux500/board-mop500-audio.c | 1 -
arch/arm/mach-ux500/board-mop500-pins.c | 1 -
arch/arm/mach-ux500/board-mop500.c | 33 +-
arch/arm/mach-ux500/cpu-db8500.c | 3 +-
arch/arm/mach-ux500/pins-db8500.h | 746 -----
arch/arm/mm/init.c | 2 +-
drivers/dma/amba-pl08x.c | 23 +-
drivers/irqchip/Makefile | 1 +
.../mach-mmp/irq.c => drivers/irqchip/irq-mmp.c | 338 ++-
include/linux/irqchip/mmp.h | 6 +
69 files changed, 6486 insertions(+), 1082 deletions(-)
create mode 100644 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
delete mode 100644 arch/arm/mach-mmp/include/mach/entry-macro.S
create mode 100644 arch/arm/mach-omap2/clockdomains7xx_data.c
create mode 100644 arch/arm/mach-omap2/cm-regbits-7xx.h
create mode 100644 arch/arm/mach-omap2/cm1_7xx.h
create mode 100644 arch/arm/mach-omap2/cm2_7xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c
create mode 100644 arch/arm/mach-omap2/powerdomains7xx_data.c
create mode 100644 arch/arm/mach-omap2/prcm_mpu7xx.h
create mode 100644 arch/arm/mach-omap2/prm7xx.h
delete mode 100644 arch/arm/mach-ux500/pins-db8500.h
rename arch/arm/mach-mmp/irq.c => drivers/irqchip/irq-mmp.c (63%)
create mode 100644 include/linux/irqchip/mmp.h
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-09 22:42 ` Kevin Hilman
@ 2013-09-09 23:49 ` Linus Torvalds
-1 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-09 23:49 UTC (permalink / raw)
To: Kevin Hilman; +Cc: ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
>
> The main thing of note (or of potential annoyance factor) here is the
> handful of conflicts in PULL 2/3 coming from platform changes
> conflicting with driver changes going in to the V4L tree. I've listed
> them in detail in that pull request, and we will work with the
> platform maintainer on the workflow to avoid this in the future.
Ok. I still really despise the absolute incredible sh*t that is
non-discoverable buses, and I hope that ARM SoC hardware designers all
die in some incredibly painful accident. DT only does so much.
So if you see any, send them my love, and possibly puncture the
brake-lines on their car and put a little surprise in their coffee,
ok?
> For future reference, when it comes to these conflicts, do you want to
> see a summary of the suggested resolutions, a published branch with
> the resolutions, both or neither? Just curious.
I'll basically always end up re-doing the conflict resolution by hand
anyway unless it's just *incredibly* messy (and I think that has
happened all of once or twice), so anything you send me ends up being
just confirmation.
In this case, for example, I didn't end up looking at your pre-merged
stuff, because the summaries were enough for me to just say "ok, that
confirms my resolution". In other cases, people don't write detailed
summaries, and I end up confirming my resolution by just doing a
separate test-merge against their pre-merged branch and comparing.
And in most cases, the resolution is trivial enough that I don't
bother with either.
And in *all* cases I appreciate it when people do the preparation. It
hopefully also makes submaintainers themselves more aware of
development flow conflicts and more aware of possible problem issues
(same reason I prefer doing all the resolutions by hand myself), so I
suspect all of this is healthy even if I don't end up using it.
Final note: putting the conflict resolution explanation in the tag
message is unnecessary, since it's not really worth it after-the-fact
- so I'll just edit it away. It's not a problem, but in general I'd
suggest the tag message just contain the "here's the highlights", and
you do the conflict resolution notes just in the email. But I suspect
you may find the use of the tags a convenient way to jot down the
resolution for then sending the email later, and it's not like it
hurts me to edit it away afterwards, so not a big deal. Whatever works
for you.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-09 23:49 ` Linus Torvalds
0 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-09 23:49 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
>
> The main thing of note (or of potential annoyance factor) here is the
> handful of conflicts in PULL 2/3 coming from platform changes
> conflicting with driver changes going in to the V4L tree. I've listed
> them in detail in that pull request, and we will work with the
> platform maintainer on the workflow to avoid this in the future.
Ok. I still really despise the absolute incredible sh*t that is
non-discoverable buses, and I hope that ARM SoC hardware designers all
die in some incredibly painful accident. DT only does so much.
So if you see any, send them my love, and possibly puncture the
brake-lines on their car and put a little surprise in their coffee,
ok?
> For future reference, when it comes to these conflicts, do you want to
> see a summary of the suggested resolutions, a published branch with
> the resolutions, both or neither? Just curious.
I'll basically always end up re-doing the conflict resolution by hand
anyway unless it's just *incredibly* messy (and I think that has
happened all of once or twice), so anything you send me ends up being
just confirmation.
In this case, for example, I didn't end up looking at your pre-merged
stuff, because the summaries were enough for me to just say "ok, that
confirms my resolution". In other cases, people don't write detailed
summaries, and I end up confirming my resolution by just doing a
separate test-merge against their pre-merged branch and comparing.
And in most cases, the resolution is trivial enough that I don't
bother with either.
And in *all* cases I appreciate it when people do the preparation. It
hopefully also makes submaintainers themselves more aware of
development flow conflicts and more aware of possible problem issues
(same reason I prefer doing all the resolutions by hand myself), so I
suspect all of this is healthy even if I don't end up using it.
Final note: putting the conflict resolution explanation in the tag
message is unnecessary, since it's not really worth it after-the-fact
- so I'll just edit it away. It's not a problem, but in general I'd
suggest the tag message just contain the "here's the highlights", and
you do the conflict resolution notes just in the email. But I suspect
you may find the use of the tags a convenient way to jot down the
resolution for then sending the email later, and it's not like it
hurts me to edit it away afterwards, so not a big deal. Whatever works
for you.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-09 23:49 ` Linus Torvalds
@ 2013-09-10 0:04 ` NeilBrown
-1 siblings, 0 replies; 24+ messages in thread
From: NeilBrown @ 2013-09-10 0:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kevin Hilman, ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Mon, 9 Sep 2013 16:49:23 -0700 Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
> >
> > The main thing of note (or of potential annoyance factor) here is the
> > handful of conflicts in PULL 2/3 coming from platform changes
> > conflicting with driver changes going in to the V4L tree. I've listed
> > them in detail in that pull request, and we will work with the
> > platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
>
> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?
As you wish.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 0:04 ` NeilBrown
0 siblings, 0 replies; 24+ messages in thread
From: NeilBrown @ 2013-09-10 0:04 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 9 Sep 2013 16:49:23 -0700 Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
> >
> > The main thing of note (or of potential annoyance factor) here is the
> > handful of conflicts in PULL 2/3 coming from platform changes
> > conflicting with driver changes going in to the V4L tree. I've listed
> > them in detail in that pull request, and we will work with the
> > platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
>
> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?
As you wish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130910/a4eeff4c/attachment-0001.sig>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-09 23:49 ` Linus Torvalds
@ 2013-09-10 0:06 ` Kevin Hilman
-1 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-10 0:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>
>> The main thing of note (or of potential annoyance factor) here is the
>> handful of conflicts in PULL 2/3 coming from platform changes
>> conflicting with driver changes going in to the V4L tree. I've listed
>> them in detail in that pull request, and we will work with the
>> platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
In case it helps you feel slightly better... in what some might call a
painful accident (though probably not the kind you'd like to see), most
of the designers I used to work with (at TI) were laid off in the last
year.
> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?
Got it. I'll be sure to send your love.
>> For future reference, when it comes to these conflicts, do you want to
>> see a summary of the suggested resolutions, a published branch with
>> the resolutions, both or neither? Just curious.
>
> I'll basically always end up re-doing the conflict resolution by hand
> anyway unless it's just *incredibly* messy (and I think that has
> happened all of once or twice), so anything you send me ends up being
> just confirmation.
>
> In this case, for example, I didn't end up looking at your pre-merged
> stuff, because the summaries were enough for me to just say "ok, that
> confirms my resolution". In other cases, people don't write detailed
> summaries, and I end up confirming my resolution by just doing a
> separate test-merge against their pre-merged branch and comparing.
>
> And in most cases, the resolution is trivial enough that I don't
> bother with either.
>
> And in *all* cases I appreciate it when people do the preparation. It
> hopefully also makes submaintainers themselves more aware of
> development flow conflicts and more aware of possible problem issues
> (same reason I prefer doing all the resolutions by hand myself), so I
> suspect all of this is healthy even if I don't end up using it.
OK, thanks for the feedback.
> Final note: putting the conflict resolution explanation in the tag
> message is unnecessary, since it's not really worth it after-the-fact
> - so I'll just edit it away. It's not a problem, but in general I'd
> suggest the tag message just contain the "here's the highlights", and
> you do the conflict resolution notes just in the email. But I suspect
> you may find the use of the tags a convenient way to jot down the
> resolution for then sending the email later, and it's not like it
> hurts me to edit it away afterwards, so not a big deal. Whatever works
> for you.
Noted, thanks.
Kevin
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 0:06 ` Kevin Hilman
0 siblings, 0 replies; 24+ messages in thread
From: Kevin Hilman @ 2013-09-10 0:06 UTC (permalink / raw)
To: linux-arm-kernel
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>
>> The main thing of note (or of potential annoyance factor) here is the
>> handful of conflicts in PULL 2/3 coming from platform changes
>> conflicting with driver changes going in to the V4L tree. I've listed
>> them in detail in that pull request, and we will work with the
>> platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
In case it helps you feel slightly better... in what some might call a
painful accident (though probably not the kind you'd like to see), most
of the designers I used to work with (at TI) were laid off in the last
year.
> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?
Got it. I'll be sure to send your love.
>> For future reference, when it comes to these conflicts, do you want to
>> see a summary of the suggested resolutions, a published branch with
>> the resolutions, both or neither? Just curious.
>
> I'll basically always end up re-doing the conflict resolution by hand
> anyway unless it's just *incredibly* messy (and I think that has
> happened all of once or twice), so anything you send me ends up being
> just confirmation.
>
> In this case, for example, I didn't end up looking at your pre-merged
> stuff, because the summaries were enough for me to just say "ok, that
> confirms my resolution". In other cases, people don't write detailed
> summaries, and I end up confirming my resolution by just doing a
> separate test-merge against their pre-merged branch and comparing.
>
> And in most cases, the resolution is trivial enough that I don't
> bother with either.
>
> And in *all* cases I appreciate it when people do the preparation. It
> hopefully also makes submaintainers themselves more aware of
> development flow conflicts and more aware of possible problem issues
> (same reason I prefer doing all the resolutions by hand myself), so I
> suspect all of this is healthy even if I don't end up using it.
OK, thanks for the feedback.
> Final note: putting the conflict resolution explanation in the tag
> message is unnecessary, since it's not really worth it after-the-fact
> - so I'll just edit it away. It's not a problem, but in general I'd
> suggest the tag message just contain the "here's the highlights", and
> you do the conflict resolution notes just in the email. But I suspect
> you may find the use of the tags a convenient way to jot down the
> resolution for then sending the email later, and it's not like it
> hurts me to edit it away afterwards, so not a big deal. Whatever works
> for you.
Noted, thanks.
Kevin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-09 23:49 ` Linus Torvalds
@ 2013-09-10 15:05 ` David Woodhouse
-1 siblings, 0 replies; 24+ messages in thread
From: David Woodhouse @ 2013-09-10 15:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kevin Hilman, ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
Setting aside the inevitable whining from the emotionally-incontinent
contingent that the above way of saying it will provoke, I'm not quite
sure why you still haven't got over the fact that we have
non-discoverable buses.
In cost-sensitive products (and what *isn't* cost-sensitive these days),
you really don't want to have to put an extra EEPROM on the board
somewhere, just to describe what devices you've hung off which
chip-select today. Storing that in the main flash is just *going* to
happen, however much we'd like to think that devices should identify
themselves cleanly and autonomously.
And it isn't even something that a simple number like a PCI ID could
manage. Peripherals are synthesisable components which vary *wildly*,
with what are essentially #ifdefs in the VHDL. So a given controller
could be seen with different FIFO depths, different numbers of queues,
all kinds of variations. To cover the various permutations, you'd have
to assign an *insane* number of PCI IDs. And then there's the various
ways that you can connect blocks *together*...
That's why we end up with the device-tree model which gives us a rich
way to describe *this* instance of the hardware. If it wasn't
device-tree, it'd have to be something *else*.
From a software point of view it *isn't* nice, I agree. But you might as
well be railing against the sunset, as far as I can tell.
Not that any of this excuses crappy merges with lots of conflicts; but
those don't seem to be an inexorable result of non-discoverable buses.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 15:05 ` David Woodhouse
0 siblings, 0 replies; 24+ messages in thread
From: David Woodhouse @ 2013-09-10 15:05 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
Setting aside the inevitable whining from the emotionally-incontinent
contingent that the above way of saying it will provoke, I'm not quite
sure why you still haven't got over the fact that we have
non-discoverable buses.
In cost-sensitive products (and what *isn't* cost-sensitive these days),
you really don't want to have to put an extra EEPROM on the board
somewhere, just to describe what devices you've hung off which
chip-select today. Storing that in the main flash is just *going* to
happen, however much we'd like to think that devices should identify
themselves cleanly and autonomously.
And it isn't even something that a simple number like a PCI ID could
manage. Peripherals are synthesisable components which vary *wildly*,
with what are essentially #ifdefs in the VHDL. So a given controller
could be seen with different FIFO depths, different numbers of queues,
all kinds of variations. To cover the various permutations, you'd have
to assign an *insane* number of PCI IDs. And then there's the various
ways that you can connect blocks *together*...
That's why we end up with the device-tree model which gives us a rich
way to describe *this* instance of the hardware. If it wasn't
device-tree, it'd have to be something *else*.
>From a software point of view it *isn't* nice, I agree. But you might as
well be railing against the sunset, as far as I can tell.
Not that any of this excuses crappy merges with lots of conflicts; but
those don't seem to be an inexorable result of non-discoverable buses.
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130910/dbeab541/attachment-0001.bin>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-10 15:05 ` David Woodhouse
@ 2013-09-10 15:31 ` Linus Torvalds
-1 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-10 15:31 UTC (permalink / raw)
To: David Woodhouse
Cc: Kevin Hilman, ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> In cost-sensitive products (and what *isn't* cost-sensitive these days),
> you really don't want to have to put an extra EEPROM on the board
> somewhere
Don't be silly. Nobody wants an extra chip. Especially not one that is
programmable separately from the hardware. That way lies madness and
the usual firmware crazies.
It's not even what I asked for. I talked about discoverable buses. How
hard is that to understand? No extra chips, no eeprom, just a bus with
a notion of configuration cycles. It doesn't even have to be as
complicated as PCI, it could easily be a read-only model.
But no, every SoC designer out there seems to want to make their
hardware crap. Don't be surprised when I then call them out on the
fact. And don't bring up totally irrelevant issues that have nothing
to do with anything.
Is there a cost? Yes, it's a cost of good design and effort to try to
get it right. Usually that cost pays itself back over the years.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 15:31 ` Linus Torvalds
0 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-10 15:31 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> In cost-sensitive products (and what *isn't* cost-sensitive these days),
> you really don't want to have to put an extra EEPROM on the board
> somewhere
Don't be silly. Nobody wants an extra chip. Especially not one that is
programmable separately from the hardware. That way lies madness and
the usual firmware crazies.
It's not even what I asked for. I talked about discoverable buses. How
hard is that to understand? No extra chips, no eeprom, just a bus with
a notion of configuration cycles. It doesn't even have to be as
complicated as PCI, it could easily be a read-only model.
But no, every SoC designer out there seems to want to make their
hardware crap. Don't be surprised when I then call them out on the
fact. And don't bring up totally irrelevant issues that have nothing
to do with anything.
Is there a cost? Yes, it's a cost of good design and effort to try to
get it right. Usually that cost pays itself back over the years.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-10 15:31 ` Linus Torvalds
@ 2013-09-10 15:43 ` Stephen Warren
-1 siblings, 0 replies; 24+ messages in thread
From: Stephen Warren @ 2013-09-10 15:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Kevin Hilman, ARM SoC, linux-arm-kernel,
Linux Kernel Mailing List
On 09/10/2013 09:31 AM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>
>> In cost-sensitive products (and what *isn't* cost-sensitive these days),
>> you really don't want to have to put an extra EEPROM on the board
>> somewhere
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware. That way lies madness and
> the usual firmware crazies.
>
> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.
>
> But no, every SoC designer out there seems to want to make their
> hardware crap. Don't be surprised when I then call them out on the
> fact. And don't bring up totally irrelevant issues that have nothing
> to do with anything.
(Many of) the buses aren't something that ARM SoC designers invented
though; they're industry standard things like I2C, SPI, I2S, all of
which are supported by SoC manufacturers solely because there are huge
numbers of useful chips that attach to these buses, from many many
manufacturers. This is an industry issue, not some evil conspiracy by
ARM SoC vendors.
True, it'd be lovely if those standard buses were discoverable; if the
industry had ended up with more advanced buses (although again: cost, to
implement those features, even if embedded into the chip itself rather
than as an external component).
Now, there are certainly cases where everybody just does their own silly
thing in HW, such as using GPIOs from a separate GPIO controller for SD
card detect and write-protect signals, rather than having the SDHCI
controller handle those functions, and hence be standalone. So from that
perspective your point is justified. However, solving this aspect would
only solve part of the problem.
x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
LM90 thermal sensors. However, I /think/ this all gets hidden from the
OS by ACPI or other firmware mechanisms. Do you prefer firmware
abstraction over DT?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 15:43 ` Stephen Warren
0 siblings, 0 replies; 24+ messages in thread
From: Stephen Warren @ 2013-09-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
On 09/10/2013 09:31 AM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>
>> In cost-sensitive products (and what *isn't* cost-sensitive these days),
>> you really don't want to have to put an extra EEPROM on the board
>> somewhere
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware. That way lies madness and
> the usual firmware crazies.
>
> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.
>
> But no, every SoC designer out there seems to want to make their
> hardware crap. Don't be surprised when I then call them out on the
> fact. And don't bring up totally irrelevant issues that have nothing
> to do with anything.
(Many of) the buses aren't something that ARM SoC designers invented
though; they're industry standard things like I2C, SPI, I2S, all of
which are supported by SoC manufacturers solely because there are huge
numbers of useful chips that attach to these buses, from many many
manufacturers. This is an industry issue, not some evil conspiracy by
ARM SoC vendors.
True, it'd be lovely if those standard buses were discoverable; if the
industry had ended up with more advanced buses (although again: cost, to
implement those features, even if embedded into the chip itself rather
than as an external component).
Now, there are certainly cases where everybody just does their own silly
thing in HW, such as using GPIOs from a separate GPIO controller for SD
card detect and write-protect signals, rather than having the SDHCI
controller handle those functions, and hence be standalone. So from that
perspective your point is justified. However, solving this aspect would
only solve part of the problem.
x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
LM90 thermal sensors. However, I /think/ this all gets hidden from the
OS by ACPI or other firmware mechanisms. Do you prefer firmware
abstraction over DT?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-10 15:43 ` Stephen Warren
@ 2013-09-10 15:56 ` Linus Torvalds
-1 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-10 15:56 UTC (permalink / raw)
To: Stephen Warren
Cc: David Woodhouse, Kevin Hilman, ARM SoC, linux-arm-kernel,
Linux Kernel Mailing List
On Tue, Sep 10, 2013 at 8:43 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
> LM90 thermal sensors. However, I /think/ this all gets hidden from the
> OS by ACPI or other firmware mechanisms. Do you prefer firmware
> abstraction over DT?
If there was a standard one, I would actually prefer it. Just not the
insanity of ACPI with pseudo-executable code, just plain read-only
tables. The fact that there isn't any unification in the ARM market
makes bad design decisions _worse_.
So yes, the same mess exists on PC's too (sound in particular tends to
be a morass of just basically crazy "this is wired up so-and-so"), but
on PCs you end up having the advantage of (a) more stuff is
discoverable and (b) a long-time standard platform so the stuff that
isn't is much less bad. ARM doesn't have that (and it's basically
impossible to create a standard in that space), and as a result
absolutely _everything_ is one-off, which just exacerbates the
problem.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 15:56 ` Linus Torvalds
0 siblings, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2013-09-10 15:56 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 10, 2013 at 8:43 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
> LM90 thermal sensors. However, I /think/ this all gets hidden from the
> OS by ACPI or other firmware mechanisms. Do you prefer firmware
> abstraction over DT?
If there was a standard one, I would actually prefer it. Just not the
insanity of ACPI with pseudo-executable code, just plain read-only
tables. The fact that there isn't any unification in the ARM market
makes bad design decisions _worse_.
So yes, the same mess exists on PC's too (sound in particular tends to
be a morass of just basically crazy "this is wired up so-and-so"), but
on PCs you end up having the advantage of (a) more stuff is
discoverable and (b) a long-time standard platform so the stuff that
isn't is much less bad. ARM doesn't have that (and it's basically
impossible to create a standard in that space), and as a result
absolutely _everything_ is one-off, which just exacerbates the
problem.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
2013-09-10 15:31 ` Linus Torvalds
@ 2013-09-10 16:00 ` David Woodhouse
-1 siblings, 0 replies; 24+ messages in thread
From: David Woodhouse @ 2013-09-10 16:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kevin Hilman, ARM SoC, linux-arm-kernel, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]
On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.
But if I've got device <foo> attached to pin 15 of a GPIO controller
<bar>, surely that has to be programmed separately from the synthesis of
the two components <foo> and <bar>?
Yeah, if they really are all soft IP and we're *really* doing a whole
system on a single chip, we can do it all at the same time. But it isn't
always like that.
> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.
Setting aside the inter-component connections that are used to describe
a *board* rather than just a bag full of components, that's still far
from trivial to get right.
Let's assume you can take the same information we have in the
device-tree, and put it in the device itself to be accessed via
'configuration cycles'. Yes, you can certainly avoid having physically
separate EEPROMs for it.
But look at the abortion we've made ourselves of defining the 'bindings'
— the schemas which this extra information needs to conform to, in order
to support the full range of devices of a given type. That's where the
pain has *actually* been, and I suspect that's what's responsible for
the merge issues you were dealing with. Would that really be improved by
trying to force the various vendors of soft-IP peripherals do it
instead? Getting *them* to play along would be like herding cats... and
then they'd have to get their *customers*, who use their designs, to do
it right too in order for it to really work.
It's all very well saying "put it on the device and access it through
configuration cycles", but that doesn't actually address the part of the
problem that's been *most* problematic. If anything, I suspect it would
make it orders of magnitude worse.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12
@ 2013-09-10 16:00 ` David Woodhouse
0 siblings, 0 replies; 24+ messages in thread
From: David Woodhouse @ 2013-09-10 16:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.
But if I've got device <foo> attached to pin 15 of a GPIO controller
<bar>, surely that has to be programmed separately from the synthesis of
the two components <foo> and <bar>?
Yeah, if they really are all soft IP and we're *really* doing a whole
system on a single chip, we can do it all at the same time. But it isn't
always like that.
> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.
Setting aside the inter-component connections that are used to describe
a *board* rather than just a bag full of components, that's still far
from trivial to get right.
Let's assume you can take the same information we have in the
device-tree, and put it in the device itself to be accessed via
'configuration cycles'. Yes, you can certainly avoid having physically
separate EEPROMs for it.
But look at the abortion we've made ourselves of defining the 'bindings'
? the schemas which this extra information needs to conform to, in order
to support the full range of devices of a given type. That's where the
pain has *actually* been, and I suspect that's what's responsible for
the merge issues you were dealing with. Would that really be improved by
trying to force the various vendors of soft-IP peripherals do it
instead? Getting *them* to play along would be like herding cats... and
then they'd have to get their *customers*, who use their designs, to do
it right too in order for it to really work.
It's all very well saying "put it on the device and access it through
configuration cycles", but that doesn't actually address the part of the
problem that's been *most* problematic. If anything, I suspect it would
make it orders of magnitude worse.
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130910/b0b1eb5b/attachment.bin>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2013-09-10 16:01 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-09 22:42 [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 Kevin Hilman
2013-09-09 22:42 ` Kevin Hilman
2013-09-09 22:42 ` [GIT PULL 1/3] ARM: SoC drivers " Kevin Hilman
2013-09-09 22:42 ` Kevin Hilman
2013-09-09 22:42 ` [GIT PULL 2/3] ARM: Renesas SoC cleanup, refactoring and more SMP support Kevin Hilman
2013-09-09 22:42 ` Kevin Hilman
2013-09-09 22:42 ` [GIT PULL 3/3] ARM: SoC late changes for v3.12 Kevin Hilman
2013-09-09 22:42 ` Kevin Hilman
2013-09-09 23:49 ` [GIT PULL 0/3] ARM: SoC: Second round of " Linus Torvalds
2013-09-09 23:49 ` Linus Torvalds
2013-09-10 0:04 ` NeilBrown
2013-09-10 0:04 ` NeilBrown
2013-09-10 0:06 ` Kevin Hilman
2013-09-10 0:06 ` Kevin Hilman
2013-09-10 15:05 ` David Woodhouse
2013-09-10 15:05 ` David Woodhouse
2013-09-10 15:31 ` Linus Torvalds
2013-09-10 15:31 ` Linus Torvalds
2013-09-10 15:43 ` Stephen Warren
2013-09-10 15:43 ` Stephen Warren
2013-09-10 15:56 ` Linus Torvalds
2013-09-10 15:56 ` Linus Torvalds
2013-09-10 16:00 ` David Woodhouse
2013-09-10 16:00 ` David Woodhouse
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.