* [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 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 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: 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 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: 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 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: 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 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: 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 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: 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
* [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: 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 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: 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 0 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@lists.infradead.org, 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 @ 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: 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-10 0:04 ` NeilBrown 0 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@lists.infradead.org, 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-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: 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-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: Linus Torvalds Cc: ARM SoC, linux-arm-kernel@lists.infradead.org, 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-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: 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 0 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@lists.infradead.org, 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 @ 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: 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 0 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@lists.infradead.org, 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 @ 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: 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 0 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@lists.infradead.org, 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 @ 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: 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:56 ` Linus Torvalds 0 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@lists.infradead.org, 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: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: 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
* Re: [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: Linus Torvalds Cc: Kevin Hilman, ARM SoC, linux-arm-kernel@lists.infradead.org, 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
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.