linux/drivers/sh, branch v3.16

Merge tag 'renesas-sh-drivers-for-v3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next

2014-06-06T18:44:09Z

Pull SH driver update from Simon Horman: - PM Runtime enhancements targeted for use with ARM-based Renesas R-Car Gen2 SoCs - Restrict INTC_USERIMASK to SH4A as it is only used there * tag 'renesas-sh-drivers-for-v3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: drivers: sh: Enable PM runtime for new R-Car Gen2 SoCs drivers: sh: pm_runtime implementation needs to suspend and resume devices drivers: sh: Restrict INTC_USERIMASK to SH4A drivers: sh: pm_runtime does not need idle callback

drivers: sh: Enable PM runtime for new R-Car Gen2 SoCs

2014-06-05T00:50:11Z

The PM runtime code should also be enabled for: - r8a7792 (R-Car V2H) - r8a7793 (R-Car M2-N) - r8a7794 (R-Car E2) Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman

Merge branch 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into next

2014-06-04T22:59:13Z

Pull core irq updates from Thomas Gleixner: "The irq department delivers: - Another tree wide update to get rid of the horrible create_irq interface along with its even more horrible variants. That also gets rid of the last leftovers of the initial sparse irq hackery. arch/driver specific changes have been either acked or ignored. - A fix for the spurious interrupt detection logic with threaded interrupts. - A new ARM SoC interrupt controller - The usual pile of fixes and improvements all over the place" * 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (40 commits) Documentation: brcmstb-l2: Add Broadcom STB Level-2 interrupt controller binding irqchip: brcmstb-l2: Add Broadcom Set Top Box Level-2 interrupt controller genirq: Improve documentation to match current implementation ARM: iop13xx: fix msi support with sparse IRQ genirq: Provide !SMP stub for irq_set_affinity_notifier() irqchip: armada-370-xp: Move the devicetree binding documentation irqchip: gic: Use mask field in GICC_IAR genirq: Remove dynamic_irq mess ia64: Use irq_init_desc genirq: Replace dynamic_irq_init/cleanup genirq: Remove irq_reserve_irq[s] genirq: Replace reserve_irqs in core code s390: Avoid call to irq_reserve_irqs() s390: Remove pointless arch_show_interrupts() s390: pci: Check return value of alloc_irq_desc() proper sh: intc: Remove pointless irq_reserve_irqs() invocation x86, irq: Remove pointless irq_reserve_irqs() call genirq: Make create/destroy_irq() ia64 private tile: Use SPARSE_IRQ tile: pci: Use irq_alloc/free_hwirq() ...

Merge back earlier cpufreq material.

2014-06-03T13:03:27Z

Conflicts: arch/mips/loongson/lemote-2f/clock.c drivers/cpufreq/intel_pstate.c

drivers: sh: pm_runtime implementation needs to suspend and resume devices

2014-05-26T01:45:06Z

If we override the platform bus calls for pm_runtime then we end up with the calls to the devices' suspend and resume methods ignored in favour of the bus ones. Change to calling the pm_runtime calls to suspend and resume the devices specifically in the drivers/sh/pm_runtime.c implementation to allow any device that may want to run power management to do so. Note, all the current sh driver implementations do not use their own power management code so this is not a major implementation issues. This also brings the implementation into line with the versions used by the Davinci and Keystone PM domain code, so once fully tested these implementations could be merged together. Signed-off-by: Ben Dooks Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Simon Horman

drivers: sh: Restrict INTC_USERIMASK to SH4A

2014-05-26T01:45:02Z

register_intc_userimask() is called from sh4a code only. Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart [r8a7779 legacy] Signed-off-by: Simon Horman

drivers: sh: pm_runtime does not need idle callback

2014-05-26T01:44:54Z

In the runtime_pm idle callback the code assumes that a NULL .runtime_idle entry is the same as a .runtime_idle entry that returns 0 as a result. This means the entry in drivers/sh/pm_runtime can be removed in favour of just leaving the entry NULL. Signed-off-by: Ben Dooks Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart [r8a7779 legacy] Signed-off-by: Simon Horman

sh: intc: Remove pointless irq_reserve_irqs() invocation

2014-05-16T12:05:21Z

The preceding call to irq_create_identity_mapping() marks the interrupt as allocated already. Remove the leftover. Signed-off-by: Thomas Gleixner Reviewed-by: Grant Likely Cc: Tony Luck Cc: Peter Zijlstra Acked-by: Simon Horman Cc: linux-sh@vger.kernel.org Link: http://lkml.kernel.org/r/20140507154339.189047829@linutronix.de Signed-off-by: Thomas Gleixner

drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI

2014-05-12T07:05:01Z

If the kernel is built to support multi-ARM configuration with shmobile support built in, then drivers/sh is not built. This contains the PM runtime code in drivers/sh/pm_runtime.c, which implicitly enables the module clocks for all devices, and thus is quite essential. Without this, the state of clocks depends on implicit reset state, or on the bootloader. If ARCH_SHMOBILE_MULTI then build the drivers/sh directory, but ensure that bits that may conflict (drivers/sh/clk if the common clock framework is enabled) or are not used (drivers/sh/intc), are not built. Also, only enable the PM runtime code when actually running on a shmobile SoCs that needs it. ARCH_SHMOBILE_MULTI was added a while ago by commit efacfce5f8a523457e9419a25d52fe39db00b26a ("ARM: shmobile: Introduce ARCH_SHMOBILE_MULTI"), but drivers/sh was compiled for both ARCH_SHMOBILE_LEGACY and ARCH_SHMOBILE_MULTI until commit bf98c1eac1d4a6bcf00532e4fa41d8126cd6c187 ("ARM: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY"). Inspired by a patch from Ben Dooks . Signed-off-by: Geert Uytterhoeven Signed-off-by: Simon Horman

sh: clk: Use cpufreq_for_each_valid_entry macro for iteration

2014-04-29T22:07:00Z

The cpufreq core now supports the cpufreq_for_each_valid_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki