- 17 7月, 2014 8 次提交
-
-
由 Peter De Schrijver 提交于
The Tegra20 fuse driver is the only user of tegra_apb_readl_using_dma(). Therefore we can simply the code by incorporating the APB DMA handling into the driver directly. tegra_apb_writel_using_dma() is dropped because there are no users. Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Peter De Schrijver 提交于
Add efuse and apbmisc bindings for Tegra20, Tegra30, Tegra114 and Tegra124. Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Peter De Schrijver 提交于
Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124. This replaces functionality previously provided in arch/arm/mach-tegra, which is removed in this patch. While at it, move the only user of the global tegra_revision variable over to tegra_sku_info.revision and export tegra_fuse_readl() to allow drivers to read calibration fuses. Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Peter De Schrijver 提交于
All fuse related functionality will move to a driver in the following patches. To prepare for this, export all the required functionality in a global header file and move all users of fuse.h to soc/tegra/fuse.h. While we're at it, remove tegra_bct_strapping, as its only user was removed in Commit a7cbe92c ("ARM: tegra: remove tegra EMC scaling driver"). Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Peter De Schrijver 提交于
Export APB DMA readl and writel. These are needed because we can't access the fuses directly on Tegra20 without potentially causing a system hang. Also have the APB DMA readl and writel return an error in case of a read failure instead of just returning zero or ignore write failures. Signed-off-by: NPeter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
Instead of using a simple variable access to get at the Tegra chip ID, use a function so that we can run additional code. This can be used to determine where the chip ID is being accessed without being available. That in turn will be handy for resolving boot sequence dependencies in order to convert more code to regular initcalls rather than a sequence fixed by Tegra SoC setup code. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
If these aren't sorted alphabetically, then the logical choice is to append new ones, however that creates a lot of potential for conflicts because every change will then add new includes in the same location. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
由 Thierry Reding 提交于
In order to not clutter the include/linux directory with SoC specific headers, move the Tegra-specific headers out into a separate directory. Signed-off-by: NThierry Reding <treding@nvidia.com>
-
- 17 6月, 2014 3 次提交
-
-
由 Doug Anderson 提交于
Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
由 Doug Anderson 提交于
Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
由 Doug Anderson 提交于
All ChromeOS ARM devices that have the standard "CrOS EC" have the same keyboard mapping. It's silly to include this same definition everywhere. Let's create a "dtsi" fragment that we can include from many different boards. This fragment is based on what's currently in tegra124-venice2.dts Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
- 08 6月, 2014 2 次提交
-
-
由 Mark Charlebois 提交于
Patch to prevent warning of a buggy compiler when using clang and the ARM_UNWIND option. Clang defines (at least on the current trunk) GNUC, GNUC_MINOR, and GNUC_PATCHLEVEL to 4, 2, and 1 respectively. This version of GCC gets flagged as buggy, but it isn't actually an issue with clang so the patch will do what it did before unless clang is defined and then it will not report the GCC version as an issue. Signed-off-by: NMark Charlebois <charlebm@gmail.com> Signed-off-by: NBehan Webster <behanw@converseincode.com>
-
由 Behan Webster 提交于
With compilers which follow the C99 standard (like modern versions of gcc and clang), "extern inline" does the wrong thing (emits code for an externally linkable version of the inline function). "static inline" is the correct choice instead. Author: Behan Webster <behanw@converseincode.com> Signed-off-by: NBehan Webster <behanw@converseincode.com> Reviewed-by: NMark Charlebois <charlebm@gmail.com>
-
- 07 6月, 2014 5 次提交
-
-
由 Joe Perches 提交于
This typedef is unnecessary and should just be removed. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Boris BREZILLON 提交于
sam9x5 SoCs have the following errata: "RTC: Interrupt Mask Register cannot be used Interrupt Mask Register read always returns 0." Hence we should not rely on what IMR claims about already masked IRQs and just disable all IRQs. Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com> Reported-by: NBryan Evenson <bevenson@melinkcorp.com> Reviewed-by: NJohan Hovold <johan@hovold.com> Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com> Cc: Bryan Evenson <bevenson@melinkcorp.com> Cc: Andrew Victor <linux@maxim.org.za> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Roszko <mark.roszko@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Nishanth Menon 提交于
OMAP5432, DRA75x and DRA72x have MPU DPLLs that need Duty Cycle Correction(DCC) to operate safely at frequencies >= 1.4GHz. Switch to "ti,omap5-mpu-dpll-clock" compatible property which provides this support. Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Andrii Tseglytskyi 提交于
Duty Cycle Correction(DCC) needs to be enabled if the MPU is to run at frequencies beyond 1.4GHz for OMAP5, DRA75x, DRA72x. MPU DPLL has a limitation on the maximum frequency it can be locked at. Duty Cycle Correction circuit is used to recover a correct duty cycle for achieving higher frequencies (hardware internally switches output to M3 output(CLKOUTHIF) from M2 output (CLKOUT)). For further information, See the note on OMAP5432 Technical Reference Manual(SWPU282U) chapter 3.6.3.3.1 "DPLLs Output Clocks Parameters", and also the "OMAP543x ES2.0 DM Operating Conditions Addendum v0.5" chapter 2.1 "Micro Processor Unit (MPU)". Equivalent information is present in relevant DRA75x, 72x documentation(SPRUHP2E, SPRUHI2P). Signed-off-by: NAndrii Tseglytskyi <andrii.tseglytskyi@ti.com> Signed-off-by: NTaras Kondratiuk <taras@ti.com> Signed-off-by: NJ Keerthy <j-keerthy@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> [t-kristo@ti.com: added TRM / DM references for DCC clock rate] Signed-off-by: NTero Kristo <t-kristo@ti.com>
-
由 Linus Torvalds 提交于
Russell King points out that my ARM merge (commit eb3d3ec5) was broken wrt the arch/arm/mach-mvebu/board-v7.c file, leaving in a stale l2x0_of_init() call (it's now handled by the DT description). Which is kind of embarrassing, since I knew about it as it wasn't the only file that had similar merge issues. At least I got the other ones right. Reported-by: NRussell King <rmk@arm.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 06 6月, 2014 1 次提交
-
-
由 Santosh Shilimkar 提交于
Laura's series removed the meminfo structure and its no longer available. Update keystone code to remove the usage of it. Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 05 6月, 2014 3 次提交
-
-
由 Vince Weaver 提交于
Make the ARM perf code use the new common PMU interrupt disabled code. This allows perf to work on ARM machines without a working PMU interrupt (for example, raspberry pi). Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NVince Weaver <vincent.weaver@maine.edu> [peterz: applied changes suggested by Will] Signed-off-by: NPeter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Grant Likely <grant.likely@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1405161712190.11099@vincent-weaver-1.umelst.maine.edu [ Small readability tweaks to the code. ] Signed-off-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Nicolas Pitre 提交于
It is better not to think about compute capacity as being equivalent to "CPU power". The upcoming "power aware" scheduler work may create confusion with the notion of energy consumption if "power" is used too liberally. This contains the architecture visible changes. Incidentally, only ARM takes advantage of the available pow^H^H^Hcapacity scaling hooks and therefore those changes outside kernel/sched/ are confined to one ARM specific file. The default arch_scale_smt_power() hook is not overridden by anyone. Replacements are as follows: arch_scale_freq_power --> arch_scale_freq_capacity arch_scale_smt_power --> arch_scale_smt_capacity SCHED_POWER_SCALE --> SCHED_CAPACITY_SCALE SCHED_POWER_SHIFT --> SCHED_CAPACITY_SHIFT The local usage of "power" in arch/arm/kernel/topology.c is also changed to "capacity" as appropriate. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NPeter Zijlstra <peterz@infradead.org> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Morten Rasmussen <morten.rasmussen@arm.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: linaro-kernel@lists.linaro.org Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Brown <broonie@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/n/tip-48zba9qbznvglwelgq2cfygh@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Naoya Horiguchi 提交于
Currently hugepage migration is available for all archs which support pmd-level hugepage, but testing is done only for x86_64 and there're bugs for other archs. So to avoid breaking such archs, this patch limits the availability strictly to x86_64 until developers of other archs get interested in enabling this feature. Simply disabling hugepage migration on non-x86_64 archs is not enough to fix the reported problem where sys_move_pages() hits the BUG_ON() in follow_page(FOLL_GET), so let's fix this by checking if hugepage migration is supported in vma_migratable(). Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com> Reported-by: NMichael Ellerman <mpe@ellerman.id.au> Tested-by: NMichael Ellerman <mpe@ellerman.id.au> Acked-by: NHugh Dickins <hughd@google.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Miller <davem@davemloft.net> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 6月, 2014 1 次提交
-
-
由 Arnd Bergmann 提交于
The prototype for mvebu_mbus_dt_init() changed around the same time as a new caller was added to orion5x. This adds the missing argument to make orion5x behave correctly. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
- 03 6月, 2014 14 次提交
-
-
由 Jyri Sarha 提交于
Adds HDMI audio sDMA properties. Signed-off-by: NJyri Sarha <jsarha@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Jyri Sarha 提交于
Adds HDMI audio sDMA properties. Signed-off-by: NJyri Sarha <jsarha@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Florian Vaussard 提交于
Add the necessary DTS nodes to enable the micro-HDMI output on Parlor board. Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Florian Vaussard 提交于
Alto35 expansion board has a ZIF connector for a 3.5'' LCD. Add a common include file for this configuration, and use it on Alto35. Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Florian Vaussard 提交于
Chestnut43, Gallop43 and Palo43 expansion boards have a ZIF connector for a 4.3'' LCD. Add a common include file for this configuration, and use it on relevant expansion boards. Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Florian Vaussard 提交于
Summit and Tobi expansion boards have a HDMI connector with a TFP410 encoder. Add a common include file for this configuration, and then use it for Summit and Tobi. Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's configured as various panel dpi entries for whatever legacy reasons. For device tree based support, let's just configure these properly for panel ls037v7dw01 instead of panel dpi. This patch creates a common file for panel ls037v7dw01, and makes boards ldp and omap3-evm to use it. The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen controller for the omaps, so let's add a basic configuration for the touchscreen also using the default values. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Marek Belisko 提交于
This patch add support for lcd display on gta04 board. Display control is connected to spi (used spi bitbang driver). Signed-off-by: NMarek Belisko <marek@goldelico.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
omap5-uevm has a single HDMI output. Add the necessary display information, including pinmuxing. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Add OMAP5 DSS nodes to omap5.dtsi. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Add DT data for am43x-epos-evm's LCD panel. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Sathya Prakash M R 提交于
Add DT data for am437x-gp-evm's LCD panel. Signed-off-by: NSathya Prakash M R <sathyap@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Sathya Prakash M R 提交于
Add DT data for the display subsystem for AM4372. The DSS on AM4372 is basically OMAP3's DSS, without DSI and VENC blocks. Signed-off-by: NSathya Prakash M R <sathyap@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 02 6月, 2014 3 次提交
-
-
由 Russell King 提交于
This does the same as the previous commit, but for the S bit, which also needs to match the initial value which the assembly code used for the same reasons. Again, we add a check for SMP to ensure that the page tables are correctly setup for SMP. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Ulf Hansson 提交于
Remove the option to provide DMA configuration as platform data, enforce it through DT. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Roland Stigge <stigge@antcom.de> Acked-by: NArnd Bergmann <arnd@arndb.de>
-
由 Russell King 提交于
Fix a long standing bug where, for ARMv6+, we don't fully ensure that the C code sets the same cache policy as the assembly code. This was introduced partially by commit 11179d8c ([ARM] 4497/1: Only allow safe cache configurations on ARMv6 and later) and also by adding SMP support. This patch sets the default cache policy based on the flags used by the assembly code, and then ensures that when a cache policy command line argument is used, we verify that on ARMv6, it matches the initial setup. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-