- 03 Apr, 2015 3 commits
-
-
Olof Johansson authored
Merge tag 'renesas-soc-cleanup3-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/cleanup Merge "Third Round of Renesas ARM Based SoC Cleanup for v4.1" from Simon Horman: * Remove default cpuidle driver, it does not appear to serve any purpose * tag 'renesas-soc-cleanup3-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: cpuidle: Remove the pointless default driver Signed-off-by:
Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
Merge tag 'renesas-pm-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/cleanup Merge "Renesas ARM Based SoC PM Updates for v4.1" from Simon Horman: * Consolidate the pm code for R-Car Gen2 * Correct SYSCIER value for r8a7790 and r8a7791 SoCs * tag 'renesas-pm-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: Consolidate the pm code for R-Car Gen2 ARM: shmobile: r8a7791: Correct SYSCIER value ARM: shmobile: r8a7790: Correct SYSCIER value Signed-off-by:
-
Olof Johansson authored
Merge tag 'v4.1-legacy' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup Merge "omap legacy boot clean-up for v4.1" from Tony Lindgren: Drop three omap3 legacy board-*.c files We want to get omap3 moved over to device tree only based booting. These three board-*.c files seem to be inactive, so let's attempt to drop them now rather than later. With these dropped, we have omap3 device tree conversion status in a known state. Then we know that we have .dts support for the remaining omap3 board-*.c files, or it's being worked on. By dropping these files now, we can simply revert them if really needed for the next few merge cycles if we run into suprises. Reverting things later on will not be so easily done. * tag 'v4.1-legacy' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: Remove legacy support for omap3 TouchBook ARM: OMAP3: Remove legacy support for devkit8000 ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board Signed-off-by:
-
- 02 Apr, 2015 1 commit
-
-
Olof Johansson authored
Merge tag 'davinci-for-v4.1/mcasp' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/cleanup Merge "DaVinci McASP changes for v4.1" from Sekhar Nori: This pull request contains cleanups and non-urgent fixes for DaVinci McASP platform support code. * tag 'davinci-for-v4.1/mcasp' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: dm646x: Add interrupt resource for McASPs ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x ARM: davinci: dm646x: Clean up the McASP DMA resources ARM: davinci: devices-da8xx: Add support for McASP2 on da830 ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request Signed-off-by:
-
- 19 Mar, 2015 1 commit
-
-
Daniel Lezcano authored
The default idle driver uses one state with the WFI instruction. The default idle routine invokes WFI when no cpuidle driver is present. The default cpuidle driver is pointless and does not give more than the default idle routine and moreover it pulls all the mathematics tied with the cpuidle governor for nothing, hence consuming more energy. Remove the default driver, the related code and register the driver directly. [compiled only - no board - no test] Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au>
-
- 18 Mar, 2015 7 commits
-
-
Peter Ujfalusi authored
The interrupt can be used for error recovery. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com>
-
Peter Ujfalusi authored
McASP1 TX interrupt is 30, not 32 on DM646x DMSoC. While at it remove the bogus AEMIF interrupt entry from dm646x_default_priorities[]. AEMIF interrupt on DM6467 is 60 not 30 and the entry for the correct interrupt number is already present in the same table. Signed-off-by:
-
Peter Ujfalusi authored
Add names to the DMA resources and remove the RX DMA dummy part for McASP1. Signed-off-by:
-
Peter Ujfalusi authored
da830 has three McASP blocks. Signed-off-by:
-
Peter Ujfalusi authored
Both DA830 and DA850 has McASP0 module, so do not restrict the use of McASP0 for da850 only. Signed-off-by:
-
Peter Ujfalusi authored
On da8xx McASP TX/RX interrupt requests are combined. The interrupt can be used for error recovery. Signed-off-by:
-
Peter Ujfalusi authored
Add "tx" or "rx" as resource name for the DMA resources. Signed-off-by:
-
- 17 Mar, 2015 2 commits
-
-
Tony Lindgren authored
We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree. As it seems this board only has minimal support upstreamed for the legacy booting and has not seen activity for on the mailing lists for a few years, let's attempt to remove the related legacy board-*.c file. I do not have this board, but it seems getting the same level of support with device tree based booting is mostly just configuring the .dts file. And there is no need to upgrade the boot loader as we can boot with appended DTB too. And most of the omap3 boards seem to be related to omap3-evm, and omap3beagleboard that are supported with device tree based booting. If somebody is using this board actively with the mainline kernel, please communicate this to the linux-omap mailing list so we can get the board booting with device tree based support. I can help some too getting the minimal device tree based booting going if help is needed. The reason for attempting to remove this board now is that I'd rather get the remaining omap3 legacy booting support into a known state where we at least have a .dts file being written for the remaining legacy boards. That is because for the next few merge cycles we can still revert this patch if absolutely necessary, but I'd rather not get suprised by missing .dts files at the point where we are ready to drop all remaining omap3 legacy booting support later on. Cc: Gregoire Gentil <gregoire@gentil.com> Cc: Radek Pilar <mrkva@mrkva.eu> Signed-off-by:Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree. As it seems this board only has minimal support upstreamed for the legacy booting and has not seen activity for on the mailing lists for a few years, let's attempt to remove the related legacy board-*.c file. I do not have this board, but it seems getting the same level of support with device tree based booting is mostly just configuring the .dts file. And there is no need to upgrade the boot loader as we can boot with appended DTB too. And most of the omap3 boards seem to be related to omap3-evm, and omap3beagleboard that are supported with device tree based booting. If somebody is using this board actively with the mainline kernel, please communicate this to the linux-omap mailing list so we can get the board booting with device tree based support. I can help some too getting the minimal device tree based booting going if help is needed. The reason for attempting to remove this board now is that I'd rather get the remaining omap3 legacy booting support into a known state where we at least have a .dts file being written for the remaining legacy boards. That is because for the next few merge cycles we can still revert this patch if absolutely necessary, but I'd rather not get suprised by missing .dts files at the point where we are ready to drop all remaining omap3 legacy booting support later on. http://www.embest-tech.com/product/single-board-computers/index.html Cc: Thomas Weber <thomas@tomweber.eu> Signed-off-by:
-
- 16 Mar, 2015 5 commits
-
-
Tony Lindgren authored
We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree. As it seems this board only has minimal support upstreamed for the legacy booting and has not seen activity for on the mailing lists for a few years, let's attempt to remove the related legacy board-*.c file. I do not have this board, but it seems getting the same level of support with device tree based booting is mostly just configuring the .dts file. And there is no need to upgrade the boot loader as we can boot with appended DTB too. And most of the omap3 boards seem to be related to omap3-evm, and omap3beagleboard that are supported with device tree based booting. If somebody is using this board actively with the mainline kernel, please communicate this to the linux-omap mailing list so we can get the board booting with device tree based support. I can help some too getting the minimal device tree based booting going if help is needed. The reason for attempting to remove this board now is that I'd rather get the remaining omap3 legacy booting support into a known state where we at least have a .dts file being written for the remaining legacy boards. That is because for the next few merge cycles we can still revert this patch if absolutely necessary, but I'd rather not get suprised by missing .dts files at the point where we are ready to drop all remaining omap3 legacy booting support later on. Also looks like this board is no longer listed on ema-tech.com product page at: http://ema-tech.com/en/categories.html Cc: Jason Lam <lzg@ema-tech.com> Signed-off-by:
-
Gaku Inami authored
The pm code for R-Car Gen2 is scatterd in each SoC. These files (pm-r8a7790.c/pm-r8a7791.c) have some overlap code. This change consolidate the pm code for R-Car Gen2 into one. Signed-off-by:
Gaku Inami <gaku.inami.xw@bp.renesas.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Simon Horman authored
Set the SYSCIER as per the values indicated in the documentation. The value previously used appears to been copied from the r8a7779 implementation but on closer inspection is not correct for the r8a7791. Fixes: 5f6108bb ("ARM: shmobile: r8a7791 SYSC setup code") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Simon Horman authored
Set the SYSCIER as per the values indicated in the documentation. The value previously used appears to been copied from the r8a7779 implementation but on closer inspection is not correct for the r8a7790. Fixes: a48f1655 ("ARM: shmobile: r8a7790 SYSC setup code") Reported-by:
-
Arnd Bergmann authored
Merge tag 'renesas-soc-cleanup2-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/cleanup Merge "Second Round of Renesas ARM Based SoC Cleanup for v4.1" into next/cleanup: * Remove restart callback from r8a7740 SoC * Remove unnecessary check on always set CONFIG_COMMON_CLK from shared R-Car Gen2 SoC code * Remove stray closing parenthesis in SCIF debug description for R-Car Gen2 SoC * tag 'renesas-soc-cleanup2-for-v4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: r8a7740: Remove restart callback ARM: shmobile: R-Car Gen2: CONFIG_COMMON_CLK is always set ARM: shmobile: Remove stray closing parenthesis in debug description
-
- 13 Mar, 2015 21 commits
-
-
Arnd Bergmann authored
Merge tag 'at91-cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91 into next/cleanup Pull "Second batch of cleanup for 4.1" from Nicolas Ferre: - remove unused matrix header files - dbgu + chip identification: new driver for SoC detection this allow to remove all additional io mapping - remove old non-standard AT91 setup code First batch of cleanup for 4.1: - little phy fixup that is not needed anymore - hudge cleanup of the PM code: - removal of "use slow clock" option => always use this for suspend to RAM - quicker suspend as the asm function is copied only once to SRAM - use of the same asm function for "standby" and "mem" types of suspend actions - adaptation to the ARMv7 processors * tag 'at91-cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91: (44 commits) ARM: at91: remove old setup ARM: at91: sama5d4: remove useless map_io ARM: at91: sama5 use SoC detection infrastructure ARM: at91: at91sam9: use SoC detection infrastructure ARM: at91: at91rm9200 use SoC detection infrastructure ARM: at91: add soc detection infrastructure ARM: at91/dt: introduce atmel,<chip>-dbgu ARM: at91: remove unused _matrix.h headers ARM: at91: remove unused at91_ioremap_matrix and header ARM: at91: remove NEED_MACH_IO_H ARM: at91/pm: flush data cache and clean, invalidate and disable the L2 cache ARM: at91/pm_suspend: add the WFI instruction support for ARMv7 ARM: at91/pm: remove unused void (*at91_pm_standby)(void) ARM: at91/pm: rename function name: at91_slow_clock() --> at91_pm_suspend_sram_fn() ARM: at91/pm: rename file name: pm_slowclock.S --> pm_suspend.S ARM: at91/pm: standby mode uses same sram function as suspend to memory mode ARM: at91/pm: move the copying the sram function to the sram initialization phase ARM: at91/pm_slowclock: create the procedure to handle the sdram self-refresh ARM: at91/pm_slowclock: remove clocks which are already stopped when entering slow clock mode ARM: at91/pm: remove CONFIG_AT91_SLOW_CLOCK config option ...
-
Alexandre Belloni authored
The old setup is not used anymore, remove it Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com>
-
Alexandre Belloni authored
All the peripheral remapped at io_map are taken care of by their respective drivers. Signed-off-by:
-
Alexandre Belloni authored
Use the soc detection infrastructure for sama5 initialization. Signed-off-by:
-
Alexandre Belloni authored
Use the soc detection infrastructure for at91sam9 initialization. Signed-off-by:
-
Alexandre Belloni authored
Use the soc detection infrastructure for at91rm9200 initialization. Signed-off-by:
-
Boris BREZILLON authored
Add new structures and functions to handle AT91 SoC detection. [alexandre.belloni@free-electrons.com: reworked DBGU detection] Signed-off-by:
Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by:
-
Alexandre Belloni authored
The DBGU is not a simple UART and we need to be able to distinguish it from the other UARTs, in particular to get its address and check the chip id. Signed-off-by:
-
Alexandre Belloni authored
The matrix headers are not used anymore, remove them. Signed-off-by:
-
Alexandre Belloni authored
at91_ioremap_matrix and the at91_matrix.h header are not used anymore, remove them. Signed-off-by:
-
Arnd Bergmann authored
The mach/io.h header on at91 is used to support a nonstandard I/O space window for the cf card driver. This changes the driver to use pci_ioremap_io in order to have the standard location, and then removes the custom mach/io.h. [alexandre.belloni@free-electrons.com: Added PCI dependency] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Wenyou Yang authored
Flush data cache, and clean, invalidate and disable the L2 cache before going to suspend. Restore the L2 cache configuration and re-enable the L2 cache after waking up. Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> Acked-by:
Sylvain Rochet <sylvain.rochet@finsecur.com> Signed-off-by:
-
Wenyou Yang authored
Add the WFI instruction to make the cpu to the idle state. In the meanwhile, disable the processor's clock. Signed-off-by:
-
Wenyou Yang authored
Because the standby mode use the same sram function as the suspend to memory mode, void (*at91_pm_standby)(void) doesn't need, remove it. Signed-off-by:
-
Wenyou Yang authored
As the file name is renamed, rename the function name at91_slow_clock() --> at91_pm_suspend_sram_fn(), rename the function handler's name at the same time. Signed-off-by:
-
Wenyou Yang authored
Because the sram function is used for both suspend to memory and the suspend to standby mode, renaming is more elegant. Signed-off-by:
-
Wenyou Yang authored
To simply the PM code, the suspend to standby mode uses same sram function as the suspend to memory mode, running in the internal SRAM, instead of the respective code for each mode. For the suspend to standby mode, the master clock doesn't switch to the slow clock, and PLLA and the main oscillator doesn't turn off as well. Signed-off-by:
-
Wenyou Yang authored
To decrease the suspend time, move copying the sram function to the sram initialization phase, instead of every time go to suspend. In the meanwhile, substitute fncpy() for memcpy(). If there is no sram allocated for PM, the PM is not supported. Signed-off-by:
-
Wenyou Yang authored
To decrease the duplicated code, create the procedure to contain both activing and exiting the sdram self-refresh mode. Signed-off-by:
-
Sylvain Rochet authored
Assume USB PLL and PLL B are already stopped before entering sleep mode. Removed PLL B from slow clock code, all drivers are supposed to properly unprepare clocks. Signed-off-by:
-
Wenyou Yang authored
The slow clock always exists, selecting CONFIG_AT91_SLOW_CLOCK config is unnecessary for the suspend to memory mode. For this mode the master clock should always switch to the slow clock. Signed-off-by:
-
