[GIT PULL] OMAP DSS fixes for 3.2-rc
Hi Florian, Here are a few OMAP display subsystem fixes for 3.2-rc. One for the old omapfb, which was missing include module.h, and two for the omapdss fixing issues related to HDMI. Tomi The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37: Linux 3.2-rc2 (2011-11-15 15:02:59 -0200) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-3.2-rc Tomi Valkeinen (3): OMAPDSS: HDMI: fix returned HDMI pixel clock OMAPFB: fix compilation warnings due to missing include OMAPDSS: DISPC: skip scaling calculations when not scaling drivers/video/omap/dispc.c |1 + drivers/video/omap2/dss/dispc.c | 11 +-- drivers/video/omap2/dss/hdmi.c |2 +- 3 files changed, 7 insertions(+), 7 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: omap_hwmod: Add a new state to handle hwmods left enabled at init
Hi Kevin and Rajendra,
On 11/18/2011 7:44 AM, Rajendra Nayak wrote:
Hi Kevin,
On Friday 18 November 2011 01:05 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT'
to identify such devices/hwmods, so nothing but just a state
change to '_HWMOD_STATE_ENABLED' can be done when the device/hwmod
is requested to be enabled (the first time) by its driver/user.
A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.
Nice. This is indeed much cleaner than what we're doing in the UART
code. However...
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 16 ++--
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index d7f4623..7d94cc3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1441,6 +1441,17 @@ static int _enable(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: enabling\n, oh-name);
+ /*
+ * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left
(no the ' isn't necessary)
+ * in enabled state at init.
+ * Now that someone is really trying to enable them,
+ * just update the state.
+ */
+ if (oh-_state == _HWMOD_STATE_ENABLED_AT_INIT) {
+ oh-_state = _HWMOD_STATE_ENABLED;
+ return 0;
+ }
...this subtly changes the behavior, at least compared to how the UART
code handles this today.
One thing that this doesn't do that the current UART code does is ensure
that the IP is actually in a state that can properly idle after this is
done.
For example, if the bootloader is dumb (most are) and has configured the
UARTs in mode that prevents idle (e.g. no-idle mode), then these UARTs
will never allow the SoC to hit low power states.
That will not happen because we already did the complete enable sequence
during setup phase that will set the sysconfig properly.
So the device is properly initialized, we just skipped the idle phase
because we wanted to keep the device operational for the console.
So, what's really needed is not just a return here, but an _idle() and
then continue so we know that the HW is in a state that we know can
idle from here on out.
We are in the enable call, so the driver / omap_device does expect the
IP to be operational at the moment, we cannot put it into idle.
I don't know if I completely understand what you are saying.
The above change is in the _enable() call which would be triggered
as part of runtime call from the serial driver to enable the module.
(Since the module is already enabled, you just change state to suggest
its now enabled by its user, rather than 'left enabled' at init)
There would be another call from the serial driver to idle it when
a corresponding hwmod _idle() call would idle the device.
I don't seem to understand why would a call to _idle() be needed
in an _enable() call.
Yep, I agree. I think Kevin's point is due to the previous sequence used
by the uart:
+ omap_hwmod_idle(od-hwmods[0]);
+ omap_hwmod_enable(od-hwmods[0]);
But that sequence is not needed for my point of view. The device is
already properly enabled. I don't think it was even needed in the
previous code. The hwmod was already enabled properly, only the
omap_device was disabled. So the original omap_console_hwmod_enable
should just do nothing.
Regards,
Benoit
--
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 2/2] cbus: Fix initialization of cached IRQ masks
On Thu, Nov 17, 2011 at 11:38:47PM +0100, Michael Büsch wrote: This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch --- Index: linux-3.1.1/drivers/cbus/retu.c === --- linux-3.1.1.orig/drivers/cbus/retu.c 2011-11-17 23:09:26.498214061 +0100 +++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:15:50.280659655 +0100 @@ -451,7 +451,8 @@ static int __devinit retu_probe(struct p (rev 4) 0x07, rev 0x0f); /* Mask all RETU interrupts */ - __retu_write_reg(retu, RETU_REG_IMR, 0x); + retu-mask = 0x; nitpicking but please use lowercase as it was before :-) -- balbi signature.asc Description: Digital signature
[PATCH v2] cbus: Fix initialization of cached IRQ masks
This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch --- v2: lowercase Index: linux-3.1.1/drivers/cbus/retu.c === --- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:09:26.498214061 +0100 +++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:15:50.280659655 +0100 @@ -451,7 +451,8 @@ static int __devinit retu_probe(struct p (rev 4) 0x07, rev 0x0f); /* Mask all RETU interrupts */ - __retu_write_reg(retu, RETU_REG_IMR, 0x); + retu-mask = 0x; + __retu_write_reg(retu, RETU_REG_IMR, retu-mask); ret = request_threaded_irq(retu-irq, NULL, retu_irq_handler, IRQF_ONESHOT, retu, retu); Index: linux-3.1.1/drivers/cbus/tahvo.c === --- linux-3.1.1.orig/drivers/cbus/tahvo.c 2011-11-17 23:15:46.684674232 +0100 +++ linux-3.1.1/drivers/cbus/tahvo.c2011-11-17 23:15:50.280659655 +0100 @@ -346,7 +346,8 @@ static int __devinit tahvo_probe(struct (rev 4) 0x0f, rev 0x0f); /* Mask all TAHVO interrupts */ - __tahvo_write_reg(tahvo, TAHVO_REG_IMR, 0x); + tahvo-mask = 0x; + __tahvo_write_reg(tahvo, TAHVO_REG_IMR, tahvo-mask); ret = request_threaded_irq(irq, NULL, tahvo_irq_handler, IRQF_TRIGGER_RISING | IRQF_ONESHOT, -- Greetings, Michael. -- 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 v5 0/4] Device tree support for regulators
v5 is based on 3.2-rc2 and has the following changes -1- Used microvolt/microamp in bindings instead of uV/uA -2- Added more documentation surrounding regulator-consumer mapping in the core bindings -3- Dropped CONFIG_OF_REGULATOR and use just CONFIG_OF -4- Reused core regulator bindings on Fixed regulator bindings -5- Corrected the gpio binding for Fixed regulator The patches can be found here: git://gitorious.org/omap-pm/linux.git for-dt/regulator For the first 2 patches (1/4 and 2/4) I have dropped Acks from Mark, since they have changed to some extent from the last post and retained the Acks recieved on the last 2 patches (3/4 and 4/4) as they remain unchanged. regards, Rajendra Rajendra Nayak (4): regulator: helper routine to extract regulator_init_data regulator: adapt fixed regulator driver to dt regulator: pass additional of_node to regulator_register() regulator: map consumer regulator based on device tree .../bindings/regulator/fixed-regulator.txt | 29 +++ .../devicetree/bindings/regulator/regulator.txt| 54 + drivers/regulator/88pm8607.c |2 +- drivers/regulator/Makefile |1 + 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 | 82 --- drivers/regulator/da903x.c |2 +- drivers/regulator/db8500-prcmu.c |2 +- drivers/regulator/dummy.c |2 +- drivers/regulator/fixed.c | 62 +++- 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/of_regulator.c | 81 +++ 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 |4 +- include/linux/regulator/of_regulator.h | 20 + sound/soc/codecs/sgtl5000.c|2 +- 46 files changed, 362 insertions(+), 58 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt 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 -- 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 v5 2/4] regulator: adapt fixed regulator driver to dt
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 rna...@ti.com
---
.../bindings/regulator/fixed-regulator.txt | 29 +
drivers/regulator/fixed.c | 65
2 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 000..9cf57fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,29 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be regulator-fixed;
+
+Optional properties:
+- gpio: gpio to use for enable control
+- startup-delay-us: startup time in microseconds
+- enable-active-high: Polarity of GPIO is Active high
+If this property is missing, the default assumed is Active low.
+
+Any property defined as part of the core regulator
+binding, defined in regulator.txt, can also be used.
+However a fixed voltage regulator is expected to have the
+regulator-min-microvolt and regulator-max-microvolt
+to be the same.
+
+Example:
+
+ abc: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = fixed-supply;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio1 16 0;
+ startup-delay-us = 7;
+ enable-active-high;
+ regulator-boot-on
+ };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 21ecf21..0650856 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -27,6 +27,10 @@
#include linux/gpio.h
#include linux/delay.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/regulator/of_regulator.h
+#include linux/regulator/machine.h
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -38,6 +42,53 @@ struct fixed_voltage_data {
bool is_enabled;
};
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+ struct fixed_voltage_config *config;
+ struct device_node *np = dev-of_node;
+ const __be32 *delay;
+ struct regulator_init_data *init_data;
+
+ config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config),
+GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config-init_data = of_get_regulator_init_data(dev);
+ init_data = config-init_data;
+
+ config-supply_name = init_data-constraints.name;
+ if (init_data-constraints.min_uV == init_data-constraints.max_uV) {
+ config-microvolts = init_data-constraints.min_uV;
+ } else {
+ dev_err(dev,
+Fixed regulator specified with variable voltages\n);
+ return NULL;
+ }
+
+ if (init_data-constraints.boot_on)
+ config-enabled_at_boot = true;
+
+ config-gpio = of_get_named_gpio(np, gpio, 0);
+ delay = of_get_property(np, startup-delay-us, NULL);
+ if (delay)
+ config-startup_delay = be32_to_cpu(*delay);
+
+ if (of_find_property(np, enable-active-high, NULL))
+ config-enable_high = true;
+
+ return config;
+}
+
static int fixed_voltage_is_enabled(struct regulator_dev *dev)
{
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
@@ -109,6 +160,9 @@ static int __devinit reg_fixed_voltage_probe(struct
platform_device *pdev)
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev-dev.of_node)
+ config = of_get_fixed_voltage_config(pdev-dev);
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(pdev-dev, Failed to allocate device data\n);
@@ -217,12 +271,23 @@ static int __devexit reg_fixed_voltage_remove(struct
platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+ { .compatible = regulator-fixed, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
static struct platform_driver regulator_fixed_voltage_driver = {
.probe
[PATCH v5 1/4] regulator: helper routine to extract regulator_init_data
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
+
+Example:
+
+ xyzreg: regulator@0 {
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 250;
+ regulator-always-on;
+ vin-supply = vin;
+ };
+
+Regulator Consumers:
+Consumer nodes can reference one or more of its supplies/
+regulators using the below bindings.
+
+- name-supply: phandle to the regulator node
+
+These are the same bindings that a regulator in the above
+example used to reference its own supply, in which case
+its just seen as a special case of a regulator being a
+consumer itself.
+
+Example of a consumer device node (mmc) referencing two
+regulators (twl-reg1 and twl-reg2),
+
+ twl-reg1: regulator@0 {
+ ...
+ ...
+ ...
+ };
+
+ twl-reg2: regulator@1 {
+ ...
+ ...
+ ...
+ };
+
+ mmc: mmc@0x0 {
+ ...
+ ...
+ vmmc-supply = twl-reg1;
+ vmmcaux-supply = twl-reg2;
+ };
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 93a6318..c75a522 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_REGULATOR) += core.o dummy.o
+obj-$(CONFIG_OF) += of_regulator.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 000..76673c7
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,81 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/regulator/machine.h
+
+static void of_get_regulation_constraints(struct device_node *np,
+ struct regulator_init_data **init_data)
+{
+ const __be32 *min_uV, *max_uV, *uV_offset;
+ const __be32 *min_uA, *max_uA;
+ struct regulation_constraints *constraints = (*init_data)-constraints;
+
+ constraints-name = of_get_property(np, regulator-name, NULL);
+
+ min_uV = of_get_property(np, regulator-min-microvolt, NULL);
+ if (min_uV)
+ constraints-min_uV = be32_to_cpu(*min_uV);
+ max_uV = of_get_property(np,
[PATCH v5 3/4] regulator: pass additional of_node to regulator_register()
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(-)
diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index ca0d608..df33530 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -427,7 +427,7 @@ static int __devinit pm8607_regulator_probe(struct
platform_device *pdev)
/* replace driver_data with info */
info-regulator = regulator_register(info-desc, pdev-dev,
-pdata, info);
+pdata, info, NULL);
if (IS_ERR(info-regulator)) {
dev_err(pdev-dev, failed to register regulator %s\n,
info-desc.name);
diff --git a/drivers/regulator/aat2870-regulator.c
b/drivers/regulator/aat2870-regulator.c
index 5abeb3a..07e98ec 100644
--- a/drivers/regulator/aat2870-regulator.c
+++ b/drivers/regulator/aat2870-regulator.c
@@ -188,7 +188,7 @@ static int aat2870_regulator_probe(struct platform_device
*pdev)
ri-pdev = pdev;
rdev = regulator_register(ri-desc, pdev-dev,
- pdev-dev.platform_data, ri);
+ pdev-dev.platform_data, ri, NULL);
if (IS_ERR(rdev)) {
dev_err(pdev-dev, Failed to register regulator %s\n,
ri-desc.name);
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index 585e494..042271a 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -634,7 +634,7 @@ static int __devinit ab3100_regulators_probe(struct
platform_device *pdev)
rdev = regulator_register(ab3100_regulator_desc[i],
pdev-dev,
plfdata-reg_constraints[i],
- reg);
+ reg, NULL);
if (IS_ERR(rdev)) {
err = PTR_ERR(rdev);
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 6e1ae69..e91b8dd 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -822,7 +822,7 @@ static __devinit int
[PATCH v5 4/4] regulator: map consumer regulator based on device tree
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = regulator1;
vpll-supply = regulator2;
};
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.
Use it to 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.
Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/regulator/core.c | 79 --
include/linux/regulator/driver.h |2 +
2 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8b01eb0..9867ebc 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,6 +25,8 @@
#include linux/mutex.h
#include linux/suspend.h
#include linux/delay.h
+#include linux/of.h
+#include linux/regulator/of_regulator.h
#include linux/regulator/consumer.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
@@ -132,6 +134,33 @@ static struct regulator *get_device_regulator(struct
device *dev)
return NULL;
}
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator(struct device *dev, const char
*supply)
+{
+ struct device_node *regnode = NULL;
+ char prop_name[32]; /* 32 is max size of property name */
+
+ dev_dbg(dev, Looking up %s-supply from device tree\n, supply);
+
+ snprintf(prop_name, 32, %s-supply, supply);
+ regnode = of_parse_phandle(dev-of_node, prop_name, 0);
+
+ if (!regnode) {
+ dev_warn(dev, %s property in node %s references invalid
phandle,
+ prop_name, dev-of_node-full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
/* Platform voltage constraint check */
static int regulator_check_voltage(struct regulator_dev *rdev,
int *min_uV, int *max_uV)
@@ -1148,6 +1177,30 @@ static int _regulator_get_enable_time(struct
regulator_dev *rdev)
return rdev-desc-ops-enable_time(rdev);
}
+static struct regulator_dev *regulator_dev_lookup(struct device *dev,
+const char *supply)
+{
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev dev-of_node) {
+ node = of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r, regulator_list, list)
+ if (r-dev.parent
+ node == r-dev.of_node)
+ return r;
+ }
+
+ /* if not found, try doing it non-dt way */
+ list_for_each_entry(r, regulator_list, list)
+ if (strcmp(rdev_get_name(r), supply) == 0)
+ return r;
+
+ return NULL;
+}
+
/* Internal regulator request function */
static struct regulator *_regulator_get(struct device *dev, const char *id,
int exclusive)
@@ -1168,6 +1221,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
mutex_lock(regulator_list_mutex);
+ rdev = regulator_dev_lookup(dev, id);
+ if (rdev)
+ goto found;
+
list_for_each_entry(map, regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name
@@ -2642,6 +2699,7 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
static atomic_t regulator_no = ATOMIC_INIT(0);
struct regulator_dev *rdev;
int ret, i;
+ const char *supply = NULL;
if (regulator_desc == NULL)
return ERR_PTR(-EINVAL);
@@ -2718,21 +2776,18 @@ struct regulator_dev *regulator_register(struct
regulator_desc *regulator_desc,
if (ret 0)
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Ming Lei,
Sorry, for the delay, it took me some time to gather the exhaustive data for
that block.
On 11/10/2011 10:02 AM, Paul Walmsley wrote:
Hello Ming Lei,
just a few quick comments for now -
On Wed, 9 Nov 2011, Ming Lei wrote:
On Tue, Nov 8, 2011 at 11:26 PM, Paul Walmsleyp...@pwsan.com wrote:
+static struct omap_hwmod_irq_info omap44xx_emu_irqs[] = {
+ { .name = cti0, .irq = 1 + OMAP44XX_IRQ_GIC_START },
+ { .name = cti1, .irq = 2 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
Are you sure these are part of the emulation IP? We already have those
I am not sure, I just figure out one way to make omap4 pmu work. Since there
are few descriptions in TRM about it, it is a hacking based on [1], :-)
IRQs in the MPU hwmod, see omap44xx_mpu_irqs[] in the same file.
I just see it, but looks like the mpu hwmod isn't populated as omap_device,
so the CTI irqs aren't requested now.
Okay. Maybe you can probably add some code in mach-omap2/devices.c to
build an omap_device for this for right now? I am not 100% sure whether
those cti0/1 interrupts should be associated with the MPU or with the
DEBUGSS but Benoît might be able to answer this.
Also, current arm perf code don't handle three IRQs(one pl310 irq and
two CTI irq) inside one device correctly.
To fix this, that ARM perf code should either be using
platform_get_irq_byname(), or the hwmod hardware data will need to be
rearranged to meet the arbitrary ordering requirement. I'd suggest
pinging Will on this issue to see what he wants to do.
So any suggestion about CTI IRQs connecting to which hwmod, so that they can
be found by pmu driver?
+/*emu hwmod*/
+static struct omap_hwmod omap44xx_emu_hwmod = {
+ .name = emu,
+ .class =omap44xx_emu_hwmod_class,
+ .clkdm_name = emu_sys_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_EMU_CLKSTCTRL_OFFSET,
This doesn't look right either: EMU is a clockdomain, not an IP block.
I defined the 'emu' hwmod to control the clock state transition of the EMU
clock domain by writing to CLKTRCTRL.CM_EMU_CLKSTCTRL with standard
hwmod interface(_enable / _idle). Is there any other neat way to do it?
So the clockdomain is already defined in
mach-omap2/clockdomains44xx_data.c and there's code to control it - see
for example clkdm_enable_idle(). But this code should not be called
directly by any device driver code or driver integration code. The thing
to do here is to ask Benoît to release the hwmod data for the DEBUGSS
hwmod, then someone will need to write an MFD driver for that which
exposes the PMU address space to the PMU platform driver.
Following that discussion, here is the patch to expose debugss hwmod.
I have moved the CTIs irq from MPU to debugss and exposed all the internals IP
that are part of the OMAP debug subsystem.
Since the DEBUGSS cannot be accessed at boot time if the l3_main_3 and the
l3_instr interconnects are not enable, you will have some warnings.
[0.416992] omap_hwmod: debugss: softreset failed (waited 1 usec)
[0.426727] omap_hwmod: debugss: _wait_target_disable failed
Just let me know if you have any issue with that patch.
Please note that will will need the fix ARM: OMAP: hwmod: Fix the addr space,
irq, dma count APIs to avoid hwmod core messing up with the resources.
I've just posted a pull request for Tony to get it for -rc3.
http://comments.gmane.org/gmane.linux.ports.arm.kernel/140458
I pushed these two patches on a branch based on mainline for your convenience.
git://gitorious.org/omap-pm/linux.git wip-emu/debuss_hwmod
Regards,
Benoit
---
From: Benoit Cousson b-cous...@ti.com
Date: Fri, 18 Nov 2011 11:42:12 +0100
Subject: [PATCH] ARM: OMAP4: hwmod data: Add support for the debug modules
The OMAP4 DEBUG subsystem contains all the IPs used for emulation,
included the ones from the CortexA9 MPU.
Expose the individual modules base address.
Re-map the CTIs IRQs from MPU to DEBUGSS.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 177 +++-
1 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..6cf21ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -47,6 +47,7 @@
/* Backward references (IPs with Bus Master capability) */
static struct omap_hwmod omap44xx_aess_hwmod;
+static struct omap_hwmod omap44xx_debugss_hwmod;
static struct omap_hwmod omap44xx_dma_system_hwmod;
static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
@@ -337,6 +338,14 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
};
/* l3_main_2 */
+/* debugss - l3_main_2 */
+static struct omap_hwmod_ocp_if
Re: [PATCH v2] cbus: Fix initialization of cached IRQ masks
On Fri, Nov 18, 2011 at 11:31:32AM +0100, Michael Büsch wrote: This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch Reviewed-by: Felipe Balbi ba...@ti.com --- v2: lowercase Index: linux-3.1.1/drivers/cbus/retu.c === --- linux-3.1.1.orig/drivers/cbus/retu.c 2011-11-17 23:09:26.498214061 +0100 +++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:15:50.280659655 +0100 @@ -451,7 +451,8 @@ static int __devinit retu_probe(struct p (rev 4) 0x07, rev 0x0f); /* Mask all RETU interrupts */ - __retu_write_reg(retu, RETU_REG_IMR, 0x); + retu-mask = 0x; + __retu_write_reg(retu, RETU_REG_IMR, retu-mask); ret = request_threaded_irq(retu-irq, NULL, retu_irq_handler, IRQF_ONESHOT, retu, retu); Index: linux-3.1.1/drivers/cbus/tahvo.c === --- linux-3.1.1.orig/drivers/cbus/tahvo.c 2011-11-17 23:15:46.684674232 +0100 +++ linux-3.1.1/drivers/cbus/tahvo.c 2011-11-17 23:15:50.280659655 +0100 @@ -346,7 +346,8 @@ static int __devinit tahvo_probe(struct (rev 4) 0x0f, rev 0x0f); /* Mask all TAHVO interrupts */ - __tahvo_write_reg(tahvo, TAHVO_REG_IMR, 0x); + tahvo-mask = 0x; + __tahvo_write_reg(tahvo, TAHVO_REG_IMR, tahvo-mask); ret = request_threaded_irq(irq, NULL, tahvo_irq_handler, IRQF_TRIGGER_RISING | IRQF_ONESHOT, -- Greetings, Michael. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod
Hi Benoit, On Fri, Nov 18, 2011 at 12:58:20PM +, Cousson, Benoit wrote: Hi Ming Lei, Sorry, for the delay, it took me some time to gather the exhaustive data for that block. Thanks for looking at this! I don't think we'd have managed to get all of the magic numbers in the right place ourselves :) Ming Lei - can you take this into your patch series please? Then we'll have: - The two perf patches in my tree - The hwmod fix in Tony's tree (pending pull) - Your patches plus this one for hooking everything together The sooner we can push these into -next, the better. Cheers, Will -- 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] ARM: omap_hwmod: Add a new state to handle hwmods left enabled at init
Cousson, Benoit b-cous...@ti.com writes:
Hi Kevin and Rajendra,
On 11/18/2011 7:44 AM, Rajendra Nayak wrote:
Hi Kevin,
On Friday 18 November 2011 01:05 AM, Kevin Hilman wrote:
Rajendra Nayakrna...@ti.com writes:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by introducing a new state '_HWMOD_STATE_ENABLED_AT_INIT'
to identify such devices/hwmods, so nothing but just a state
change to '_HWMOD_STATE_ENABLED' can be done when the device/hwmod
is requested to be enabled (the first time) by its driver/user.
A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.
Nice. This is indeed much cleaner than what we're doing in the UART
code. However...
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 16 ++--
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index d7f4623..7d94cc3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1441,6 +1441,17 @@ static int _enable(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: enabling\n, oh-name);
+ /*
+ * hwmods' with HWMOD_INIT_NO_IDLE flag set, are left
(no the ' isn't necessary)
+ * in enabled state at init.
+ * Now that someone is really trying to enable them,
+ * just update the state.
+ */
+ if (oh-_state == _HWMOD_STATE_ENABLED_AT_INIT) {
+ oh-_state = _HWMOD_STATE_ENABLED;
+ return 0;
+ }
...this subtly changes the behavior, at least compared to how the UART
code handles this today.
One thing that this doesn't do that the current UART code does is ensure
that the IP is actually in a state that can properly idle after this is
done.
For example, if the bootloader is dumb (most are) and has configured the
UARTs in mode that prevents idle (e.g. no-idle mode), then these UARTs
will never allow the SoC to hit low power states.
That will not happen because we already did the complete enable
sequence during setup phase that will set the sysconfig properly.
So the device is properly initialized, we just skipped the idle phase
because we wanted to keep the device operational for the console.
Ah, perfect.
So, what's really needed is not just a return here, but an _idle() and
then continue so we know that the HW is in a state that we know can
idle from here on out.
We are in the enable call, so the driver / omap_device does expect the
IP to be operational at the moment, we cannot put it into idle.
I don't know if I completely understand what you are saying.
The above change is in the _enable() call which would be triggered
as part of runtime call from the serial driver to enable the module.
(Since the module is already enabled, you just change state to suggest
its now enabled by its user, rather than 'left enabled' at init)
There would be another call from the serial driver to idle it when
a corresponding hwmod _idle() call would idle the device.
I don't seem to understand why would a call to _idle() be needed
in an _enable() call.
Yep, I agree. I think Kevin's point is due to the previous sequence
used by the uart:
+ omap_hwmod_idle(od-hwmods[0]);
+ omap_hwmod_enable(od-hwmods[0]);
But that sequence is not needed for my point of view. The device is
already properly enabled. I don't think it was even needed in the
previous code. The hwmod was already enabled properly, only the
omap_device was disabled. So the original omap_console_hwmod_enable
should just do nothing.
OK, thanks for the clarification.
In that case, this patch
Acked-by: Kevin Hilman khil...@ti.com
Kevin
--
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] ARM: OMAP: PM: only register TWL with voltage layer when device is present
-Original Message- From: Hilman, Kevin Sent: Friday, November 18, 2011 12:51 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present Premi, Sanjeev pr...@ti.com writes: [...] If PMIC is not TWL family, then I don't expect any functions in twl_common.c to be called. This is the reason I wanted to know if the check on .irq in the patch is sufficient. If any PMIC requires sets pmic_i2c_board_info.irq then both omap3_twl_init() and omap4_twl_init() will be called. Only TWL PMICs should be calling these functions, as they are in code for TWL PMICs *only*. If you have a non-TWL PMIC, then you should not be using the omap_pmic_* functions. Admittedly, these omap_pmic_* functions should be renamed to be clear that they are TWL specific. Thanks. We also need mechanism - may be name - to identify the PMIC family at this stage; and that should be used to select the corresponding init function. ~sanjeev Kevin -- 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: [PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks
Tero Kristo t-kri...@ti.com writes: These are needed because runtime PM is disabled during suspend, and it is bad if we get interrupts from the PRCM chain handler during it. Now, PRCM interrupt forwarding is disabled until the suspend-complete, which makes sure that all the needed drivers are up. Just to clarify... based on reading the patch, the wakeup and PRCM interrupts themselves still happen (and are saved). They are just not dispatched to the drivers until -complete(). I think the changelog should be a bit clearer about that. Thanks, Kevin -- 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: [PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler
Hi,
On Thu, Nov 17, 2011 at 02:34:46PM -0800, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.
PRCM interrupts have two priority levels, high or normal. High priority
is needed for IO event handling, so that we can be sure that IO events
are processed before other events. This reduces latency for IO event
customers and also prevents incorrect ack sequence on OMAP3.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Avinash.H.M avinas...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-prm-common.c | 239
+
drivers/mfd/omap-prm.h| 40 +++
drivers/mfd/omap3xxx-prm.c| 29 +-
drivers/mfd/omap4xxx-prm.c| 28 +-
4 files changed, 334 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-prm.h
diff --git a/drivers/mfd/omap-prm-common.c b/drivers/mfd/omap-prm-common.c
index 39b199c8..2886eb2 100644
--- a/drivers/mfd/omap-prm-common.c
+++ b/drivers/mfd/omap-prm-common.c
@@ -15,10 +15,249 @@
#include linux/ctype.h
#include linux/module.h
#include linux/io.h
+#include linux/irq.h
+#include linux/interrupt.h
#include linux/slab.h
#include linux/init.h
#include linux/err.h
+#include omap-prm.h
+
+#define OMAP_PRCM_MAX_NR_PENDING_REG 2
+
+struct omap_prm_device {
+ const struct omap_prcm_irq_setup *irq_setup;
+ const struct omap_prcm_irq *irqs;
+ struct irq_chip_generic **irq_chips;
+ int nr_irqs;
+ u32 *saved_mask;
+ u32 *priority_mask;
+ int base_irq;
+ int irq;
+ void __iomem *base;
+};
+
+static struct omap_prm_device prm_dev;
This shouldn't be statically allocated, and needlessly forces us to
assume a single, global PRM (which is the case today, but who knows...)
Instead, it should be allocated at init time and associated with the
instance (using set_drvdata or somthing.)
+static inline u32 prm_read_reg(int offset)
+{
+ return __raw_readl(prm_dev.base + offset);
+}
+
+static inline void prm_write_reg(u32 value, int offset)
+{
+ __raw_writel(value, prm_dev.base + offset);
+}
This doesn't seem right either.
The register layout/access parts are what are are different between the
OMAP3 and OMAP4 versions, so I would expect anything that accesses
registers to be going through the SoC specific code.
I'm having some second thoughts about the split of common and SoC
specific code here. Currently the SoC specific code is basically
identical (ignoring the s/omap3/omap4/ throughout.)
I think we need to discuss this further, but what seems to me that the
current design is to have 2 separate drivers, with some common helper
functions. I'm starting to think that what we need instead is a single,
common driver with a set of SoC-specific functions that implement the
SoC-specific details. This latter approach follows what is done in the
powerdomain code today for example: common code in powerdomain.c and SoC
specific implementation of all the ops in powerdomain2xxx_3xxx.c and
powerdomain4xxx.c.
Is it so that only register layout is different ? In that case isn't it
better to use driver_data field of the id_table structure to pass
different register offsets based on the e.g. driver name ? Something
like below:
static const struct platform_device_id omap_prm_id_table[] __devinitconst = {
{
.name = omap3-prm,
.driver_data = (kernel_ulong_t) omap3_prm_data,
},
{
.name = omap4-prm,
.driver_data = (kernel_ulong_t) omap4_prm_data,
},
};
MODULE_DEVICE_TABLE(platform, omap_prm_id_table);
struct platform_driver omap_prm_driver = {
.probe = omap_prm_probe,
.remove = omap_prm_remove,
.id_table = omap_prm_id_table,
};
then on probe you get your id, copy id-driver_data to your own
structure and use that to access your registers. Works for you ?
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/2] ARM: OMAP: misc. PM fixes for v3.2-rc
Tony, Here's a couple more PM fixes for v3.2-rc. Also available here if you prefer to pull: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.2/fixes/pm (Note that this branch also includes the CPUidle fix that you already have in your fixes branch) Kevin Felipe Balbi (1): arm: omap: smartreflex: fix IRQ handling bug Kevin Hilman (1): ARM: OMAP: PM: only register TWL with voltage layer when device is present arch/arm/mach-omap2/pm.c |6 ++ arch/arm/mach-omap2/smartreflex.c |2 +- arch/arm/mach-omap2/twl-common.c | 11 +++ arch/arm/mach-omap2/twl-common.h |3 +++ 4 files changed, 17 insertions(+), 5 deletions(-) -- 1.7.6 -- 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 1/2] ARM: OMAP: PM: only register TWL with voltage layer when device is present
Current code registers voltage layer details for TWL PMIC even when a TWL
has not been registered. Fix this to only register the TWL with voltage
layer when the TWL PMIC is initialized by board-level code.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |6 ++
arch/arm/mach-omap2/twl-common.c | 11 +++
arch/arm/mach-omap2/twl-common.h |3 +++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1e79bdf..00bff46 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -24,6 +24,7 @@
#include powerdomain.h
#include clockdomain.h
#include pm.h
+#include twl-common.h
static struct omap_device_pm_latency *pm_lats;
@@ -226,11 +227,8 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
- /* Init the OMAP TWL parameters */
- omap3_twl_init();
- omap4_twl_init();
-
/* Init the voltage layer */
+ omap_pmic_late_init();
omap_voltage_late_init();
/* Initialize the voltages */
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 52243577..10b20c6 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -30,6 +30,7 @@
#include plat/usb.h
#include twl-common.h
+#include pm.h
static struct i2c_board_info __initdata pmic_i2c_board_info = {
.addr = 0x48,
@@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, pmic_i2c_board_info, 1);
}
+void __init omap_pmic_late_init(void)
+{
+ /* Init the OMAP TWL parameters (if PMIC has been registerd) */
+ if (!pmic_i2c_board_info.irq)
+ return;
+
+ omap3_twl_init();
+ omap4_twl_init();
+}
+
#if defined(CONFIG_ARCH_OMAP3)
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 5e83a5b..275dde8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -1,6 +1,8 @@
#ifndef __OMAP_PMIC_COMMON__
#define __OMAP_PMIC_COMMON__
+#include plat/irqs.h
+
#define TWL_COMMON_PDATA_USB (1 0)
#define TWL_COMMON_PDATA_BCI (1 1)
#define TWL_COMMON_PDATA_MADC (1 2)
@@ -30,6 +32,7 @@ struct twl4030_platform_data;
void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
struct twl4030_platform_data *pmic_data);
+void omap_pmic_late_init(void);
static inline void omap2_pmic_init(const char *pmic_type,
struct twl4030_platform_data *pmic_data)
--
1.7.6
--
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 2/2] arm: omap: smartreflex: fix IRQ handling bug
From: Felipe Balbi ba...@ti.com
fix a bug which has been on this driver since
it was added by the original commit 984aa6db
which would never clear IRQSTATUS bits.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6a4f683..cf246b3 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -139,7 +139,7 @@ static irqreturn_t sr_interrupt(int irq, void *data)
sr_write_reg(sr_info, ERRCONFIG_V1, status);
} else if (sr_info-ip_type == SR_TYPE_V2) {
/* Read the status bits */
- sr_read_reg(sr_info, IRQSTATUS);
+ status = sr_read_reg(sr_info, IRQSTATUS);
/* Clear them by writing back */
sr_write_reg(sr_info, IRQSTATUS, status);
--
1.7.6
--
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: omap_hsmmc noisy/broken for suspend resume
Hello Girish, On 11/03/2011 09:21 PM, Girish K S wrote: On 3 November 2011 17:24, Kevin Hilman khil...@ti.com wrote: Hello, Using Linus' master branch, I was testing PM functionality on OMAP3/4 and noticed that the MMC driver is now rather noisy during suspend on OMAP3[1], but seems to work. [...] / # echo mem /sys/power/state [ 811.145507] PM: Syncing filesystems ... done. [ 811.150268] PM: Preparing system for mem sleep [ 811.155059] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 811.179992] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 811.203460] PM: Entering mem sleep [ 811.207489] Suspending console(s) (use no_console_suspend to debug) a[ 811.225860] [ cut here ] [ 811.225891] WARNING: at /work/kernel/omap/pm/drivers/mmc/core/core.c:453 mmc_wait_for_cmd+0x78/0x84() [ 811.225921] Modules linked in: [ 811.225952] [c001a810] (unwind_backtrace+0x0/0xf0) from [c00525d0] (warn_slowpath_common+0x4c/0x64) [ 811.225982] [c00525d0] (warn_slowpath_common+0x4c/0x64) from [c0052604] (warn_slowpath_null+0x1c/0x24) [ 811.226013] [c0052604] (warn_slowpath_null+0x1c/0x24) from [c033a494] (mmc_wait_for_cmd+0x78/0x84) [ 811.226043] [c033a494] (mmc_wait_for_cmd+0x78/0x84) from [c033e7b8] (mmc_switch+0x74/0x118) [ 811.226074] [c033e7b8] (mmc_switch+0x74/0x118) from [c033b034] (mmc_power_off+0xd8/0x108) The problem is caused by the card-poweroff_notify_state = MMC_POWERED_ON; statement in the mmc_card_init function it is set for the non eMMC4.5 devices. I will rectify this and soon send a patch for the same. Is this the patch that fixes this issue: http://article.gmane.org/gmane.linux.kernel.mmc/10961 I found this by digging (since I'm not subscribed to linux-mmc), but it would've been much more efficient if you Cc the original lists where the issue was reported, and especially the person reporting the bug so it can be tested by those reporting the problem. I tested the above patch and verified it gets rid of all the noise in the OMAP HS-MMC driver. Chris, I see this is already in mmc-next. Feel free to add: Tested-by: Kevin Hilman khil...@ti.com If you like. Thanks, Kevin -- 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
[GIT PULL] cpufreq: OMAP: move to drivers/cpufreq and updates for v3.3
Hi Dave, Here's the updated pull request after a rebase onto v3.2-rc1 and some fixes to address other changes that went into v3.2. This is targetted for v3.3, so I'd like to get it into your tree and into linux-next. Also, let me know if you want a MAINTAINERS entry for this file, as I'm happy to maintain it. Kevin The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5: Linux 3.2-rc1 (2011-11-07 16:16:02 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.3/omap-cpufreq Colin Cross (1): cpufreq: OMAP: notify even with bad boot frequency Kevin Hilman (1): cpufreq: OMAP: fixup for omap_device changes, include linux/module.h Nishanth Menon (6): cpufreq: OMAP: move clk name decision to init cpufreq: OMAP: deny initialization if no mpudev cpufreq: OMAP: dont support !freq_table cpufreq: OMAP: only supports OPP library cpufreq: OMAP: put clk if cpu_init failed cpufreq: OMAP: fix freq_table leak Russell King (1): cpufreq: OMAP: Add SMP support for OMAP4+ Santosh Shilimkar (1): cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreq Todd Poynor (1): cpufreq: OMAP: Enable all CPUs in shared policy mask arch/arm/plat-omap/Makefile|1 - arch/arm/plat-omap/cpu-omap.c | 171 - drivers/cpufreq/Makefile |1 + drivers/cpufreq/omap-cpufreq.c | 274 4 files changed, 275 insertions(+), 172 deletions(-) delete mode 100644 arch/arm/plat-omap/cpu-omap.c create mode 100644 drivers/cpufreq/omap-cpufreq.c -- 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 v8 17/20] OMAP2+: UART: Use custom activate func for console uart.
Govindraj.R govindraj.r...@ti.com writes: Omap-uart can be used as console uart to print early boot messages using earlyprintk so for console uart prevent hwmod reset or idling during bootup. Identify the console_uart set the id and use the custom pm_latency ops for console uart for the first time to idle console uart left enabled from bootup and then enable them back and reset pm_latency ops to default ops. Thanks to Kevin Hilman khil...@ti.com for suggesting this approach. You're welcome, but Rajendra's solution is much better. ;) Can you updated your branch without these custom hooks and using Rajendra's INIT_NO_IDLE change to the hwmod core. Kevin -- 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: [PATCHv9 05/18] mfd: omap-prm: add driver skeleton
On 09/23/2011 05:46 AM, Tero Kristo wrote: This driver will eventually support OMAP soc PRM module features, e.g. PRCM chain interrupts and voltage processor / controller. This patch only adds basic skeleton for the driver that can be probed for omap3 and omap4. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com +config OMAP_PRM + bool OMAP Power and Reset Management driver + depends on (ARCH_OMAP) PM Minor: this should probably be default ARCH_OMAP PM So it's enabled by default whenever a PM kernel is built for OMAP. Kevin -- 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] staging: tidspbridge: request dmtimer clocks on init
Hi Greg, On Fri, Nov 18, 2011 at 3:54 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c b/drivers/staging/tidspbridge/core/dsp-clock.c index 3d1279c..1ba10ae 100644 --- a/drivers/staging/tidspbridge/core/dsp-clock.c +++ b/drivers/staging/tidspbridge/core/dsp-clock.c @@ -54,6 +54,7 @@ /* Bridge GPT id (1 - 4), DM Timer id (5 - 8) */ #define DMT_ID(id) ((id) + 4) +#define DM_TIMER_CLOCKS 5 :/ typo, please ignore this patch there are only 4 clocks for the dsp. I'll send v2 instead. Thanks, Omar -- 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 v2] staging: tidspbridge: request dmtimer clocks on init
Given that dm timer framework doesn't support request of clocks
by soft | hard irqs because some recent changes, tidspbridge needs
to request its clocks on init and enable/disable them on demand.
This was first seen on 3.2-rc1.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/dsp-clock.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c
b/drivers/staging/tidspbridge/core/dsp-clock.c
index 3d1279c..7eb5617 100644
--- a/drivers/staging/tidspbridge/core/dsp-clock.c
+++ b/drivers/staging/tidspbridge/core/dsp-clock.c
@@ -54,6 +54,7 @@
/* Bridge GPT id (1 - 4), DM Timer id (5 - 8) */
#define DMT_ID(id) ((id) + 4)
+#define DM_TIMER_CLOCKS4
/* Bridge MCBSP id (6 - 10), OMAP Mcbsp id (0 - 4) */
#define MCBSP_ID(id) ((id) - 6)
@@ -114,8 +115,13 @@ static s8 get_clk_type(u8 id)
*/
void dsp_clk_exit(void)
{
+ int i;
+
dsp_clock_disable_all(dsp_clocks);
+ for (i = 0; i DM_TIMER_CLOCKS; i++)
+ omap_dm_timer_free(timer[i]);
+
clk_put(iva2_clk);
clk_put(ssi.sst_fck);
clk_put(ssi.ssr_fck);
@@ -130,9 +136,13 @@ void dsp_clk_exit(void)
void dsp_clk_init(void)
{
static struct platform_device dspbridge_device;
+ int i, id;
dspbridge_device.dev.bus = platform_bus_type;
+ for (i = 0, id = 5; i DM_TIMER_CLOCKS; i++, id++)
+ timer[i] = omap_dm_timer_request_specific(id);
+
iva2_clk = clk_get(dspbridge_device.dev, iva2_ck);
if (IS_ERR(iva2_clk))
dev_err(bridge, failed to get iva2 clock %p\n, iva2_clk);
@@ -204,8 +214,7 @@ int dsp_clk_enable(enum dsp_clk_id clk_id)
clk_enable(iva2_clk);
break;
case GPT_CLK:
- timer[clk_id - 1] =
- omap_dm_timer_request_specific(DMT_ID(clk_id));
+ status = omap_dm_timer_start(timer[clk_id - 1]);
break;
#ifdef CONFIG_OMAP_MCBSP
case MCBSP_CLK:
@@ -281,7 +290,7 @@ int dsp_clk_disable(enum dsp_clk_id clk_id)
clk_disable(iva2_clk);
break;
case GPT_CLK:
- omap_dm_timer_free(timer[clk_id - 1]);
+ status = omap_dm_timer_stop(timer[clk_id - 1]);
break;
#ifdef CONFIG_OMAP_MCBSP
case MCBSP_CLK:
--
1.7.0.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: Help with clk API
Hi
On Wed, 16 Nov 2011, Felipe Balbi wrote:
ok, so if I understood correctly, xclk60mhsp1_ck is the external clock
for port 1 and init_60m_clk is the internal optional 60MHz clock, right?
Yes.
So the final workaround would be something like:
clk = uhh-utmi_p1_fck;
Since the struct clk representing the clock gate is currently defined to
be downstream of the struct clk representing the clock mux, rather than
upstream, you'll need to work with at least two different struct clks
here:
1. the struct clk representing the gate: usb_host_hs_utmi_p1_clk.
Maybe call this 'clk_gate' or something.
2. the struct clk representing the mux: utmi_p1_gfclk.
Maybe call this 'clk_mux'.
Also you haven't explicitly defined 'parent'.
So the above would instead be something like:
clk_gate = uhh-usb_host_hs_utmi_p1_clk;
clk_mux = uhh-utmi_p1_fck; /* assuming this is utmi_p1_gfclk */
parent = uhh-init_60m_fclk;
/* ensure optional clock is disabled */
clk_disable(clk);
clk_disable(clk_gate);
And just to be explicit, it's only safe to disable it if the driver has
enabled it already.
ret = clk_set_parent(clk, parent);
ret = clk_set_parent(clk_mux, parent);
if (ret) {
dev_err(uhh-dev, can't change %s's parent to %s\n,
clk-name, parent-name);
return;
Probably return some error code here.
}
ret = clk_enable(clk);
ret = clk_enable(clk_gate);
if (ret) {
dev_err(uhh-dev, failed to enable %s\n, clk-name);
return;
Probably return some error code here.
}
/* wait 1ms */
msleep(1);
I'd suggest using usleep_range(). See
Documentation/timers/timers-howto.txt
parent = uhh-xclk60mhsp1_ck;
clk_disable(clk);
clk_disable(clk_gate);
ret = clk_set_parent(clk, parent);
ret = clk_set_parent(clk_mux, parent);
if (ret) {
dev_err(uhh-dev, can't change %s's parent to %s\n,
clk-name, parent-name);
return;
error code
}
ret = clk_enable(clk);
ret = clk_enable(clk_gate);
if (ret) {
dev_err(uhh-dev, failed to enable %s\n, clk-name);
return some error code
}
and similarly for port 2, but :%s/p1/p2/g
right ?
yep ;-)
- Paul
--
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: [GIT PULL] ARM: OMAP: hwmod fix for 3.2-rc3
* Cousson, Benoit b-cous...@ti.com [16 07:27]: Hi Tony, That bug is becoming annoying, and a bunch of folks are hitting that issue during DT dev for 3.3, so it will be cool to fix that ASAP. OK pulling it in. BTW, next time, please try to base branches on some recent tag like v3.2 or v3.2-rc2. Of course, that is assuming there's no dependency to some recent fix :) Regards, Tony It might already be in Paul's queue for 3.2-rc3. Thanks, Benoit The following changes since commit 6aaf05f472c97ebceff47d9eef464574f1a55727: Linus Torvalds (1): Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 are available in the git repository at: git://gitorious.org/omap-pm/linux.git for_3.2-rc/hwmod-fixes sricharan (1): ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs arch/arm/mach-omap2/omap_hwmod.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) -- 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 0/2] ARM: OMAP: misc. PM fixes for v3.2-rc
* Kevin Hilman khil...@ti.com [18 10:47]: Tony, Here's a couple more PM fixes for v3.2-rc. Also available here if you prefer to pull: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.2/fixes/pm (Note that this branch also includes the CPUidle fix that you already have in your fixes branch) This leads into the same commit showing up twice since it's now applied in two different trees. Can you please rebase your branch on the current fixes? Regards, Tony Kevin Felipe Balbi (1): arm: omap: smartreflex: fix IRQ handling bug Kevin Hilman (1): ARM: OMAP: PM: only register TWL with voltage layer when device is present arch/arm/mach-omap2/pm.c |6 ++ arch/arm/mach-omap2/smartreflex.c |2 +- arch/arm/mach-omap2/twl-common.c | 11 +++ arch/arm/mach-omap2/twl-common.h |3 +++ 4 files changed, 17 insertions(+), 5 deletions(-) -- 1.7.6 -- 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 v2] cbus: Fix initialization of cached IRQ masks
* Felipe Balbi ba...@ti.com [18 04:59]: On Fri, Nov 18, 2011 at 11:31:32AM +0100, Michael Büsch wrote: This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch Reviewed-by: Felipe Balbi ba...@ti.com Thanks applying all three into cbus. Tony -- 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 0/2] ARM: OMAP: misc. PM fixes for v3.2-rc
* Tony Lindgren t...@atomide.com [18 15:09]: * Kevin Hilman khil...@ti.com [18 10:47]: Tony, Here's a couple more PM fixes for v3.2-rc. Also available here if you prefer to pull: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.2/fixes/pm (Note that this branch also includes the CPUidle fix that you already have in your fixes branch) This leads into the same commit showing up twice since it's now applied in two different trees. Can you please rebase your branch on the current fixes? Thanks for updating it, pulling in the fixed branch. Tony Felipe Balbi (1): arm: omap: smartreflex: fix IRQ handling bug Kevin Hilman (1): ARM: OMAP: PM: only register TWL with voltage layer when device is present arch/arm/mach-omap2/pm.c |6 ++ arch/arm/mach-omap2/smartreflex.c |2 +- arch/arm/mach-omap2/twl-common.c | 11 +++ arch/arm/mach-omap2/twl-common.h |3 +++ 4 files changed, 17 insertions(+), 5 deletions(-) -- 1.7.6 -- 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 -- 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: [GIT PULL] ARM: OMAP: DSS hwmod/reset fixes for 3.2
* Tomi Valkeinen tomi.valkei...@ti.com [14 22:31]: On Mon, 2011-11-14 at 14:04 -0800, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [14 13:05]: On Mon, 14 Nov 2011, Tony Lindgren wrote: I suggest we only merge the ones with fix in the subject during the -rc cycle. The others add new features for the reset, so they should wait until v3.3 merge window. Most of the other patches in the branch discuss what they fix in the patch descriptions, rather than the subject lines. Do you want the subject lines rewritten to highlight this? Well we should only merge major bugs and regressions during the -rc cycle. It seems that at least OMAP: HWMOD: Unify DSS resets for OMAPs has high flame potential based on that? Maybe we should wait until the next merge window to start removing some of these workarounds? I'm not sure what you mean... The Unify DSS resets... patch itself fixes only a minor bug: This causes causes the HWMOD reset to fail for dss_dispc and dss_rfbi. But it makes the next patch, Ensure DSS works correctly..., possible. And that patch fixes a bigger bug, DSS or the whole device hanging if the bootloader had enabled the display (which I believe is the default on the shipped beagles/pandas). There's one patch in the series that is not a fix, though: ARM: OMAP4: HWMOD: remove extra clocks. I'm fine with queuing that for the next merge window. But most of the patches have now somehow missed two merge windows, and I'd really like to get them in. OK let's try to get them in then. Hopefully after these DSS will be more independent from the core omap changes. Tony -- 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 1/4] ARM: OMAP3: cm-t35: add regulator supply for ads7846
* Igor Grinberg grinb...@compulab.co.il [08 04:47]: On 11/07/11 22:31, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [06 04:45]: Hi Tony, On 11/05/11 01:57, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [04 16:05]: * Igor Grinberg grinb...@compulab.co.il [111019 02:05]: Applying to board branch for v3.3 merge window. Hmm, actually I suggest you respin patches 2 and 3 so they apply on their own to current fixes branch. Then update 1 and 4 to apply on top of those. This way we can apply 2 and 3 during the -rc cycle, and then queue 1 and 4 for the next merge window. Well, actually all them are fixes, although it cannot be understood from the subject. I will adjust the subjects (and may be the commit messages also) to be more specific and resend. Hmm 1 4 are features that never worked type fixes, so they have flame potential. Those have to wait for the next merge window. Not exactly: 1/4 is a fix that I should have submitted more than a year ago, just after the ads7846 got support for the regulators: Sounds like it's not that urgent then :) Or I can just apply all of them into board branch to wait for the next merge window. That can be an option, if it bothers you too much, but I prefer to have this already in 3.2. I'll just apply them into board branch to wait for the next merge window then. Thanks, Tony -- 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 2/4] mmc: omap: adapt the hsmmc driver to device tree
* Rajendra Nayak rna...@ti.com [14 19:40]:
On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [04 04:16]:
@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match,pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
+ }
So this is now using both DT and pdata?
We want to use DT only, and get rid of pdata. Other than the
deferred probe, is there some other dependency remaining to
having to use the pdata also?
We are using pdata today mainly for the platform function pointers
that get passed for MMC, which can never be passed from DT.
The omap_mmc_platform_data structure today has '17' function pointers.
Most might be sparingly used, nevertheless, its an awfully large number.
Yeah OK.
Here's the list...
-
int (*switch_slot)(struct device *dev, int slot);
int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
int (*get_context_loss_count)(struct device *dev);
per-slot functions
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
int (*set_sleep)(struct device *dev, int slot, int sleep,
int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
void (*before_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*after_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*init_card)(struct mmc_card *card);
int (*get_cover_state)(struct device *dev, int slot);
int (*card_detect)(struct device *dev, int slot);
-
To me it seems we should move these into drivers/mmc/host/omap_hsmmc.c
and set them based on DT compatible (or some other) property.
If these functions tinker with some internal registers, then we need
to fix those too to use regulator/gpio API.
This way we don't need the platform_data any longer.
Regards,
Tony
--
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] arm: omap2: select ARM_AMBA if OMAP3_EMU is defined
* tom.leim...@gmail.com tom.leim...@gmail.com [07 20:02]: From: Ming Lei tom.leim...@gmail.com This patch selects ARM_AMBA if OMAP3_EMU is defined because OC_ETM depends on ARM_AMBA, so fix the link failure[1]. Thanks applying into fixes. Tony [1], arch/arm/kernel/built-in.o: In function `etm_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etm_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined reference to `amba_driver_unregister' arch/arm/kernel/built-in.o: In function `etm_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined reference to `amba_release_regions' arch/arm/mach-omap2/built-in.o: In function `emu_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62: undefined reference to `amba_device_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63: undefined reference to `amba_device_register' make: *** [.tmp_vmlinux1] Error 1 making modules Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5034147..e1293aa 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -334,6 +334,7 @@ config MACH_OMAP4_PANDA config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 + select ARM_AMBA select OC_ETM help Say Y here to enable debugging hardware of omap3 -- 1.7.5.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] ARM: OMAP2+: Remove empty io.h
* Thomas Weber we...@corscience.de [08 04:05]: The file arch/arm/mach-omap2/io.h is empty, so we can remove it. Thanks applying into fixes. Tony Signed-off-by: Thomas Weber we...@corscience.de --- 0 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 arch/arm/mach-omap2/io.h diff --git a/arch/arm/mach-omap2/io.h b/arch/arm/mach-omap2/io.h deleted file mode 100644 index e69de29..000 -- 1.7.7.2 -- 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/RESEND #3 1/7] OMAP3+: PM: SR: add suspend/resume handlers
On Wed, Nov 16, 2011 at 18:02, Kevin Hilman khil...@ti.com wrote: Felipe Balbi ba...@ti.com writes: From: Nishanth Menon n...@ti.com SmartReflex should be disabled while entering low power mode due to the following reasons: [...] Nishanth, in the end, didn't you decide to drop this patch? Yes, I did eventually, once we implemented DVFS for GPU, Ducati, HSI, and other drivers, there was no real way to ensure sequence of suspend sequencing even after moving this to suspend_noirq. some of the other reasons: if I disabled Smartreflex and went to Nominal voltage on MPU, and say MPU was at performance mode of 1.5GHz or so, thermal scenarios got worse due on hot corner samples - these tend to have higher leakage and thermal characteristics tend to be more pronounced. The option of throttling frequency down while suspend was not really a good option in comparison to switching off smart reflex in the last possible moment - in pmxxx.c Regards, Nishanth Menon -- 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 4/4] mcx: initial support for HTKW mcx board
* Ilya Yanok ya...@emcraft.com [14 12:04]: Hi Tony, On 11.11.2011 04:12, Tony Lindgren wrote: This looks OK but let's concentrate on getting things working with board-generic.c and DT only in mainline kernel. I can apply this into testing-board, but let's not cause more churn in mainline with the board files that will be disappearing. Can you please split it into something minimal for mainline that allows booting with DT, and then another patch for testing-board branch? Well, it already boots with DT actually. Did you mean booting with DT and board-generic? I have to admit I don't know how to proceed here: Good to hear you're already playing with it. Yes, let's work on making all the boards work with DT and board-generic.. board-generic initialize twl4030 which we don't have on our board... Could you give me some pointer how I'm supposed to handle this? .. we should only initialize twl4030/twl6030 if the DT compatible flag for it is set. But we're still missing the DT bindings for those :( For now, maybe try to fix the twl4030 probe so it won't do anything unless the I2C device is found? Regards, Tony -- 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] OMAP2+: Fix Compilation error when omap_l3_noc built as module
* Govindraj.R govindraj.r...@ti.com [09 03:12]:
Fix below compilation failure on mainline kernel 3.2-rc1
when omap_l3_noc.c is built as module.
arch/arm/mach-omap2/omap_l3_noc.c:240: error: expected ',' or ';' before
'MODULE_DEVICE_TABLE'
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Thanks applying into fixes.
Tony
---
arch/arm/mach-omap2/omap_l3_noc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c
b/arch/arm/mach-omap2/omap_l3_noc.c
index 6a66aa5..d15225f 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -237,7 +237,7 @@ static int __devexit omap4_l3_remove(struct
platform_device *pdev)
static const struct of_device_id l3_noc_match[] = {
{.compatible = ti,omap4-l3-noc, },
{},
-}
+};
MODULE_DEVICE_TABLE(of, l3_noc_match);
#else
#define l3_noc_match NULL
--
1.7.4.1
--
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
