[PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
From: J Keerthy j-keer...@ti.com
The SMPS10 regulator is not presesnt in all the variants
of the PALMAS PMIC family. Hence adding a feature to distingush
between them.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 27 ---
drivers/regulator/palmas-regulator.c |3 +++
include/linux/mfd/palmas.h | 14 ++
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index b24bee3..1cacc6a 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -238,8 +248,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -261,9 +272,16 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
palmas-irq = i2c-irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-dev);
+
+ if (!match)
+ return -ENODATA;
+
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas-i2c_clients[i] = i2c;
@@ -433,11 +451,6 @@ static const struct i2c_device_id palmas_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
-static struct of_device_id of_palmas_match_tbl[] = {
- { .compatible = ti,palmas, },
- { /* end */ }
-};
-
static struct i2c_driver palmas_i2c_driver = {
.driver = {
.name = palmas,
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 3ae44ac..1ae1e83 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
continue;
ramp_delay_support = true;
break;
+ case PALMAS_REG_SMPS10:
+ if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST))
+ continue;
}
if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8))
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8f21daf..98058ca 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -32,6 +32,19 @@
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
+/**
+ * Palmas PMIC feature types
+ *
+ * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides SMPS10_BOOST
+ * regulator.
+ *
+ * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a
+ * specific feature (above) or not. Return non-zero, if yes.
+ */
+#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(0)
+#define PALMAS_PMIC_HAS(b, f) \
+ ((b)-features PALMAS_PMIC_FEATURE_ ## f)
+
struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
@@ -46,6 +59,7 @@ struct palmas {
/* Stored chip id */
int id;
+ unsigned int features;
/* IRQ Data */
int irq;
u32 irq_mask;
--
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
[PATCH v3 3/4] mfd: Palmas: Add TPS659038 PMIC support
From: J Keerthy j-keer...@ti.com
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
drivers/mfd/palmas.c |5 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index 7bcd59c..89cb773 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -5,6 +5,7 @@ twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
+tps659038
Required properties:
- compatible : Should be from the list
@@ -14,6 +15,7 @@ Required properties:
ti,tps65913
ti,tps65914
ti,tps80036
+ ti,tps659038
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 1cacc6a..0439edb 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -232,12 +232,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
}
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+static unsigned int tps659038_features;
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
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
[PATCH v3 1/4] MFD: Palmas: Check if irq is valid
From: J Keerthy j-keer...@ti.com
Check if irq value obtained is valid. If it is not valid
then skip the irq request step and go ahead with the probe.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 62fa728..b24bee3 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -290,6 +290,11 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ if (!palmas-irq) {
+ dev_warn(palmas-dev, IRQ missing: skipping irq request\n);
+ goto no_irq;
+ }
+
/* Change interrupt line output polarity */
if (pdata-irq_flags IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -316,6 +321,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err;
+no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
--
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
[PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
From: J Keerthy j-keer...@ti.com The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V3: Implements Interrupts check using i2c-irq variable instead of DT interrupts property. Cleans ups in assiging the features variable in patch 2. V2: Implements Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if irq is valid MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 + .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c | 38 drivers/regulator/palmas-regulator.c |4 ++ include/linux/mfd/palmas.h | 14 +++ 5 files changed, 52 insertions(+), 7 deletions(-) -- 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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model. I couldn't
find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Do you have any better ideas?
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
cheers,
-roger
--
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 1/4] ARM: dts: omap4-panda: Add USB Host support
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model. I couldn't
find a better
way to represent this. It gives us a way to specify not only the GPIO line
but also
the polarity. I know mostly reset is active low but still there is
flexibility as you never
know for sure.
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
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] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 0/2] ARM: dts: Add initial support for IGEP AQUILA
Hi all, These two patches introduces initial support for the IGEP AM335x-based platforms. The first patch add support for IGEP COM AQUILA products, and the second patch add support for the development board. These patches apply on top of bcousson/for_3.11/dts repository. Best regards, Enric Balletbo i Serra (2): ARM: dts: AM33XX: Add support for IGEP COM AQUILA ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board. arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/am335x-base0033.dts | 17 +++ arch/arm/boot/dts/am335x-igep0033.dtsi | 269 + 3 files changed, 288 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/am335x-base0033.dts create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi -- 1.8.1.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
[PATCH 2/2] ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board.
The IGEP AQUILA EXPANSION board is a development platform for the IGEP COM
AQUILA AM335x boards.
The board adds the following connectivity:
o USB OTG
o USB HOST
o HDMI
o Ethernet
o Serial Debug (3.3V)
o 2x46 pin headers
o EEPROM
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am335x-base0033.dts | 17 +
2 files changed, 18 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-base0033.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..cb675d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -154,6 +154,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
+ am335x-base0033.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
new file mode 100644
index 000..a365f11
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * IGEP AQUILA Expansion Board.
+ *
+ */
+
+#include am335x-igep0033.dtsi
+
+/ {
+ model = IGEP COM AM335x on AQUILA Expansion;
+ compatible = ti,am335x-base0033, ti,am335x-igep0033, ti,am33xx;
+};
--
1.8.1.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
[PATCH 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 269 +
1 file changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..1d70141
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ nandflash_pins: pinmux_nandflash_pins {
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wpn.gpio0_30 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ ;
+ };
+
+ user_leds: pinmux_user_leds_pins {
+ pinctrl-single,pins =
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ ;
+ };
+
+ };
+
+ ocp {
+ uart0: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+ status = okay;
+ };
+
+ i2c0: i2c@44e0b000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
+ status = okay;
+ clock-frequency = 40;
+
+ tps: tps@2d {
+ reg = 0x2d;
+ };
+ };
+
+ elm: elm@4808 {
+ status = okay;
+ };
+
+ gpmc: gpmc@5000 {
+ pinctrl-names = default;
+ pinctrl-0 = nandflash_pins;
+
+ status = okay;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+
+
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
Hi Lee, On Wed, Jun 19, 2013 at 09:26:33AM +0100, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. It's already in mfd-next. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1] MFD: Change TWL6025 references to TWL6032
On Fri, 07 Jun 2013, Oleksandr Kozaruk wrote: From: Graeme Gregory g...@slimlogic.co.uk The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there is no users of TWL6025 in the code. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com --- There are non-mainline branches that use twl6032 by its name (for example git://git.omapzoom.org/kernel/omap.git). There is intention to add support of twl6032 device in mainline, but we'd like to know if we can use twl6032 instead of twl6025 in our new patches, that we are going to provide. drivers/mfd/twl-core.c| 46 +++--- drivers/regulator/twl-regulator.c | 76 ++--- drivers/usb/phy/phy-twl6030-usb.c |2 +- include/linux/i2c/twl.h | 30 +++ 4 files changed, 77 insertions(+), 77 deletions(-) If the TWL6025 truly didn't enter production then I'm okay with this as long as Mark and the other maintainers are. For the MFD parts: Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Wed, 19 Jun 2013, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. Ah, it looks like Sam must have already applied this. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 4/4] arm: omap: remove using usb_bind_phy for binding musb and phy
Now that MUSB for OMAP started using devm_usb_get_phy_by_name which does not require PHY library to already have the binding information, removed usb_bind_phy calls that binds the MUSB controller with the PHY from the board files. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Felipe Balbi ba...@ti.com Tested-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |1 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3stalker.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c|1 - arch/arm/mach-omap2/board-rm680.c|1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 - 18 files changed, 18 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 244d8a5..30d81f2 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -233,7 +233,6 @@ static void __init omap_2430sdp_init(void) omap_hsmmc_init(mmc); omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 23b004a..7f431b4 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -590,7 +590,6 @@ static void __init omap_3430sdp_init(void) omap_ads7846_init(1, gpio_pendown, 310, NULL); omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 56a9a4f..5a05b5a 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -730,7 +730,6 @@ static void __init omap_4430sdp_init(void) omap4_sdp4430_wifi_init(); omap4_twl6030_hsmmc_init(mmc); - usb_bind_phy(musb-hdrc.2.auto, 0, omap-usb2.3.auto); usb_musb_init(musb_board_data); status = omap_ethernet_init(); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index ee6218c..f9b4241 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -690,7 +690,6 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index 5764205..8d24aab 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -593,7 +593,6 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c index b54562d..5451c9c 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -628,7 +628,6 @@ static void __init igep_init(void) omap_serial_init(); omap_sdrc_init(m65kam_sdrc_params, m65kam_sdrc_params); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); igep_flash_init(); diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index d0d17bc..07423f2 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -376,7 +376,6 @@ static void __init omap_ldp_init(void) omap_ads7846_init(1, 54, 310, NULL); omap_serial_init(); omap_sdrc_init(NULL, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); usb_musb_init(NULL); board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions),
[PATCH 3/4] usb: musb: omap: use the new API to get PHY reference by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/usb/musb/musb_core.c |1 +
drivers/usb/musb/musb_core.h |1 +
drivers/usb/musb/omap2430.c |2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..00fbaf4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-board_set_power = plat-set_power;
musb-min_power = plat-min_power;
musb-ops = plat-platform_ops;
+ musb-phy_name = plat-phy_name;
/* The musb_platform_init() call:
* - adjusts musb-mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..e9a9339 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -434,6 +434,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
struct musb_hdrc_config *config;
+ const char *phy_name;
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..f872ebc 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -352,7 +352,7 @@ static int omap2430_musb_init(struct musb *musb)
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
else
- musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-xceiv = devm_usb_get_phy_by_name(dev, musb-phy_name);
if (IS_ERR(musb-xceiv)) {
status = PTR_ERR(musb-xceiv);
--
1.7.10.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
[PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..5ddbe39 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ musb_plat.phy_name = omap-usb2;
+ } else if (cpu_is_omap34xx()) {
+ musb_plat.phy_name = twl4030;
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..c05d46d 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char *clock;
+ /* phy device label */
+ const char *phy_name;
+
/* (HOST or OTG) switch VBUS on/off */
int (*set_vbus)(struct device *dev, int is_on);
--
1.7.10.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
[PATCH 0/4] usb: musb: fix USB enumeration issue in OMAP3 platform
In the case of non-dt boot, the platform specific initialization file (board file) will do usb_bind_phy that binds the usb controller with the PHY using device names. After the device names are created using PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't work reliably (since the device name changes). Hence the usb controller is made to use labels for getting the PHY. Here the PHY name is added in the plat data of USB controller device which should be used by the controller driver to get the PHY. Two new APIs usb_get_phy_by_name and devm_usb_get_phy_by_name are added to be used by the controller to get the PHY by name. Changes from RFC *) Changed the signature of usb_get_phy_by_name() not to use struct device * Kishon Vijay Abraham I (4): arm: omap: Add phy binding info for musb in plat data usb: phy: add a new API to get PHY ref by label usb: musb: omap: use the new API to get PHY reference by label arm: omap: remove using usb_bind_phy for binding musb and phy arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-3430sdp.c |1 - arch/arm/mach-omap2/board-4430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |1 - arch/arm/mach-omap2/board-devkit8000.c |1 - arch/arm/mach-omap2/board-igep0020.c |1 - arch/arm/mach-omap2/board-ldp.c |1 - arch/arm/mach-omap2/board-omap3beagle.c |1 - arch/arm/mach-omap2/board-omap3evm.c |1 - arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/board-omap3pandora.c |1 - arch/arm/mach-omap2/board-omap3stalker.c |1 - arch/arm/mach-omap2/board-omap3touchbook.c |1 - arch/arm/mach-omap2/board-omap4panda.c |1 - arch/arm/mach-omap2/board-overo.c|1 - arch/arm/mach-omap2/board-rm680.c|1 - arch/arm/mach-omap2/board-rx51.c |1 - arch/arm/mach-omap2/board-zoom-peripherals.c |1 - arch/arm/mach-omap2/usb-musb.c |6 +- drivers/usb/musb/musb_core.c |1 + drivers/usb/musb/musb_core.h |1 + drivers/usb/musb/omap2430.c |2 +- drivers/usb/phy/phy.c| 77 ++ include/linux/usb/musb.h |3 + include/linux/usb/phy.h | 14 + 25 files changed, 102 insertions(+), 20 deletions(-) -- 1.7.10.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
[PATCH 2/4] usb: phy: add a new API to get PHY ref by label
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So
added a new API to get the PHY reference by PHY label (PHY label
should be filled which creating the PHY).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/usb/phy/phy.c | 77 +++
include/linux/usb/phy.h | 14 +
2 files changed, 91 insertions(+)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index a9984c7..92bba2f 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -55,6 +55,21 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__usb_find_phy_by_name(struct list_head *list,
+ const char *name)
+{
+ struct usb_phy *phy = NULL;
+
+ list_for_each_entry(phy, list, head) {
+ if (strcmp(name, phy-label))
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static struct usb_phy *__of_usb_find_phy(struct device_node *node)
{
struct usb_phy *phy;
@@ -272,6 +287,68 @@ struct usb_phy *devm_usb_get_phy_dev(struct device *dev,
u8 index)
EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
/**
+ * usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @name - the name of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy. The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_by_name(const char *name)
+{
+ struct usb_phy *phy = NULL;
+ unsigned long flags;
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __usb_find_phy_by_name(phy_list, name);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ pr_err(unable to find transceiver\n);
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(usb_get_phy_by_name);
+
+/**
+ * devm_usb_get_phy_by_name - find the USB PHY using device ptr and phy label
+ * @dev - device that requests this phy
+ * @name - the label of the phy
+ *
+ * Gets the phy using usb_get_phy_by_name(), and associates a device with it
+ * using devres. On driver detach, release function is invoked on the devres
+ * data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_name(struct device *dev, const char *name)
+{
+ struct usb_phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ phy = usb_get_phy_by_name(name);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_usb_get_phy_by_name);
+
+/**
* devm_usb_put_phy - release the USB PHY
* @dev - device that wants to release this phy
* @phy - the phy returned by devm_usb_get_phy()
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..8272cba 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -188,6 +188,9 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index);
extern struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index);
+extern struct usb_phy *usb_get_phy_by_name(const char *name);
+extern struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name);
extern struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
const char *phandle, u8 index);
extern void usb_put_phy(struct usb_phy *);
@@ -216,6 +219,17 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct
device *dev, u8 index)
return ERR_PTR(-ENXIO);
}
+static inline struct usb_phy *usb_get_phy_by_name(const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
+static inline struct usb_phy *devm_usb_get_phy_by_name(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENXIO);
+}
+
static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
const char *phandle, u8 index)
{
--
1.7.10.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 1/3] ARM: dts: Add headers with constants for MTD partitions
Hello,
Thank you for the review.
On 06/12/2013 03:05 PM, Grant Likely wrote:
On Tue, 11 Jun 2013 16:48:56 +0200, Florian Vaussard florian.vauss...@epfl.ch
wrote:
These constants can be used to easily declare MTD partitions inside
DTS.
The constants MTDPART_OFS_* are purposely not included. Indeed,
parse_ofpart_partitions() is expecting u64, but a DT cell is u32.
Negative constants, as defined by MTDPART_OFS_*, would be wrongly
The DT binding uses the number of cells defined by #address-cells. It is
not fixed to a u32 or a u64
The message was ill-formatted, sorry. As an address cell is u32, and as
parse_ofpart_partitions() is storing the value inside u64 without checking
for sign extension (as one assumes to have only positive offsets),
passing a negative value would require 2 address cells, making it more
difficult
for the DT user. But as Stephen Warren noticed, it is probably desirable
to specify sizes = 4GB, thus I will think about a way to easily handle
such case.
Anyway, MTDPART_OFS_* would probably face the same objection raised by
you for
MTDPART_SIZ_FULL.
interpreted by parse_ofpart_partitions(). Two cells should be
used to correctly encode the negative constants, but this breaks
current usage.
The binding doesn't even allow for shortcuts like MTDPART_SIZ_FULL. If a
partition fills the whole device, then the reg property should include
the actual size. If the code is allowing '0' to be used to mean
MTDPART_SIZ_FULL, then that is a bug that needs to be fixed.
The root problem is that many System on Module, like the Gumstix Overo, are
shipped with various NAND sizes depending on the version or even the
manufacturing
period. Supporting such a diversity would painfully duplicates lots of DT
code and clutter the arch/arm/boot/dts/ directory with dozens of slightly-
different versions. I believe that determining the NAND size is better done
at probe time, and this is what is currently done in legacy board files:
static struct mtd_partition overo_nand_partitions[] = {
{
.name = xloader,
.offset = 0,/* Offset =
0x0 */
.size = 4 * NAND_BLOCK_SIZE,
.mask_flags = MTD_WRITEABLE
},
snip...
{
.name = rootfs,
.offset = MTDPART_OFS_APPEND, /* Offset =
0x68 */
.size = MTDPART_SIZ_FULL,
},
};
Moreover, I do not see such strict restriction in the OF norm. If I
refer to IEEE
1275-1994 page 174, for the definition of the reg property, it is written:
The interpretation of the size entries is dependent on the parent bus.
Nevertheless, if such an approach is not acceptable, could we think about an
alternative solution? Like a boolean property mtd,append-and-fill that
would
replace the reg property and tell the MTD core to compute the
partition size
at probe time, like what is currently done with board files?
Best regards,
Florian
--
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: dts: Protect pinctrl headers against multiple inclusions
Hello Benoit, On 06/12/2013 06:18 PM, Cousson, Benoit wrote: Hi Florian, On 6/12/2013 8:42 AM, Florian Vaussard wrote: Hello Grant, On 06/11/2013 11:57 PM, Grant Likely wrote: On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard florian.vauss...@epfl.ch wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Obviously this needs to go in via whatever tree added the modified header files. I authored these files, sorry for this stupid omission. Benoit, can you take this patch? Yes, sure, I'll take it with Grant's ack. I think that you missed this one. Regards, Florian -- 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/4] ARM: dts: OMAP3: Updates for Overo
Hello Benoit, Any comments on this series? Regards, Florian On 06/11/2013 04:49 PM, Florian Vaussard wrote: Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 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] ARM: dts: Protect pinctrl headers against multiple inclusions
Hi Florian, On 06/19/2013 04:28 AM, Florian Vaussard wrote: Hello Benoit, On 06/12/2013 06:18 PM, Cousson, Benoit wrote: Hi Florian, On 6/12/2013 8:42 AM, Florian Vaussard wrote: Hello Grant, On 06/11/2013 11:57 PM, Grant Likely wrote: On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard florian.vauss...@epfl.ch wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Obviously this needs to go in via whatever tree added the modified header files. I authored these files, sorry for this stupid omission. Benoit, can you take this patch? Yes, sure, I'll take it with Grant's ack. I think that you missed this one. In was in the pipe but not pushed yet. That will be done soon. Thanks, 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 0/4] ARM: dts: OMAP3: Updates for Overo
On 06/19/2013 04:29 AM, Florian Vaussard wrote: Hello Benoit, Any comments on this series? That series looks good to me. I've just applied it. Thanks, Benoit Regards, Florian On 06/11/2013 04:49 PM, Florian Vaussard wrote: Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 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 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Tony Lindgren t...@atomide.com writes: Hi, * Tony Lindgren t...@atomide.com [130617 03:32]: * Arnaud Patard arnaud.pat...@rtp-net.org [130617 02:52]: Tony Lindgren t...@atomide.com writes: I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Right, like I said: the idea is to have it usable with DT. And USB and Ethernet certainly are part of what I call usable. So is MMC, WLAN and DSS. I've certainly spent quite a bit of time on making sure panda works with DT, and I can assure you that fixing the USB extclock is easier than supporting the legacy boot with DT :) This issue can also be fixed with a clock alias if we don't have DT defined clocks ready for v3.11. It may take a few days for us to have the solution. But get getting a clock to a driver certainly is not a showstopper here. After all, that's what all drivers already do. Care to test the last patch just posted by Roger in thread [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix? I tried to test them but they don't apply on linux-next due to some pinctrl changes probably missing: Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error which corresponds to : 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) doesn't apply as the omap5-uevm.dts doesn't exist. Which tree should I use to test the patches if it's not linux-next ? Also, you might want to know that drivers/usb/musb/omap2430.c doesn't build due to some typos (musb_resources vs musb_resouces). Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Wed, 19 Jun 2013, Samuel Ortiz wrote: Hi Lee, On Wed, Jun 19, 2013 at 09:26:33AM +0100, Lee Jones wrote: On Mon, 17 Jun 2013, J Keerthy wrote: Remove code which is not necessary for a device tree boot. So we're exclusively DT now right? Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) If that's the case, applied with all Acks, thanks. It's already in mfd-next. I noticed. Odd that I didn't receive you applied message. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/3] Add pinmux DT nodes to CPSW for AM335x
On 06/19/2013 12:53 AM, Mugunthan V N wrote: On 6/7/2013 5:02 PM, Mugunthan V N wrote: Add pinmux DT nodes to CPSW for the following AM335x boards * AM335x Beaglebone * AM335x EVM * AM335x EVMsk default state contains the pinmux required for active mode and sleep mode contains pinmux reset values for energy saving. Mugunthan V N (3): ARM: dts: AM33XX: Add pinmux configuration for CPSW to beaglebone ARM: dts: AM33XX: Add pinmux configuration for CPSW to EVMsk ARM: dts: AM33XX: Add pinmux configuration for CPSW to am335x EVM arch/arm/boot/dts/am335x-bone.dts | 67 ++ arch/arm/boot/dts/am335x-evm.dts | 64 + arch/arm/boot/dts/am335x-evmsk.dts | 92 3 files changed, 223 insertions(+) Benoit Do you have any comments on this patch series, if not can you queue it for v3.11 The series looks good to me. I've just applied it. Thanks, 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/6] ARM: OMAP2+: Remove board-omap4panda.c
* Arnaud Patard arnaud.pat...@rtp-net.org [130619 02:52]: Tony Lindgren t...@atomide.com writes: Hi, * Tony Lindgren t...@atomide.com [130617 03:32]: * Arnaud Patard arnaud.pat...@rtp-net.org [130617 02:52]: Tony Lindgren t...@atomide.com writes: I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Right, like I said: the idea is to have it usable with DT. And USB and Ethernet certainly are part of what I call usable. So is MMC, WLAN and DSS. I've certainly spent quite a bit of time on making sure panda works with DT, and I can assure you that fixing the USB extclock is easier than supporting the legacy boot with DT :) This issue can also be fixed with a clock alias if we don't have DT defined clocks ready for v3.11. It may take a few days for us to have the solution. But get getting a clock to a driver certainly is not a showstopper here. After all, that's what all drivers already do. Care to test the last patch just posted by Roger in thread [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix? I tried to test them but they don't apply on linux-next due to some pinctrl changes probably missing: Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error which corresponds to : 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Oops, right, that's in Benoit's branch too for the .dts preprocessing. Until it is merged, maybe try with Roger's earlier version of that patch that did not yet use the macros? Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) doesn't apply as the omap5-uevm.dts doesn't exist. OK that's in Benoit's branch. But you won't need that one. Which tree should I use to test the patches if it's not linux-next ? Also, you might want to know that drivers/usb/musb/omap2430.c doesn't build due to some typos (musb_resources vs musb_resouces). Thanks, I think Felipe is already aware of that. 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 v5] i2c: omap: correct usage of the interrupt enable register
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote: We've been lucky not to have any interrupts fire during the suspend path, otherwise we would have unpredictable behaviour in the kernel. Based on the logic of the kernel code interrupts from i2c should be prohibited during suspend. Kernel writes 0 to the I2C_IE register in the omap_i2c_runtime_suspend() function. In the other side kernel writes saved interrupt flags to the I2C_IE register in omap_i2c_runtime_resume() function. I.e. interrupts should be disabled during suspend. This works for chips with version1 registers scheme. Interrupts are disabled during suspend. For chips with version2 scheme registers writting 0 to the I2C_IE register does nothing (because now the I2C_IRQENABLE_SET register is located at this address). This register is used to enable interrupts. For disabling interrupts I2C_IRQENABLE_CLR register should be used. Because the registers I2C_IRQENABLE_SET and I2C_IE have the same addresses, the interrupt enabling procedure is unchanged. I've checked that interrupts in the i2c controller are still enabled after writting 0 to the I2C_IRQENABLE_SET register. With this patch interrupts are disabled in the omap_i2c_runtime_suspend() function. Patch is based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git tag: v3.10-rc2 Last paragraph should be below ---. Verified on OMAP4430. Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com Applied to for-next, thanks! signature.asc Description: Digital signature
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to
abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my
point of view. pinctrl can handle pin configuration and this is what the
pbias is in the case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep
doing that :-)
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using
the regulator in the future for controlling a gpio line.
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: [RFC] i2c: add deprecation warning for class based instantiation
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote: Class based instantiation can cause huge delays when booting. This mechanism was used when it was not possible to describe slaves on I2C busses. We now have other mechanisms, so most embedded I2C will not need classes and it was explicitly not recommended to use them. Add a deprecation warning for drivers who want to disable class based in the near future to gain boot-up time, so users relying on this technique can switch to something better. They really should. Signed-off-by: Wolfram Sang w...@the-dreams.de No reactions on this, pity. Deferring. signature.asc Description: Digital signature
Re: [PATCH 1/1] arm: add bandgap DT entry for OMAP5
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 8
1 file changed, 8 insertions(+)
---
Benoit,
Sorry for this very late request, but can you please consider
these patches for 3.11 still?
I completely forgot to send these on my Enable TI SoC thermal driver series.
All best,
Eduardo
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2ad63c4..5ede6e1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -615,5 +615,13 @@
interrupts = 0 80 0x4;
ti,hwmods = wd_timer2;
};
missing blank line
+ bandgap {
You must use the first address in that case. Otherwise DT will affect a random
number and provide a non-standard device name. That does not really matter in
theory, but it will looks ugly in the /sys/devices list.
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ interrupts = 0 126 4; /* talert */
Not well aligned and should use the macros.
+ compatible = ti,omap5430-bandgap;
+ };
};
};
I did the update for you :-)
Here is the version I've just applied.
Benoit
From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin eduardo.valen...@ti.com
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
};
};
+
+ bandgap@4a0021e0 {
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c;
+ interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+ compatible = ti,omap5430-bandgap;
+ };
};
};
--
1.7.9.5
--
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: dts: AM43x EPOS EVM support
Hi Afzal,
On 06/14/2013 09:03 AM, Afzal Mohammed wrote:
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get
it booting. Also include it in omap2plus dtbs and document bindings.
The hardware is under development.
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Benoit,
This is based on your for_3.11/dts branch.
Ideally I wanted to split this into 3 patches - first doc, second dts
and last adding build support. As changes in total is trivial, it was
made a single one.
That's fine for me. I've just applied it.
Thanks,
Benoit
Regards
Afzal
Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43x-epos-evm.dts| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
- OMAP5 EVM : Evaluation Module
compatible = ti,omap5-evm, ti,omap5
+
+- AM43x EPOS EVM
+ compatible = ti,am43x-epos-evm, ti,am4372, ti,am43
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..05da469 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -155,7 +155,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
- am3517_mt_ventoux.dtb
+ am3517_mt_ventoux.dtb \
+ am43x-epos-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
new file mode 100644
index 000..74174d4
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM43x EPOS EVM */
+
+/dts-v1/;
+
+#include am4372.dtsi
+
+/ {
+ model = TI AM43x EPOS EVM;
+ compatible = ti,am43x-epos-evm,ti,am4372,ti,am43;
+};
--
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/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
Hi Enric,
On 06/19/2013 03:27 AM, Enric Balletbo i Serra wrote:
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 269 +
1 file changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..1d70141
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
That node should be inside the ocp one since the control module is a
regular IP connected to the OCP interconnect.
+ pinctrl-names = default;
+
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
+ ;
+ };
+
+ nandflash_pins: pinmux_nandflash_pins {
+ pinctrl-single,pins =
+ 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wpn.gpio0_30 */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ ;
+ };
+
+ uart0_pins: pinmux_uart0_pins {
+ pinctrl-single,pins =
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
+ ;
+ };
+
+ user_leds: pinmux_user_leds_pins {
+ pinctrl-single,pins =
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ ;
+ };
+
+ };
+
+ ocp {
+ uart0: serial@44e09000 {
+ pinctrl-names = default;
+ pinctrl-0 = uart0_pins;
+ status = okay;
+ };
+
+ i2c0: i2c@44e0b000 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pins;
+
+ status = okay;
+ clock-frequency = 40;
+
+ tps: tps@2d {
+ reg = 0x2d;
+ };
+ };
+
+ elm: elm@4808 {
+ status = okay;
+ };
+
+ gpmc: gpmc@5000 {
+
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line
but also
the polarity. I know mostly reset is active low but still there is
flexibility as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my point
of view. pinctrl can handle pin configuration and this is what the pbias is
in the case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is
into 3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep doing
that :-)
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
regulator in the future for controlling a gpio line.
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
cheers,
-roger
--
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 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 06:03 AM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
Well, at that time, it was not available either. The point is still that
using a existing fmwk that has nothing to do with the signal you need to
handle just because it works is not a very good justification.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO line but
also
the polarity. I know mostly reset is active low but still there is flexibility
as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver to
parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
Maybe, but it is not the right thing to do.
Can you explain me the commonality between a reset line and a regulator???
I think it's really a mux + a comparator. But from Linux driver point of view
a regulator fits well as we don't have anything better. After all, the pin
voltage changes, and then something can be done based on the comparator
value.
Do you have any better ideas?
We have a similar issue with the MMC1 PBIAS. I think in the long run we
should expand regulator (and possibly pinctrl) framework(s) to handle
comparators. We could just assume that a comparatator is a regulator,
and have a comparator binding that just uses the regulator code.
In the case of pbias, the pinctrl seems to be a much better fit for my point of
view. pinctrl can handle pin configuration and this is what the pbias is in the
case of MMC pins.
FYI. The USB PHY driver is already treating reset as a regulator and is into
3.10. Reworking that
will take some time. Not getting these in will prevent USB host/ethernet
support on panda.
That's not because we did some mistake in the past that we have to keep doing
that :-)
I had actually thought it well and don't consider it as a mistake. It is just a
difference in opinion.
Well, I don't think so. Again, you are abusing the regulator fmwk to
enable at boot time a GPIO line that should reset the IP. I doubt the
regulator fmwk was done for that. Otherwise Mark would have named it
miscellaneous fmwk or regulator reset fmwk.
Yes and we need to have some solution for v3.11 as we've dropped the
legacy data for omap4. Otherwise things won't work properly.
I'm fine taking it as soon as big disclaimer is added to avoid mis-using the
regulator in the future for controlling a gpio line.
I can re-work the phy driver. No problem. But I'm still not convinced
what it will improve. IMHO it just adds more code in the phy driver without any
benefits.
Yes, it will. It will give explicitly the reset control to the driver
that knows and needs it. Moreover, it will avoid abusing a fmwk that was
not done for that purpose.
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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to abuse
the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since there
is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
Regards,
Florian
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/36830
--
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/1] arm: add bandgap DT entry for OMAP5
On 19-06-2013 06:36, Benoit Cousson wrote:
Hi Eduardo,
On 06/18/2013 09:36 PM, Eduardo Valentin wrote:
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 8
1 file changed, 8 insertions(+)
---
Benoit,
Sorry for this very late request, but can you please consider
these patches for 3.11 still?
I completely forgot to send these on my Enable TI SoC thermal driver
series.
All best,
Eduardo
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2ad63c4..5ede6e1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -615,5 +615,13 @@
interrupts = 0 80 0x4;
ti,hwmods = wd_timer2;
};
missing blank line
+bandgap {
You must use the first address in that case. Otherwise DT will affect a
random number and provide a non-standard device name. That does not really
matter in theory, but it will looks ugly in the /sys/devices list.
+reg = 0x4a0021e0 0xc
+0x4a00232c 0xc
+0x4a002380 0x2c
+0x4a0023C0 0x3c;
+interrupts = 0 126 4; /* talert */
Not well aligned and should use the macros.
+compatible = ti,omap5430-bandgap;
+};
};
};
I did the update for you :-)
Here is the version I've just applied.
Benoit
From f0160bb93467e22f2f8bc77591dcd7e35cdee999 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin eduardo.valen...@ti.com
Date: Tue, 18 Jun 2013 22:36:38 -0400
Subject: [PATCH] ARM: dts: Add bandgap DT entry for OMAP5
Add bandgap device DT entry for OMAP5 dtsi.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Benoit Cousson benoit.cous...@linaro.org
---
arch/arm/boot/dts/omap5.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index accab62..47693c9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -696,5 +696,14 @@
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
};
};
+
+ bandgap@4a0021e0 {
+ reg = 0x4a0021e0 0xc
+0x4a00232c 0xc
+0x4a002380 0x2c
+0x4a0023C0 0x3c;
+ interrupts = GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH;
+ compatible = ti,omap5430-bandgap;
+ };
};
};
Looks good to me.
Tks Benoit!
--
You have got to be excited about what you are doing. (L. Lamport)
Eduardo Valentin
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator
was not the right fmwk to do that :-)
Thanks for the pointer Florian.
I guess that series should be merged for 3.11? Based on the thread, it
should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding
that a new solution will be available soon as a disclaimer.
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
[PATCH] MFD: Change TWL6025 references to TWL6032
From: Graeme Gregory g...@slimlogic.co.uk
The TWL6025 was never released beyond sample form and was replaced by
the PhoenixLite range of chips - TWL6032. Change the references to
reference the TWL6032 class and name the registers to twl6032 in line with
an actual released chip name to avoid confusion.
Currently there are no users of TWL6025 in the code.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
There are non-mainline branches that use twl6032 by its name (for example
git://git.omapzoom.org/kernel/omap.git). There is intention to add support
of twl6032 device in mainline, but we'd like to know if we can use twl6032
instead of twl6025 in our new patches, that we are going to provide.
Related discussion: https://patchwork.kernel.org/patch/2686331/
.../bindings/regulator/twl-regulator.txt | 26 +++
.../devicetree/bindings/usb/twl-usb.txt|2 +-
drivers/mfd/twl-core.c | 46 ++--
drivers/regulator/twl-regulator.c | 76 ++--
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/i2c/twl.h| 30
6 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index 658749b..75b0c16 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
- ti,twl6030-vdd1 for VDD1 SMPS
- ti,twl6030-vdd2 for VDD2 SMPS
- ti,twl6030-vdd3 for VDD3 SMPS
-For twl6025 regulators/LDOs
+For twl6032 regulators/LDOs
- compatible:
- - ti,twl6025-ldo1 for LDO1 LDO
- - ti,twl6025-ldo2 for LDO2 LDO
- - ti,twl6025-ldo3 for LDO3 LDO
- - ti,twl6025-ldo4 for LDO4 LDO
- - ti,twl6025-ldo5 for LDO5 LDO
- - ti,twl6025-ldo6 for LDO6 LDO
- - ti,twl6025-ldo7 for LDO7 LDO
- - ti,twl6025-ldoln for LDOLN LDO
- - ti,twl6025-ldousb for LDOUSB LDO
- - ti,twl6025-smps3 for SMPS3 SMPS
- - ti,twl6025-smps4 for SMPS4 SMPS
- - ti,twl6025-vio for VIO SMPS
+ - ti,twl6032-ldo1 for LDO1 LDO
+ - ti,twl6032-ldo2 for LDO2 LDO
+ - ti,twl6032-ldo3 for LDO3 LDO
+ - ti,twl6032-ldo4 for LDO4 LDO
+ - ti,twl6032-ldo5 for LDO5 LDO
+ - ti,twl6032-ldo6 for LDO6 LDO
+ - ti,twl6032-ldo7 for LDO7 LDO
+ - ti,twl6032-ldoln for LDOLN LDO
+ - ti,twl6032-ldousb for LDOUSB LDO
+ - ti,twl6032-smps3 for SMPS3 SMPS
+ - ti,twl6032-smps4 for SMPS4 SMPS
+ - ti,twl6032-vio for VIO SMPS
For twl4030 regulators/LDOs
- compatible:
- ti,twl4030-vaux1 for VAUX1 LDO
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 36b9aed..0aee0ad 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
- if it is twl6030 or ldousb if it is twl6025 subclass.
+ if it is twl6030 or ldousb if it is twl6032 subclass.
twl6030-usb {
compatible = ti,twl6030-usb;
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 89ab4d9..f39bceb 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -118,7 +118,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
-#define TWL6025_BASEADD_CHARGER0x00DA
+#define TWL6032_BASEADD_CHARGER0x00DA
#define TWL6030_BASEADD_LED0x00F4
/* subchip/slave 2 0x4A - DFT */
@@ -718,9 +718,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
| REGULATOR_CHANGE_STATUS,
};
- if (features TWL6025_SUBCLASS) {
+ if (features TWL6032_SUBCLASS) {
usb3v3.supply = ldousb;
- regulator = TWL6025_REG_LDOUSB;
+ regulator = TWL6032_REG_LDOUSB;
} else {
usb3v3.supply = vusb;
regulator = TWL6030_REG_VUSB;
@@ -747,8 +747,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
usb3v3.dev_name = dev_name(child);
} else if (IS_ENABLED(CONFIG_REGULATOR_TWL4030)
twl_class_is_6030()) {
- if (features TWL6025_SUBCLASS)
- child = add_regulator(TWL6025_REG_LDOUSB,
+ if (features
Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. 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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 05:30]:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
If it's a reset, then yeah it's not a regulator. If the GPIO line is
really used to control the regulator in the external device, then it
makes sense to set it up as a regulator.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the
regulator was not the right fmwk to do that :-)
Thanks for the pointer Florian.
Good to hear about the gpio-controlled reset lines :)
I guess that series should be merged for 3.11? Based on the thread,
it should to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one,
adding that a new solution will be available soon as a disclaimer.
We need some solution for v3.11 for omap4 USB on panda so people can
use it with DT.
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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( 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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
* Benoit Cousson b-cous...@ti.com [130619 05:41]: Hi Tony, On 06/19/2013 07:27 AM, Tony Lindgren wrote: * Benoit Cousson b-cous...@ti.com [130619 03:17]: On 06/19/2013 02:46 AM, Tony Lindgren wrote: We have a similar issue with the MMC1 PBIAS. I think in the long run we should expand regulator (and possibly pinctrl) framework(s) to handle comparators. We could just assume that a comparatator is a regulator, and have a comparator binding that just uses the regulator code. In the case of pbias, the pinctrl seems to be a much better fit for my point of view. pinctrl can handle pin configuration and this is what the pbias is in the case of MMC pins. Well just recently Linus W specifically wanted us to use regulator framework for the MMC1 PBIAS rather than pinctrl. That's because from consumer driver point of view, it changes voltage and there's a delay involved. So I guess no conclusion yet, and it's best to do stand alone drivers to deal with those that use pinctrl for the pinctrl specific parts and export it as a regulator for the consumer devices. In the case of pbias, the boundary is not that clear, and it is true that writing a complete pinctrl driver is really overkill. I've tried in the past, and gave up due to the complexity of fmwk and the lack of time. I still think, it is a much better fmwk to handle pin configuration than the regulator fmwk. For omaps, these kind of registers can already be handled by pinctrl-single,bits. What's missing is the capability to create a regulator out of the voltage mux + comparator bits. That's pretty much along the lines what Roger has done, except the transceiver could use the pinctrl-single,bits for the muxing and pinconf. Well, in that case, this is a reset line, so it does not have anything to do with voltage :-) Anyway, thanks to Florian, we know that there is a real solution to that problem. It is just not merged now :-( Right. Meanwhile, sounds like the transceiver driver needs to deal with the GPIO directly. 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
[PATCHv2 01/11] CLK: clkdev: add support for looking up clocks from DT
clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clkdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
EXPORT_SYMBOL(of_clk_get_by_name);
#endif
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+ list_add_tail(cl-node, clocks);
+}
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
{
struct clk_lookup *p, *cl = NULL;
int match, best_found = 0, best_possible = 0;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
if (dev_id)
best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
break;
}
}
+
+ if (cl)
+ return cl;
+
+ /* If clock was not found, attempt to look-up from DT */
+ node = of_find_node_by_name(NULL, con_id);
+
+ clkspec.np = node;
+
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!IS_ERR(clk)) {
+ /* We found a clock, add node to clkdev */
+ cl = clkdev_alloc(clk, con_id, dev_id);
+ clkdev_add_nolock(cl);
+ }
+
return cl;
}
--
1.7.9.5
--
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
[PATCHv2 02/11] CLK: use of_property_read_u32 instead of read_u8
of_property_read_u8 does not work properly because of endianess problem
with its current implementation, and this causes it to always return
0 with little endian architectures. Instead, use property_read_u32
until this is fixed.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |4 ++--
drivers/clk/clk-gate.c|4 ++--
drivers/clk/clk-mux.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 17ea475..3413602 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -361,7 +361,7 @@ void of_divider_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_divider_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
struct clk_div_table *table;
of_property_read_string(node, clock-output-names, clk_name);
@@ -375,7 +375,7 @@ void of_divider_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 72cf99d..61b4dc1 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -162,7 +162,7 @@ void of_gate_clk_setup(struct device_node *node)
void __iomem *reg;
const char *parent_name;
u8 clk_gate_flags = 0;
- u8 bit_idx = 0;
+ u32 bit_idx = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -170,7 +170,7 @@ void of_gate_clk_setup(struct device_node *node)
reg = of_iomap(node, 0);
- if (of_property_read_u8(node, bit-shift, bit_idx)) {
+ if (of_property_read_u32(node, bit-shift, bit_idx)) {
pr_err(%s: missing bit-shift property for %s\n,
__func__, node-name);
return;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c9f9f32..e63dd1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -170,7 +170,7 @@ void of_mux_clk_setup(struct device_node *node)
int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -194,7 +194,7 @@ void of_mux_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
--
1.7.9.5
--
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
[PATCHv2 00/11] ARM: OMAP4 clock data conversion to DT
Hi, This set converts the OMAP4 clock data to device tree format. This set also fixes a couple of problems detected in the basic clock devicetree code (patches 2 3), and adds some generic support functions for the transition phase when all the drivers are not fully devicetree compliant (see patches 1 7.) OMAP4 clock data was converted from cclock44xx_data.c file with a custom perl script, which can probably be applied for other SoCs with some modifications also. Version one for this work was done by Mike Turquette: http://comments.gmane.org/gmane.linux.ports.arm.omap/98741 This set needs the basic devicetree support code from Mike: http://comments.gmane.org/gmane.linux.kernel/1509300 Testing done with omap4-panda board, booted up to console and tested that suspend / resume works with 3.10-rc6. I have also provided a working branch here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.10-rc6-omap4-dt-clks-v2 This branch contains the pre-req set from Mike, and a couple of additional hacks you can ignore. Any comments / testing feedback welcome. -Tero -- 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
[PATCHv2 06/11] CLK: omap: move part of the machine specific clock header contents to driver
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.h | 150 +
include/linux/clk/omap.h| 155 ++-
2 files changed, 155 insertions(+), 150 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..3238c57 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
#include linux/clkdev.h
#include linux/clk-provider.h
+#include linux/clk/omap.h
struct omap_clk {
u16 cpu;
@@ -178,83 +179,6 @@ struct clksel {
const struct clksel_rate *rates;
};
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- * omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- * omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
- void __iomem*mult_div1_reg;
- u32 mult_mask;
- u32 div1_mask;
- struct clk *clk_bypass;
- struct clk *clk_ref;
- void __iomem*control_reg;
- u32 enable_mask;
- unsigned long last_rounded_rate;
- u16 last_rounded_m;
- u8 last_rounded_m4xen;
- u8 last_rounded_lpmode;
- u16 max_multiplier;
- u8 last_rounded_n;
- u8 min_divider;
- u16 max_divider;
- u8 modes;
- void __iomem*autoidle_reg;
- void __iomem*idlest_reg;
- u32 autoidle_mask;
- u32 freqsel_mask;
- u32 idlest_mask;
- u32 dco_mask;
- u32 sddiv_mask;
- u32 lpmode_mask;
- u32 m4xen_mask;
- u8 auto_recal_bit;
- u8 recal_en_bit;
- u8 recal_st_bit;
- u8 flags;
-};
-
/*
* struct clk.flags possibilities
*
@@ -274,56 +198,6 @@ struct dpll_data {
#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 5)
[PATCHv2 09/11] CLK: omap: add support for OMAP gate clock
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/gate.c | 88 +
include/linux/clk/omap.h |1 +
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/gate.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o autoidle.o
+obj-y += clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 181795f..20643a2 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -30,6 +30,7 @@ static const struct of_device_id clk_match[] = {
{.compatible = divider-clock, .data = of_omap_divider_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
{.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
+ {.compatible = ti,gate-clock, .data = of_omap_gate_clk_setup, },
{},
};
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap2_clkops_enable_clkdm,
+ .disable= omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.ops = omap_gate_clk_ops;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap trace_clk %s must have parent(s)\n,
+ __func__, node-name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ init.num_parents = num_parents;
+ init.parent_names = parent_names;
+
+ clk = clk_register(NULL, clk_hw-hw);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ return;
+ }
+
+cleanup:
+ kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, ti,omap-gate-clock, of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 003e374..17757d3 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -175,6 +175,7 @@ int dt_omap_clk_init(void);
void of_omap4_dpll_setup(struct device_node *node);
void of_omap_fixed_factor_setup(struct device_node *node);
void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *node);
void of_omap_clk_allow_autoidle_all(void);
void of_omap_clk_deny_autoidle_all(void);
--
1.7.9.5
--
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
[PATCHv2 07/11] ARM: OMAP: clock: add DT duplicate clock registration mechanism
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c | 39 +++
arch/arm/mach-omap2/clock.h | 16
2 files changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..6fe14b5 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -584,6 +584,45 @@ void __init omap_clocks_register(struct omap_clk oclks[],
int cnt)
}
/**
+ * omap_dt_clocks_register - register DT duplicate clocks during boot
+ * @oclks: list of clocks to register
+ * @cnt: number of clocks
+ *
+ * Register duplicate or non-standard DT clock entries during boot. By
+ * default, DT clocks are found based on their node name. If any
+ * additional con-id / dev-id - clock mapping is required, use this
+ * function to list these.
+ */
+void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
+{
+ struct omap_dt_clk *c;
+ struct device_node *n;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
+
+ for (c = oclks; c oclks + cnt; c++) {
+ n = of_find_node_by_name(NULL, c-node_name);
+
+ if (!n) {
+ pr_err(%s: %s not found!\n, __func__, c-node_name);
+ continue;
+ }
+
+ clkspec.np = n;
+
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!clk) {
+ pr_err(%s: %s has no clock!\n, __func__,
+ c-node_name);
+ continue;
+ }
+ c-lk.clk = clk;
+ clkdev_add(c-lk);
+ }
+}
+
+/**
* omap2_clk_switch_mpurate_at_boot - switch ARM MPU rate by boot-time argument
* @mpurate_ck_name: clk name of the clock to change rate
*
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 3238c57..1c1fbe4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -37,6 +37,21 @@ struct omap_clk {
}, \
}
+struct omap_dt_clk {
+ u16 cpu;
+ struct clk_lookup lk;
+ const char *node_name;
+};
+
+#define DT_CLK(dev, con, name) \
+ { \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ }, \
+ .node_name = name, \
+ }
+
struct clockdomain;
#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
@@ -316,4 +331,5 @@ extern const struct clksel_rate div31_1to31_rates[];
extern int am33xx_clk_init(void);
extern void omap_clocks_register(struct omap_clk *oclks, int cnt);
+extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
#endif
--
1.7.9.5
--
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
[PATCHv2 10/11] ARM: dts: omap4 clock data
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM).
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap4-clocks.dtsi | 1704 +++
arch/arm/boot/dts/omap4.dtsi|2 +
2 files changed, 1706 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
@@ -0,0 +1,1704 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* Root clocks */
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 5900;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ compatible = gate-clock;
+ reg = 0x4a004108 0x4;
+ bit-shift = 8;
+ clocks = pad_clks_src_ck;
+ #clock-cells = 0;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+ compatible = gate-clock;
+ reg = 0x4a004108 0x4;
+ bit-shift = 10;
+ clocks = slimbus_src_clk;
+ #clock-cells = 0;
+};
+
+sys_32k_ck: sys_32k_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1300;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1680;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2700;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3840;
+};
+
+sys_clkin_ck: sys_clkin_ck@4a306110 {
+ compatible = mux-clock;
+ clocks = virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
virt_3840_ck;
+ #clock-cells = 0;
+ reg = 0x4a306110 0x4;
+ bit-mask = 0x7;
+ index-starts-at-one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+/* Module clocks and DPLL outputs */
+abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
+ compatible = mux-clock;
+ clocks = sys_clkin_ck, sys_32k_ck;
+ #clock-cells = 0;
+ reg = 0x4a306108 0x4;
+ bit-mask = 0x1;
+ bit-shift = 24;
+};
+
+abe_dpll_refclk_mux_ck: abe_dpll_refclk_mux_ck@4a30610c {
+ compatible = mux-clock;
+ clocks = sys_clkin_ck, sys_32k_ck;
+ #clock-cells = 0;
+ reg = 0x4a30610c 0x4;
+ bit-mask = 0x1;
+};
+
+/* DPLL_ABE */
+dpll_abe_ck: dpll_abe_ck {
+ clocks = abe_dpll_refclk_mux_ck;
+ #clock-cells = 0;
+ reg = 0x4a0041e0 0x4, 0x4a0041e4 0x4, 0x4a0041e8 0x4, 0x4a0041ec
0x4;
+ ti,clk-bypass = abe_dpll_bypass_clk_mux_ck;
+ ti,clk-ref = abe_dpll_refclk_mux_ck;
+ compatible = ti,omap4-dpll-clock;
+ ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck:
[PATCHv2 04/11] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c| 44
include/linux/clk/omap.h | 24
4 files changed, 70 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..b4533ed
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,44 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = fixed-clock, .data = of_fixed_clk_setup, },
+ {.compatible = mux-clock, .data = of_mux_clk_setup, },
+ {.compatible = fixed-factor-clock,
+ .data = of_fixed_factor_clk_setup, },
+ {.compatible = divider-clock, .data = of_divider_clk_setup, },
+ {.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {},
+};
+
+/* FIXME - need to initialize early; skip real driver registration probe */
+int __init dt_omap_clk_init(void)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
+
+MODULE_DESCRIPTION(OMAP Clock driver);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..504e838
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2010 Broadcom
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.7.9.5
--
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
[PATCHv2 08/11] CLK: omap: add autoidle support
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c |6 ++
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/autoidle.c | 130 +++
drivers/clk/omap/clk.c |4 +-
include/linux/clk/omap.h|4 ++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/omap/autoidle.c
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6fe14b5..9bd66b4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-allow_idle)
c-ops-allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-deny_idle)
c-ops-deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
return 0;
}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o
+obj-y += clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+ void __iomem*reg;
+ u8 shift;
+ u8 flags;
+ const char *name;
+ struct list_headnode;
+};
+
+#define AUTOIDLE_LOW 0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val = ~(1 clk-shift);
+ else
+ val |= (1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val |= (1 clk-shift);
+ else
+ val = ~(1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+ u32 shift;
+ void __iomem *reg;
+ struct clk_omap_autoidle *clk;
+
+ if (of_property_read_u32(node, ti,autoidle-shift, shift))
+ return;
+
+ reg = of_iomap(node, 0);
+
+ clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+ if (!clk) {
+ pr_err(%s: kzalloc failed\n, __func__);
+ return;
+ }
+
+ clk-shift = shift;
+ clk-name = node-name;
+ clk-reg = reg;
+
+ if (of_property_read_bool(node, ti,autoidle-low))
+ clk-flags |= AUTOIDLE_LOW;
+
+ list_add(clk-node, autoidle_clks);
+}
+
+void __init of_omap_divider_setup(struct device_node *node)
+{
+ of_divider_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_divider_setup);
+CLK_OF_DECLARE(omap_autoidle_clock, divider-clock, of_omap_divider_setup);
+
+void __init of_omap_fixed_factor_setup(struct device_node *node)
+{
+ of_fixed_factor_clk_setup(node);
+
[PATCHv2 05/11] CLK: OMAP4: Add DPLL clock support
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/dpll.c | 307 +
3 files changed, 309 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/dpll.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o
+obj-y += clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index b4533ed..c2a3f8f 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
.data = of_fixed_factor_clk_setup, },
{.compatible = divider-clock, .data = of_divider_clk_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
{},
};
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 000..183ec60
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,307 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+#define div_mask(d)((1 ((d)-width)) - 1)
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap4_dpll_regm4xen_recalc,
+ .round_rate = omap4_dpll_regm4xen_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap3_dpll_recalc,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+ .init = omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+ .recalc_rate= omap3_clkoutx2_recalc,
+};
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+ /* allocate the divider */
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ clk_hw-dpll_data = dpll_data;
+ clk_hw-ops = clkhwops_omap3_dpll;
+ clk_hw-clkdm_name = clkdm_name;
+ clk_hw-hw.init = init;
+
+ init.name = name;
+ init.ops = ops;
+ init.flags = flags;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+
+ /* register the clock */
+ clk = clk_register(dev, clk_hw-hw);
+
+ if (IS_ERR(clk))
+ kfree(clk_hw);
+ else
+ omap2_init_clk_hw_omap_clocks(clk);
+
+ return clk;
+}
+
+struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
+ const char *parent_name, void __iomem *reg,
+ const
[PATCHv2 03/11] CLK: divider: fix table parsing logic for DT
The existing implementation had a couple of bugs:
1) table_size was attempted to read improperly, it has to be calculated
from the 'len' parameter of a property
2) Reading the integer entries from the table was reading only first
two entries of the DT data
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3413602..2fa7932 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -325,15 +325,18 @@ struct clk *clk_register_divider_table(struct device
*dev, const char *name,
struct clk_div_table *of_clk_get_div_table(struct device_node *node)
{
int i;
- int table_size = 0;
+ u32 table_size;
struct clk_div_table *table;
- u32 pair[2];
+ const __be32 *tablespec;
+ u32 val;
- table_size = of_count_phandle_with_args(node, table, #clock-cells);
+ tablespec = of_get_property(node, table, table_size);
- if (table_size 1)
+ if (!tablespec)
return NULL;
+ table_size /= sizeof(struct clk_div_table);
+
table = kzalloc(sizeof(struct clk_div_table) * table_size, GFP_KERNEL);
if (!table) {
pr_err(%s: unable to allocate memory for %s table\n,
__func__, node-name);
@@ -341,10 +344,10 @@ struct clk_div_table *of_clk_get_div_table(struct
device_node *node)
}
for (i = 0; i table_size; i++) {
- if (!of_property_read_u32_array(node, table, pair,
ARRAY_SIZE(pair))) {
- table[i].val = pair[0];
- table[i].div = pair[1];
- }
+ of_property_read_u32_index(node, table, i * 2, val);
+ table[i].div = val;
+ of_property_read_u32_index(node, table, i * 2 + 1, val);
+ table[i].val = val;
}
return table;
--
1.7.9.5
--
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: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:19-20130619, Tero Kristo wrote:
snip
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
[...]
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck@4a004134 {
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a004134 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
[..]
+
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck@4a008154 {
+ compatible = divider-clock;
+ clocks = dpll_per_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a008154 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
[...]
+
+/*
+ * clocks specific to omap4460
+ */
+/*
+ * clocks specific to omap4430
+ */
+/*
+ * clocks common to omap44xx
+ */
could be dropped?
btw, are we differentiating 4430 and 4460?A
Example:
bandgap_fclk in 4430
Vs
div_ts_ck, bandgap_ts_fclk in 4460?
--
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 1/2] ARM: dts: AM33XX: Add support for IGEP COM AQUILA
Hi,
On Wed, Jun 19, 2013 at 12:46 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Enric,
On 06/19/2013 03:27 AM, Enric Balletbo i Serra wrote:
The IGEP COM AQUILA is industrial processors SODIMM module with
following highlights:
o AM3352/AM3354/AM3358/AM3359 Texas Instruments processor
o Cortex-A8 ARM CPU
o 3.3 volts Inputs / Outputs use industrial
o 256 MB DDR3 SDRAM / 128 Megabytes FLASH
o MicroSD card reader on-board
o Ethernet controller on-board
o JTAG debug connector available
o Designed for industrial range purposes
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/boot/dts/am335x-igep0033.dtsi | 269
+
1 file changed, 269 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi
b/arch/arm/boot/dts/am335x-igep0033.dtsi
new file mode 100644
index 000..1d70141
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2013 ISEE 2007 SL - http://www.isee.biz/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include am33xx.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = vdd1_reg;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ am33xx_pinmux: pinmux@44e10800 {
That node should be inside the ocp one since the control module is a regular
IP connected to the OCP interconnect.
In fact, I don't think that there should be a definition of the On
Chip Peripherals interconnect or any child node of the ocp in a DTS
file.
These should be defined in the included dtsi file since it will be
common to all boards based on this SoC.
DTS files that describe a board can reference these nodes defined in
the dtsi and add their custom peripherals as childs of them.
So, instead defining in the DTS:
am33xx_pinmux: pinmux@44e10800 {
...
};
gpmc: gpmc@5000 {
...
};
i2c0: i2c@44e0b000 {
...
};
uart0: serial@44e09000 {
..
};
It has to be defined as:
am33xx_pinmux {
...
};
gpmc {
...
};
i2c0 {
...
}
I'm looking at other am33xx dts such as am335x-bone.dts and
am335x-evm.dts and I see that these define device nodes already
defined in the included .dtsi which is wrong in my opinion.
The OMAP{3,4,5} dtsi and dts do correctly and can be used as a
reference on how the device nodes have to be defined and referenced.
Best regards,
Javier
--
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: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 06/19/2013 04:30 PM, Nishanth Menon wrote:
On 16:19-20130619, Tero Kristo wrote:
snip
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..b420d8a
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
[...]
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck@4a004134 {
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a004134 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
[..]
+
+/* XXX Missing round_rate, set_rate in ops */
could be dropped?
Yeah, I blame my bugged script here. :)
+dpll_per_m3x2_div_ck: dpll_per_m3x2_div_ck@4a008154 {
+ compatible = divider-clock;
+ clocks = dpll_per_x2_ck;
+ #clock-cells = 0;
+ reg = 0x4a008154 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
[...]
+
+/*
+ * clocks specific to omap4460
+ */
+/*
+ * clocks specific to omap4430
+ */
+/*
+ * clocks common to omap44xx
+ */
could be dropped?
Same.
btw, are we differentiating 4430 and 4460?A
Example:
bandgap_fclk in 4430
Vs
div_ts_ck, bandgap_ts_fclk in 4460?
Both nodes are available for both SoCs as of now. Driver should
differentiate which clock node to use though. Added Eduardo for
commenting this part, maybe we should add a couple of entries to the
list in cclock44xx_data.c...?
-Tero
--
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: [PATCHv2 10/11] ARM: dts: omap4 clock data
On 16:49-20130619, Tero Kristo wrote: On 06/19/2013 04:30 PM, Nishanth Menon wrote: On 16:19-20130619, Tero Kristo wrote: [...] + +/* + * clocks specific to omap4460 + */ +/* + * clocks specific to omap4430 + */ +/* + * clocks common to omap44xx + */ could be dropped? Same. btw, are we differentiating 4430 and 4460?A Example: bandgap_fclk in 4430 Vs div_ts_ck, bandgap_ts_fclk in 4460? Both nodes are available for both SoCs as of now. Driver should differentiate which clock node to use though. Added Eduardo for commenting this part, maybe we should add a couple of entries to the list in cclock44xx_data.c...? How about this: we do have 443x.dtsi and 4460.dtsi - add the corresponding clock nodes there? ideally, driver should just do devm_clk_get and should not worry about what SoC revision it is running on. -- 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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 02:30 PM, Benoit Cousson wrote:
On 06/19/2013 06:03 AM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the USB
PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying to
abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks. Since
there is nothing specific to
handle reset lines it is left to the driver writer how he wants to manage it.
Well, at that time, it was not available either. The point is still that
using a existing fmwk that has nothing to do with the signal you need to
handle just because it works is not a very good justification.
I couldn't find a better
way to represent this. It gives us a way to specify not only the GPIO
line but also
the polarity. I know mostly reset is active low but still there is
flexibility as you never
know for sure.
Mmm, and what about just controlling the gpio from the driver?
Yes gpio is possible. But then you need to add additional code in the driver
to parse GPIO number and polarity.
Using regulator_get() was plain simple for me.
Maybe, but it is not the right thing to do.
Can you explain me the commonality between a reset line and a regulator???
I cannot prove that a reset line is a regulator, because it is not. However,
the necessary features
required to manage a reset line were provided by the regulator framework e.g.
gpio control, polarity,
enable delay time. It was much less hassle for me to use the regulator
framework than manage
this in the phy driver.
Now that we have something specific for reset gpio I will migrate the PHY
driver to that, when it is
merged.
cheers,
-roger
--
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 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was
not the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is
possible, you should try. Otherwise, just keep the existing one, adding that
a new solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
cheers,
-roger
--
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
[RFC PATCH 0/6] Suspend USB Host controller on bus suspend
Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. This will cause its parent, the OMAP USB Host Module as well as the USB TLL Module to be put in suspend and hence allow the USB power domain to be put in a lower power state. Then we no longer prevent the rest of the OMAP SoC from entering lower power states like RETention or OFF mode when USB (or system) is suspended. This was one of the main reason why EHCI_OMAP is still not enabled in OMAP2 defconfig. In order for remote wakeup or hub events (connect/disconnect) to be detected while in suspend, we need to rely on the IO daisy chaining mechanism on OMAP. This is nothing but configuring a pin to be wakeup capable and triggering an interrupt on any pin activity while the hardware module or the entire SoC is in sleep state. For this to work, we rely on the wakeup feature added to the omap-pinctrl-single driver in [1]. This takes care of routing IO pad wakeup interrupt to the right driver's interrupt handler (i.e. ehci_irq in our case). The pin state information for DEFAULT and IDLE is specified for the omap3beagle-xm board in patch 5. So this is tested only on omap3beagle-xm board. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Patch 2 uses pinctrl framework to toggle USB host pins from DEFAULT state when active to IDLE state with wakeups enabled while in suspend. Patch 5 implements the suspend feature in ehci-omap driver and ensures that we don't loose events while in suspend. Please let me know what you think about it. I'm not 100% confident about tackling interrupt when the device is runtime suspended in patch 5. Please let me know if a race condition is possible here. [1] - OMAP pinctrl wakeup support http://thread.gmane.org/gmane.linux.ports.arm.omap/99010/focus=99041 cheers, -roger Roger Quadros (6): mfd: omap-usb-host: move initialization to module_init() mfd: omap-usb-host: Put pins in IDLE state on suspend USB: ehci: allow controller drivers to override irq bus_suspend/resume USB: ehci-omap: Suspend the controller during bus suspend ARM: dts: omap3beagle-xm: Add idle state pins for USB host ARM: OMAP3: Enable Hardware Save and Restore for USB Host arch/arm/boot/dts/omap3-beagle-xm.dts | 29 -- arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +-- drivers/mfd/omap-usb-host.c | 56 +++--- drivers/mfd/omap-usb-tll.c |8 +-- drivers/usb/host/ehci-hcd.c |9 +++- drivers/usb/host/ehci-hub.c |6 +- drivers/usb/host/ehci-omap.c| 82 +++ drivers/usb/host/ehci.h |6 ++ 8 files changed, 172 insertions(+), 32 deletions(-) -- 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
[RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
--
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
[RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusb2_pins: pinmux_hsusb2_pins {
pinctrl-single,pins =
0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
@@ -110,6 +105,25 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
+
+ /* WAKEUP enabled on DIR, DAT0-3 */
+ hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+ pinctrl-single,pins =
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)
/* etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* mcspi2_cs1.hsusb2_data3 */
+ ;
+ interrupts = 77; /* route padconf wakeup to EHCI IRQ */
+ };
};
i2c1 {
@@ -181,6 +195,9 @@
};
usbhshost {
+ pinctrl-names = default, idle;
+ pinctrl-0 = hsusb2_pins;
+ pinctrl-1 = hsusb2_idle_pins;
port2-mode = ehci-phy;
};
--
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
[RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended, so tackle it carefully using a workqueue.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c | 82 ++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..91f14f1 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -44,6 +44,8 @@
#include linux/usb/hcd.h
#include linux/of.h
#include linux/dma-mapping.h
+#include linux/workqueue.h
+#include linux/spinlock.h
#include ehci.h
@@ -69,6 +71,7 @@ static const char hcd_name[] = ehci-omap;
struct omap_hcd {
struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
int nports;
+ struct work_struct work;
};
static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
@@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
return __raw_readl(base + reg);
}
+static void omap_ehci_work(struct work_struct *work)
+{
+ struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
+ struct ehci_hcd *ehci = container_of((void *) omap,
+ struct ehci_hcd, priv);
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ struct device *dev = hcd-self.controller;
+
+ pm_runtime_get_sync(dev);
+ enable_irq(hcd-irq);
+ /*
+* enable_irq() should preempt us with a pending IRQ
+* so we can be sure that IRQ handler completes before
+* we call pm_runtime_put_sync()
+*/
+ pm_runtime_put_sync(dev);
+}
+
+static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
+{
+ struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
+ struct device *dev = hcd-self.controller;
+ irqreturn_t ret;
+
+ if (pm_runtime_suspended(dev)) {
+ schedule_work(omap-work);
+ disable_irq_nosync(hcd-irq);
+ ret = IRQ_HANDLED;
+ } else
+ ret = ehci_irq(hcd);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM
+static int omap_ehci_bus_suspend(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd-self.controller;
+ ret = ehci_bus_suspend(hcd);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_put_sync(dev);
+ if (ret 0 !(ret == -EBUSY || ret == -EAGAIN)) {
+ dev_err(dev, Failed to runtime suspend :%d\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omap_ehci_bus_resume(struct usb_hcd *hcd)
+{
+ struct device *dev;
+ int ret;
+
+ dev = hcd-self.controller;
+ ret = pm_runtime_get_sync(dev);
+ if (ret 0) {
+ dev_err(dev, Failed to runtime resume :%d\n, ret);
+ return ret;
+ }
+
+ return ehci_bus_resume(hcd);
+}
+#endif /* CONFIG_PM */
+
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -88,6 +161,11 @@ static struct hc_driver __read_mostly ehci_omap_hc_driver;
static const struct ehci_driver_overrides ehci_omap_overrides __initdata = {
.extra_priv_size = sizeof(struct omap_hcd),
+#ifdef CONFIG_PM
+ .bus_suspend = omap_ehci_bus_suspend,
+ .bus_resume = omap_ehci_bus_resume,
+#endif
+ .irq = omap_ehci_irq,
};
/**
@@ -163,6 +241,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
omap-nports = pdata-nports;
+ INIT_WORK(omap-work, omap_ehci_work);
platform_set_drvdata(pdev, hcd);
@@ -257,6 +336,9 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)-priv;
int i;
+ if (pm_runtime_suspended(dev))
+ pm_runtime_get_sync(dev);
+
usb_remove_hcd(hcd);
for (i = 0; i omap-nports; i++) {
--
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
[RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 759fae3..6601a49 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
{
return platform_driver_probe(usbhs_omap_driver, usbhs_omap_probe);
}
-
-/*
- * init before ehci and ohci drivers;
- * The usbhs core driver should be initialized much before
- * the omap ehci and ohci probe functions are called.
- * This usbhs core driver should be initialized after
- * usb tll driver
- */
-fs_initcall_sync(omap_usbhs_drvinit);
+module_init(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..fb7c73e 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
{
return platform_driver_register(usbtll_omap_driver);
}
-
-/*
- * init before usbhs core driver;
- * The usbtll driver should be initialized before
- * the usbhs core driver probe function is called.
- */
-fs_initcall(omap_usbtll_drvinit);
+module_init(omap_usbtll_drvinit);
static void __exit omap_usbtll_drvexit(void)
{
--
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
[RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
In order to support wake up from suspend use the pinctrl
framework to put the USB host pins in IDLE state during suspend.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6601a49..171cc3b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -31,6 +31,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/err.h
+#include linux/pinctrl/consumer.h
#include omap-usb.h
@@ -111,6 +112,10 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
+ struct pinctrl_state *pins_idle;
};
/*-*/
@@ -325,6 +330,10 @@ static int usbhs_runtime_resume(struct device *dev)
dev_dbg(dev, usbhs_runtime_resume\n);
+ if (!IS_ERR(omap-pins_default))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_default))
+ dev_err(dev, Could not select DEFAULT pin state\n);
+
omap_tll_enable(pdata);
if (!IS_ERR(omap-ehci_logic_fck))
@@ -402,6 +411,10 @@ static int usbhs_runtime_suspend(struct device *dev)
omap_tll_disable(pdata);
+ if (!IS_ERR(omap-pins_idle))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_idle))
+ dev_err(dev, Could not select IDLE pin state\n);
+
return 0;
}
@@ -608,6 +621,30 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ omap-pinctrl = devm_pinctrl_get(dev);
+ if (!IS_ERR(omap-pinctrl)) {
+ omap-pins_default = pinctrl_lookup_state(omap-pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(omap-pins_default))
+ dev_err(dev, Could not get DEFAULT state pins\n);
+
+ omap-pins_idle = pinctrl_lookup_state(omap-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(omap-pins_idle))
+ dev_err(dev, Could not get IDLE state pins\n);
+
+ } else {
+ dev_info(dev, pinctrl_get error\n);
+ if (PTR_ERR(omap-pinctrl) == -EPROBE_DEFER) {
+ dev_info(dev, defer\n);
+ return -EPROBE_DEFER;
+ }
+
+ omap-pins_default = omap-pins_idle = ERR_PTR(-EINVAL);
+ dev_dbg(dev, Proceeding without pinctrl: %ld\n,
+ PTR_ERR(omap-pinctrl));
+ }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
omap-uhh_base = devm_ioremap_resource(dev, res);
if (IS_ERR(omap-uhh_base))
@@ -796,6 +833,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
}
+ if (!IS_ERR(omap-pins_default))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_default))
+ dev_err(dev, Could not select DEFAULT pin state\n);
+
return 0;
err_alloc:
@@ -872,6 +913,11 @@ static int usbhs_omap_remove(struct platform_device *pdev)
/* remove children */
device_for_each_child(pdev-dev, NULL, usbhs_omap_remove_child);
+
+ if (!IS_ERR(omap-pins_idle))
+ if (pinctrl_select_state(omap-pinctrl, omap-pins_idle))
+ dev_err(pdev-dev, Could not select IDLE pin
state\n);
+
return 0;
}
--
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
[RFC PATCH 3/6] USB: ehci: allow controller drivers to override irq bus_suspend/resume
Some drivers (e.g. ehci_omap) need to do additional work in
bus suspend/resume and interrupt handler to support low power
modes and remote wakeup.
Allow drivers to override these functions through ehci_driver_overrides.
Also export the ehci_irq(), ehci_bus_suspend() and ehci_bus_resume()
functions so they can be called from the controller drivers.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-hcd.c |9 -
drivers/usb/host/ehci-hub.c |6 --
drivers/usb/host/ehci.h |6 ++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 246e124..8d35dd4 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -681,7 +681,7 @@ EXPORT_SYMBOL_GPL(ehci_setup);
/*-*/
-static irqreturn_t ehci_irq (struct usb_hcd *hcd)
+irqreturn_t ehci_irq(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 status, masked_status, pcd_status = 0, cmd;
@@ -828,6 +828,7 @@ dead:
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
}
+EXPORT_SYMBOL_GPL(ehci_irq);
/*-*/
@@ -1211,6 +1212,12 @@ void ehci_init_driver(struct hc_driver *drv,
drv-hcd_priv_size += over-extra_priv_size;
if (over-reset)
drv-reset = over-reset;
+ if (over-bus_suspend)
+ drv-bus_suspend = over-bus_suspend;
+ if (over-bus_resume)
+ drv-bus_resume = over-bus_resume;
+ if (over-irq)
+ drv-irq = over-irq;
}
}
EXPORT_SYMBOL_GPL(ehci_init_driver);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9ab4a4d..1fc03f9 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -218,7 +218,7 @@ static void ehci_adjust_port_wakeup_flags(struct ehci_hcd
*ehci,
spin_unlock_irq(ehci-lock);
}
-static int ehci_bus_suspend (struct usb_hcd *hcd)
+int ehci_bus_suspend(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
int port;
@@ -348,10 +348,11 @@ static int ehci_bus_suspend (struct usb_hcd *hcd)
hrtimer_cancel(ehci-hrtimer);
return 0;
}
+EXPORT_SYMBOL_GPL(ehci_bus_suspend);
/* caller has locked the root hub, and should reset/reinit on error */
-static int ehci_bus_resume (struct usb_hcd *hcd)
+int ehci_bus_resume(struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 temp;
@@ -489,6 +490,7 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
spin_unlock_irq(ehci-lock);
return -ESHUTDOWN;
}
+EXPORT_SYMBOL_GPL(ehci_bus_resume);
#else
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 7c978b2..992d626 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -795,15 +795,21 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd
*ehci, const __hc32 *x)
struct ehci_driver_overrides {
size_t extra_priv_size;
int (*reset)(struct usb_hcd *hcd);
+ int (*bus_suspend)(struct usb_hcd *hcd);
+ int (*bus_resume)(struct usb_hcd *hcd);
+ irqreturn_t (*irq) (struct usb_hcd *hcd);
};
extern voidehci_init_driver(struct hc_driver *drv,
const struct ehci_driver_overrides *over);
extern int ehci_setup(struct usb_hcd *hcd);
+extern irqreturn_t ehci_irq(struct usb_hcd *hcd);
#ifdef CONFIG_PM
extern int ehci_suspend(struct usb_hcd *hcd, bool do_wakeup);
extern int ehci_resume(struct usb_hcd *hcd, bool hibernated);
+extern int ehci_bus_suspend(struct usb_hcd *hcd);
+extern int ehci_bus_resume(struct usb_hcd *hcd);
#endif /* CONFIG_PM */
#endif /* __LINUX_EHCI_HCD_H */
--
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
Re: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend
On Wed, 19 Jun 2013, Roger Quadros wrote: Hi, This series attempts to suspend the OMAP EHCI host controller on USB Bus suspend. Why do you want to suspend the host controller during bus suspend? They are two different operations and should be carried out at two different times. The controller should be suspended during controller suspend, not during bus suspend. As the omap-ehci controller driver needs to do some additional work to put itself into suspend/resume and make sure it is resumed to process an interrupt, we need to be able to override irq, bus_suspend, and bus_resume handlers. This provision is done in patch 3. Do you still need to override these things if you do the controller suspend at the right time? Alan Stern -- 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 v7 1/9] drivers: phy: add generic PHY framework
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @priv: private data from phy driver
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+ const char *label, void *priv)
+{
+ int ret;
+ struct phy *phy;
+
+ if (!dev) {
+ dev_WARN(dev, no device provided for PHY\n);
+ ret = -EINVAL;
+ goto err0;
+ }
+
+ phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+ if (!phy) {
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ device_initialize(phy-dev);
+
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.of_node = dev-of_node;
+ phy-id = id;
+ phy-ops = ops;
+ phy-label = label;
Perhaps we could make it:
phy-label = kstrdup(label, GFP_KERNEL);
and free the label in phy_destroy() ?
That way the users would't need to keep the label around. It might
be useful when PHY provider generates the labels dynamically. I guess
it is OK for PHY providers to hard code the labels and having the PHY
user drivers passed labels in platform data ?
+ dev_set_drvdata(phy-dev, priv);
+
+ ret = dev_set_name(phy-dev, %s.%d, dev_name(dev), id);
+ if (ret)
+ goto err1;
+
+ ret = device_add(phy-dev);
+ if (ret)
+ goto err1;
+
+ if (pm_runtime_enabled(dev))
+ pm_runtime_enable(phy-dev);
+
+ return phy;
+
+err1:
+ put_device(phy-dev);
+ kfree(phy);
+
+err0:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+ pm_runtime_disable(phy-dev);
+ device_unregister(phy-dev);
Isn't kfree(phy); missing here ?
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
Thanks,
Sylwester
--
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/1] ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.
From: Enric Balletbo i Serra eballe...@iseebcn.com
Platform code used to depend on bootloadres for correctly setting the mux
pin modes. But bootloaders should only set the minimum required mux pins.
So, DSS mux pins are not set in U-Boot anymore and video display is broken
on IGEPv2 when booting with newer U-Boot versions.
Setup the DSS pin muxes to enable display functionality.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Tony,
Can you please take this until we have finished the OMAP3 migration to DT?
I think it falls under the critical fix category that you were talking about.
Thanks a lot and best regards,
Javier
arch/arm/mach-omap2/board-igep0020.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index b54562d..87e65dd 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -553,6 +553,37 @@ static struct usbhs_omap_platform_data igep3_usbhs_bdata
__initdata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* Display Sub System */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA9, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA10, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA11, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA12, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA13, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA14, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ /* TFP410 PanelBus DVI Transmitte (GPIO_170) */
+ OMAP3_MUX(HDQ_SIO, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
/* SMSC9221 LAN Controller ETH IRQ (GPIO_176) */
OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
--
1.7.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 v3 4/4] regulator: Palmas: Add TPS659038 support
On Wed, Jun 19, 2013 at 11:27:50AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com Add TPS659038 support. Signed-off-by: J Keerthy j-keer...@ti.com This doesn't apply against my current tree as the PMIC bindings document isn't in mainline yet. Acked-by: Mark Brown broo...@linaro.org assuming there's a tree where that does exist. signature.asc Description: Digital signature
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On Wed, Jun 19, 2013 at 11:27:47AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com Reviewed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
On 06/18/2013 11:57 PM, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Reviewed-by: Stephen Warren swar...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
Hi Roger, Roger Quadros rog...@ti.com writes: In order to support wake up from suspend use the pinctrl framework to put the USB host pins in IDLE state during suspend. CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com You should use helpers for this now in the pinctrl core: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html 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 1/2] musb: musb: dsps: support multiple instances
On 06/18/2013 10:27 AM, Felipe Balbi wrote:
--- a/arch/arm/boot/dts/am33xx.dtsi +++
b/arch/arm/boot/dts/am33xx.dtsi @@ -341,6 +341,14 @@ port1-mode =
3; power = 250; ti,hwmods = usb_otg_hs; + phys =
nopphy0 nopphy1; + }; + + nopphy0: usbphy@0 { +
compatible = usb-nop-xceiv; + }; +nopphy1:
usbphy@1 { +
compatible = usb-nop-xceiv; };
mac: ethernet@4a10 {
Any opinion on those phy nodes? Is it likely that we need a real phy
driver here and also expose a little more information like the memory
register or reset / vcc supply?
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
Hello.
On 06/19/2013 06:05 PM, Roger Quadros wrote:
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
b/arch/arm/mach-omap2/powerdomains3xxx_data.c
index f0e14e9..9554d2b 100644
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
.prcm_offs= OMAP3430ES2_USBHOST_MOD,
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_RET,
- /*
-* REVISIT: Enabling usb host save and restore mechanism seems to
-* leave the usb host domain permanently in ACTIVE mode after
-* changing the usb host power domain state from OFF to active once.
-* Disabling for now.
-*/
- /*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
+ .flags= PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
Looks like you're not indenting = right, in accordance to the other
fields...
.banks= 1,
.pwrsts_mem_ret = {
[0] = PWRSTS_RET, /* MEMRETSTATE */
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi Roger, Roger Quadros rog...@ti.com writes: Runtime suspend the controller during bus suspend and resume it during bus resume. This will ensure that the USB Host power domain enters lower power state and does not prevent the SoC from endering deeper sleep states. Remote wakeup will come up as an interrupt while the controller is suspended, so tackle it carefully using a workqueue. I don't think you need a special workqueue here. The workqueue of the PM core (pm_wq) will be used if you just use an asynchronous 'get' in the ISR. Then, the driver's own runtime PM callbacks can be used instead of an additional workqueue. Another thing to worry about here when using runtime PM to implement suspend/resume is that runtime PM can be disabled from userspace (e.g. echo disabled /sys/devices/.../power/control.) If that's the case, all the pm_runtime_suspended() checks will always fail becuase that call also checks if runtime PM is disabled. You'll likely want to use the pm_runtime_status_suspended() check instead, which checks only the status, and doesn't matter if runtime PM is currently disabled. Because of the corner issues here, please test system suspend/resume when runtime PM has been disabled. 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
[PATCH] ARM: OMAP2: reboot: Include common.h to fix build error
Include common.h which will include linux/reboot.h to fix below build error.
CC arch/arm/mach-omap2/omap4-restart.o
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: 'enum reboot_mode' declared
inside parameter list [enabled by default]
arch/arm/mach-omap2/omap4-restart.c:21:28: warning: its scope is only this
definition or declaration, which is probably not what you want [enabled by
default]
arch/arm/mach-omap2/omap4-restart.c:21:40: error: parameter 1 ('mode') has
incomplete type
arch/arm/mach-omap2/omap4-restart.c:21:6: warning: function declaration isn't a
prototype [-Wstrict-prototypes]
make[1]: *** [arch/arm/mach-omap2/omap4-restart.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Axel Lin axel@ingics.com
---
Seems this build error is introduced by commit 7507d035f3cf40c
reboot: arm: change reboot_mode to use enum reboot_mode
This patch is against linux-next 20130619.
arch/arm/mach-omap2/omap4-restart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap4-restart.c
b/arch/arm/mach-omap2/omap4-restart.c
index 652adde..7306d9b 100644
--- a/arch/arm/mach-omap2/omap4-restart.c
+++ b/arch/arm/mach-omap2/omap4-restart.c
@@ -9,6 +9,7 @@
#include linux/types.h
#include prminst44xx.h
+#include common.h
/**
* omap44xx_restart - trigger a software restart of the SoC
--
1.8.1.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 v2 1/4] ARM: dts: omap4-panda: Add USB Host support
On 06/19/2013 09:05 AM, Roger Quadros wrote:
On 06/19/2013 03:23 PM, Benoit Cousson wrote:
On 06/19/2013 07:05 AM, Florian Vaussard wrote:
Hello,
On 06/19/2013 01:03 PM, Roger Quadros wrote:
On 06/19/2013 01:10 PM, Benoit Cousson wrote:
On 06/19/2013 02:46 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130619 00:42]:
Hi Benoit,
On 06/19/2013 04:17 AM, Benoit Cousson wrote:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+/* HS USB Port 1 RESET */
+hsusb1_reset: hsusb1_reset_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb1_reset;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = gpio2 30 0;/* gpio_62 */
+startup-delay-us = 7;
+enable-active-high;
+};
Is this really a regulator? Or just a GPIO line used to reset the
USB PHY?
It is in fact a GPIO line used as reset.
If this is the case, I don't think it should be represented as a
regulator.
Why not? I think it fits very well in the regulator device model.
I'm not sure fitting very well is the correct term.
It works, for sure, but it is no different than when we were trying
to abuse the regulator fmwk to enable the 32k clock in phoenix.
It is just a hack.
The only difference is there is a dedicated framework for clocks.
Since there is nothing specific to
handle reset lines it is left to the driver writer how he wants to
manage it.
There is a proposed binding for gpio-controlled reset lines, but it is
not yet merged [1].
I guess it can fit most usage patterns, and it can be an interesting
move in the future.
I'm glad to see that I was not the only one thinking that the regulator was not
the right fmwk to do that :-)
Thanks for the pointer Florian.
Thanks again Florian.
I guess that series should be merged for 3.11? Based on the thread, it should
to through arm-soc.
Roger,
It might be tricky to have dependency on that series, but if this is possible,
you should try. Otherwise, just keep the existing one, adding that a new
solution will be available soon as a disclaimer.
I will rework the PHY driver to use the new gpio-reset driver. But for 3.11
let's proceed the way it is.
I'll resend this one with a disclaimer.
OK, sounds good.
Thanks,
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: [RFC] i2c: add deprecation warning for class based instantiation
On 06/07/2013 12:09 PM, Wolfram Sang wrote: Class based instantiation can cause huge delays when booting. This mechanism was used when it was not possible to describe slaves on I2C busses. We now have other mechanisms, so most embedded I2C will not need classes and it was explicitly not recommended to use them. Add a deprecation warning for drivers who want to disable class based in the near future to gain boot-up time, so users relying on this technique can switch to something better. They really should. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/i2c/busses/i2c-omap.c |2 +- drivers/i2c/i2c-core.c|6 ++ include/linux/i2c.h |1 + 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index e02f9e3..f06109f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1231,7 +1231,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; - adap-class = I2C_CLASS_HWMON; + adap-class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; strlcpy(adap-name, OMAP I2C adapter, sizeof(adap-name)); adap-algo = omap_i2c_algo; adap-dev.parent = pdev-dev; diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 48e31ed..47ea1f0 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -999,6 +999,12 @@ static int i2c_register_adapter(struct i2c_adapter *adap) return -EINVAL; } + if (adap-class I2C_CLASS_DEPRECATED) + dev_warn(adap-dev, This adapter will soon drop class based + instantiation of slaves\nPlease make sure all its I2C + devices are instantiated by other means.\nCheck + 'Documentation/i2c/instantiating-devices' for details\n); + Seems, this need to be moved down - after res = device_register(adap-dev); - or - right before: bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); rt_mutex_init(adap-bus_lock); mutex_init(adap-userspace_clients_lock); INIT_LIST_HEAD(adap-userspace_clients); diff --git a/include/linux/i2c.h b/include/linux/i2c.h index e988fa9..ffab838 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h @@ -473,6 +473,7 @@ void i2c_unlock_adapter(struct i2c_adapter *); #define I2C_CLASS_HWMON (10)/* lm_sensors, ... */ #define I2C_CLASS_DDC (13)/* DDC bus on graphics adapters */ #define I2C_CLASS_SPD (17)/* Memory modules */ +#define I2C_CLASS_DEPRECATED (18)/* Warn users that adapter will stop using classes */ /* Internal numbers to terminate lists */ #define I2C_CLIENT_END0xfffeU - grygorii -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: add deprecation warning for class based instantiation
Hi Wolfram,
On 06/19/2013 01:15 PM, Wolfram Sang wrote:
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote:
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes and it was explicitly not recommended to use them. Add a
deprecation warning for drivers who want to disable class based in the
near future to gain boot-up time, so users relying on this technique can
switch to something better. They really should.
Signed-off-by: Wolfram Sang w...@the-dreams.de
No reactions on this, pity. Deferring.
Sorry, for delayed reply - I've had problems with my e-mail.
I've tested this patch on our TI K3.4 product kernel with additional
change below:
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index c0330a4..442101d 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -186,7 +186,7 @@ static int __devinit i2c_gpio_probe(struct
platform_device *pdev)
adap-owner = THIS_MODULE;
snprintf(adap-name, sizeof(adap-name), i2c-gpio%d, pdev-id);
adap-algo_data = bit_data;
- adap-class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
+ adap-class = I2C_CLASS_HWMON | I2C_CLASS_SPD |
I2C_CLASS_DEPRECATED;
adap-dev.parent = pdev-dev;
adap-dev.of_node = pdev-dev.of_node;
It works fine, in general - see my minor comment inline.
[0.662536] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz
[0.662567] (null): This adapter will soon drop class based
instantiation of slaves
^ invalid adapter device name here
[0.662567] Please make sure all its I2C devices are instantiated by
other means.
[0.662567] Check 'Documentation/i2c/instantiating-devices' for details
Also tested on Linux master - OMAP4 SDP board.
In addition, I've found the following users of *i2c-gpio* (just FYI):
./arch/powerpc/boot/dts/wii.dts:compatible = i2c-gpio;
./arch/mips/alchemy/board-gpr.c:.name= i2c-gpio,
./arch/mips/ath79/mach-pb44.c:.name= i2c-gpio,
./arch/avr32/boards/merisc/setup.c:.name= i2c-gpio,
./arch/avr32/boards/atngw100/setup.c:.name= i2c-gpio,
./arch/avr32/boards/hammerhead/setup.c:.name= i2c-gpio,
./arch/avr32/boards/mimc200/setup.c:.name= i2c-gpio,
./arch/blackfin/mach-bf533/boards/blackstamp.c:.name=
i2c-gpio,
./arch/blackfin/mach-bf533/boards/ezkit.c:.name= i2c-gpio,
./arch/blackfin/mach-bf533/boards/stamp.c:.name= i2c-gpio,
./arch/blackfin/mach-bf561/boards/ezkit.c:.name= i2c-gpio,
./arch/arm/mach-ep93xx/core.c:.name= i2c-gpio,
./arch/arm/mach-shmobile/board-armadillo800eva.c:.name = i2c-gpio,
./arch/arm/mach-pxa/viper.c:.name= i2c-gpio,
./arch/arm/mach-pxa/viper.c:tpm_device =
platform_device_alloc(i2c-gpio, 2);
./arch/arm/mach-pxa/palmz72.c:.name= i2c-gpio,
./arch/arm/boot/dts/at91sam9g45.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91sam9263.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91sam9x5.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/usb_a9g20-dab-mmx.dtsi:i2c-gpio@0 {
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
i2c-gpio;
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
i2c-gpio;
./arch/arm/boot/dts/ste-nomadik-stn8815.dtsi:compatible =
i2c-gpio;
./arch/arm/boot/dts/at91sam9260.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91rm9200.dtsi:compatible = i2c-gpio;
./arch/arm/boot/dts/at91sam9n12.dtsi:compatible = i2c-gpio;
./arch/arm/mach-ks8695/board-acs5k.c:.name= i2c-gpio,
./arch/arm/mach-s5pv210/mach-goni.c:.name= i2c-gpio,
./arch/arm/mach-s5pv210/mach-goni.c:.name= i2c-gpio,
./arch/arm/mach-s5pv210/mach-aquila.c:.name= i2c-gpio,
./arch/arm/mach-s5pv210/mach-aquila.c:.name= i2c-gpio,
./arch/arm/mach-sa1100/simpad.c:.name = i2c-gpio,
./arch/arm/mach-exynos/mach-universal_c210.c:.name= i2c-gpio,
./arch/arm/mach-exynos/mach-nuri.c:.name= i2c-gpio,
./arch/arm/mach-at91/at91sam9263_devices.c:.name=
i2c-gpio,
./arch/arm/mach-at91/at91sam9261_devices.c:.name=
i2c-gpio,
./arch/arm/mach-at91/at91sam9g45_devices.c:.name=
i2c-gpio,
./arch/arm/mach-at91/at91sam9g45_devices.c:.name=
i2c-gpio,
./arch/arm/mach-at91/at91rm9200_devices.c:.name= i2c-gpio,
./arch/arm/mach-at91/at91sam9260_devices.c:.name=
i2c-gpio,
./arch/arm/mach-at91/at91sam9rl_devices.c:.name= i2c-gpio,
[RFC 1/2] i2c: omap: drop class based instantiation of slaves
Class based instantiation mechanism can cause huge delays when booting. For example: when CONFIG_SENSORS_LM75 option is enabled for omap4-sdp board - it introduces 5-6 ms boot delay. It's not recommended to use this mechanism with embedded I2C, so disable it by leaving I2C adapter class field undefined (remove I2C_CLASS_HWMON). CC: Tony Lindgren t...@atomide.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index f06109f..ae2b27f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1231,7 +1231,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; - adap-class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; + adap-class = I2C_CLASS_DEPRECATED; strlcpy(adap-name, OMAP I2C adapter, sizeof(adap-name)); adap-algo = omap_i2c_algo; adap-dev.parent = pdev-dev; -- 1.7.9.5 -- 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
[RFC 2/2] i2c: gpio: drop class based instantiation of slaves
Class based instantiation mechanism can cause huge delays when booting. For example: when CONFIG_SENSORS_LM75 option is enabled for or omap5-uevm board, where i2c-gpio is used for HDMI edid reading - it introduces up to 5 sec boot delay. It's not recommended to use this mechanism with embedded I2C, so disable it by leaving I2C adapter class field undefined (remove I2C_CLASS_HWMON and I2C_CLASS_SPD) and add a deprecation warning to allow users, relying on this mechanism, to switch to something better. CC: Haavard Skinnemoen hskinnem...@gmail.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- drivers/i2c/busses/i2c-gpio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c index bc6e139..33e3d0e 100644 --- a/drivers/i2c/busses/i2c-gpio.c +++ b/drivers/i2c/busses/i2c-gpio.c @@ -215,7 +215,7 @@ static int i2c_gpio_probe(struct platform_device *pdev) snprintf(adap-name, sizeof(adap-name), i2c-gpio%d, pdev-id); adap-algo_data = bit_data; - adap-class = I2C_CLASS_HWMON | I2C_CLASS_SPD; + adap-class = I2C_CLASS_DEPRECATED; adap-dev.parent = pdev-dev; adap-dev.of_node = pdev-dev.of_node; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
Roger Quadros rog...@ti.com writes:
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
This one doesn't apply...
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
omap3_pmx_core {
- pinctrl-names = default;
- pinctrl-0 =
- hsusbb2_pins
- ;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
This omap3_pmx_core section doesn't exist upstream in the xM DTS file
(but does in omap3-beagle.dts.)
Is there a dependency patch missing?
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 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
Hi Felipe, On 06/07/2013 10:05 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote: ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be Have you seen that happen ever ? AL is Arbitration Lost, we never put OMAP in a multi-master environment before. This is an example from real life: [0.271942] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [1.283416] omap_i2c omap_i2c.1: timeout waiting for bus ready [1.300109] OMAP_I2C DEBUG: stat=1001 [1.300140] omap_i2c omap_i2c.1: Arbitration lost [1.300140] OMAP_I2C DEBUG: IE=601F [1.300140] OMAP_I2C DEBUG: STAT=1000 [1.300170] OMAP_I2C DEBUG: IV=636F [1.300170] OMAP_I2C DEBUG: WE=636F [1.300170] OMAP_I2C DEBUG: SYSS=1 [1.300170] OMAP_I2C DEBUG: BUF=707 [1.300201] OMAP_I2C DEBUG: CNT=1 [1.300201] OMAP_I2C DEBUG: DATA=1 [1.300201] OMAP_I2C DEBUG: SYSC=215 [1.300201] OMAP_I2C DEBUG: CON=8200 [1.300231] OMAP_I2C DEBUG: OA=0 [1.300231] OMAP_I2C DEBUG: SA=49 [1.300231] OMAP_I2C DEBUG: PSC=9 [1.300262] OMAP_I2C DEBUG: SCLL=9 [1.300262] OMAP_I2C DEBUG: SCLH=3 [1.300262] OMAP_I2C DEBUG: SYSTEST=1E0 [1.300262] OMAP_I2C DEBUG: BUFSTAT=4000 and my headache now :..( ARDY | NACK I also find it a bit hard for those two to happen together since ARDY will be set when you can change controller's register *again*, mening that a transfer has completed. There are examples: [3.544952] omap_i2c 4806.i2c: IRQ (ISR = 0x0006) [ 25.574523] omap_i2c 4835.i2c: IRQ (ISR = 0x0014) [ 25.579925] omap_i2c 4835.i2c: IRQ (ISR = 0x0012) to see it - enable debug output in omap_i2c_isr_thread: dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat); Also, we need to follow what the programming model says. And, I don't have docs with me right now, but IIRC it tells us to bail out if any of the error conditions are met. yep, but first of all - all IRQs need to be acked before exit. Sorry, for delayed reply - I've had problems with my e-mail. - grygorii -- 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/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
Hi Felipe,
On 06/07/2013 10:02 PM, Felipe Balbi wrote:
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return IRQ_NONE;
}
Produce warning in case if ISR called when i2c is disabled
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 97844ff..2dac598 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
u16 stat;
spin_lock(dev-lock);
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
returning IRQ_NONE is not what you want to do in this case. You want to
setup a flag so that your runtime_resume() knows that there are pending
events to be handled and you handle those in runtime_resume time.
I don't want to handle this IRQ - we should never be here.
Will be changed to IRQ_HANDLED.
But to be frank, I don't see how this can trigger since we're calling
pm_runtime_get_sync() from omap_i2c_xfer() which means by the time
pm_runtime_get_sync() returns, assuming no errors, i2c module should be
fully resumed and ready to go. Perhaps you have found a bug somewhere
else ?
May be it's better to revert this patch:
e3a36b207f76364c281aeecaf14c1b22a7247278
i2c: omap: remove unnecessary pm_runtime_suspended check
which doesn't cover case when transfer is *finished*.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
Also, your 'We should never be here' message isn't helpfull at all.
@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
because of IRQF_ONESHOT I can't see how this would *ever* be a valid
check.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
Sorry, for delayed reply - I've had problems with my e-mail.
- grygorii
--
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 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
Hi Felipe, On 06/07/2013 10:07 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote: The omap_i2c_isr() does the irq check and schedules threaded handler if any of enabled IRQs is active, but currently the I2C IRQs are enabled just once, when I2C IP is enabling (transfer started) and they aren't changed after that. More over, now the I2C INTC IRQ is disabled when I2C IP is idled. Thus, I2C IRQs will start coming only when we want that, and there is no sense to have omap_i2c_isr() anymore: so ? we still want to check if this device generated IRQs in hardirq context. What if the IRQ line is shared ? Pleas see, https://patchwork.kernel.org/patch/2689211/ [1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle It covers shared IRQ problem Sorry, for delayed reply - I've had problems with my e-mail. - grygorii -- 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/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
On 06/07/2013 11:51 PM, Kevin Hilman wrote: Grygorii Strashko grygorii.stras...@ti.com writes: From: Kevin Hilman khil...@deeprootsystems.com Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's -runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -runtime_suspend() (and re-enable them in -runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. More over, this patch fixes the kernel boot failure which happens when CONFIG_SENSORS_LM75=y: [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- The root casue of crash is race between omap_i2c_runtime_suspend() and omap_i2c_isr_thread() If there's a race here, then it's not the same problem which is described above, unless the CPU2 IRQ is happening because of a shared user of I2C, in which case it doesn't need any additional explanation. no shared users here CPU1: CPU2: |-omap_i2c_xfer | |- pm_runtime_put_autosuspend() | |-timeout |-omap_i2c_isr() |-return IRQ_WAKE_THREAD; |-omap_i2c_runtime_suspend() | |-omap_i2c_isr_thread() |- oops is here - I2C module is in idle state If this is happening, I don't think it's related to $SUBJECT patch (but is probably hidden by it.) I can remove fix spurious IRQs: from $SUBJECT. What do you think? Instead, what probably needs to happen in this is case is that omap_i2c_isr() should be doing a mark last busy to reset the autosuspend timeout. And, that should be done in a separate patch. Yes - from one side. From other side, this patch prevents such situation to happen. disable_irq(_dev-irq); - waits for any pending IRQ handlers for this interrupt to complete before returning. If we are in .runtime_idle() callback - it means I2C transaction has been finished (and It doesn't matter successfully or not) and we don't want to receive IRQs any more. As I mentioned in cover-latter this happens because PM runtime auto-suspend isn't working properly during the boot: [ 23.190002] omap_i2c 4835.i2c: i2c_add_numbered_adapter [ 23.204681] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
[RFC PATCH] regulator: core: allow consumers to request to closes step voltage
Regulator consumers are not aware of the characteristics of regulator
used to supply. For example:
consumerX requests for voltage min_uV = 500mV, max_uV = 500mV
On a regulator which has a step size of 10mV, this can be exactly
achieved.
However, on a regulator which is non-exact divider step size (example
12.66mV step size), the closest achievable would be 506.4.
regulator_set_voltage_tol does not work out either as 500mV is not an
operational voltage.
Account for step size accuracy when exact voltage requests are send for
step based regulators.
Signed-off-by: Nishanth Menon n...@ti.com
---
The specific example I faced was using cpufreq-cpu0 driver with voltages
for OPPs for MPU rail and attempting the common definitions against voltages
that are non-exact multiples of stepsize of PMIC.
The alternative would be implement custom set_voltage (as againsta simpler
set_voltage_sel and using linear map/list functions) for the regulator which
will account for the same.
Yet another alternative might be to introduce yet another custom function
similar
to regulator_set_voltage_tol which accounts for this. something like:
regulator_set_voltage_floor(regulator, voltage, tol) or something to that
effect.
drivers/regulator/core.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 288c75a..98c96b2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2407,6 +2407,9 @@ static int _regulator_do_set_voltage(struct regulator_dev
*rdev,
}
} else if (rdev-desc-ops-set_voltage_sel) {
+ if (min_uV == max_uV rdev-desc-uV_step)
+ max_uV += rdev-desc-uV_step;
+
if (rdev-desc-ops-map_voltage) {
ret = rdev-desc-ops-map_voltage(rdev, min_uV,
max_uV);
--
1.7.9.5
--
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/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, On Wed, Jun 19, 2013 at 09:35:38PM +0300, Grygorii Strashko wrote: On 06/07/2013 11:51 PM, Kevin Hilman wrote: Grygorii Strashko grygorii.stras...@ti.com writes: From: Kevin Hilman khil...@deeprootsystems.com Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's -runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -runtime_suspend() (and re-enable them in -runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. More over, this patch fixes the kernel boot failure which happens when CONFIG_SENSORS_LM75=y: [2.251220] WARNING: at drivers/bus/omap_l3_noc.c:113 l3_interrupt_handler+0x140/0x184() [2.257781] L3 custom error: MASTER:MPU TARGET:L4 PER2 [2.264373] Modules linked in: [2.268463] CPU: 0 PID: 2 Comm: kthreadd Not tainted 3.10.0-rc4-00034-g042dd60-dirty #64 [2.270385] [c001a80c] (unwind_backtrace+0x0/0xf0) from [c0017238] (show_stack+0x10/0x14) [2.286102] [c0017238] (show_stack+0x10/0x14) from [c0040fd0] (warn_slowpath_common+0x4c/0x68) [2.295593] [c0040fd0] (warn_slowpath_common+0x4c/0x68) from [c0041080] (warn_slowpath_fmt+0x30/0x40) [2.299987] [c0041080] (warn_slowpath_fmt+0x30/0x40) from [c02c5ed0] (l3_interrupt_handler+0x140/0x184) [2.315582] [c02c5ed0] (l3_interrupt_handler+0x140/0x184) from [c009ffb8] (handle_irq_event_percpu+0x58/0x258) [2.323364] [c009ffb8] (handle_irq_event_percpu+0x58/0x258) from [c00a01f4] (handle_irq_event+0x3c/0x5c) [2.327819] [c00a01f4] (handle_irq_event+0x3c/0x5c) from [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) [2.337829] [c00a2f7c] (handle_fasteoi_irq+0xbc/0x164) from [c009f978] (generic_handle_irq+0x20/0x30) [2.357513] [c009f978] (generic_handle_irq+0x20/0x30) from [c0014168] (handle_IRQ+0x4c/0xac) [2.366821] [c0014168] (handle_IRQ+0x4c/0xac) from [c00085b4] (gic_handle_irq+0x28/0x5c) [2.375762] [c00085b4] (gic_handle_irq+0x28/0x5c) from [c04f08a4] (__irq_svc+0x44/0x5c) [2.379821] Exception stack(0xdb085ec0 to 0xdb085f08) [2.389953] 5ec0: 0001 0001 db07ea00 4113 db2317a8 db084000 02f1 [2.389953] 5ee0: db07ea00 c04fd990 db085f08 c009170c c04f03e8 [2.405609] 5f00: 2113 [2.408355] [c04f08a4] (__irq_svc+0x44/0x5c) from [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) [2.418304] [c04f03e8] (_raw_spin_unlock_irqrestore+0x34/0x44) from [c00403c0] (do_fork+0xa4/0x2d4) [2.427795] [c00403c0] (do_fork+0xa4/0x2d4) from [c0040620] (kernel_thread+0x30/0x38) [2.437805] [c0040620] (kernel_thread+0x30/0x38) from [c0063888] (kthreadd+0xd4/0x13c) [2.448364] [c0063888] (kthreadd+0xd4/0x13c) from [c0013308] (ret_from_fork+0x14/0x2c) [2.448364] ---[ end trace da8cf92c433d1616 ]--- The root casue of crash is race between omap_i2c_runtime_suspend() and omap_i2c_isr_thread() If there's a race here, then it's not the same problem which is described above, unless the CPU2 IRQ is happening because of a shared user of I2C, in which case it doesn't need any additional explanation. no shared users here CPU1: CPU2: |-omap_i2c_xfer | |- pm_runtime_put_autosuspend() | |-timeout |-omap_i2c_isr() |-return IRQ_WAKE_THREAD; |-omap_i2c_runtime_suspend() | |-omap_i2c_isr_thread() |- oops is here - I2C module is in idle state If this is happening, I don't think it's related to $SUBJECT patch (but is probably hidden by it.) I can remove fix spurious IRQs: from $SUBJECT. What do you think? Instead, what probably needs to happen in this is case is that omap_i2c_isr() should be doing a mark last busy to reset the autosuspend timeout. And, that should be done in a separate patch. this doesn't make sense... mark last busy is done after the I2C message is actually complete, so is pm_runtime_put_autosuspend() which is done following mark_last_busy. autosuspend timer shouldn't be firing since put won't be called until we're dead sure I2C message (all of them, in fact) are finalized. Yes - from one side. From other side, this patch prevents such situation to happen. disable_irq(_dev-irq); - waits for any pending IRQ handlers for this
Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree
On Tue, Jun 18, 2013 at 12:57 PM, Stijn Devriendt high...@gmail.com wrote:
On Thu, Jun 6, 2013 at 4:05 PM, Archit Taneja arc...@ti.com wrote:
+static struct pcf857x_platform_data *of_gpio_pcf857x(struct device *dev)
+{
+ struct pcf857x_platform_data *pdata;
+ int r;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
This memory is never freed, is it?
Why should it, given it's allocated with devres?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: Change TWL6025 references to TWL6032
On Wed, Jun 19, 2013 at 03:24:02PM +0300, Oleksandr Kozaruk wrote: There are non-mainline branches that use twl6032 by its name (for example git://git.omapzoom.org/kernel/omap.git). There is intention to add support of twl6032 device in mainline, but we'd like to know if we can use twl6032 instead of twl6025 in our new patches, that we are going to provide. Related discussion: https://patchwork.kernel.org/patch/2686331/ It's always been OK to use the new name, the only question was if it was better to keep the old name supported as well. Given that the chips are essentially nonexistant now your current approach seems sensible so Reviwed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree
On Mon, Jun 17, 2013 at 1:46 PM, Archit Taneja arc...@ti.com wrote:
On Monday 17 June 2013 02:35 PM, Linus Walleij wrote:
Just a query, there is an example in gpio.txt in the gpio
bindings documentation which sets #gpio-cells as 1. Is this is a wrong
example, or are 1 cell gpio controllers valid?
I don't think so. Try it and see if it works!
(If you want it, you may have to go in and fix drivers/gpio/gpiolib-of.c.)
About this chip, a change in any of it's GPIOs configured as inputs will
generate an interrupt, then it's up to the driver to figure out which GPIOs
changed and handle their corresponding irqs. So shouldn't a device connected
to the chip describe the gpio number within the pcf857x chip as it's first
cell?
I guess so...
I've made a hypothetical example of a pcf8575 chip, which has it's interrupt
line connected to an omap gpio, and pcf8575's 7th gpio is connected to
'pcf_slave'. The pcf_slave's driver requests for an interrupt. Is this the
correct way to describe this? :
pcf: pcf8575@23 {
compatible = ti,pcf8575;
reg = 0x23;
gpio-controller;
#gpio-cells = 2;
#interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = gpio2;/* an omap gpio bank */
interrupts = 2 8; /* gpio line 34, low triggered*/
};
pcf_slave: slave {
...
...
#interrupt-parent = pcf;
interrupts = 7; /* connected to 7th IO pin of pcf857x*/
};
There are two paths for dereferencing GPIOs and IRQs.
Simple approach:
give your slave a gpios = ...;
and in the driver use gpio_to_irq() to dereference an IRQ number
from the GPIO number you get. The IRQdomain etc in the
GPIO driver will take care of the rest.
How to code up a driver so that it can use irqs directly from a GPIO
controller without referring to the GPIO line it is tied into is currently
quite unclear. Atleast to me. It's been discussed for the OMAP
case so search the archives...
Yours,
Linus Walleij
--
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/5] i2c: omap: add runtime check in isr to be sure that i2c is enabled
On Wed, Jun 19, 2013 at 09:42:25PM +0300, Grygorii Strashko wrote:
Hi Felipe,
On 06/07/2013 10:02 PM, Felipe Balbi wrote:
Hi,
On Fri, Jun 07, 2013 at 09:46:05PM +0300, Grygorii Strashko wrote:
Add runtime check at the beginning of omap_i2c_isr/omap_i2c_isr_thread
to be sure that i2c is enabled, before performing IRQ handling and accessing
I2C IP registers:
if (pm_runtime_suspended(dev-dev)) {
WARN_ONCE(true, We should never be here!\n);
return IRQ_NONE;
}
Produce warning in case if ISR called when i2c is disabled
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 97844ff..2dac598 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -885,6 +885,11 @@ omap_i2c_isr(int irq, void *dev_id)
u16 stat;
spin_lock(dev-lock);
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
returning IRQ_NONE is not what you want to do in this case. You want to
setup a flag so that your runtime_resume() knows that there are pending
events to be handled and you handle those in runtime_resume time.
I don't want to handle this IRQ - we should never be here.
Will be changed to IRQ_HANDLED.
blindly returning IRQ_HANDLED won't do you any good either. Your line
will be re-enabled anyway and you'll get another IRQ even being fired.
If you have found a bug in the driver, fix it, don't try to mask it.
But to be frank, I don't see how this can trigger since we're calling
pm_runtime_get_sync() from omap_i2c_xfer() which means by the time
pm_runtime_get_sync() returns, assuming no errors, i2c module should be
fully resumed and ready to go. Perhaps you have found a bug somewhere
else ?
May be it's better to revert this patch:
e3a36b207f76364c281aeecaf14c1b22a7247278
i2c: omap: remove unnecessary pm_runtime_suspended check
which doesn't cover case when transfer is *finished*.
what happens when transfer is finished ? After we come out of the loop
in omap_i2c_xfer() we will mark last busy and
pm_runtime_put_autosuspend()
633 static int
634 omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
635 {
636 struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
637 int i;
638 int r;
639
640 r = pm_runtime_get_sync(dev-dev);
641 if (IS_ERR_VALUE(r))
642 goto out;
643
644 r = omap_i2c_wait_for_bb(dev);
645 if (r 0)
646 goto out;
647
648 if (dev-set_mpu_wkup_lat != NULL)
649 dev-set_mpu_wkup_lat(dev-dev, dev-latency);
650
651 for (i = 0; i num; i++) {
652 r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1)));
653 if (r != 0)
654 break;
655 }
656
657 if (r == 0)
658 r = num;
659
660 omap_i2c_wait_for_bb(dev);
661
662 if (dev-set_mpu_wkup_lat != NULL)
663 dev-set_mpu_wkup_lat(dev-dev, -1);
664
665 out:
666 pm_runtime_mark_last_busy(dev-dev);
667 pm_runtime_put_autosuspend(dev-dev);
668 return r;
669 }
When that timer expires, we will mask the controller's IRQs on our
-runtime_suspend().
Now, if another IRQ comes before we -runtime_suspend(), then we need to
figure out what's generating that event, we don't want to be fixing
what's not broken in this driver.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
that patch is fine, but doesn't seem like has nothing to do with what
you're talking about here.
Also, your 'We should never be here' message isn't helpfull at all.
nor is your explanation of the problem. It's not sufficient.
I'm telling you that we should never reach this case because that's the
assumption that the driver makes. It assumes that no IRQs will be fired
unless a transfer is started and by the time that for loop ends, no
transfer will be started.
@@ -905,6 +910,11 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
u16 stat;
int err = 0, count = 0;
+ if (pm_runtime_suspended(dev-dev)) {
+ WARN_ONCE(true, We should never be here!\n);
+ return IRQ_NONE;
+ }
because of IRQF_ONESHOT I can't see how this would *ever* be a valid
check.
Please, see https://patchwork.kernel.org/patch/2689211/ and
cover-latter.
explain to me how would we get to this point, meaning the IRQ thread
handler, with the device disabled.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] i2c: omap: remove omap_i2c_isr() hw irq handler
On Wed, Jun 19, 2013 at 09:43:17PM +0300, Grygorii Strashko wrote: Hi Felipe, On 06/07/2013 10:07 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:08PM +0300, Grygorii Strashko wrote: The omap_i2c_isr() does the irq check and schedules threaded handler if any of enabled IRQs is active, but currently the I2C IRQs are enabled just once, when I2C IP is enabling (transfer started) and they aren't changed after that. More over, now the I2C INTC IRQ is disabled when I2C IP is idled. Thus, I2C IRQs will start coming only when we want that, and there is no sense to have omap_i2c_isr() anymore: so ? we still want to check if this device generated IRQs in hardirq context. What if the IRQ line is shared ? Pleas see, https://patchwork.kernel.org/patch/2689211/ [1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle It covers shared IRQ problem then you don't need $SUBJECT. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/5] i2c: omap: handle all irqs befor unblocking omap_i2c_xfer_msg()
On Wed, Jun 19, 2013 at 09:43:04PM +0300, Grygorii Strashko wrote: Hi Felipe, On 06/07/2013 10:05 PM, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 09:46:06PM +0300, Grygorii Strashko wrote: ARDY|NACK and ARDY|AL are set together in OMAP_I2C_STAT_REG, which will be Have you seen that happen ever ? AL is Arbitration Lost, we never put OMAP in a multi-master environment before. This is an example from real life: [0.271942] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [1.283416] omap_i2c omap_i2c.1: timeout waiting for bus ready [1.300109] OMAP_I2C DEBUG: stat=1001 [1.300140] omap_i2c omap_i2c.1: Arbitration lost [1.300140] OMAP_I2C DEBUG: IE=601F [1.300140] OMAP_I2C DEBUG: STAT=1000 [1.300170] OMAP_I2C DEBUG: IV=636F [1.300170] OMAP_I2C DEBUG: WE=636F [1.300170] OMAP_I2C DEBUG: SYSS=1 [1.300170] OMAP_I2C DEBUG: BUF=707 [1.300201] OMAP_I2C DEBUG: CNT=1 [1.300201] OMAP_I2C DEBUG: DATA=1 [1.300201] OMAP_I2C DEBUG: SYSC=215 [1.300201] OMAP_I2C DEBUG: CON=8200 [1.300231] OMAP_I2C DEBUG: OA=0 [1.300231] OMAP_I2C DEBUG: SA=49 [1.300231] OMAP_I2C DEBUG: PSC=9 [1.300262] OMAP_I2C DEBUG: SCLL=9 [1.300262] OMAP_I2C DEBUG: SCLH=3 [1.300262] OMAP_I2C DEBUG: SYSTEST=1E0 [1.300262] OMAP_I2C DEBUG: BUFSTAT=4000 and my headache now :..( have you looked for erratas around that ? Maybe you just found a silicon issue. Why is AL bit being set ? Have you tried to reach the IP owner ? If there are no other I2C masters in the system, there will be no arbitration, hence we would never loose the arbitration. ARDY | NACK I also find it a bit hard for those two to happen together since ARDY will be set when you can change controller's register *again*, mening that a transfer has completed. There are examples: [3.544952] omap_i2c 4806.i2c: IRQ (ISR = 0x0006) [ 25.574523] omap_i2c 4835.i2c: IRQ (ISR = 0x0014) [ 25.579925] omap_i2c 4835.i2c: IRQ (ISR = 0x0012) to see it - enable debug output in omap_i2c_isr_thread: dev_dbg(dev-dev, IRQ (ISR = 0x%04x)\n, stat); then you need to figure out why that's happening, right ? What do you do to trigger that particular condition, have you looked in the wire to see if you find a real NACK or is the OMAP I2C controller misbehaving ? Also, we need to follow what the programming model says. And, I don't have docs with me right now, but IIRC it tells us to bail out if any of the error conditions are met. yep, but first of all - all IRQs need to be acked before exit. that's alright, then fix only that... OTOH, you don't want to ack a read while data is still sitting in the FIFO, data you haven't read out of the FIFO, I mean. Not sure if that could happen though. -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
ARM errata 798181 is applicable for OMAP5 based devices. So enable the same in the build. Errata extract and workaround information is as below. On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not adequately shooting down all use of the old entries. The ARM_ERRATA_798181 option enables the Linux kernel workaround for this erratum which sends an IPI to the CPUs that are running the same ASID as the one being invalidated. Cc: Tony Lindgren t...@atomide.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..fbd2b9f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -112,6 +112,7 @@ config SOC_OMAP5 select HAVE_SMP select COMMON_CLK select HAVE_ARM_ARCH_TIMER + select ARM_ERRATA_798181 comment OMAP Core Type depends on ARCH_OMAP2 -- 1.7.9.5 -- 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/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Felipe Balbi ba...@ti.com writes: [...] If you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put is called only after 200 gets, no put-get ping-pong), your -runtime_resume() gets called once, your -runtime_suspend() gets called once but your -runtime_idle() will get called 200 times. No. The driver's -runtime_idle() will only be called when the usecount goes to zero. 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 1/5] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, On Wed, Jun 19, 2013 at 01:01:28PM -0700, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: [...] If you have 200 pm_runtime_get() followed by 200 pm_runtime_put() (put is called only after 200 gets, no put-get ping-pong), your -runtime_resume() gets called once, your -runtime_suspend() gets called once but your -runtime_idle() will get called 200 times. No. The driver's -runtime_idle() will only be called when the usecount goes to zero. Indeed, just re-read the code. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] regulator: core: allow consumers to request to closes step voltage
On Wed, Jun 19, 2013 at 02:17:54PM -0500, Nishanth Menon wrote: Account for step size accuracy when exact voltage requests are send for step based regulators. If the consumer can tolerate a different voltage why not just request the range that can be tolerated? Your problem here is specifying an exact voltage. The specific example I faced was using cpufreq-cpu0 driver with voltages for OPPs for MPU rail and attempting the common definitions against voltages that are non-exact multiples of stepsize of PMIC. The alternative would be implement custom set_voltage (as againsta simpler set_voltage_sel and using linear map/list functions) for the regulator which will account for the same. Yet another alternative might be to introduce yet another custom function similar to regulator_set_voltage_tol which accounts for this. something like: regulator_set_voltage_floor(regulator, voltage, tol) or something to that effect. Or as I keep telling you guys the consumer can just do that directly using the existing API; the whole point in specifying the voltage as a range is to allow the consumer to cope with arbatrary regulators by giving a range of voltages that it can accept. The API is deliberately very conservative in these matters since there is a danger of physical damage if things really go wrong in some applications, it makes sure that both the drivers and the system integration are involved. signature.asc Description: Digital signature
