summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2012-09-07ARM: dts: omap3: Add McBSP entriesPeter Ujfalusi
Create the needed sections to be able to probe McBSP ports via DT. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2Peter Ujfalusi
Since the board is based on OMAP2420 we should include the dedicated dtsi file (which includes the common omap2 dtsi). Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoCPeter Ujfalusi
The McBSP IP within OMAP2420 and 2430 is different we need to create separate dtsi files for them. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap3-beagle: Add heartbeat and mmc LEDs supportBenoit Cousson
Add the support for D6 and D7 LEDs on Beagle board. - D6 will be used for heartbeat - D7 will be used for mmc0 Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap3: Add gpio-twl4030 properties for BeagleBoard and omap3-EVMFlorian Vaussard
Add device tree properties for twl4030/gpio, according to the platform data of corresponding boards. This enables the led connected to LEDB output for both boards, as well as pullups/pulldowns on GPIO for the BeagleBoard. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-09-07ARM: dts: OMAP4: Cleanup and move GIC outside of the OCPBenoit Cousson
Remove some useless comment and move GIC controller outside of the OCP node since it does use the MPU internal bus and not the OCP. This will not change the functionality but will reflect the reality more accurately. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2012-09-07ARM: OMAP4: Add local timer support for Device TreeSantosh Shilimkar
Add cortex-a9 local timer support for all OMAP4 based SOCs using DT. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: OMAP4: Add L2 Cache Controller in Device TreeSantosh Shilimkar
Provide PL310 Level 2 Cache Controller Device Tree support for OMAP4 based devices. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boardsAneesh V
Device tree data for the EMIF sdram controllers in OMAP4 and LPDDR2 memory devices attached to OMAP4 boards. Reviewed-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Aneesh V <aneesh@ti.com> [santosh.shilimkar@ti.com: Rebased against 3.6-rc] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [b-cousson@ti.com: Use label in board to access EMIF nodes] Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap4-sdp: Add keypad dataSourav Poddar
Add keypad data node in omap4 device tree file. Also fill the device tree binding parameters with the required value in "omap4-sdp" dts file. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> [b-cousson@ti.com: Re-align the entries and the comments]
2012-09-07ARM: dts: omap5-evm: Add bmp085 sensor supportSourav Poddar
Add bmp085 pressure sensor data in omap5 evm dts file. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap5-evm: Add keypad dataSourav Poddar
Add keypad data node in omap5 device tree file. Also fill the device tree binding parameters with the required value in "omap5-evm" dts file. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> [b-cousson@ti.com: Fix merge issue with MMC patches, put node at the proper place, align entries and comments] Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap5-evm: Add tmp102 sensor supportSourav Poddar
Add tmp102 temperature sensor data in omap5 evm dts file. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: dts: omap5-evm: Add I2C supportSourav Poddar
Add I2C data nodes in omap5 device tree file. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07ARM: OMAP: omap_device: Do not overwrite resources allocated by OF layerVaibhav Hiremath
With the new devices (like, AM33XX and OMAP5) we now only support DT boot mode of operation and now it is the time to start killing slowly the dependency on hwmod, so with this patch, we are starting with device resources. The idea here is implemented considering to both boot modes - - DT boot mode OF framework will construct the resource structure (currently does for MEM & IRQ resource) and we should respect/use these resources, killing hwmod dependency. If pdev->num_resources > 0, we assume that MEM & IRQ resources have been allocated by OF layer already (through DTB). Once DMA resource is available from OF layer, we should kill filling any resources from hwmod. - Non-DT boot mode Here, pdev->num_resources = 0, and we should get all the resources from hwmod (following existing steps) Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> [b-cousson@ti.com: Fix some checkpatch CHECK issues] Signed-off-by: Benoit Cousson <b-cousson@ti.com>
2012-09-07OMAP: 4430SDP: remove DSI clock config from board fileTomi Valkeinen
DSI clocks are now configured dynamically by the DSI driver, so we can remove the hardcoded clock configuration from the board file. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2012-09-07OMAP4: TWL: add vdda_hdmi_dac regulator supplyTomi Valkeinen
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator, or the regulator supplying the vdac, has been enabled by default and things have worked without the HDMI driver enabling the vdac. I encountered the problem when implementing HDMI device tree support, where the regulator was not enabled by default. This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI driver can use it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2012-09-07OMAPDSS: HDMI: Move GPIO handling to HDMI driverTomi Valkeinen
We currently manage HDMI GPIOs in the board files via platform_enable/disable calls. This won't work with device tree, and in any case the correct place to manage the GPIOs is in the HDMI driver. This patch moves the handling of the GPIOs to the HDMI driver. The GPIO handling is moved to the common hdmi.c file, and this probably needs to be revisited when adding OMAP5 HDMI support to see if the GPIO handling needs to be moved to IP specific files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2012-09-07serial: omap: fix compile breakageFelipe Balbi
when rebasing patches on top of Greg's tty-next, it looks like automerge broke a few things which I didn't catch (for whatever reason I didn't have OMAP Serial enabled on .config) so I ended up breaking the build on Greg's tty-next branch. Fix the breakage by re-adding the three missing members on struct uart_omap_port. Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-07ARM: tegra: Fix data type for io addressPrashant Gaikwad
Warnings were generated because following commit changed data type for address pointer 195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors arch/arm/mach-tegra/tegra30_clocks.c: In function 'clk_measure_input_freq': arch/arm/mach-tegra/tegra30_clocks.c:418:2: warning: passing argument 2 of '__raw_writel' makes pointer from integer without a cast .../arch/arm/include/asm/io.h:88:20: note: expected 'volatile void *' but argument is of type 'unsigned int Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-07ARM: ep93xx: Fix build error due to 'SZ_32M' undeclaredAxel Lin
Include linux/sizes.h to fix below build errors: CC arch/arm/mach-ep93xx/adssphere.o arch/arm/mach-ep93xx/adssphere.c: In function 'adssphere_init_machine': arch/arm/mach-ep93xx/adssphere.c:32:49: error: 'SZ_32M' undeclared (first use in this function) arch/arm/mach-ep93xx/adssphere.c:32:49: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [arch/arm/mach-ep93xx/adssphere.o] Error 1 make: *** [arch/arm/mach-ep93xx] Error 2 CC arch/arm/mach-ep93xx/gesbc9312.o arch/arm/mach-ep93xx/gesbc9312.c: In function 'gesbc9312_init_machine': arch/arm/mach-ep93xx/gesbc9312.c:32:49: error: 'SZ_8M' undeclared (first use in this function) arch/arm/mach-ep93xx/gesbc9312.c:32:49: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [arch/arm/mach-ep93xx/gesbc9312.o] Error 1 make: *** [arch/arm/mach-ep93xx] Error 2 Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Ryan Mallon <rmallon@gmail.com>
2012-09-07ARM: EXYNOS: Adds G-Scaler device from Device TreeShaik Ameer Basha
This patch adds, - 4 G-Scaler devices to the DT device list - G-Scaler specific entries to the machine file - binding documentation for G-Scaler entries Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07ARM: EXYNOS: Add clock support for G-ScalerShaik Ameer Basha
Add required clock support for G-Scaler for exynos5 Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com> Signed-off-by: Prathyush K <prathyush.k@samsung.com> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-06ARM: ux500: Switch to use common clock frameworkUlf Hansson
Remove machine specific clock implementation and switch to use new common clock framework. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2012-09-07ARM: S3C24XX: Use module_platform_driver macro in mach-osiris-dvs.cSachin Kamat
module_platform_driver simplifies the code by eliminating module_init and module_exit calls. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07ARM: S3C24XX: Use module_platform_driver macro in h1940-bluetooth.cSachin Kamat
module_platform_driver simplifies the code by eliminating module_init and module_exit calls. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07ARM: EXYNOS: Enable pinctrl driver support for EXYNOS4 device tree enabled ↵Thomas Abraham
platform This enables support for Samsung and EXYNOS4 pinctrl driver for device tree enabled EXYNOS4 platforms. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07ARM: dts: Add pinctrl node entries for SAMSUNG EXYNOS4210 SoCThomas Abraham
Add pinctrl driver nodes for the three instances of pin controllers in SAMSUNG EXYNOS4210 SoC and add the pin group nodes available in the each of those three instances. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07ARM: EXYNOS: skip wakeup interrupt setup if pinctrl driver is usedThomas Abraham
Pinctrl driver includes support for configuring the external wakeup interrupts. On exynos platforms that use pinctrl driver, the setup of wakeup interrupts in the exynos platform code can be skipped. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2012-09-07arm/crypto: Add optimized AES and SHA1 routinesDavid McCullough
Add assembler versions of AES and SHA1 for ARM platforms. This has provided up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1. Platform CPU SPeed Endian Before (bps) After (bps) Improvement IXP425 533 MHz big 11217042 15566294 ~38% KS8695 166 MHz little 3828549 5795373 ~51% Signed-off-by: David McCullough <ucdevel@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-09-06ARM: enable SUSPEND/ARCH_SUSPEND_POSSIBLE for ARCH_TEGRAStephen Warren
Even though system suspend/resume hasn't been validated on Tegra yet, this Kconfig option needs to be enabled so that system shutdown is reliable on an SMP system. Without it, I2C interrupts may be routed to CPU0, whereas shutdown code may be running on CPU1, causing I2C timeouts, preventing communication with the external PMIC. This reverts 3d5e8af "ARM: disable SUSPEND/ARCH_SUSPEND_POSSIBLE for ARCH_TEGRA". Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: fix debugfs entry for Tegra30Peter De Schrijver
Tegra30 has more powerdomains than Tegra20. The debugfs code did not take this into account. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: fix return value for debugfs initPeter De Schrijver
tegra_powergate_debugfs_init() always returns -ENOMEM. It shouldn't do that when registering the debugfs entry succeeded. Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: dt: tegra: whistler: add regulatorsStephen Warren
Whistler uses a Maxim 8907 regulator. Instantiate this. The voltage settings were derived from the schematic. The only exception is the BBAT voltage; the schematic says 1.2v, but the HW can't go that low, so use the HW default of 2.4v instead. Almost all regulators list all driven supply signal names in their regulator-names property. The exception is nvvdd_sv3, which is in turn named 12 more different names on the schematic, so these were omitted for brevity. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: dt: tegra: paz00: add regulatorsStephen Warren
The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-09-06ARM: dt: tegra: ventana: add regulatorsStephen Warren
Ventana uses a TPS6586x regulator. Instantiate this, and hook up a couple of fixed GPIO-controlled regulators too. The data was chosen to match the PMIC HW defaults, with the following exception: ldo6: The HW default is 2.85v. The schematics are unlabelled. Internal research indicates that 1.8v is correct. Our downstream kernel also uses 1.8v. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: dt: tegra: seaboard: add regulatorsStephen Warren
Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a couple of fixed GPIO-controlled regulators too. Two data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each LDO rail. In most cases these sources matched. The only differences is: ldo6: The HW default on Springbank is 2.85v. The HW default on Seaboard is 1.8v. The schematics for both Springbank and Seaboard match at 2.85v. However, internal research indicates that the schematics are incorrectly labelled, and 1.8v is correct. The ChromeOS kernel also uses 1.8v. Note that these settings don't entirely match those in the ChromeOS kernel found at the URL below. However, the selected values generally cause no behavior change in the kernel, and so were picked to avoid regressions. repo http://git.chromium.org/chromiumos/third_party/kernel.git branch chromeos-3.2 file arch/arm/mach-tegra/board-seaboard-power.c Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: cardhu: add dt entry for fixed regulatorsLaxman Dewangan
Cadhu have multiple power rails which are controlled by GPIOs. Add support of these power rail control through fixed regulators. Add entry for all fixed regulators for cardhu-a02 and a04. The details are taken from downstream kernel. Some points on this change are: * Add the tps65910-LDO5 entry and make it always ON to supply power to SDMMC. Once the sd driver support regulator handling, this flag will be remove. * Dropping registration of rail vdd_sdmmc1 as the gpio is used by sdhci power-gpio. This need to fix in sdhci driver and then need to add the registration mechanism. Just removing power-gpio and adding fixed regulator with this gpio is causing the sd access to fail because first probe call of this regulator fails due to non-available of parent and so it calls gpio_free() which disable the pins in gpio mode make pin output to LOW causes power to OFF. In probe retry, it got success and it powered-on but it again need to do again numeration of card here. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: dt: tegra: cardhu: split dts file for support multiple board versionsLaxman Dewangan
There is multiple version of cardhu starting from A01 to A07. Cardhu A01 and A03 are not supported. Cardhu A02 will have different sets of GPIOs for fixed regulator compare to cardhu A04. The Cardhu A05, A06, A07 are compatibe with A04. Based on cardhu version, the related dts file need to be chosen like for cardhu A02, use tegra30-cardhu-a02.dts, cardhu A04 and more, use tegra30-cardhu-a04.dts. This patch create the DTS file A02 and A04 and convert tegra30-cardhu.dts as dts include file. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: dt: tegra: cardhu: add entry for PMIC TPS65911.Laxman Dewangan
Tegra30 based platform "cardhu" have the power management IC TPS65911 for the regulator. Adding DT entry for this device. Data are chosen from downstream kernel and making the voltage output as require by default for device to operate. The default interrupt line is HIGH from PMIC device and so inverting the interrupt detection line of PMU interrupt through configuring PMC. In this patch, do not registering LDO5 because the input supply for this rail is different for different version of cardhu i..e A02 and A04. The registration will be done once the dts file for cardhu A02 and A04 are added in follow on patches. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: remove tegra_timer from tegra_list_clksStephen Warren
tegra_time is a struct sys_timer, not a struct clk, so can't be included in an array of struct clk *. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra30: clocks: fix the wrong tegra_audio_sync_clk_ops nameJoseph Lo
It should use tegra30_audio_sync_clk_ops for tegra30. It will cause the tegra30 use the wrong audio_sync_clk_ops when build a kernel with a tegra20 and tegra30 both supported kernel. And building error when a tegra30-only kernel. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: clocks: separate tegra_clk_32k_ops from Tegra20 and Tegra30Joseph Lo
Currently the tegra20 and tegra30 share the same symbol for tegra_clk_32k_ops. This will cause a compile error when building a tegra20-only kernel image. Add tegra_clk_32k_ops for tegra20 and modify tegra30_clk_32k_ops for tegra30. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: Remove duplicate codePrashant Gaikwad
Remove Tegra legacy clock framework code. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: Port tegra to generic clock frameworkPrashant Gaikwad
This patch converts tegra clock code to generic clock framework in following way: - Implement clk_ops as required by generic clk framework. (tegraXX_clocks.c) - Use platform specific struct clk_tegra in clk_ops implementation instead of struct clk. - Initialize all clock data statically. (tegraXX_clocks_data.c) Legacy framework did not have recalc_rate and is_enabled functions. Implemented these functions. Removed init function. It's functionality is splitted into recalc_rate and is_enabled. Static initialization is used since slab is not up in .init_early and clock is needed to be initialized before clockevent/clocksource initialization. Macros redefined for clk_tegra. Also, single struct clk_tegra is used for all type of clocks (PLL, peripheral etc.). This is to move quickly to generic common clock framework so that other dependent features will not be blocked (such as DT binding). Enabling COMMON_CLOCK config moved to ARCH_TEGRA since it is enabled for both Tegra20 and Tegra30. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: Add clk_tegra structure and helper functionsPrashant Gaikwad
Add Tegra platform specific clock structure clk_tegra and some helper functions for generic clock framework. struct clk_tegra is the single strcture used for all types of clocks. reset and cfg_ex ops moved to clk_tegra from clk_ops. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: Rename tegra20 clock filePrashant Gaikwad
Make the name consistent with other files. s/tegra2/tegra20 Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra20: Separate out clk ops and clk dataPrashant Gaikwad
Move clock initialization data to separate file. This is required for migrating to generic clock framework if static initialization is used. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra30: Separate out clk ops and clk dataPrashant Gaikwad
Move clock initialization data to separate file. This is required for migrating to generic clock framework if static initialization is used. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-09-06ARM: tegra: fix U16 divider range checkStephen Warren
A U16 divider can divide a clock by 1..64K. However, the range-check in clk_div16_get_divider() limited the range to 1..256. Fix this. NVIDIA's downstream kernels already have the fixed range-check. In practice this is a problem on Whistler's I2C bus, which uses a bus clock rate of 100KHz (rather than the more common 400KHz on Tegra boards), which requires a HW module clock of 8*100KHz. The parent clock is 216MHz, leading to a desired divider of 270. Prior to conversion to the common clock framework, this range error was somehow ignored/irrelevant and caused no problems. However, the common clock framework evidently has more rigorous error-checking, so this failure causes the I2C bus to fail to operate correctly. Signed-off-by: Stephen Warren <swarren@nvidia.com>
generated by cgit (git 2.34.1) at 2025-09-30 06:41:58 +0000