On Monday 24 October 2011 02:41 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 02:26:49PM +0530, Rajendra Nayak wrote:
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
Okay, it's wrong then since so many people say it's wrong :) I guess
a quick fix would be adding one property
On Monday 24 October 2011 02:32 PM, Shawn Guo wrote:
On Mon, Oct 24, 2011 at 10:17:06AM +0200, Grant Likely wrote:
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak
On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
[...]
+ /* find device_node and attach it
On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
[...]
+ /* find device_node and attach it */
+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
so would this do a complete dt search for
Do you have any RFC patch/code which could explain better what you are
suggesting we do here?
Here is what I changed based on your patches. It only changes
drivers/regulator/core.c.
---8<---
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 9a5ebbe..8fe132d 100644
--
We can always start off just completely omitting the data and then see
how we go from there. If we only cover 50% of users that's still 50%
more than are currently covered with device tree right now and it means
we can then spin round and look at the bits that are hard again without
review fatig
On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
Let's look at mc13892-regulator driver. There are 23 regulators defined
in array mc13892_regulators. Needless to say, there is a dev behind
mc13892-regulator driver.
I'm not sure why twl works in that way. Is it a sign that those
configuration peeked by twl regulator driver should be encoded in twl
regulator driver itself instead of being passed from the board? Or
No, the driver is just trying to make sure that nothing invalid (not
supported by hardware)
On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote:
The problem is that the DT is supposed to be separate to the kernel and
the decisions can depend on what the kernel is currently capable of.
When the data is embedded in the kernel it's not an issue as the data is
attached to the rest of th
On Tuesday 18 October 2011 06:50 PM, Shawn Guo wrote:
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies&#
I do not see that of_get_regulation_constraints() covers the following
fields. We do not support them for DT probe?
I left these out as I wasn't sure how such (if at all) Linux specific
params should be passed through dt, and I am still not quite sure :(
struct regulation_constraints {
On Monday 10 October 2011 10:52 PM, Mark Brown wrote:
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator
@@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+ if (!dev)
+ list_for_each_entry(rdev,®ulator_list, list)
+ if (strcmp(rdev_get_name(rd
On Monday 10 October 2011 09:55 PM, Mark Brown wrote:
On Mon, Oct 10, 2011 at 09:49:34PM +0530, Rajendra Nayak wrote:
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
Acked-by: Mark Brown
The fixed regulator driver uses of_get_fixed_voltage_config()
to extract fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak
---
.../bindings/regulator/fixed
ifferently,
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.
Signed-off-by: Rajendra Nayak
---
.../dev
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak
---
drivers/regulator/core.c | 91 +++--
include/linux/regulator/driver.h |2 +
2 files changed, 78 insertions(+), 15 deletions(-)
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
Acked-by: Mark Brown
---
drivers/regulator/twl-regulator.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a
Add empty of_device_is_compatible(), of_find_property()
and of_parse_phandle() for non-dt builds to work.
Signed-off-by: Rajendra Nayak
---
include/linux/of.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
(ex: cpufreq)
-4- used same binding for regulator<->consumer and regulator<->parent mapping
regards,
Rajendra
Rajendra Nayak (5):
regulator: twl: Remove hardcoded board constraints from driver
dt: add empty dt helpers for non-dt build
regulator: helper routine to extract regulat
Hi Kevin,
On Wednesday 05 October 2011 02:33 AM, Kevin Hilman wrote:
Hi Rajendra,
Rajendra Nayak writes:
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
This seems fairly straightforward though it will require some changes
within Linux, all we have to do is have the
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property b
On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
The "regulator-supplies" is used to specific the regulator *parent*.
Same as what was earlier passed by using the
"supply_regulator" field of regulator
On Monday 03 October 2011 10:30 AM, Govindraj wrote:
Thanks for the review,
On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak wrote:
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to determine IO-PAD wakeup event status for a given
hwmod dynamic_mux pad.
Wake up event set will be cleared on pad mux_read.
Are these api's even getting used in this series?
Signed-off-by: Govindraj.R
---
arch/arm/mach-oma
On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
Add API to enable IO pad wakeup capability based on mux dynamic pad and
wake_up enable flag available from hwmod_mux initialization.
Use the wakeup_enable flag and enable wakeup capability
for the given pads. Wakeup capability will be enab
On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
+ init_data->supply_regulator = (char *)of_get_property(dev->o
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
On 9/27/2011 8:59 PM, Mark Brown wrote:
I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just
On Friday 30 September 2011 07:08 AM, Grant Likely wrote:
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Devices can
[]...
+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
+ "regulator-supplies", NULL);
I'd expect that in the device tree world the supply regulator would
reference the node for that regulator.
You mean using phandles
On Wednesday 28 September 2011 12:29 AM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
+ if (!dev)
+ return NULL
On Wednesday 28 September 2011 01:39 PM, Cousson, Benoit wrote:
On 9/27/2011 8:59 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote
On Tuesday 27 September 2011 05:53 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
As with the
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
+ if (!dev)
+ return NULL;
So how do we handle CPUs? cpufreq is one of the most active users of
regulators...
Hmm, never thought of it :(
Maybe I
On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
On Tuesday 27 September 2011 05:44 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ charcompatible[128];
+#endif
Might it not be better to just make this a pointer to const char?
Yes, my bad.
--
To
On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+GFP_KERNEL);
+ if (!init_data
On Tuesday 27 September 2011 05:07 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c | 117 -
1 files
ifferently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak
---
.../devicetree/bindings/regulator/regulator.txt| 42 +
drivers/regulat
Pass adjustable regulator information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak
---
.../bindings
device node.
Signed-off-by: Rajendra Nayak
---
drivers/regulator/core.c | 14 ++
include/linux/regulator/driver.h |3 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..47b851c 100644
-
Pass the fixed and adjustable voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap4-panda.dts | 54 +
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak
---
.../bindings/regulator/fixed-regulator.txt
or1>;
vpll-supply = <®ulator1>;
};
The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/fixed.c | 18 +-
1 files changed, 17 insertions(+), 1
way devices associate with regulators
i.e using -supply = <®ulator-phandle>;
regards,
Rajendra
Rajendra Nayak (9):
regulator: twl: Remove hardcoded board constraints from driver
regulator: helper routine to extract regulator_init_data
omap4: sdp: Pass regulator data from dt
regulator:
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/twl
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Add documentation for GPIO properties specific to OMAP.
Remove an un-needed
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson
Cc: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap4.dtsi | 32
1 files changed, 32 insertions(+), 0 deletions(-)
dif
On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
Add initial device-tree support for twl familly chips.
s/familly/family
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
p
Hi Benoit,
On Saturday 24 September 2011 01:53 AM, Benoit Cousson wrote:
Re-cycle the original board-generic file to support Device Tree
for every OMAP2+ variants.
Note: Since it is a completely new content in the existing file
I removed the original copyright.
The current approach is an interm
On Friday 16 September 2011 02:31 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:49:17PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
+# For fixed voltage regulators
+- supply-name
On Friday 16 September 2011 02:30 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:47:05PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be
On Friday 16 September 2011 02:27 PM, Mark Brown wrote:
On Fri, Sep 16, 2011 at 12:41:53PM +0530, Rajendra Nayak wrote:
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote:
There is no need for all the board files to pass
On Friday 16 September 2011 03:48 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:52:01PM +0530, Rajendra Nayak wrote:
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds
On Friday 16 September 2011 03:42 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which
On Thursday 15 September 2011 07:51 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:07PM +0530, Rajendra Nayak wrote:
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Regulators can be devices
On Thursday 15 September 2011 07:29 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:06PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev
On Friday 16 September 2011 04:33 AM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:50:35PM -0600, Grant Likely wrote:
We've got two competing approaches here. For reg and interrupts, the
proposal on the table that we talked about at LPC is to do reg-names
and interrupts-names so as to preserve
On Thursday 15 September 2011 07:20 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:02PM +0530, Rajendra Nayak wrote:
.../devicetree/bindings/regulator/regulator.txt| 19
drivers/of/of_regulator.c | 31
include/linux
On Thursday 15 September 2011 07:16 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:52:00PM +0530, Rajendra Nayak wrote:
+Required properties:
+- compatible: Must be "regulator","ti,twl-reg";
I'd expect listings for the specific chips too.
I just did'nt do
On Thursday 15 September 2011 07:14 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile
On Thursday 15 September 2011 07:03 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:58PM +0530, Rajendra Nayak wrote:
The parameters to set_consumer_device_supply() can be considered
invalid (and hence it could return -EINVAL) if nether consumer_dev nor
consumer_dev_name are passed, not
On Thursday 15 September 2011 07:02 PM, Mark Brown wrote:
On Thu, Sep 15, 2011 at 04:51:57PM +0530, Rajendra Nayak wrote:
The TWL driver seems to set the default .valid_modes_mask to
(REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask
to (REGULATOR_CHANGE_VOLTAGE
Pass regulator_init_data information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak
---
.../bindings
of_regulator_register_devices() registers all regulators
as platform devices. Use this to register all twl regulators
from the twl driver probe.
Signed-off-by: Rajendra Nayak
---
drivers/mfd/twl-core.c |3 +++
drivers/of/of_regulator.c| 30 ++
include
};
When a device driver calls a regulator_get, specifying the
supply name, the phandle and eventually the regulator node
is extracted from the device and a mapping created by calling
set_consumer_device_supply().
Signed-off-by: Rajendra Nayak
---
drivers/regulator/core.c | 23 ++
le of patches in the series are just fixes and
cleanups leading to the regulator DT migration.
The series is tested on OMAP4SDP and OMAP4PANDA boards.
regards,
Rajendra
Rajendra Nayak (11):
OMAP: TWL: Clean up mode and ops mask passed from board files
regulator: Fix error che
this information
additionally, when the driver already sets them by default.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/board-2430sdp.c |5 --
arch/arm/mach-omap2/board-3430sdp.c | 30 --
arch/arm/mach-omap2/board-4430sdp.c | 10 -
arch
;®ulator2>;
regulator-names = "supply1","supply2";
};
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Signed-off-by: Rajendra Nayak
---
drivers/of/of_regulator.c| 37 +++
emented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak
---
.../devicetree/bindings/regulator/regulator.txt| 37 +
drivers/of/Kconfig
Pass the fixed voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap4-panda.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/fixed.c | 20 +++-
1 files changed, 19 insertions(+), 1
The helper routine defined here (of_get_fixed_voltage_config) can
be used to extract information about fixed regulators (which are not
software controlable) from device tree.
Add documenation about additional bindings for fixed
regulators that can be passed through DT.
Signed-off-by: Rajendra
The parameters to set_consumer_device_supply() can be considered
invalid (and hence it could return -EINVAL) if nether consumer_dev nor
consumer_dev_name are passed, not when *both* are passed.
Signed-off-by: Rajendra Nayak
---
drivers/regulator/core.c |2 +-
1 files changed, 1 insertions
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c | 28 +---
1 files changed, 25
temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock rate indirectly.
Signed-off-by: Keerthy
Reviewed-by: Rajendra Nayak
Cc: t...@atomide.com
Cc: rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files
On 8/23/2011 10:45 PM, Kevin Hilman wrote:
Rajendra Nayak writes:
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayak writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
supports.
Except
On 8/23/2011 8:04 PM, Santosh wrote:
+ Rajendra and Benoit to comment on optional clock
handling.
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops
On 8/23/2011 10:33 AM, G, Manjunath Kondaiah wrote:
Add omap4 soc dts file for handling omap4 soc i2c
controllers existing on l4-core bus.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap4-panda.dts |7 +---
arch/arm/boot/dts/omap4.dtsi | 68
On 8/23/2011 5:28 AM, Kevin Hilman wrote:
Rajendra Nayak writes:
[...]
FWIK, its a one time requirement to set the clock rate to the
right rate the device can operate in based on what a platform
supports.
Except $SUBJECT patch hard-codes the clock rate for all platforms in the
driver
On 8/12/2011 3:07 AM, Roger Quadros wrote:
On 08/11/2011 01:55 PM, Felipe Balbi wrote:
Hi,
On Thu, Aug 11, 2011 at 09:54:09PM +0300, Felipe Balbi wrote:
you need some other way to handle this. Why do you need to manually set
the rate rather than having hwmod handle this for you ?
your argumen
On 8/11/2011 7:42 PM, Felipe Balbi wrote:
Hi,
On Thu, Aug 11, 2011 at 06:30:04PM +0530, J, KEERTHY wrote:
> >> >> diff --git a/drivers/hwmon/omap_temp_sensor.c
b/drivers/hwmon/omap_temp_sensor.c
> >> >> new file mode 100644
> >> >> index 000..15e2559
> >> >> --- /dev/null
> >>
On 8/11/2011 1:51 PM, Munegowda, Keshava wrote:
On Thu, Aug 11, 2011 at 1:37 PM, Ohad Ben-Cohen wrote:
+ Paul, Benoit, Rajendra
On Tue, Aug 9, 2011 at 2:26 PM, Luciano Coelho wrote:
I'm again getting a very similar oops with 3.1-rc1 on my pandaboard:
[2.054351] usbcore: registered new i
On 8/11/2011 1:37 PM, Ohad Ben-Cohen wrote:
+ Paul, Benoit, Rajendra
On Tue, Aug 9, 2011 at 2:26 PM, Luciano Coelho wrote:
I'm again getting a very similar oops with 3.1-rc1 on my pandaboard:
[2.054351] usbcore: registered new interface driver cdc_ncm
[2.061431] ehci_hcd: USB 2.0 'Enh
On 8/10/2011 11:00 AM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 10:56 AM, Rajendra Nayak wrote:
On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/
Patches from Kevin Hilman and others are
On 8/9/2011 7:40 PM, G, Manjunath Kondaiah wrote:
This is in continuation of patch series posted at:
http://lwn.net/Articles/451917/
Patches from Kevin Hilman and others are consolidated along with this
series since it will be part of ongoing work of decoupling pdev from
omap_device.
[There is
On 7/21/2011 2:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote:
On 7/20/2011 3:04 AM, Grant Likely wrote:
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
* Grant Likely [110716 22:08]:
The way I see it, you've got two op
On 7/20/2011 3:04 AM, Grant Likely wrote:
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote:
* Grant Likely [110716 22:08]:
The way I see it, you've got two options:
1) modify the of_platform_bus_create() to call some kind of
of_platform_bus_create_omap() for devices that match "
On 7/7/2011 11:39 PM, Paul Walmsley wrote:
On Thu, 7 Jul 2011, Tony Lindgren wrote:
* Rajendra Nayak [110706 22:26]:
On 7/6/2011 12:19 AM, Paul Walmsley wrote:
Patch 16, to me, belongs best with the 4460 support series and so I'll see
if it makes sense to fit it in there somewhere.
On 7/8/2011 12:11 AM, Paul Walmsley wrote:
On Thu, 7 Jul 2011, Martin Fouts wrote:
From: Tony Lindgren [t...@atomide.com]
The second problem we have here is "why does adding 4460 support depend
on a cosmetic clean-up patch". That dependency should not exist at all
as it seems the 4460 patches
On 7/7/2011 11:49 PM, Paul Walmsley wrote:
On Sat, 2 Jul 2011, Rajendra Nayak wrote:
Add the new clock nodes (bandgap_ts_fclk, div_ts_ck) for omap4460.
Handle these nodes using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Hi Paul,
On 7/7/2011 11:30 PM, Paul Walmsley wrote:
Hi Rajendra
On Sat, 2 Jul 2011, Rajendra Nayak wrote:
This patch adds additional register bitshifts for
registers added in OMAP4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
On 7/6/2011 12:19 AM, Paul Walmsley wrote:
Hi,
On Fri, 1 Jul 2011, Benoit Cousson wrote:
Here are a bunch of cleanups on almost every PRCM related data files.
Some of them are purely code moves, and will look like a lot of
noise for nothing, but this is needed if we want to keep the files
alig
The 4460 platform has no difference in the clockdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same clockdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
The 4460 platform has no difference in the powerdomains as compared
to the 4430 platform. Hence just update the .omap_chip field to make
sure the same powerdomain data can be reused on the 4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Add the new clock nodes (bandgap_ts_fclk, div_ts_ck) for omap4460.
Handle these nodes using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/clock44xx_data.c | 39
This patch adds additional register bitshifts for
registers added in OMAP4460 platform.
Signed-off-by: Rajendra Nayak
Signed-off-by: Nishanth Menon
Signed-off-by: Benoit Cousson
Reviewed-by: Kevin Hilman
---
arch/arm/mach-omap2/cm-regbits-44xx.h | 36
arch
801 - 900 of 1421 matches
Mail list logo
