* [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-6-git-send-email-rnayak@ti.com>
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 Nayak <rnayak@ti.com>
---
.../devicetree/bindings/regulator/regulator.txt | 19 ++++++++++++
drivers/of/of_regulator.c | 31 ++++++++++++++++++++
include/linux/of_regulator.h | 7 ++++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 001e5ce..f8c51d8 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -2,6 +2,8 @@ Voltage/Current Regulators
Required properties:
- compatible: Must be "regulator";
+or
+- compatible: Must be "regulator-fixed"; /* For Fixed volatge regulator */
Optional properties:
- supply-regulator: Name of the parent regulator
@@ -24,6 +26,13 @@ Optional properties:
- always-on: boolean, regulator should never be disabled
- boot-on: bootloader/firmware enabled regulator
- apply-uV: apply uV constraint if min == max
+# For fixed voltage regulators
+- supply-name: Name of the regulator supply
+- microvolts: Output voltage of regulator
+- gpio: gpio to use for enable control
+- startup-delay: startup time in microseconds
+- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- enabled-at-boot: 1 = yes, 0 = no
Example:
@@ -35,3 +44,13 @@ Example:
change-voltage;
always-on;
};
+
+ abc-fixedregulator {
+ compatible = "regulator-fixed";
+ supply-name = "fixed-supply";
+ microvolts = <1800000>;
+ gpio = <43>;
+ startup-delay = <70000>;
+ enable-high;
+ enabled-at-boot;
+ };
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index f01d275..4d7a49d 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
@@ -83,3 +84,33 @@ struct regulator_init_data *of_get_regulator_init_data(struct device_node *np)
return init_data;
}
EXPORT_SYMBOL(of_get_regulator_init_data);
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @np: Pointer to fixed-regulator device tree node
+ *
+ * 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_node *np)
+{
+ struct fixed_voltage_config *config;
+
+ config = kzalloc(sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config->supply_name = (char *)of_get_property(np, "supply-name", NULL);
+ of_property_read_u32(np, "microvolts", &config->microvolts);
+ of_property_read_u32(np, "gpio", &config->gpio);
+ of_property_read_u32(np, "startup-delay", &config->startup_delay);
+ if (of_find_property(np, "enable-high", NULL))
+ config->enable_high = true;
+ if (of_find_property(np, "enabled-at-boot", NULL))
+ config->enabled_at_boot = true;
+ config->init_data = of_get_regulator_init_data(np);
+
+ return config;
+}
+EXPORT_SYMBOL(of_get_fixed_voltage_config);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5eb048c..39860c5 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -11,12 +11,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
+extern struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 07/11] regulator: Make fixed regulator driver extract data from DT
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-7-git-send-email-rnayak@ti.com>
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 <rnayak@ti.com>
---
drivers/regulator/fixed.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..a214b30 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -26,6 +26,8 @@
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_regulator.h>
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -104,10 +106,15 @@ static struct regulator_ops fixed_voltage_ops = {
static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
{
- struct fixed_voltage_config *config = pdev->dev.platform_data;
+ struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev->dev.of_node)
+ config = of_get_fixed_voltage_config(pdev->dev.of_node);
+ else
+ config = pdev->dev.platform_data;
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(&pdev->dev, "Failed to allocate device data\n");
@@ -216,12 +223,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 = reg_fixed_voltage_probe,
.remove = __devexit_p(reg_fixed_voltage_remove),
.driver = {
.name = "reg-fixed-voltage",
.owner = THIS_MODULE,
+ .of_match_table = fixed_of_match,
},
};
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 08/11] omap4: panda: Pass fixed regulator data from DT
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-8-git-send-email-rnayak@ti.com>
Pass the fixed voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
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-panda.dts
index 0a83e3f..9c34c7f 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,6 +52,16 @@
interrupts = <11>;
reg = <0>;
};
+
+ vwl1271-fixedregulator {
+ compatible = "regulator-fixed","ti,twl-reg";
+ supply-name = "vwl1271";
+ microvolts = <1800000>;
+ gpio = <43>;
+ startup-delay = <70000>;
+ enable-high;
+ enabled-at-boot;
+ };
};
};
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 09/11] DT: regulator: Helper to extract regulator node based on supply name
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-9-git-send-email-rnayak@ti.com>
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node at 0x0 {
...
...
regulator = <®ulator1>,<®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 <rnayak@ti.com>
---
drivers/of/of_regulator.c | 37 +++++++++++++++++++++++++++++++++++++
include/linux/of_regulator.h | 7 +++++++
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index 4d7a49d..6f8fd4e 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -114,3 +114,40 @@ struct fixed_voltage_config *of_get_fixed_voltage_config(struct device_node *np)
return config;
}
EXPORT_SYMBOL(of_get_fixed_voltage_config);
+
+/**
+ * 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.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+ struct device_node *regnode = NULL;
+ u32 reghandle;
+ int regsz, namesz;
+ const void *regprop;
+ const char *namesprop;
+
+ regprop = of_get_property(dev->of_node, "regulator", ®sz);
+ namesprop = of_get_property(dev->of_node, "regulator-names", &namesz);
+ if (!regprop || !namesprop)
+ return NULL;
+
+ while (regsz && namesz) {
+ if (!strcmp(namesprop, supply)) {
+ reghandle = be32_to_cpup(regprop);
+ regnode = of_find_node_by_phandle(reghandle);
+ break;
+ }
+ regsz -= 4;
+ regprop += 4;
+ namesz -= strlen(namesprop) + 1;
+ namesprop += strlen(namesprop) + 1;
+ }
+ return regnode;
+}
+EXPORT_SYMBOL(of_get_regulator);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 39860c5..5fc7329 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -13,6 +13,8 @@ extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
+extern struct device_node *of_get_regulator(struct device *dev,
+ const char *id);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -24,6 +26,11 @@ static inline struct fixed_voltage_config
{
return NULL;
}
+static inline struct device_node *of_get_regulator(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 10/11] regulator: Implement consumer regulator mapping from device tree
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-10-git-send-email-rnayak@ti.com>
With device tree, the consumer regulator mapping is deferred till
a regulator_get is called from the corresponding device driver,
instead of being done during regulator_register.
This avoids a complete scan of all DT nodes to identify consumers
for all regulators.
Devices can assocaite with one or more regulators by providing a
list of phandles and supply names.
For Example:
devicenode: node at 0x0 {
...
...
regulator = <®ulator1>,<®ulator2>;
regulator-names = "supply1","supply2";
};
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 <rnayak@ti.com>
---
drivers/regulator/core.c | 23 +++++++++++++++++++++++
include/linux/regulator/driver.h | 3 +++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 9365359..61da2e7 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/of_regulator.h>
#include <linux/regulator/consumer.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
@@ -1167,6 +1169,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
mutex_lock(®ulator_list_mutex);
+#ifdef CONFIG_OF
+ struct device_node *node;
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto out;
+ list_for_each_entry(rdev, ®ulator_list, list)
+ if (node == rdev->node)
+ goto found;
+#else
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
@@ -1178,6 +1189,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
goto found;
}
}
+#endif
if (board_wants_dummy_regulator) {
rdev = dummy_regulator_rdev;
@@ -1216,6 +1228,15 @@ found:
if (!try_module_get(rdev->owner))
goto out;
+#ifdef CONFIG_OF
+ ret = set_consumer_device_supply(rdev, dev, devname, id);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set supply %d\n", ret);
+ unset_regulator_supplies(rdev);
+ goto out;
+ }
+#endif
+
regulator = create_regulator(rdev, dev, id);
if (regulator == NULL) {
regulator = ERR_PTR(-ENOMEM);
@@ -2619,6 +2640,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
rdev->reg_data = driver_data;
rdev->owner = regulator_desc->owner;
rdev->desc = regulator_desc;
+ if (dev && dev->of_node)
+ rdev->node = dev->of_node;
INIT_LIST_HEAD(&rdev->consumer_list);
INIT_LIST_HEAD(&rdev->list);
BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 1a80bc7..4aebbf5 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -196,6 +196,9 @@ struct regulator_dev {
struct mutex mutex; /* consumer lock */
struct module *owner;
struct device dev;
+#ifdef CONFIG_OF
+ struct device_node *node;
+#endif
struct regulation_constraints *constraints;
struct regulator *supply; /* for tree */
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 11/11] DT: regulator: register regulators as platform devices
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-11-git-send-email-rnayak@ti.com>
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 <rnayak@ti.com>
---
drivers/mfd/twl-core.c | 3 +++
drivers/of/of_regulator.c | 30 ++++++++++++++++++++++++++++++
include/linux/of_regulator.h | 5 +++++
3 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index a12af12..f210e28 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -36,6 +36,7 @@
#include <linux/slab.h>
#include <linux/of_irq.h>
#include <linux/irqdomain.h>
+#include <linux/of_regulator.h>
#include <linux/regulator/machine.h>
@@ -1357,6 +1358,8 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
else
status = add_children(pdata, id->driver_data);
+ of_regulator_register_devices(node);
+
fail:
if (status < 0)
twl_remove(client);
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index 6f8fd4e..0312a6a 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
@@ -151,3 +152,32 @@ struct device_node *of_get_regulator(struct device *dev, const char *supply)
return regnode;
}
EXPORT_SYMBOL(of_get_regulator);
+
+/**
+ * of_regulator_register_devices - Register regulator devices to platform bus
+ * @np: Parent device node with regulator child nodes
+ *
+ * Registers all the regulator and regulator-fixed nodes as platform devices
+ *
+ */
+void of_regulator_register_devices(struct device_node *np)
+{
+ struct device_node *child;
+ struct platform_device *dev;
+
+ for_each_child_of_node(np, child) {
+ if (of_device_is_compatible(child, "regulator")
+ || of_device_is_compatible(child, "regulator-fixed")) {
+ dev = of_device_alloc(child, NULL, NULL);
+ if (!dev)
+ return;
+ dev->dev.bus = &platform_bus_type;
+ if (of_device_add(dev) != 0) {
+ platform_device_put(dev);
+ return;
+ }
+ }
+ }
+ return;
+}
+
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5fc7329..38cf7e3 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -15,6 +15,7 @@ extern struct fixed_voltage_config
*of_get_fixed_voltage_config(struct device_node *np);
extern struct device_node *of_get_regulator(struct device *dev,
const char *id);
+extern void of_regulator_register_devices(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
@@ -31,6 +32,10 @@ static inline struct device_node *of_get_regulator(struct device *dev,
{
return NULL;
}
+static inline void of_regulator_register_devices(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related
* [PATCHv2 3/3] picoxcell: add the DTS for the PC7302 board
From: Benjamin Herrenschmidt @ 2011-09-15 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314196906-20709-4-git-send-email-jamie@jamieiles.com>
On Wed, 2011-08-24 at 15:41 +0100, Jamie Iles wrote:
> + chosen {
> + bootargs = "console=ttyS0,115200 earlyprintk loglevel=9 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=5,2048";
> + linux,stdout-path = &uart0;
> + };
Hrm... we don't normally put the bootargs in the device-tree.
Either you have a way to pass it from a previous firmware (which
can then slap it into the device-tree at runtime), or you
can have a way to compile it in the kernel image but the device-tree
isn't the right place for it.
Cheers,
Ben.
^ permalink raw reply
* confusion regarding the CMD19 and CMD21 in eMMC/SD card spec
From: Girish K S @ 2011-09-15 11:58 UTC (permalink / raw)
To: linux-arm-kernel
Dear all,
The eMMC 4.5 specification mentions that the CMD21 in
class 2 is a SEND_TUNING BLOCK command. where as the SD card
specification
in the given link says CMD19 in class 2 is the SEND_TUNING_BLOCK
http://www.scribd.com/doc/50685191/53/Figure-4-8-Send-Tuning-Block-Command.
Also the implementation in the drivers/mmc/host/sdhci.c uses the CMD19
as the SEND_TUNING_BLOCK.
Can anybody clarify why there is overlapping in this command number.
May be my understand is wrong.
In the MMC spec the CMD19 is BUS_TEST_W in class 0 and CMD21 is
reserved till eMMC 4.41 version.
But in the SD specification (given link) CMD19 is SEND_TUNING_BLOCK
and CMD21 is reserved.
Thanks and regards
Girish K S
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Shilimkar, Santosh @ 2011-09-15 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71C702.40206@ti.com>
On Thu, Sep 15, 2011 at 3:06 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Santosh,
>
> On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote:
>>
>> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>>>
>>> * Santosh<santosh.shilimkar@ti.com> ? [110914 09:40]:
>>>>
>>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>>>
>>>>> * Santosh<santosh.shilimkar@ti.com> ? ?[110914 09:16]:
>>>>>
>>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>>> wrong as we've had the GIC working for over two years now without
>>>>> doing anything with the wakeup gen registers :)
>>>>>
>>>> It's working because CPU clockdomain are never put under HW
>>>> supervised mode and they are kept in force wakeup. Clock-domain
>>>> never idles on mainline code. PM series will put the clock-domains
>>>> under HW supervison as needed to achieve any low power states and
>>>> then all sorts of corner cases will come out.
>>>
>>> But again the wakeup gen triggers only do something when hitting
>>> idle. There should be no use for them during runtime, right?
>>>
>> You missed my point in the description. Clockdomain inactive
>> doesn't depend on idle or WFI execution. Under HW supervison
>> CPU clock domain can get into inactive when CPU is stalled and
>> waiting for a read response from slow interconnect.
>
> I'm a little bit confused by that statement...
>
> I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it if
> the MPU is gated? What kind of event can wakeup the CPU in case of CPU
> stalled?
>
> The spec seems to indicate that wakeupgen is needed only if CPU are in WFI.
> It is even written: "CPUx will change power state only when StandbyWFI is
> asserted.". Even a WFE is not supposed to trigger a standby.
> How can the CPU be inactive at clock domain level without a WFI?
>
I mean only CPU clock domain and not the power domain inactive
and local CPU clock can be gated without WFI when clock domain
is kept under hardware supervision.
But I agree with you that, for the stalled case, wakeupgen can't
generate any event and it will LPRM state-machine which take
care of un-gating the clock for that local CPU.
I have been discussing today morning with design IP team on the
restriction in the functional specs and they said they will check and
comeback.
For now, I would like to go with what specs says. By next merge window,
am sure we will be clear inputs from IP team on this and if it happens
that the requirement needs to be changed and we need not do
mask/unmask in non-low power scenario, we can start looking
at other aspects as Tony suggested.
Regards
Santosh
^ permalink raw reply
* [PATCHv2 3/3] picoxcell: add the DTS for the PC7302 board
From: Jamie Iles @ 2011-09-15 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316086322.2602.1.camel@pasglop>
On Thu, Sep 15, 2011 at 08:32:02AM -0300, Benjamin Herrenschmidt wrote:
> On Wed, 2011-08-24 at 15:41 +0100, Jamie Iles wrote:
>
> > + chosen {
> > + bootargs = "console=ttyS0,115200 earlyprintk loglevel=9 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=5,2048";
> > + linux,stdout-path = &uart0;
> > + };
>
> Hrm... we don't normally put the bootargs in the device-tree.
>
> Either you have a way to pass it from a previous firmware (which
> can then slap it into the device-tree at runtime), or you
> can have a way to compile it in the kernel image but the device-tree
> isn't the right place for it.
OK, that's fair enough. A few other ARM platforms (tegra, prima2 and
zynq) have bootargs in the chosen node and that's where I got it from,
but our bootloader has fdt support so this can easily be removed.
Thanks,
Jamie
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-15 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915102915.GJ6267@n2100.arm.linux.org.uk>
On 9/15/2011 12:29 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>
> SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
> numbering given to us by the GIC.
>
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>
> That depends whether you're counting SPI number or whether you're counting
> IRQ number in the GIC interfaces. SPI0 will be reported to us from the
> GIC as 32, not 0, so to start numbering from 0 (which is already frowned
> upon for many reasons) we'd have to subtract 32 after checking that the
> IRQ is not a SGI nor PPI in the assembly code instead.
The HW specs is obviously counting the IRQ number at the GIC interface.
That offset is not known outside the MPUSS. Please have a look at the
OMAP4430 TRM p4761 (NDA vM version).
FWIW, the same numbering scheme is used on tegra2.
My proposal is just to handle the addition within the irq_domain_to_irq,
so I'm not sure to understand your concern.
Regards,
Benoit
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Russell King - ARM Linux @ 2011-09-15 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71EF56.3050503@ti.com>
On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
> The HW specs is obviously counting the IRQ number at the GIC interface.
> That offset is not known outside the MPUSS. Please have a look at the
> OMAP4430 TRM p4761 (NDA vM version).
As far as I know, I have no access to that. I've certainly never been
pointed to any documentation on OMAP4.
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-15 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSFu2HC+u2NY41+yw9tEyy85RKa4Dpm3SL+jbwS_OOA0A@mail.gmail.com>
On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 53 ++++++++++++++++++++++++
>> arch/arm/common/gic.c | 55 +++++++++++++++++++++++--
>> arch/arm/include/asm/hardware/gic.h | 10 +++++
>> 3 files changed, 114 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> [...]
>
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>
> [...]
>
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> + void __iomem *cpu_base;
>> + void __iomem *dist_base;
>> + int irq;
>> + struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> +
>> + if (WARN_ON(!node))
>> + return;
>> +
>> + dist_base = of_iomap(node, 0);
>> + WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> + cpu_base = of_iomap(node, 1);
>> + WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> + domain->nr_irq = gic_irq_count(dist_base);
>> + domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.
>
So I guess you have the A9 external nIRQ hooked up to another
controller? Why can't the 0-31 interrupts get mapped to after the gic
interrupts? Ultimately we want h/w irq numbers completely decoupled from
linux irq numbers. So you will want to put that controller in devicetree
and have an DT init function for it as well.
In anycase, there's a simple solution. You just need a call to
irq_alloc_descs to reserve the first 32 interrupts before calling
of_irq_init.
Rob
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-15 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915125107.GK6267@n2100.arm.linux.org.uk>
On 9/15/2011 2:51 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
>> The HW specs is obviously counting the IRQ number at the GIC interface.
>> That offset is not known outside the MPUSS. Please have a look at the
>> OMAP4430 TRM p4761 (NDA vM version).
>
> As far as I know, I have no access to that. I've certainly never been
> pointed to any documentation on OMAP4.
That's easy to fix since the same information is in the public TRM
(p3386 in that case). And here is the link:
http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vX.zip
Do not hesitate to ask if you never further information on OMAP SoC.
Regards,
Benoit
^ permalink raw reply
* [PATCH v3 1/1] ASoC: mxs-saif: add record function
From: Dong Aisheng-B29396 @ 2011-09-15 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110909133051.GS1912@pengutronix.de>
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang at pengutronix.de]
> Sent: Friday, September 09, 2011 9:31 PM
> To: Dong Aisheng-B29396
> Cc: alsa-devel at alsa-project.org; linux-arm-kernel at lists.infradead.org;
> broonie at opensource.wolfsonmicro.com; lrg at ti.com; s.hauer at pengutronix.de
> Subject: Re: [PATCH v3 1/1] ASoC: mxs-saif: add record function
>
> On Wed, Sep 07, 2011 at 08:51:50PM +0800, Dong Aisheng wrote:
> > 1. add different clkmux mode handling
> > SAIF can use two instances to implement full duplex (playback &
> > recording) and record saif may work on EXTMASTER mode which is using
> > other saif's BITCLK&LRCLK.
> >
> > The clkmux mode could be set in pdata->init() in mach-specific code.
> > For generic saif driver, it only needs to know who is his master and
> > the master id is also provided in mach-specific code.
> >
> > 2. support playback and capture simutaneously however the sample rates
> > can not be different due to hw limitation.
> >
> > Signed-off-by: Dong Aisheng <b29396@freescale.com>
>
> One thing I see...
>
> > @@ -422,20 +503,39 @@ static int mxs_saif_trigger(struct
> snd_pcm_substream *substream, int cmd,
> > __raw_readl(saif->base + SAIF_DATA);
> > }
> >
> > - dev_dbg(cpu_dai->dev, "CTRL 0x%x STAT 0x%x\n",
> > + master_saif->ongoing = 1;
> > +
> > + dev_dbg(saif->dev, "CTRL 0x%x STAT 0x%x\n",
> > __raw_readl(saif->base + SAIF_CTRL),
> > __raw_readl(saif->base + SAIF_STAT));
> >
> > + dev_dbg(master_saif->dev, "CTRL 0x%x STAT 0x%x\n",
> > + __raw_readl(master_saif->base + SAIF_CTRL),
> > + __raw_readl(master_saif->base + SAIF_STAT));
> > break;
> > case SNDRV_PCM_TRIGGER_SUSPEND:
> > case SNDRV_PCM_TRIGGER_STOP:
> > case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > dev_dbg(cpu_dai->dev, "stop\n");
> >
> > - clk_disable(saif->clk);
> > - if (!saif->mclk_in_use)
> > + /* wait a while for the current sample to complete */
> > + delay = USEC_PER_SEC / master_saif->cur_rate;
> > +
> > + if (!master_saif->mclk_in_use) {
> > + __raw_writel(BM_SAIF_CTRL_RUN,
> > + master_saif->base + SAIF_CTRL + MXS_CLR_ADDR);
> > + udelay(delay);
> > + }
> > + clk_disable(master_saif->clk);
> > +
> > + if (saif != master_saif) {
> > __raw_writel(BM_SAIF_CTRL_RUN,
> > saif->base + SAIF_CTRL + MXS_CLR_ADDR);
> > + udelay(delay);
>
> I think we should use usleep_range for both udelays here? Having a rate
> of 8000, we'd burn 250us here.
>
Yes, I agree that it's a bit long for 8000.
I tried sleep way but I found the trigger function is called with
spin_lock held, so it seems we may not be able to sleep here.
I think the way of dynamically calculate delay suggested by Liam has
Already minimize the affection, especially for high sample rate, it
may work more efficiency than sleep (context switch cost).
Do you think if it's reasonable to accept it?
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-15 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71CE5D.9030900@ti.com>
Benoit,
On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> Hi Rob,
>
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com> wrote:
>>> From: Rob Herring<rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>> the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/gic.txt | 53
>>> ++++++++++++++++++++++++
>>> arch/arm/common/gic.c | 55
>>> +++++++++++++++++++++++--
>>> arch/arm/include/asm/hardware/gic.h | 10 +++++
>>> 3 files changed, 114 insertions(+), 4 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>> *parent)
>>> +{
>>> + void __iomem *cpu_base;
>>> + void __iomem *dist_base;
>>> + int irq;
>>> + struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>> +
>>> + if (WARN_ON(!node))
>>> + return;
>>> +
>>> + dist_base = of_iomap(node, 0);
>>> + WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> + cpu_base = of_iomap(node, 1);
>>> + WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> + domain->nr_irq = gic_irq_count(dist_base);
>>> + domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>> numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
>
> I have another concern on a similar topic.
>
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
> 32. Only the internal PPI are between 0 and 31.
>
> For the moment we add 32 to every SoC interrupts in the irq.h define,
Those defines will not be used in the DT case. So the question is
whether to add 32 or not in the DT. Since we have just a single node and
a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
at 32. And from the h/w definition, SPIs always start at 32, so it's in
agreement.
> but I'm assuming that this offset calculation should be done thanks to a
> dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value that
> should be in the irq binding of the device.
>
> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.
>
That offset of SPIs is always there. If you have a GIC as a secondary
controller, It will have 32 reserved interrupts and the register layout
is exactly the same as a cpu's GIC.
Since the idea of splitting PPIs for each core out to a flattened linux
irq map has been abandoned, I see no reason to have more than 1 domain
with a simple linear translation. Ultimately, domains will do dynamic
irqdesc allocation and the translation within the gic will be completely
dynamic.
The exynos4 case appears to be another controller hooked up in parallel
to the GIC. The GIC itself is exactly the same as other platforms AFAICT.
Rob
^ permalink raw reply
* [PATCH v2] [media] at91: add code to initialize and manage the ISI_MCK for Atmel ISI driver.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-15 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E668BBF.4020600@gmail.com>
On 23:08 Tue 06 Sep , Sylwester Nawrocki wrote:
> On 09/06/2011 10:05 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> I'm not entirely sure on this one, but as we had a similar situation with
> >> clocks, we decided to extablish the clock hierarchy in the board code, and
> >> only deal with the actual device clocks in the driver itself. I.e., we
> >> moved all clk_set_parent() and setting up the parent clock into the board.
> >> And I do think, this makes more sense, than doing this in the driver, not
> >> all users of this driver will need to manage the parent clock, right?
> >
> > I don't like to manage the clock in the board except if it's manadatory otherwise
> > we manage this at soc level
> >
> > the driver does not have to manage the clock hierachy or detail implementation
> > but manage the clock enable/disable and speed depending on it's need
>
> We had a similar problem in the past and we ended up having the boot loader
> setting up the parent clock for the device clock. The driver only controls clock
> gating and sets its clock frequency based on an internal IP version information,
> derived from the SoC revision.
sorry NACK
I do not want to rely on bootloader
when we will have the DT we will pass it via it right now we need find an
other generic way
Best Regards,
J.
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Woodruff, Richard @ 2011-09-15 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gy0VX5wQVJRjpjMwtNqM5h2Te4FtoFnyZfphFyP+uSXmQ@mail.gmail.com>
> From: Shilimkar, Santosh
> Sent: Thursday, September 15, 2011 7:02 AM
> >> You missed my point in the description. Clockdomain inactive
> >> doesn't depend on idle or WFI execution. Under HW supervison
> >> CPU clock domain can get into inactive when CPU is stalled and
> >> waiting for a read response from slow interconnect.
My understanding is MPSS global clock domain can not gate unless each cpu is in wfi and other conditions are met. Other conditions are a wugen ack that there are no irqs and ocp-bridge logic giving its ok.
What kind of local clock gating is there per cpu or sub-clock domains is not as clear. The mpu's pivot on individual wfi while other blocks in mpuss have other considerations.
The spec is very clear about coherent programmation of wugen and gic. Like being discussed.
Its examples are about how wugen used I've heard about are around transition in and out of standbys at wfi. Wugen will process all irqs before giving ack to sleep, it also has ability to fail sleep if new irqs come in before final idle.
* It may be possible depending on clarifications to handle near wfi, but you might have to do it for -every- cpu's wfi unless you can coordinate who the last one is. Doing it as you go with gic would avoid redoing work over and over at the many wfi calls. This extra work costs in latency and power.
Doing housekeeping along with gic seems better from a run time perspective.
Regards,
Richard W.
^ permalink raw reply
* [RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
From: Mark Brown @ 2011-09-15 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-2-git-send-email-rnayak@ti.com>
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 | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS)
> for all the registered regulators.
>
> There is no need for all the board files to pass this information
> additionally, when the driver already sets them by default.
"the driver"? This sounds very buggy...
^ permalink raw reply
* [RFC PATCH 02/11] regulator: Fix error check in set_consumer_device_supply
From: Mark Brown @ 2011-09-15 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-3-git-send-email-rnayak@ti.com>
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 when *both* are passed.
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
No, passing both is a clear bug on the part of the caller - the two ways
of specifying the device are not supposed to be used together.
^ permalink raw reply
* [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
From: Mark Brown @ 2011-09-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-4-git-send-email-rnayak@ti.com>
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 | 1 +
> drivers/of/of_regulator.c | 85 ++++++++++++++++++++
> include/linux/of_regulator.h | 23 +++++
Don't go hiding the bindings for things away from the code they're
binding. Bindings for the regualtor API are a regulator API thing and
should be part of the regulator API code.
> +Required properties:
> +- compatible: Must be "regulator";
Is this idiomatic or should we just have a helper that parses a big list
of properties from the device node?
> +- mode-fast: boolean, Can handle fast changes in its load
> +- mode-normal: boolean, Normal regulator power supply mode
> +- mode-idle: boolean, Can be more efficient during light loads
> +- mode-standby: boolean, Can be most efficient during light loads
I guess these are actually permissions to set the given modes? The
documentation should be clearer.
> +- apply-uV: apply uV constraint if min == max
This seems a bit Linux/runtime policy specific (especially the last
bit).
^ permalink raw reply
* [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
From: Mark Brown @ 2011-09-15 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-5-git-send-email-rnayak@ti.com>
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.
> + xyz-regulator: regulator at 0 {
> + compatible = "regulator","ti,twl-reg";
> + ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
These magic numbers are *very* Linux specific, we should have a better
way of specifying regulators - I'd off the top of my head expect that
the compatible property would identify the regulator.
^ permalink raw reply
* [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
From: Mark Brown @ 2011-09-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-7-git-send-email-rnayak@ti.com>
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/of_regulator.h | 7 ++++
> 3 files changed, 57 insertions(+), 0 deletions(-)
Again, this should be part of the regulator API code not hidden away
where it will only get reviewed by device tree people.
> Required properties:
> - compatible: Must be "regulator";
> +or
> +- compatible: Must be "regulator-fixed"; /* For Fixed volatge regulator */
This seems at best confusing - the fixed voltage regulator is a
particular regulator driver, and the general concept of a fixed voltage
regulator is still a subset of regulators.
> +# For fixed voltage regulators
> +- supply-name: Name of the regulator supply
> +- microvolts: Output voltage of regulator
> +- gpio: gpio to use for enable control
> +- startup-delay: startup time in microseconds
> +- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
> +- enabled-at-boot: 1 = yes, 0 = no
Much of this is specific to the Linux fixed voltage regulator driver
rather than a generic regulator with a fixed voltage.
^ permalink raw reply
* [RFC PATCH 07/11] regulator: Make fixed regulator driver extract data from DT
From: Mark Brown @ 2011-09-15 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-8-git-send-email-rnayak@ti.com>
On Thu, Sep 15, 2011 at 04:52:03PM +0530, Rajendra Nayak wrote:
> 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)
The code you added in the previous patch should be part of this driver.
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-15 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71F978.6020402@gmail.com>
On 9/15/2011 3:11 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com> wrote:
>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>> the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/gic.txt | 53
>>>> ++++++++++++++++++++++++
>>>> arch/arm/common/gic.c | 55
>>>> +++++++++++++++++++++++--
>>>> arch/arm/include/asm/hardware/gic.h | 10 +++++
>>>> 3 files changed, 114 insertions(+), 4 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>> *parent)
>>>> +{
>>>> + void __iomem *cpu_base;
>>>> + void __iomem *dist_base;
>>>> + int irq;
>>>> + struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> + if (WARN_ON(!node))
>>>> + return;
>>>> +
>>>> + dist_base = of_iomap(node, 0);
>>>> + WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> + cpu_base = of_iomap(node, 1);
>>>> + WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> + domain->nr_irq = gic_irq_count(dist_base);
>>>> + domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>> numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>
> Those defines will not be used in the DT case. So the question is
> whether to add 32 or not in the DT. Since we have just a single node and
> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
> at 32. And from the h/w definition, SPIs always start at 32, so it's in
> agreement.
This is a agreement inside the MPUSS, but not outside.
Both Tegra and OMAP4 must add an offset to the HW irq number to deal
with that today.
>> but I'm assuming that this offset calculation should be done thanks to a
>> dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>>
>
> That offset of SPIs is always there. If you have a GIC as a secondary
> controller, It will have 32 reserved interrupts and the register layout
> is exactly the same as a cpu's GIC.
Yep, but that's the GIC view and not the SoC one. My concern is to have
to tweak the HW number provided by the HW spec in order to add that offset.
If you look at SoC level, the MPUSS is just an IP that can be
potentially replaced by other one that will not have a GIC. In that case
you will not change the IRQ mapping at SoC level.
For example if you replace the Dual-cortexA9 by a single CortexA8, then
all the interrupts will have to be shifted by 32 just because the MPU
subsystem is different.
Since that offset is dependent of the GIC internals and is not exposed
outside the MPUSS, it should not be visible by the SoC IPs. And the HW
spec is exposing exactly that.
> Since the idea of splitting PPIs for each core out to a flattened linux
> irq map has been abandoned, I see no reason to have more than 1 domain
> with a simple linear translation. Ultimately, domains will do dynamic
> irqdesc allocation and the translation within the gic will be completely
> dynamic.
I think the only reason to do that is to separate internal MPU
interrupts with the external ones that should not have a clue about the GIC.
Regards,
Benoit
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox