-
sunxi-clk-for-3.16-25c89a8b6 · ·
Rebase of Emilio's clk-sunxi-for-3.16 on top of clk-next Fixed a few compilation warnings exposed by a patch introduced during the 3.16 merge window. Original tag message: Allwinner sunXi SoCs clock changes This pull contains some new code to add support for A31 clocks by Maxime and Boris. It also reworks the driver a bit to avoid having a huge single file when we have a full folder for ourselves, and separating different functional units makes sense.
-
pinctrl-v3.16-129c7f1f5 · ·
This is the bulk of pin control changes for the v3.16 development cycle: - Antoine Tenart made the get_group_pins() vtable entry optional. - Antoine also provides an entirely new driver for the Marvell Berlin SoC. This is unrelated to the existing MVEBU hardware driver and warrants its own separate driver. - Reflected from the GPIO subsystem there is a number of refactorings to make pin control drivers with gpiochips use the new gpiolib irqchip helpers. The following drivers were converted to use the new infrastructure: - ST Microelectronics STiH416 and friends - The Atmel AT91 - The CSR SiRF (Prima2) - The Qualcomm MSM series - Massive improvements in the Qualcomm MSM driver from Bjorn Andersson, Andy Gross and Kumar Gala. Among those new support for the IPQ8064 and MSM8x74 SoC variants. - Support for the Freescale i.MX6 SoloX SoC variant. - Massive improvements in the Allwinner sunxi driver from Boris Brezillon, Maxime Ripard and Chen-Yu Tsai. - Renesas PFC updates from Laurent Pinchart, Kuninori Morimoto, Wolfram Sang and Magnus Damm. - Cleanups and refactorings of the nVidia Tegra driver from Stepgen Warren. - The Exynos driver now supports the Exynos3250 SoC. - Intel BayTrail updates from Jin Yao, Mika Westerberg. - The MVEBU driver now supports the Orion5x SoC variants, which is part of the effort of getting rid of the old Marvell kludges in arch/arm/mach-orion5x - Rockchip driver updates from Heiko Stuebner. - A ton of cleanups and janitorial patches from Axel Lin. - Some minor fixes and improvements here and there.
-
soc-for-3.16b5b9324a · ·
ARM: SoC updates for 3.16 (part 1) A quite large set of SoC updates this cycle. In no particular order: - Multi-cluster power management for Samsung Exynos, adding support for big.LITTLE CPU switching on EXYNOS5 - SMP support for Marvell Armada 375 and 38x - SMP rework on Allwinner A31 - Xilinx Zynq support for SOC_BUS, big endian - Marvell orion5x platform cleanup, modernizing the implementation and moving to DT. - _Finally_ moving Samsung Exynos over to support MULTIPLATFORM, so that their platform can be enabled in the same kernel binary as most of the other v7 platforms in the tree. \o/ The work isn't quite complete, there's some driver fixes still needed, but the basics now work. New SoC support added: - Freescale i.MX6SX - LSI Axxia AXM55xx SoCs - Samsung EXYNOS 3250, 5260, 5410, 5420 and 5800 - STi STIH407 Plus a large set of various smaller updates for different platforms. I'm probably missing some important one here.
-
drivers-for-3.1645e70b7d · ·
ARM: SoC driver changes SoC-near driver changes that we're merging through our tree. Mostly because they depend on other changes we have staged, but in some cases because the driver maintainers preferred that we did it this way. This contains a largeish cleanup series of the omap_l3_noc bus driver, cpuidle rework for Exynos, some reset driver conversions and a long branch of TI EDMA fixes and cleanups, with more to come next release. The TI EDMA cleanups is a shared branch with the dmaengine tree, with a handful of Davinci-specific fixes on top. After discussion at last year's KS (and some more on the mailing lists), we are here adding a drivers/soc directory. The purpose of this is to keep per-vendor shared code that's needed by different drivers but that doesn't fit into the MFD (nor drivers/platform) model. We expect to keep merging contents for this hierarchy through arm-soc so we can keep an eye on what the vendors keep adding here and not making it a free-for-all to shove in crazy stuff.
-
fixes-for-3.16da98f44f · ·
ARM: SoC low-priority fixes for 3.16 A small selection of fixes coming in late during the release cycle and not being critical enough for 3.15 inclusion.
-
dt-for-3.160f16aa3c · ·
ARM: SoC devicetree updates for 3.16 As with previous release, this continues to be among the largest branches we merge, with lots of new contents. New things for this release are among other things: - DTSI contents for the new SoCs supported in 3.16 (see SoC pull request) - Qualcomm APQ8064 and APQ8084 SoCs and eval boards - Nvidia Jetson TK1 development board (Tegra T124-based) Two new SoCs that didn't need enough new platform code to stand out enough for me to notice when writing the SoC tag, but that adds new DT contents are: - TI DRA72 - Marvell Berlin 2Q
-
defconfig-for-3.16c6ac4487 · ·
ARM: SoC defconfig updates for 3.16 A number of defconfig updates for 3.16. We have quite a few of these as new SoCs and drivers get supported, and we've started collecting them in one shared branch. We started halfway through the merge window so there'll be some small conflicts with other branches on nearby changes, but nothing major. Next cycle should be smoother.
-
cleanup-for-3.1608d38beb · ·
ARM: SoC cleanups for 3.16 Cleanups for 3.16. Among these are: - A bunch of misc cleanups for Broadcom platforms, mostly housekeeping - Enabling Common Clock Framework on the older s3c24xx Samsung chipsets - Cleanup of the Versatile Express system controller code, moving it to syscon - Power management cleanups for OMAP platforms + a handful of other cleanups across the place
-
gpio-v3.16-1fc346270 · ·
This is the bulk of GPIO changes for the v3.16 series: - We are finalizing and fixing up the gpiochip irqchip helpers bringing a helpful irqchip implementation into the gpiolib core and avoiding duplicate code and, more importantly, duplicate bug fixes: - Support for using the helpers with threaded interrupt handlers as used on sleeping GPIO-irqchips - Do not set up hardware triggers for edges or levels if the default IRQ type is IRQ_TYPE_NONE - some drivers would exploit the fact that you could get default initialization of the IRQ type from the core at probe() but if no default type is set up from the helper, we should not call the driver to configure anything. Wait until a consumer requests the interrupt instead. - Make the irqchip helpers put the GPIO irqs into their own lock class. The GPIO irqchips can often emit (harmless, but annoying) lockdep warnings about recursions when they are in fact just cascaded IRQs. By putting them into their own lock class we help the lockdep core to keep track of things. - Switch the tc3589x GPIO expanders to use the irqchip helpers - Switch the OMAP GPIO driver to use the irqchip helpers - Add some documentation for the irqchip helpers - select IRQ_DOMAIN when using the helpers since some platforms may not be using this by default and it's a strict dependency. - Continued GPIO descriptor refactoring: - Remove the one instance of gpio_to_desc() from the device tree code, making the OF GPIO code use GPIO descriptors only. - Introduce gpiod_get_optional() and gpiod_get_optional_index() akin to the similar regulator functions for cases where the use of GPIO is optional and not strictly required. - Make of_get_named_gpiod_flags() private - we do not want to unnecessarily expose APIs to drivers that make the gpiolib harder than necessary to maintain and refactor. Privatize this function. - Support "-gpio" suffix for the OF GPIO retrieveal path. We used to look for "foo-gpios" or just "gpios" in device tree nodes, but it turns out that some drivers with a single GPIO line will just state "foo-gpio" (singularis). Sigh. Support this with a fallback looking for it, as this simplifies driver code and handles it in core code. - Switch the ACPI GPIO core to fetch GPIOs with the *_cansleep function variants as the GPIO operation region handler can sleep, and shall be able to handle gpiochips that sleep. - Tons of cleanups and janitorial work from Jingoo Han, Axel Lin, Javier Martinez Canillas and Abdoulaye Berthe. Notably Jingoo cut off a ton of pointless OOM messages. - Incremental development and fixes for various drivers, nothing really special here.
-
mfd-omap-v3.16-143fef47f · ·
Second immutable branch between MFD and OMAP due for the v3.16 merge window.