Re: [PATCH v5 3/4] regulator: pass additional of_node to regulator_register()
Hi Rajendra, On 18 November 2011 16:47, Rajendra Nayak rna...@ti.com wrote: With device tree support for regulators, its needed that the regulator_dev-dev device has the right of_node attached. To be able to do this add an additional parameter to the regulator_register() api, wherein the dt-adapted driver can then pass this additional info onto the regulator core. Signed-off-by: Rajendra Nayak rna...@ti.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Michael Hennerich michael.henner...@analog.com Cc: Ian Lartey i...@opensource.wolfsonmicro.com Cc: Dimitris Papastamos d...@opensource.wolfsonmicro.com Cc: Jaroslav Kysela pe...@perex.cz Cc: Takashi Iwai ti...@suse.de Cc: Wolfram Sang w.s...@pengutronix.de Cc: Zeng Zhaoming b32...@freescale.com Cc: Dan Carpenter erro...@gmail.com --- drivers/regulator/88pm8607.c | 2 +- drivers/regulator/aat2870-regulator.c | 2 +- drivers/regulator/ab3100.c | 2 +- drivers/regulator/ab8500.c | 2 +- drivers/regulator/ad5398.c | 2 +- drivers/regulator/bq24022.c | 2 +- drivers/regulator/core.c | 3 ++- drivers/regulator/da903x.c | 2 +- drivers/regulator/db8500-prcmu.c | 2 +- drivers/regulator/dummy.c | 2 +- drivers/regulator/fixed.c | 2 +- drivers/regulator/isl6271a-regulator.c | 2 +- drivers/regulator/lp3971.c | 2 +- drivers/regulator/lp3972.c | 2 +- drivers/regulator/max1586.c | 2 +- drivers/regulator/max8649.c | 2 +- drivers/regulator/max8660.c | 2 +- drivers/regulator/max8925-regulator.c | 2 +- drivers/regulator/max8952.c | 2 +- drivers/regulator/max8997.c | 2 +- drivers/regulator/max8998.c | 2 +- drivers/regulator/mc13783-regulator.c | 2 +- drivers/regulator/mc13892-regulator.c | 2 +- drivers/regulator/pcap-regulator.c | 2 +- drivers/regulator/pcf50633-regulator.c | 2 +- drivers/regulator/tps6105x-regulator.c | 3 ++- drivers/regulator/tps65023-regulator.c | 2 +- drivers/regulator/tps6507x-regulator.c | 2 +- drivers/regulator/tps6524x-regulator.c | 2 +- drivers/regulator/tps6586x-regulator.c | 2 +- drivers/regulator/tps65910-regulator.c | 2 +- drivers/regulator/tps65912-regulator.c | 2 +- drivers/regulator/twl-regulator.c | 2 +- drivers/regulator/wm831x-dcdc.c | 8 drivers/regulator/wm831x-isink.c | 2 +- drivers/regulator/wm831x-ldo.c | 6 +++--- drivers/regulator/wm8350-regulator.c | 2 +- drivers/regulator/wm8400-regulator.c | 2 +- drivers/regulator/wm8994-regulator.c | 2 +- include/linux/regulator/driver.h | 2 +- sound/soc/codecs/sgtl5000.c | 2 +- 41 files changed, 48 insertions(+), 46 deletions(-) Documentation/power/regulator/regulator.txt would also require an update the reflect the change in api. Thanks, Thomas. [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: TWL: add power off functionality
Hi Neil, On 12/03/11 03:35, NeilBrown wrote: On Sun, 27 Nov 2011 11:42:17 +0200 Igor Grinberg grinb...@compulab.co.il wrote: ping! pong ... Hi, I've been trying this patch out on my GTA04 with 3.2-rc4 and it doesn't work :-( Probably, v3.2-rc4 is not the best to try things out... This patch is based on v3.1, can you try v3.1, so at least we can check the that the patch itself has no problems? Also, CC'ing linux-omap. As soon as it tries to touch the i2c controller to send the power-down message I get: [ 96.130920] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa070008 [ 96.138885] Internal error: : 1028 [#1] PREEMPT [ 96.143585] Modules linked in: bluetooth ipv6 g_ether hso rfkill [ 96.149841] CPU: 0Not tainted (3.2.0-rc4+ #145) [ 96.155029] PC is at omap_i2c_wait_for_bb+0xc4/0x100 [ 96.160186] LR is at omap_i2c_wait_for_bb+0xac/0x100 [ 96.165344] pc : [c02e84d4]lr : [c02e84bc]psr: 6013 [ 96.165344] sp : d4a1ddc0 ip : d4a1dd20 fp : 0002 [ 96.177246] r10: 0002 r9 : c0d1f2c8 r8 : dbda9c00 [ 96.182678] r7 : c05d2a88 r6 : dbda9c00 r5 : 9aa8 r4 : c0d1f458 [ 96.189453] r3 : 0008 r2 : 0002 r1 : fa07 r0 : 0001 [ 96.196228] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 96.203643] Control: 10c5387d Table: 8bdc8019 DAC: 0015 [ 96.209625] Process poweroff (pid: 722, stack limit = 0xd4a1c2f0) The call trace is [ 96.373413] [c02e84d4] (omap_i2c_wait_for_bb+0xc4/0x100) from [c02e8aa8] (omap_i2c_xfer+0x34/0x4fc) [ 96.383178] [c02e8aa8] (omap_i2c_xfer+0x34/0x4fc) from [c02e6978] (i2c_transfer+0xac/0x130) [ 96.392211] [c02e6978] (i2c_transfer+0xac/0x130) from [c0259d20] (twl_i2c_read+0xd8/0x12c) [ 96.401153] [c0259d20] (twl_i2c_read+0xd8/0x12c) from [c025ba0c] (twl4030_power_off+0x34/0x124) [ 96.410583] [c025ba0c] (twl4030_power_off+0x34/0x124) from [c000f130] (machine_power_off+0x1c/0x28) [ 96.420349] [c000f130] (machine_power_off+0x1c/0x28) from [c004ad94] (sys_reboot+0x124/0x1e0) [ 96.429565] [c004ad94] (sys_reboot+0x124/0x1e0) from [c000e780] (ret_fast_syscall+0x0/0x3c) Have you modified the patch? Because, there is no twl_i2c_read() call in twl4030_power_off() function... Are there any other changes we need to be aware of? It has accessed this same address 0xfa070008 multiple times during normally running, but here at shutdown it gets an external abort. Presumably something is being turned of earlier in the shutdown sequence so that i2c is no longer available, but I have no idea what. What distro are you using? Does it do any kernel related sub systems power games? Do you have any idea what might be being disabled/turned-off/unmapped/ cleared/whatever that could cause this? No idea currently, I need to examine the changes between v3.1 and v3.2-rc4. I see: [ 96.029968] twl 1-0048: shutdown [ 96.038604] i2c i2c-1: shutdown amongst the messages, but as far as I can tell there is no actual shutdown method for these to call so they don't do anything. Ideas? I haven't seen those messages in my v3.1. I will try to look at this, but it will take time as I'm on something else right now. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: TWL: add power off functionality
On Sun, 04 Dec 2011 11:56:44 +0200 Igor Grinberg grinb...@compulab.co.il wrote: Hi Neil, On 12/03/11 03:35, NeilBrown wrote: On Sun, 27 Nov 2011 11:42:17 +0200 Igor Grinberg grinb...@compulab.co.il wrote: ping! pong ... Hi, I've been trying this patch out on my GTA04 with 3.2-rc4 and it doesn't work :-( Probably, v3.2-rc4 is not the best to try things out... This patch is based on v3.1, can you try v3.1, so at least we can check the that the patch itself has no problems? Also, CC'ing linux-omap. I think I'll be able to give 3.1 a try - I'll let you know. As soon as it tries to touch the i2c controller to send the power-down message I get: [ 96.130920] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa070008 [ 96.138885] Internal error: : 1028 [#1] PREEMPT [ 96.143585] Modules linked in: bluetooth ipv6 g_ether hso rfkill [ 96.149841] CPU: 0Not tainted (3.2.0-rc4+ #145) [ 96.155029] PC is at omap_i2c_wait_for_bb+0xc4/0x100 [ 96.160186] LR is at omap_i2c_wait_for_bb+0xac/0x100 [ 96.165344] pc : [c02e84d4]lr : [c02e84bc]psr: 6013 [ 96.165344] sp : d4a1ddc0 ip : d4a1dd20 fp : 0002 [ 96.177246] r10: 0002 r9 : c0d1f2c8 r8 : dbda9c00 [ 96.182678] r7 : c05d2a88 r6 : dbda9c00 r5 : 9aa8 r4 : c0d1f458 [ 96.189453] r3 : 0008 r2 : 0002 r1 : fa07 r0 : 0001 [ 96.196228] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 96.203643] Control: 10c5387d Table: 8bdc8019 DAC: 0015 [ 96.209625] Process poweroff (pid: 722, stack limit = 0xd4a1c2f0) The call trace is [ 96.373413] [c02e84d4] (omap_i2c_wait_for_bb+0xc4/0x100) from [c02e8aa8] (omap_i2c_xfer+0x34/0x4fc) [ 96.383178] [c02e8aa8] (omap_i2c_xfer+0x34/0x4fc) from [c02e6978] (i2c_transfer+0xac/0x130) [ 96.392211] [c02e6978] (i2c_transfer+0xac/0x130) from [c0259d20] (twl_i2c_read+0xd8/0x12c) [ 96.401153] [c0259d20] (twl_i2c_read+0xd8/0x12c) from [c025ba0c] (twl4030_power_off+0x34/0x124) [ 96.410583] [c025ba0c] (twl4030_power_off+0x34/0x124) from [c000f130] (machine_power_off+0x1c/0x28) [ 96.420349] [c000f130] (machine_power_off+0x1c/0x28) from [c004ad94] (sys_reboot+0x124/0x1e0) [ 96.429565] [c004ad94] (sys_reboot+0x124/0x1e0) from [c000e780] (ret_fast_syscall+0x0/0x3c) Have you modified the patch? Because, there is no twl_i2c_read() call in twl4030_power_off() function... Are there any other changes we need to be aware of? Yes I did, but with the unaltered patch I still got the crash in omap_i2c_wait_for_bb. I was just seeing if reading would work when writing didn't. It has accessed this same address 0xfa070008 multiple times during normally running, but here at shutdown it gets an external abort. Presumably something is being turned of earlier in the shutdown sequence so that i2c is no longer available, but I have no idea what. What distro are you using? Debian Does it do any kernel related sub systems power games? I don't think so, no. Do you have any idea what might be being disabled/turned-off/unmapped/ cleared/whatever that could cause this? No idea currently, I need to examine the changes between v3.1 and v3.2-rc4. I see: [ 96.029968] twl 1-0048: shutdown [ 96.038604] i2c i2c-1: shutdown amongst the messages, but as far as I can tell there is no actual shutdown method for these to call so they don't do anything. Ideas? I haven't seen those messages in my v3.1. I will try to look at this, but it will take time as I'm on something else right now. These messages are generated by having CONFIG_DEBUG_DRIVER defined. It's just showing that device_shutdown() had tried to shut these things down. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [RFC PATCH v1 5/7] media: v4l2: introduce two IOCTLs for face detection
Hi,
On Fri, Dec 2, 2011 at 8:33 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011 17:12:56 Ming Lei wrote:
+/**
+ * struct v4l2_fd_result - VIDIOC_G_FD_RESULT argument
+ * @buf_index: entry, index of v4l2_buffer for face detection
+ * @face_cnt: return, how many faces detected from the @buf_index
+ * @fd: return, result of faces' detection
+ */
+struct v4l2_fd_result {
+ __u32 buf_index;
+ __u32 face_cnt;
+ __u32 reserved[6];
+ struct v4l2_fd_detection *fd;
+};
This data structure is not 32/64 bit safe: running a 64 bit kernel with 32 bit
user space will see an incompatible layout.
I agree that this is not 32/64 bit safe, but I understand lib32 can handle
this correctly, otherwise many 32bit applications can't run on current
64bit kernel
since many kernel structures used by user space contained pointer,
such as struct v4l2_buffer, struct v4l2_ext_controls in v4l2 ABI.
One way to solve this is to remove the pointer and just start the array
directly after the __u32 members. Alternatively, you can use a __u64
to pass the pointer in an integer representation.
So I think this need not to be solved.
A nicer interface from the data structure perspective would be to
get rid of the array altogether and always return exactly one face.
I choose to return array to user space since v4l2 ioctl has provided
this kind of support, see video_usercopy().
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: Move dpll1 rates selection from config to runtime
For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm. Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate. Once done, remove no longer needed clock rate configure time options. Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Hi, Here is a list of changes against the initial version, submitted as patch 2a/5 v2 ARM: OMAP1: select clock rate by CPU type of the series ARM: OMAP1: Fix dpll1 reprogramming related issues: * drop no longer needed .config options, as suggested by Tony (thanks!), * follow selection conditions of those removed .config clock rate options more closely (I missed that before, ended up reinventing the wheel), * add extra clkdev platform flag for OMAP1710 to be able to limit the 216 MHz rate selection to this SoC subtype only, * update commit summary and message. I still wonder if it is sufficient to select a highest rate for a board based on a SoC type only, not on the board type itself. For example, the Amstrad Delta has been used to be running at 150 MHz since it was introduced first, while from now on it will be running at 168 MHz. I haven't noticed any visible issues so far, but who knows... Any opinions? Thanks, Janusz arch/arm/configs/omap1_defconfig |1 - arch/arm/mach-omap1/Kconfig | 64 - arch/arm/mach-omap1/clock.c |6 ++ arch/arm/mach-omap1/clock.h |3 + arch/arm/mach-omap1/clock_data.c |6 ++- arch/arm/mach-omap1/opp.h |1 + arch/arm/mach-omap1/opp_data.c| 63 +++- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + 8 files changed, 45 insertions(+), 100 deletions(-) diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig index 945a34f..dde2a1a 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -48,7 +48,6 @@ CONFIG_MACH_SX1=y CONFIG_MACH_NOKIA770=y CONFIG_MACH_AMS_DELTA=y CONFIG_MACH_OMAP_GENERIC=y -CONFIG_OMAP_ARM_182MHZ=y # CONFIG_ARM_THUMB is not set CONFIG_PCCARD=y CONFIG_OMAP_CF=y diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index 73f287d..4f8d66f 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -168,70 +168,6 @@ config MACH_OMAP_GENERIC custom OMAP boards. Say Y here if you have a custom board. -comment OMAP CPU Speed - depends on ARCH_OMAP1 - -config OMAP_ARM_216MHZ - bool OMAP ARM 216 MHz CPU (1710 only) -depends on ARCH_OMAP1 ARCH_OMAP16XX -help - Enable 216 MHz clock for OMAP1710 CPU. If unsure, say N. - -config OMAP_ARM_195MHZ - bool OMAP ARM 195 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP730 || ARCH_OMAP850) - help - Enable 195MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_192MHZ - bool OMAP ARM 192 MHz CPU - depends on ARCH_OMAP1 ARCH_OMAP16XX - help - Enable 192MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_182MHZ - bool OMAP ARM 182 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP730 || ARCH_OMAP850) - help - Enable 182MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_168MHZ - bool OMAP ARM 168 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) - help - Enable 168MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_150MHZ - bool OMAP ARM 150 MHz CPU - depends on ARCH_OMAP1 ARCH_OMAP15XX - help - Enable 150MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_120MHZ - bool OMAP ARM 120 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) - help - Enable 120MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_96MHZ - bool OMAP ARM 96 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) - help - Enable 96MHz clock for OMAP CPU. If unsure, say N. - -config OMAP_ARM_60MHZ - bool OMAP ARM 60 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) -default y - help - Enable 60MHz clock for OMAP CPU. If unsure, say Y. - -config OMAP_ARM_30MHZ - bool OMAP ARM 30 MHz CPU - depends on ARCH_OMAP1 (ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_OMAP850) - help -
Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data
On 18 November 2011 16:47, Rajendra Nayak rna...@ti.com wrote:
The helper routine is meant to be used by the regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Similarly the regulator--parent/supply mapping is handled in
subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Some of the regulator properties which are linux and board specific,
are left out since its not clear if they can
be in someway embedded into the kernel or passed in from DT.
They will be revisited later.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/regulator/regulator.txt | 54 +
drivers/regulator/Makefile | 1 +
drivers/regulator/of_regulator.c | 81
include/linux/regulator/of_regulator.h | 20 +
4 files changed, 156 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..82bef20
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,54 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-name: A string used as a descriptive name for regulator outputs
+- regulator-min-microvolt: smallest voltage consumers may set
+- regulator-max-microvolt: largest voltage consumers may set
+- regulator-microvolt-offset: Offset applied to voltages to compensate for
voltage drops
+- regulator-min-microamp: smallest current consumers may set
+- regulator-max-microamp: largest current consumers may set
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+- name-supply: phandle to the parent supply/regulator node
For regulators that are not turned on by bootloader, and which require
'apply_uV' constraint, is there any alternative for turning on the
regulator when using dt?
Or, how about adding a additional check as below.
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5baa196..25a6781 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -816,8 +816,9 @@ static int machine_constraints_voltage(struct
regulator_dev *rdev,
int ret;
/* do we need to apply the constraint voltage */
- if (rdev-constraints-apply_uV
- rdev-constraints-min_uV == rdev-constraints-max_uV) {
+ if ((rdev-constraints-apply_uV
+ rdev-constraints-min_uV == rdev-constraints-max_uV) ||
+ (!rdev-constraints-boot_on rdev-constraints-always_on)) {
ret = _regulator_do_set_voltage(rdev,
rdev-constraints-min_uV,
rdev-constraints-max_uV);
Thanks,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mdt nand: omap2+ use platform options
On Fri, 2011-12-02 at 09:28 -0800, Brian Norris wrote: On Fri, Dec 2, 2011 at 2:20 AM, Grazvydas Ignotas nota...@gmail.com wrote: On Thu, Dec 1, 2011 at 10:42 AM, Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote: Signed-off-by: Jan Weitzel j.weit...@phytec.de Pushed to l2-mtd-2.6.git, thank you! This breaks build here, did you really test it, Jan? drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': drivers/mtd/nand/omap2.c:1078: error: 'struct omap_nand_platform_data' has no member named 'options' This is exactly what I was asking already. I don't see 'options' in 'struct omap_nand_platform_data' in 'arch/arm/plat-omap/include/plat/nand.h', even in linux-next. Yes, sorry, I've payed not enough attention to the patch. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH] ARM: OMAP1: Always reprogramme dpll1 rate at boot.
DPLL1 reprogramming to a different rate is actually blocked inside
omap1_select_table_rate(). However, it is already forced at boot, for
boards which boot at unusable clock rates, and this seems to work
correctly.
OTOH, we now have a fine, run time performed clock selection algorithm
implemented, which prevents less powerfull SoCs from being overclocked
unintentionally.
Allow reprogramming of dpll1 by default, and use it for switching to the
higest supported clock rate with all boards, including those already
booting at a usable rate of 60 MHz or above.
Created against linux-omap/master tip as of Thu Dec 1,
commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Requires the just
submitted patch ARM: OMAP1: Move dpll1 rates selection from config to
runtime to prevent from unintentional overclocking. Tested on Amstrad
Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/clock.c |4
arch/arm/mach-omap1/clock_data.c |6 --
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 84ef704..6993cd0 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -200,10 +200,6 @@ int omap1_select_table_rate(struct clk *clk, unsigned long
rate)
if (ptr-xtal != ref_rate)
continue;
- /* DPLL1 cannot be reprogrammed without risking system crash */
- if (likely(dpll1_rate != 0) ptr-pll_rate != dpll1_rate)
- continue;
-
/* Can check only after xtal frequency check */
if (ptr-rate = rate)
break;
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 9ff90a7..8629178 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -931,12 +931,6 @@ void __init omap1_clk_late_init(void)
{
unsigned long rate = ck_dpll1.rate;
- if (rate = OMAP1_DPLL1_SANE_VALUE)
- return;
-
- /* System booting at unusable rate, force reprogramming of DPLL1 */
- ck_dpll1_p-rate = 0;
-
/* Find the highest supported frequency and enable it */
if (omap1_select_table_rate(virtual_ck_mpu, ~0)) {
pr_err(System frequencies not set, using default. Check your
config.\n);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data
On Sun, Dec 04, 2011 at 06:51:23PM +0530, Thomas Abraham wrote:
For regulators that are not turned on by bootloader, and which require
'apply_uV' constraint, is there any alternative for turning on the
regulator when using dt?
If the regulator isn't software managed then always_on covers this - the
regulator core will enable any always_on regulators that haven't been
enabled already.
/* do we need to apply the constraint voltage */
- if (rdev-constraints-apply_uV
- rdev-constraints-min_uV == rdev-constraints-max_uV) {
+ if ((rdev-constraints-apply_uV
+ rdev-constraints-min_uV == rdev-constraints-max_uV) ||
+ (!rdev-constraints-boot_on rdev-constraints-always_on)) {
ret = _regulator_do_set_voltage(rdev,
rdev-constraints-min_uV,
rdev-constraints-max_uV);
I'm not sure I understand the intended logic there. Voltage constraints
and enable/disable constraints are orthogonal here.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: TWL: add power off functionality
On Sun, 4 Dec 2011 21:58:59 +1100 NeilBrown ne...@suse.de wrote:
On Sun, 04 Dec 2011 11:56:44 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Neil,
On 12/03/11 03:35, NeilBrown wrote:
On Sun, 27 Nov 2011 11:42:17 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
ping!
pong ...
Hi,
I've been trying this patch out on my GTA04 with 3.2-rc4 and it doesn't
work :-(
Probably, v3.2-rc4 is not the best to try things out...
This patch is based on v3.1, can you try v3.1, so at least we can
check the that the patch itself has no problems?
Also, CC'ing linux-omap.
I think I'll be able to give 3.1 a try - I'll let you know.
Yes, works fine with 3.1
I've managed to find the problem.
commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9
Author: Peter Chen peter.c...@freescale.com
Date: Tue Nov 15 21:52:29 2011 +0100
PM / driver core: disable device's runtime PM during shutdown
@@ -1742,6 +1743,8 @@ void device_shutdown(void)
*/
list_del_init(dev-kobj.entry);
spin_unlock(devices_kset-list_lock);
+ /* Disable all device's runtime power management */
+ pm_runtime_disable(dev);
if (dev-bus dev-bus-shutdown) {
dev_dbg(dev, shutdown\n);
Removing this call allows power-off to work.
It seems that omap_i2c.1 is normally in runtime suspend.
omap_i2c_xfer wakes it up, performs the xfer, then puts it back to sleep.
So this pm_runtime_disable is called while the device is asleep, so it stays
asleep. omap_i2c_xfer cannot wake it up and so cannot xfer anything.
I'll start a new thread including the people responsible for that patch.
Thanks for your time,
NeilBrown
signature.asc
Description: PGP signature
Re: [RFC PATCH v1 4/7] media: videobuf2: introduce VIDEOBUF2_PAGE memops
Hi, On Sat, Dec 3, 2011 at 12:35 AM, Aguirre, Sergio saagui...@ti.com wrote: Hi Ming, diff --git a/include/media/videobuf2-page.h b/include/media/videobuf2-page.h new file mode 100644 index 000..29b3e20 --- /dev/null +++ b/include/media/videobuf2-page.h @@ -0,0 +1,20 @@ +/* + * videobuf2-vmalloc.h - vmalloc memory allocator for videobuf2 + * + * Copyright (C) 2010 Samsung Electronics + * + * Author: Pawel Osciak pa...@osciak.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation. + */ + +#ifndef _MEDIA_VIDEOBUF2_VMALLOC_H +#define _MEDIA_VIDEOBUF2_VMALLOC_H Copy-paste much? :) Yes, will fix it in next version, :-) thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 2/7] omap4: build fdif omap device from hwmod
Hi,
On Fri, Dec 2, 2011 at 8:10 PM, Sergei Shtylyov sshtyl...@ru.mvista.com wrote:
Hello.
On 02-12-2011 13:12, Ming Lei wrote:
Signed-off-by: Ming Leiming@canonical.com
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1166bdc..a392af5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -728,6 +728,38 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
+static struct platform_device* __init omap4_init_fdif(void)
Shouldn't there be space before *? checkpatch.pl is silent about it?
ALso, I'd have placed '__init' after 'static'...
Yes, you are right, will do do it in next version.
+{
+ int id = -1;
+ struct platform_device *pd;
+ struct omap_hwmod *oh;
+ const char *dev_name = fdif;
Why you need this variable at all?
Will remove some of them.
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 2/7] omap4: build fdif omap device from hwmod
Hi,
On Sat, Dec 3, 2011 at 12:28 AM, Aguirre, Sergio saagui...@ti.com wrote:
Hi Ming,
Thanks for the patches.
Thanks for your review.
On Fri, Dec 2, 2011 at 9:02 AM, Ming Lei ming@canonical.com wrote:
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/devices.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1166bdc..a392af5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -728,6 +728,38 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
+static struct platform_device* __init omap4_init_fdif(void)
+{
+ int id = -1;
You could remove this , as it is being used only once, and never changed.
Yes.
+ struct platform_device *pd;
+ struct omap_hwmod *oh;
+ const char *dev_name = fdif;
+
+ oh = omap_hwmod_lookup(fdif);
+ if (!oh) {
+ pr_err(Could not look up fdif hwmod\n);
+ return NULL;
+ }
+
+ pd = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
Just do:
pd = omap_device_build(dev_name, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pd), Can't build omap_device for %s.\n,
+ dev_name);
+ return pd;
+}
+
+static void __init omap_init_fdif(void)
+{
+ if (cpu_is_omap44xx()) {
+ struct platform_device *pd;
+
+ pd = omap4_init_fdif();
+ if (!pd)
+ return;
+
+ pm_runtime_enable(pd-dev);
+ }
+}
IMHO, you could reduce 1 level of indentation here, like this:
static void __init omap_init_fdif(void)
{
struct platform_device *pd;
if (!cpu_is_omap44xx())
return;
pd = omap4_init_fdif();
if (!pd)
return;
pm_runtime_enable(pd-dev);
}
OK, will take this.
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] regulator: pass additional of_node to regulator_register()
Documentation/power/regulator/regulator.txt would also require an update the reflect the change in api. Thanks Thomas, I just sent a patch to fix this up. regards, Rajendra Thanks, Thomas. [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: TWL: add power off functionality
On 12/04/11 23:43, NeilBrown wrote:
On Sun, 4 Dec 2011 21:58:59 +1100 NeilBrown ne...@suse.de wrote:
On Sun, 04 Dec 2011 11:56:44 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
Hi Neil,
On 12/03/11 03:35, NeilBrown wrote:
On Sun, 27 Nov 2011 11:42:17 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
ping!
pong ...
Hi,
I've been trying this patch out on my GTA04 with 3.2-rc4 and it doesn't
work :-(
Probably, v3.2-rc4 is not the best to try things out...
This patch is based on v3.1, can you try v3.1, so at least we can
check the that the patch itself has no problems?
Also, CC'ing linux-omap.
I think I'll be able to give 3.1 a try - I'll let you know.
Yes, works fine with 3.1
Good to hear!
I've managed to find the problem.
commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9
Author: Peter Chen peter.c...@freescale.com
Date: Tue Nov 15 21:52:29 2011 +0100
PM / driver core: disable device's runtime PM during shutdown
@@ -1742,6 +1743,8 @@ void device_shutdown(void)
*/
list_del_init(dev-kobj.entry);
spin_unlock(devices_kset-list_lock);
+ /* Disable all device's runtime power management */
+ pm_runtime_disable(dev);
if (dev-bus dev-bus-shutdown) {
dev_dbg(dev, shutdown\n);
Removing this call allows power-off to work.
It seems that omap_i2c.1 is normally in runtime suspend.
omap_i2c_xfer wakes it up, performs the xfer, then puts it back to sleep.
So this pm_runtime_disable is called while the device is asleep, so it stays
asleep. omap_i2c_xfer cannot wake it up and so cannot xfer anything.
Good job on that investigation.
There were several discussions runtime pm related at the kernel summit,
but I failed to see the impact of that on the issue...
I'll start a new thread including the people responsible for that patch.
Hopefully, it will get us a solution.
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
