- 27 May, 2011 40 commits
-
-
Mark Brown authored
When applying the set_voltage() requests from consumers skip over those consumers that haven't set anything, otherwise we'll come out with a maximum voltage of zero. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk>
-
Mark Brown authored
If either a regulator driver can't tell us what the optimum mode is (or doesn't have modes in the first place) or the system doesn't allow DRMS changes then it's more helpful for users to just say that we're in the optimal mode, even if it's from a selection of one. Still report errors if the process of picking and setting a mode changes as this may indicate that we're stuck in a low power mode and unable to deliver a higher current that the consumer just asked for. Signed-off-by:
-
Jonghwan Choi authored
fix unreachable code. Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by:
MyungJoo Ham <myungjoo.ham@samsung.com> Acked-by:
-
Axel Lin authored
Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Kyungmin Park <kyungmin.park@samsung.com> Acked-by:
-
Axel Lin authored
The desc_id variable should not be a static variable. The rest of the code assumes the desc_id must less than TPSxxxxx_NUM_REGULATOR. If we set desc_id to be a static variable, checking the return value of rdev_get_id() may return error. Signed-off-by:
-
Jorge Eduardo Candelaria authored
On May 10, 2011, at 9:27 PM, Stephen Rothwell wrote: > Hi Jorge, > > On Tue, 10 May 2011 12:30:36 -0500 Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> wrote: >> >> On May 10, 2011, at 3:38 AM, Liam Girdwood wrote: >> >>> On Tue, 2011-05-10 at 12:44 +1000, Stephen Rothwell wrote: >>>> Hi Liam, >>>> >>>> After merging the voltage tree, today's linux-next build (x86_64 >>>> allmodconfig) failed like this: >>>> >>>> ERROR: "tps65910_gpio_init" [drivers/mfd/tps65910.ko] undefined! >>>> ERROR: "tps65910_irq_init" [drivers/mfd/tps65910.ko] undefined! >>>> ERROR: "irq_modify_status" [drivers/mfd/tps65910-irq.ko] undefined! >>>> ERROR: "irq_set_chip_and_handler_name" [drivers/mfd/tps65910-irq.ko] undefined! >>>> ERROR: "handle_edge_irq" [drivers/mfd/tps65910-irq.ko] undefined! >>>> >>>> I have used the voltage tree from next-20110509 for today. >>> >>> Jorge, could you send a fix for this today. >> >> The following patch should solve this: >> >> From: Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> >> MFD: Fix TPS65910 build >> >> Support for tps65910 as a module is not available. The driver can >> only be compiled as built-in. OTOH, the regulator driver can still >> be built as module without breaking the compilation. >> >> Signed-off-by: Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> > > Today (even with the above patch included) I got these errors from the > x86_64 allmodconfig build: > > tps65910.c:(.text+0xf4140): undefined reference to `i2c_master_send' > drivers/built-in.o: In function `tps65910_i2c_read': > tps65910.c:(.text+0xf41d2): undefined reference to `i2c_transfer' > drivers/built-in.o: In function `tps65910_i2c_init': > tps65910.c:(.init.text+0xcb83): undefined reference to `i2c_register_driver' > drivers/built-in.o: In function `tps65910_i2c_exit': > tps65910.c:(.exit.text+0x6e0): undefined reference to `i2c_del_driver' > > I have used the voltage tree from next-20110509 again today. Following patch should fix the dependency problems. Please review: From: Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> [PATCH] MFD: TPS65910: Fix I2C dependency TPS65910 driver can only be compiled built-in, so the I2C driver should be as well. Signed-off-by:
Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> Signed-off-by:
-
Axel Lin authored
I check this patch again and found this actually is not a bug because MC13xxx_DEFINE explictly defines the order of each entry in the array. Thus revert the patch. Signed-off-by:
-
Mark Brown authored
These became unused with the IRQ removal patch, I'm fairly sure that a patch was sent earlier by someone else but it doesn't seem to have been applied and I don't have a copy sitting around any more. Signed-off-by:
-
Jorge Eduardo Candelaria authored
On May 10, 2011, at 3:38 AM, Liam Girdwood wrote: > On Tue, 2011-05-10 at 12:44 +1000, Stephen Rothwell wrote: >> Hi Liam, >> >> After merging the voltage tree, today's linux-next build (x86_64 >> allmodconfig) failed like this: >> >> ERROR: "tps65910_gpio_init" [drivers/mfd/tps65910.ko] undefined! >> ERROR: "tps65910_irq_init" [drivers/mfd/tps65910.ko] undefined! >> ERROR: "irq_modify_status" [drivers/mfd/tps65910-irq.ko] undefined! >> ERROR: "irq_set_chip_and_handler_name" [drivers/mfd/tps65910-irq.ko] undefined! >> ERROR: "handle_edge_irq" [drivers/mfd/tps65910-irq.ko] undefined! >> >> I have used the voltage tree from next-20110509 for today. > > Jorge, could you send a fix for this today. > > Thanks > > Liam > The following patch should solve this: From: Jorge Eduardo Candelaria <jedu@slimlogic.co.uk> MFD: Fix TPS65910 build Support for tps65910 as a module is not available. The driver can only be compiled as built-in. OTOH, the regulator driver can still be built as module without breaking the compilation. Signed-off-by:
-
Graeme Gregory authored
The regulator module consists of 3 DCDCs and 8 LDOs. The output voltages are configurable and are meant to supply power to the main processor and other components Signed-off-by:
Graeme Gregory <gg@slimlogic.co.uk> Signed-off-by:
-
Graeme Gregory authored
This module controls the interrupt handling for the tps chip. The interrupt sources are the following: - GPIO falling/rising edge detection - Battery voltage below/above threshold - PWRON signal - PWRHOLD signal - Temperature detection - RTC alarm and periodic event Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Graeme Gregory authored
TPS65910 has one configurable GPIO that can be used for several purposes. Subsequent versions of the TPS chip support more than one GPIO. Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Graeme Gregory authored
The TPS65910 chip is a power management IC for multimedia and handheld devices. It contains the following components: - Regulators - GPIO controller - RTC The tps65910 core driver is registered as a platform driver and provides communication through I2C with the host device for the different components. Signed-off-by:
-
Axel Lin authored
Currently, we call mc13xxx_reg_read and mc13xxx_reg_rmw for the same register. This can be converted to simply a mc13xxx_reg_read and a mc13xxx_reg_write, thus save a redundant register read. Signed-off-by:
-
Mark Brown authored
Some systems, particularly physically large systems used for early prototyping, may experience substantial voltage drops between the regulator and the consumers as a result of long traces in the system. With these systems voltages may need to be set higher than requested in order to ensure reliable system operation. Allow systems to work around such hardware issues by allowing constraints to supply an offset to be applied to any requested and reported voltages. This is not ideal, especially since the voltage drop may be load dependant, but is sufficient for most affected systems, it is not expected to be used in production hardware. The offset is applied after all constraint processing so constraints should be specified in terms of consumer values not physically configured values. Signed-off-by:
-
Mark Brown authored
supply_regulator_dev (using a struct pointer) has been deprecated in favour of supply_regulator (using a regulator name) for quite a few releases now with a warning generated if it is used and there are no current in tree users so just remove the code. Signed-off-by:
-
Axel Lin authored
In include/linux/mfd/mc13892.h, we define MC13892_VCOINCELL as 23. Thus VCOINCELL should be defined as 23th element in mc13892_regulators array, not the first one. This actually fixes an off-by-one bug while accessing mc13892_regulators array. For example, In mc13892_regulator_probe, we use MC13892_VCAM as array index of mc13892_regulators array. mc13892_regulators[MC13892_VCAM].desc.ops->set_mode = mc13892_vcam_set_mode; Currently, it access mc13892_regulators[12] ,which is VAUDIO not VCAM. Signed-off-by: -
Mark Brown authored
Don't go looking up the rdev pointer every time, just use a local variable like everything else. Signed-off-by:
-
Mark Brown authored
Signed-off-by:
-
Axel Lin authored
The second parameter of regulator_mode_constrain takes a pointer. This patch fixes below warning: drivers/regulator/core.c: In function 'regulator_set_mode': drivers/regulator/core.c:2014: warning: passing argument 2 of 'regulator_mode_constrain' makes pointer from integer without a cast drivers/regulator/core.c:200: note: expected 'int *' but argument is of type 'unsigned int' Signed-off-by:
Liam Girdwood <lrg@vega.(none)>
-
Saquib Herman authored
Current set_mode logic does not support 6030. The logic for 4030 is not reusable for 6030 as the mode setting for 6030 now uses the new CFG_STATE register. We hence rename the old get_status as being specific to 4030. Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Saquib Herman <saquib@ti.com> Acked-by:
-
Saquib Herman authored
Current get_status logic does not support 6030 get_status. The logic for 4030 is not reusable for 6030 as the status check for 6030 now depends on the new CFG_STATE register. We hence rename the old get_status as being specific to 4030 and remove the redundant check for the same. Signed-off-by:
-
Saquib Herman authored
With TWL6030, it is not enough to ensure that the regulator is the group of P1 group (CPU/Linux), but we need to check the state as far as APP is concerned as well. Split the current is_enabled to 6030 and 4030 specific ones. This split impacts few macros and variables as well, but sets up the stage for further fixes to set_mode and get_status in subsequent patches. Signed-off-by:
-
Saquib Herman authored
TWL6030 does not have remap register. The current implementation causes value of remap to be written to state register, accidentally causing the regulators which are probed to be switched on as well. This is wrong as regulators should be controllable based on calls to enable/disable for TWL regulator framework. Further, the values initialized make no sense as well. We hence remove this from the initalizers and also write to remap register only if the TWL is 4030. Signed-off-by:
-
Saquib Herman authored
TWL6030 requires an additional register write to CFG_STATE register to explicitly state that the regulator is in a certain state. Merely associating the regulator with the group is not enough. Add the required register field definitions and fix the handling for TWL6030 enable/disable. Signed-off-by:
-
Axel Lin authored
Otherwise, calling platform_get_drvdata in tps6105x_regulator_remove returns NULL. Signed-off-by:
-
Mark Brown authored
If a mode requested by a consumer is not allowed by constraints automatically fall back to a higher power mode if possible. This ensures that consumers get at least the output they requested while allowing machine drivers to transparently limit lower power modes if required. Signed-off-by:
-
Linus Torvalds authored
Merge branch 'upstream/tidy-xen-mmu-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen * 'upstream/tidy-xen-mmu-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen: xen: fix compile without CONFIG_XEN_DEBUG_FS Use arbitrary_virt_to_machine() to deal with ioremapped pud updates. Use arbitrary_virt_to_machine() to deal with ioremapped pmd updates. xen/mmu: remove all ad-hoc stats stuff xen: use normal virt_to_machine for ptes xen: make a pile of mmu pvop functions static vmalloc: remove vmalloc_sync_all() from alloc_vm_area() xen: condense everything onto xen_set_pte xen: use mmu_update for xen_set_pte_at() xen: drop all the special iomap pte paths.
-
Linus Torvalds authored
Right now security_get_user_sids() will pass in a NULL avd pointer to avc_has_perm_noaudit(), which then forces that function to have a dummy entry for that case and just generally test it. Don't do it. The normal callers all pass a real avd pointer, and this helper function is incredibly hot. So don't make avc_has_perm_noaudit() do conditional stuff that isn't needed for the common case. This also avoids some duplicated stack space. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-linusLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/pkl/squashfs-linus: Squashfs: update email address Squashfs: add extra sanity checks at mount time Squashfs: add sanity checks to fragment reading at mount time Squashfs: add sanity checks to lookup table reading at mount time Squashfs: add sanity checks to id reading at mount time Squashfs: add sanity checks to xattr reading at mount time Squashfs: reverse order of filesystem table reading Squashfs: move table allocation into squashfs_read_table()
-
Akinobu Mita authored
The implementation of find_next_bit_le() on m68knommu is identical with the generic implementation of find_next_bit_le(). Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Akinobu Mita authored
The previous style change enables to use asm-generic/bitops/le.h on s390. Signed-off-by:
-
Akinobu Mita authored
The previous style change enables to use asm-generic/bitops/le.h on arm. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by:
-
Akinobu Mita authored
By the previous style change, CONFIG_GENERIC_FIND_NEXT_BIT, CONFIG_GENERIC_FIND_BIT_LE, and CONFIG_GENERIC_FIND_LAST_BIT are not used to test for existence of find bitops anymore. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Akinobu Mita authored
The style that we normally use in asm-generic is to test the macro itself for existence, so in asm-generic, do: #ifndef find_next_zero_bit_le extern unsigned long find_next_zero_bit_le(const void *addr, unsigned long size, unsigned long offset); #endif and in the architectures, write static inline unsigned long find_next_zero_bit_le(const void *addr, unsigned long size, unsigned long offset) #define find_next_zero_bit_le find_next_zero_bit_le This adds the #ifndef for each of the find bitops in the generic header and source files. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Akinobu Mita authored
The style that we normally use in asm-generic is to test the macro itself for existence, so in asm-generic, do: #ifndef find_next_zero_bit_le extern unsigned long find_next_zero_bit_le(const void *addr, unsigned long size, unsigned long offset); #endif and in the architectures, write static inline unsigned long find_next_zero_bit_le(const void *addr, unsigned long size, unsigned long offset) #define find_next_zero_bit_le find_next_zero_bit_le This adds the #define for each of the optimized find bitops in the architectures. Suggested-by:
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Akinobu Mita authored
m68knommu can't build ext4, udf, and ocfs2 due to the lack of find_next_bit_le(). This implements find_next_bit_le() on m68knommu by duplicating the generic find_next_bit_le() in lib/find_next_bit.c. Signed-off-by:
-
Clifton Barnes authored
Add support for the Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC. It was suggested to combine this functionality with the current ds2782 driver. Unfortunately, I'm unable to commit the time to refactoring this driver to that extent and I don't have a platform with the ds2782 part to validate that there are no regression issues by adding this functionality. [akpm@linux-foundation.org: use min_t()] Signed-off-by:
Clifton Barnes <cabarnes@indesign-llc.com> Tested-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Ryan Mallon <ryan@bluewatersys.com> Signed-off-by:
-
David Fries authored
Reorganize so the netlink connector one wire search command will update the kernel list of detected slave devices. Otherwise, a newly detected device is unusable because unless it's in the kernel list of known devices any commands will result in ENODEV status. Signed-off-by:
David Fries <David@Fries.net> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Jean-François Dagenais authored
This adds multi-slave support of the w1 bus for the ds1wm Synthesizable 1-Wire Bus Master. Also many fixes and tweaks based on the rev3 of the datasheet http://datasheets.maxim-ic.com/en/ds/DS1WM.pdfSigned-off-by:
Jean-François Dagenais <dagenaisj@sonatest.com> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Cc: Szabolcs Gyurko <szabolcs.gyurko@tlt.hu> Cc: Matt Reimer <mreimer@vpop.net> Signed-off-by:
-
