- 23 11月, 2009 15 次提交
-
-
由 Felipe Balbi 提交于
Add platform init code for EHCI driver. Various fixes to the original patch by Ajay Kumar Gupta <ajay.gupta@ti.com> and Anand Gadiyar <gadiyar@ti.com>. Overo support added by Olof Johansson <olof@lixom.net> Beagle support added by Koen Kooi <koen@beagleboard.org> CM-T32 support added by Mike Rapoport <mike@compulab.co.il> Signed-off-by: NSigned-off-by: Olof Johansson <olof@lixom.net> Acked-by: NSteve Sakoman <steve@sakoman.com> Signed-off-by: NKoen Kooi <koen@beagleboard.org> Signed-off-by: NMike Rapoport <mike@compulab.co.il> Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Anand Gadiyar 提交于
Add missing declarations to allow the recently introduced ehci-omap driver to build on OMAP3 Signed-off-by: NAnand Gadiyar <gadiyar@ti.com> Cc: Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Ranjith Lohithakshan 提交于
AM35xx is functionally similar to OMAP3430 ES3.1 from a powerdomain/clockdomain perspective. This patch initializes the omap_chip bits on AM35xx for use by powerdomain and clockdomain code. Signed-off-by: NRanjith Lohithakshan <ranjithl@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sanjeev Premi 提交于
Add support to detect AM3505/AM3517 devices at runtime. Also updates the CPU names printed during boot. Signed-off-by: NSanjeev Premi <premi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 vikram pandita 提交于
3630 is getting treated like next rev of 3430 omap_chip.oc variable has to be updated for 3630 version Otherwise the Core power domain is not getting registered. This gets used in the registration of power domains in: "arch/arm/mach-omap2/powerdomains34xx.h" core_34xx_es3_1_pwrdm OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1) Core power doman will get registered for 3630 only when .oc is populated correctly. Tested on Zoom3(3630) board Signed-off-by: NVikram Pandita <vikram.pandita@ti.com> Acked-by: NAlexander Shishkin <virtuoso@slind.org> Acked-by: NAri Kauppi <kauppi@papupata.org> Acked-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Nishanth Menon 提交于
OMAP3630 is the latest in the family of OMAP3 devices and among the changes it introduces are: New OPP levels for new voltage and frequency levels. a bunch of Bug fixes to various modules feature additions, notably with ISP, sDMA etc. Details about the chip is available here: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12836&contentId=52606 Strategy used: Strategy to introduce this device into Linux was discussed here: Ref: http://marc.info/?t=125343303400003&r=1&w=2 Two approaches were available: a) Consider 3630 generation of devices as a new family of silicon b) Consider 3630 as an offshoot of 3430 family of devices As a common consensus, (b) seems to be more valid for 3630 as: * There are changes which are easily handled by using "FEATURES" infrastructure. For details how to do this, see thread: http://marc.info/?t=125050998500001&r=1&w=2 * Most of existing 34xx infrastructure can be reused(almost 90%+) - so no ugly if (cpu_is_omap34xx() || cpu_is_omap36xx()) all over the place - lesser chance of bugs due to reuse of proven code flow - 36xx specific handling can still be done where required within the existing infrastructure NOTE: * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be added on top of the existing 3630 ones are renumbered This patch was tested on SDP3430, boot tested on 3630 platform using 3430sdp defconfig Signed-off-by: NMadhusudhan Chikkature Rajashekar <madhu.cr@ti.com> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NVikram Pandita <vikram.pandita@ti.com> Cc: Allen Pais <allen.pais@ti.com> Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Felipe Balbi <felipe.balbi@nokia.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Sergio Alberto Aguirre Rodriguez <saaguirre@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sanjeev Premi 提交于
Add runtime check for these OMAP35x variations based on the detected Si features: OMAP3503, OMAP3515, OMAP3525 and OMA3530. Also, delayed the call to pr_info() into actual variant is detected in omap3_cpuinfo() Signed-off-by: NSanjeev Premi <premi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sanjeev Premi 提交于
The OMAP35x family has multiple variants differing in the HW features. This patch detects these features at runtime and prints information during the boot. Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: NSanjeev Premi <premi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Cory Maccarrone 提交于
The l3_ocpi_ck clock is needed on omap7xx processors for USB. Additionally, bit 8 of the SOFT_REQ_REG needs to be enabled for the usb_dc_ck on omap7xx, which is a different bit than that of the omap16xx-defined clock of the same name. I added a provision for the usb_dc_ck and l3_ocpi_ck clocks as dc_clk and hhc_clk, respectively, for omap7xx CPUs. Additionally, I added a check in machine_without_vbus_sense for all omap7xx devices, as presently I know of no omap7xx-based devices that have vbus sense, and it made more sense to me to use a cpu check here than to spell out each machine one at a time. Finally, DMA is disabled for omap7xx, as it causes problems with these chips. Cc: linux-usb@vger.kernel.org Cc: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Cory Maccarrone 提交于
The MMC mux pins normally used by omap chips in devices.c are different from what is needed by omap7xx chips. This change adds a conditional around the mux setup code to enable the correct mux pins. The omap730 and omap850 both use a different clock for the "fck" clock of the MMC interface than other omap processors based on the SOFT_REQ_REG, pin 12. The "ick" clock is the same as that used by other omap processors. * Added the missing clock definition as mmc3_ck to clock.h * Added the clock definition to omap_clks in clock.c * Added CK_7XX to the mmci-omap.0 "ick" clock already in clock.c With these changes, it is now possible to initialize and use MMC cards with omap730 and omap850 devices. Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 vikram pandita 提交于
Zoom2/Zoom3 kind of boards do not use omap uarts for console. These use external debug board for console. So these boards should not have "Uncompressing Kernel...." log put on omap uarts. By interoducing OMAP_LL_DEBUG_NONE option, unnecessary writes to omap uarts is avoided. In future, the DEBUG_LL interface will be enhanced to use external debug board. Signed-off-by: NVikram Pandita <vikram.pandita@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Alexander Shishkin 提交于
Eliminate OMAP_MAX_NR_PORTS Note that also the null terminator entry for omap1 serial_platform_data needs to be now removed to avoid oopsing. Note that mach-omap1 uses struct plat_serial8250_port array, which requires a null terminator at the end, and that's why we need to use ARRAY_SIZE - 1. This is not needed on mach-omap2 as the array used is struct omap_uart_state, and does not use a null terminator. Signed-off-by: NAlexander Shishkin <virtuoso@slind.org> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NLadislav Michl <ladis@linux-mips.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jani Nikula 提交于
Initialize some of the RX-51 input GPIO lines as gpio keys. Enable gpio keys as a module in rx51_defconfig. Signed-off-by: NJani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
-
由 Peter Ujfalusi 提交于
audio_mclk value is going to be handled by the twl4030-codec MFD driver, configure the correct value for boards, which is using the twl4030 audio. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
由 Peter Ujfalusi 提交于
Add needed platform data for the twl4030_codec MFD on boards, where the audio part of the twl4030 codec is used. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 19 11月, 2009 2 次提交
-
-
由 Roel Kluin 提交于
The index `cs' is signed, test whether it is negative before we release gpmc_cs_mem[cs]. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
由 Roel Kluin 提交于
The closing parenthesis was not in the right location. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
-
- 18 11月, 2009 8 次提交
-
-
由 Rusty Russell 提交于
"[CPUFREQ] cpumask: avoid playing with cpus_allowed in speedstep-ich.c" changed the code to mistakenly pass the current cpu as the "processor" argument of speedstep_get_frequency(), whereas it should be the type of the processor. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14340 Based on a patch by Dave Mueller. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Acked-by: NDominik Brodowski <linux@brodo.de> Reported-by: NDave Mueller <dave.mueller@gmx.ch> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 John Villalovos 提交于
Removing the SMT/HT check, since the Errata doesn't mention Hyper-Threading. Adding in a printk, so that the user knows why acpi-cpufreq refuses to load. Also, once system is blacklisted, don't repeat checks to see if blacklisted. This also causes the message to only be printed once, rather than for each CPU. Signed-off-by: NJohn L. Villalovos <john.l.villalovos@intel.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Roel Kluin 提交于
Not makes it a bool before the comparison. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Krzysztof Helt 提交于
There is a typo in the longhaul detection code so only Longhaul v1 or Longhaul v3 is selected. The Longhaul v2 is not selected even for CPUs which are capable of. Tested on PCChips Giga Pro board. Frequency changes work and the Longhaul v2 detects that the board is not capable of changing CPU voltage. Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Thomas Gleixner 提交于
The typename member of struct irq_chip was kept for migration purposes and is obsolete since more than 2 years. Fix up the leftovers. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: linux-sh@vger.kernel.org Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Tero Kristo 提交于
Current calculation does not take into account any changes to M2 divisor, and thus when we change VDD2 OPP, dpll3_m2x2 rate does not change. Fixed by re-routing dpll3_m2x2 parent to dpll3_m2. Signed-off-by: NTero Kristo <tero.kristo@nokia.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Rajendra Nayak 提交于
Fix the freqsel value computation. Use n instead of (n+1) The formula in the TRM uses a zero-based N, hence the (n+1); however at this point in the clock34xx.c code, N is one-based. Hayati Bayrakdar <h-bayrakdar@ti.com> and Nishanth Menon <nm@ti.com> helped track down this bug. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> [paul@pwsan.com: modified commit message] Cc: Hayati Bayrakdar <h-bayrakdar@ti.com> Cc: Nishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Stephen Rothwell 提交于
These values were only introduced during this release cycle, so it is still early enough to get them right. alpha uses the same values that are in asm-generic/fcntl.h, so just remove them. parisc uses the values interchanged for no apparent reason, so remove them to give us consistency across all architectures. Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 11月, 2009 4 次提交
-
-
由 Vimal Singh 提交于
Interpretation of 'row' and 'col' got reversed in matrix keymap framework. Also last element '0', present in keymap array, is no more needed. Correcting zoom2 keyboard keymap accordingly. Signed-off-by: NVimal Singh <vimalsingh@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Roel Kluin 提交于
Ensure we do not read/write outside array boundaries with a negative index. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Paul Parsons 提交于
hx4700 touchscreen events were being dropped in ads7846_rx() because their pressure values consistently exceeded the platform maximum of 512; a sample of 256 pressure values were in the range 531 to 815. Doubling the platform maximum to 1024 allows hx4700 touchscreen events to pass the test. Signed-off-by: NPaul Parsons <lost.distance@yahoo.com> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
由 Linus Walleij 提交于
This will fix some small issues with the COH 901 331 RTC driver: - Interrupt is disabled after alarm so that we don't fire multiple interrupts. - We return 0 from the coh901331_alarm_irq_enable() ridding a compile warning. - We alter the name in the U300 device registry to match that of the driver so they sucessfully resolve. Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 16 11月, 2009 4 次提交
-
-
由 Nicolas Ferre 提交于
at91sam9g20ek rev. C and onwards embed two SD/MMC slots. This patch modify the previous dual slot board definition to match the official rev. C board. It also allows the use of at91_mci SD/MMC driver in addition to the atmel-mci one. Some pins have been re-affected from leds or Ethernet phy IRQ to the SD/MMC slot A. This lead to a modification of those definitions. Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NAndrew Victor <linux@maxim.org.za>
-
由 Josh Triplett 提交于
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
-
由 Josh Triplett 提交于
Nothing outside of arch/powerpc/boot/addRamDisk.c references the functions "get4k", "put4k", or "death". Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
-
由 Josh Triplett 提交于
Nothing outside of arch/alpha/boot/tools/objstrip.c references the usage function. Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
-
- 14 11月, 2009 6 次提交
-
-
由 Lennert Buytenhek 提交于
Disable propagation of mbus errors to the CPU local bus, as this causes mbus errors (which can occur for example for PCI aborts) to throw CPU aborts, which we're not set up to deal with. Reported-by: NDieter Kiermaier <dk-arm-linux@gmx.de> Signed-off-by: NLennert Buytenhek <buytenh@marvell.com> Signed-off-by: NNicolas Pitre <nico@marvell.com>
-
由 Kevin D. Kissell 提交于
1. At the end of smtc_distribute_timer, nextstamp is valid and has already passed so we goto repeat. 2. Nothing updates nextstamp (only updated if the timeout is in the future And we just decided it is in the past) 3. At the end nextstamp still has the same value so it is still valid and in the past. 4. This repeats until read_c0_count has a value which causes nextstamp to be in the future. Reported and initial patch and testing by Mikael Starvik <mikael.starvik@axis.com>. Signed-off-by: NKevin D. Kissell <kevink@paralogos.com> Cc: Mikael Starvik <mikael.starvik@axis.com> Cc: linux-mips@linux-mips.org Cc: Jesper Nilsson <Jesper.Nilsson@axis.com> Patchwork: http://patchwork.linux-mips.org/patch/621/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Atsushi Nemoto 提交于
Enable following features: * MTD (RBTX4939, NAND_TXX9NDFMC) * HW_RANDOM (HW_RANDOM_TX4939) * SOUND (SND_SOC_TXX9ACLC) * DMADEVICE (TXX9_DMAC) Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Atsushi Nemoto 提交于
Since commit 22242681 ("MIPS: Extend COMMAND_LINE_SIZE"), CL_SIZE is 4096 and local array variables with this size will cause an build failure with default CONFIG_FRAME_WARN settings. Although current users of such array variables are all early bootstrap code and not likely to cause real stack overflow (thread_info corruption), it is preferable to to declare these arrays static with __initdata. Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Yoichi Yuasa 提交于
The ohci-sm501 driver requires dma_declare_coherent_memory(). It is used by the driver's local memory allocation with dma_alloc_coherent(). Tested on TANBAC TB0287(VR4131 + SM501). [Ralf: Fixed reject in dma-default.c and removed the entire #if 0'ed block in dma-mapping.h instead of just the #if 0.] Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 David Daney 提交于
Running a 64-bit kernel on a 64-bit CPU without an FPU would cause the emulator to run in 32-bit mode. The c0_Status.FR bit is wired to zero on systems without an FPU, so using that bit to decide how the emulator behaves doesn't allow for proper emulation on 64-bit FPU-less processors. Instead, we need to select the emulator mode based on the user-space ABI. Since the thread flag TIF_32BIT_REGS is used to set c0_Status.FR, we can just use it to decide if the emulator should be in 32-bit or 64-bit mode. Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 13 11月, 2009 1 次提交
-
-
由 Christian Borntraeger 提交于
On s390 there are two ways of specifying the system call number for the svc instruction. The standard way is to use the immediate field in the instruction (or to use EXecute for values unknown during assemble time). This can encode 256 system calls. The kernel ABI also allows to put the system call number in r1 and then execute svc 0 to enable system call numbers > 255. It turns out that single stepping svc 0 is broken, since the PER program check handler uses r1. We have to use a different register. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-