- 26 Sep, 2011 1 commit
-
-
Jarkko Nikula authored
These variables got unused after McBSP was converted to use resource structures. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 22 Sep, 2011 2 commits
-
-
- 21 Sep, 2011 1 commit
-
-
Kevin Hilman authored
Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
- 20 Sep, 2011 1 commit
-
-
Tony Lindgren authored
Commit f41caddb (omap2+: Use Kconfig symbol in Makefile instead of obj-y) cleaned up the omap2+ Makefile. However this did not account for the inline functions that are now needed for board_flash_init and board_nand_init. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- 16 Sep, 2011 1 commit
-
-
Kevin Hilman authored
During the idle/suspend path, we expect the console lock to be held so that no console output is done during/after the UARTs are idled. However, when using the no_console_suspend argument on the command-line, the console driver does not take the console lock. This allows the possibility of console activity after UARTs have been disabled. To fix, update the current is_suspending() to also check the console_suspend_enabled flag. Reported-by: Abhilash Koyamangalath <abhilash.kv@ti.com> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
- 15 Sep, 2011 9 commits
-
-
Kevin Hilman authored
Rather than embedding a struct platform_device inside a struct omap_device, decouple them, leaving only a pointer to the platform_device inside the omap_device. Use the arch-specific data field of the platform_device (pdev_archdata) to add an omap_device pointer after the platform_device has been created. Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
Public omap_device functions need to take platform_device pointers, conversion to omap_device pointers is done internal to the omap_device layer. Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
The internal device register functions do not need or use any omap_device internals, so pass in a platform_device pointer instead of an omap_device pointer. Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
The *_device_register() functions and the count/fill resources functions are internal to omap_device and do not need to be in the header. Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Grazvydas Ignotas authored
During normal system operation warning messages similar to this are appearing quite often: omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035 This doesn't seem to be reporting a problem, nor is it very useful for non-developers, so reduce it to debug level. Acked-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Kevin Hilman authored
For consistency in kernel printk output for devices, use dev_dbg(), dev_warn(), dev_err() instead of pr_debug(), pr_warning() and pr_err(), some of which currently use direct access of name from platform_device and others of which use dev_name(). Using the dev_* versions uses the standard device naming from the driver core. Some pr_* prints were not converted with this patch since they are used before the platform_device and struct device are created so neither the dev_* prints or dev_name() is valid. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
-
Jarkko Nikula authored
struct omap_device *od is only set with find_omap_device_by_dev but not used otherwise so remove them and references to omap device API. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
-
-
- 14 Sep, 2011 12 commits
-
-
Paul Walmsley authored
Now that all of the users of the OMAP_CHIP bitfield code have been converted to use lists, the OMAP_CHIP code, data, and declarations can be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com>
-
Paul Walmsley authored
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
-
Paul Walmsley authored
At Tony's request, remove the omap_chip bitmasks from the powerdomain definitions. Instead, initialize powerdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a related patch that also applied to this patch - thanks Gražvydas. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
-
Paul Walmsley authored
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three functions. This allows some of them to be called multiple times: for example, pwrdm_register_pwrdms() can be called once to register powerdomains that are common to a group of SoCs, and once to register powerdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. pwrdm_register_platform_funcs() 2. pwrdm_register_pwrdms() (can be called multiple times) 3. pwrdm_complete_init() Convert the OMAP2, 3, and 4 powerdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com>
-
Paul Walmsley authored
At Tony's request, remove the omap_chip bitmasks from the clockdomain and clockdomain dependency definitions. Instead, initialize clockdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Tony Lindgren <tony@atomide.com> found a bug in a previous version of this patch - thanks Tony. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
-
Paul Walmsley authored
In preparation for OMAP_CHIP() removal, split clkdm_init() into four functions. This allows some of them to be called multiple times: for example, clkdm_register_clkdms() can be called once to register clockdomains that are common to a group of SoCs, and once to register clockdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. clkdm_register_platform_funcs() 2. clkdm_register_clkdms() (can be called multiple times) 3. clkdm_register_autodeps() (optional; deprecated) 4. clkdm_complete_init() Convert the OMAP2, 3, and 4 clockdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com>
-
Paul Walmsley authored
The OMAP_REVBITS_* macros are just used as otherwise meaningless aliases for the numbers zero through five, so remove these macros. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
Paul Walmsley authored
omap3_cpuinfo() contains essentially duplicated code from omap3_check_revision(), just for the purpose of determining the chip ES level. Set the cpu_rev char array pointer in omap3_check_revision() instead, and drop the now-useless code from omap3_cpuinfo(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
Paul Walmsley authored
Emit a warning to the console in omap3_check_revision() if that code cannot determine what type of SoC the system is currently running on. Remove some extra whitespace, remove some duplicate code, and add an appropriate comment to a fallthrough case. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Hemant Pedanekar <hemantp@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
Paul Walmsley authored
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest of the OMAP2+ SoCs do in mach-omap2/cpu.c. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
Paul Walmsley authored
omap3_cpuinfo() is filled with useless strcpy() calls; remove them. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
Paul Walmsley authored
The OMAP3505/AM3505 appears to be based on the same silicon as the OMAP3517/AM3517, with some features disabled via eFuse bits. Follow the same practice as OMAP3430 and identify these devices internally as part of the OMAP3517/AM3517 family. The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon as the OMAP3430, with some features disabled via eFuse bits. Identify these devices internally as part of the OMAP3430 family. Remove the old OMAP35XX_CLASS, which actually covered two very different chip families. The OMAP3503/3515/3525/3530 chips will now be covered by OMAP343X_CLASS, since the silicon appears to be identical. For the OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS. Thanks to Tony Lindgren <tony@atomide.com> for some help with the second revision of this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
-
- 12 Sep, 2011 9 commits
-
-
Linus Torvalds authored
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm: Remove duplicate "return" statement drm/nv04/crtc: Bail out if FB is not bound to crtc drm/nouveau: fix nv04_sgdma_bind on non-"4kB pages" archs drm/nouveau: properly handle allocation failure in nouveau_sgdma_populate drm/nouveau: fix oops on pre-semaphore hardware drm/nv50/crtc: Bail out if FB is not bound to crtc drm/radeon/kms: fix DP detect and EDID fetch for DP bridges
-
git://git.linaro.org/people/arnd/arm-socLinus Torvalds authored
* 'fixes' of git://git.linaro.org/people/arnd/arm-soc: ARM: CSR: add missing sentinels to of_device_id tables ARM: cns3xxx: Fix newly introduced warnings in the PCIe code ARM: cns3xxx: Fix compile error caused by hardware.h removed ARM: davinci: fix cache flush build error ARM: davinci: correct MDSTAT_STATE_MASK ARM: davinci: da850 EVM: read mac address from SPI flash OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[] OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain OMAP4: clock: fix compile warning OMAP4: clock: re-enable previous clockdomain enable/disable sequence OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup OMAP: powerdomains: Make all powerdomain target states as ON at init
-
Mathieu Desnoyers authored
The LTTng 2.0 kernel tracer (stand-alone module package, available at http://lttng.org) uses the 0xF6 ioctl range for tracer control and transport operations. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://github.com/chrismason/linuxLinus Torvalds authored
* 'for-linus' of git://github.com/chrismason/linux: Btrfs: add dummy extent if dst offset excceeds file end in Btrfs: calc file extent num_bytes correctly in file clone btrfs: xattr: fix attribute removal Btrfs: fix wrong nbytes information of the inode Btrfs: fix the file extent gap when doing direct IO Btrfs: fix unclosed transaction handle in btrfs_cont_expand Btrfs: fix misuse of trans block rsv Btrfs: reset to appropriate block rsv after orphan operations Btrfs: skip locking if searching the commit root in csum lookup btrfs: fix warning in iput for bad-inode Btrfs: fix an oops when deleting snapshots
-
Miklos Szeredi authored
kmemleak is reporting that 32 bytes are being leaked by FUSE: unreferenced object 0xe373b270 (size 32): comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<b05517d7>] kmemleak_alloc+0x27/0x50 [<b0196435>] kmem_cache_alloc+0xc5/0x180 [<b02455be>] fuse_alloc_forget+0x1e/0x20 [<b0245670>] fuse_alloc_inode+0xb0/0xd0 [<b01b1a8c>] alloc_inode+0x1c/0x80 [<b01b290f>] iget5_locked+0x8f/0x1a0 [<b0246022>] fuse_iget+0x72/0x1a0 [<b02461da>] fuse_get_root_inode+0x8a/0x90 [<b02465cf>] fuse_fill_super+0x3ef/0x590 [<b019e56f>] mount_nodev+0x3f/0x90 [<b0244e95>] fuse_mount+0x15/0x20 [<b019d1bc>] mount_fs+0x1c/0xc0 [<b01b5811>] vfs_kern_mount+0x41/0x90 [<b01b5af9>] do_kern_mount+0x39/0xd0 [<b01b7585>] do_mount+0x2e5/0x660 [<b01b7966>] sys_mount+0x66/0xa0 This leak report is consistent and happens once per boot on 3.1.0-rc5-dirty. This happens if a FORGET request is queued after the fuse device was released. Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Miklos Szeredi authored
Commit 37fb3a30 ("fuse: fix flock") added in 3.1-rc4 caused flock() to fail with ENOSYS with the kernel ABI version 7.16 or earlier. Fix by falling back to testing FUSE_POSIX_LOCKS for ABI versions 7.16 and earlier. Reported-by: Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Tested-by: Martin Ziegler <ziegler@email.mathematik.uni-freiburg.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
-
Arnd Bergmann authored
-
- 11 Sep, 2011 4 commits
-
-
git://linuxtv.org/mchehab/for_linusLinus Torvalds authored
* 'v4l_for_linus' of git://linuxtv.org/mchehab/for_linus: [media] vp7045: fix buffer setup [media] nuvoton-cir: simplify raw IR sample handling [media] [Resend] viacam: Don't explode if pci_find_bus() returns NULL [media] v4l2: Fix documentation of the codec device controls [media] gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 [media] gspca - sonixj: Fix wrong register mask for sensor om6802 [media] gspca - ov519: Fix LED inversion of some ov519 webcams [media] pwc: precedence bug in pwc_init_controls()
-
git://openrisc.net/~jonas/linuxLinus Torvalds authored
* 'for-linus' of git://openrisc.net/~jonas/linux: Add missing DMA ops openrisc: don't use pt_regs in struct sigcontext
-
Li Zefan authored
You can see there's no file extent with range [0, 4096]. Check this by btrfsck: # btrfsck /dev/sda7 root 5 inode 258 errors 100 ... Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-
Li Zefan authored
num_bytes should be 4096 not 12288. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Chris Mason <chris.mason@oracle.com>
-