[PATCH v6] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
This patch is based on can-next/master
Changes from v5:
- Incorporated Marc's commets on v5
* changed runtime pm calls in c_can driver to handle
the drivers which are not using platform drivers.
* added device pointer protection in c_can driver if
not passed from platform/pci driver.
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 25 -
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c |6 ++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 4c538e3..64344b8 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,8 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
#include linux/can.h
#include linux/can/dev.h
@@ -201,6 +203,18 @@ static const struct can_bittiming_const
c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline void c_can_pm_runtime_get_sync(struct device *dev)
+{
+ if (dev)
+ pm_runtime_get_sync(dev);
+}
+
+static inline void c_can_pm_runtime_put_sync(struct device *dev)
+{
+ if (dev)
+ pm_runtime_put_sync(dev);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -673,11 +687,15 @@ static int c_can_get_berr_counter(const struct net_device
*dev,
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
reg_err_counter = priv-read_reg(priv, C_CAN_ERR_CNT_REG);
bec-rxerr = (reg_err_counter ERR_CNT_REC_MASK)
ERR_CNT_REC_SHIFT;
bec-txerr = reg_err_counter ERR_CNT_TEC_MASK;
+ c_can_pm_runtime_put_sync(priv-device);
+
return 0;
}
@@ -1053,11 +1071,13 @@ static int c_can_open(struct net_device *dev)
int err;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
/* open the can device */
err = open_candev(dev);
if (err) {
netdev_err(dev, failed to open can device\n);
- return err;
+ goto exit_open_fail;
}
/* register interrupt handler */
@@ -1079,6 +1099,8 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
+exit_open_fail:
+ c_can_pm_runtime_put_sync(priv-device);
return err;
}
@@ -1091,6 +1113,7 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+ c_can_pm_runtime_put_sync(priv-device);
return 0;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 4e56baa..1437a6d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -153,6 +153,7 @@ struct c_can_priv {
struct can_priv can;/* must be the first member */
struct napi_struct napi;
struct net_device *dev;
+ struct device *device;
int tx_object;
int current_status;
int last_status;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0a66cf..197683b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pm_runtime.h
#include linux/can/dev.h
@@ -177,8 +178,11 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_enable(pdev-dev);
+
dev-irq = irq;
priv-base = addr;
+ priv-device = pdev-dev;
priv-can.clock.freq = clk_get_rate(clk);
priv-priv = clk;
@@ -198,6 +202,7 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
exit_free_device:
platform_set_drvdata(pdev, NULL);
+
RE: [PATCH] mfd: Fix allocation size of tps65217 platform data
Hi Matthias, Can you comment on my latest patch? So that I can fix this issue on the same. https://patchwork.kernel.org/patch/1220151/ Thanks AnilKumar On Thu, Aug 09, 2012 at 02:30:51, Matthias Kaehlcke wrote: tps65217_parse_dt() allocates a struct tps65217_board for each regulator specified in the device tree. the structure itself provides arrays for the pointers to the regulator init data and the regulator device tree node, so only one instance of it is needed This patch is based on the mfd tree Signed-off-by: Matthias Kaehlcke matth...@kaehlcke.net --- drivers/mfd/tps65217.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c index 61c097a..cf908ac 100644 --- a/drivers/mfd/tps65217.c +++ b/drivers/mfd/tps65217.c @@ -162,7 +162,7 @@ static struct tps65217_board *tps65217_parse_dt(struct i2c_client *client) return NULL; count = ret; - pdata = devm_kzalloc(client-dev, count * sizeof(*pdata), GFP_KERNEL); + pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL); if (!pdata) return NULL; -- 1.7.10 -- 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/regulator: tps65217: Move regulator plat data handling to regulator
Hi,
El Fri, Jul 20, 2012 at 03:00:01PM +0530 AnilKumar Ch ha dit:
Regulator platform data handling was mistakenly added to MFD
driver. So we will see build errors if we compile MFD drivers
without CONFIG_REGULATOR. This patch moves regulator platform
data handling from TPS65217 MFD driver to regulator driver.
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
index 6caa222..9730f1d 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
+static struct tps65217_board *tps65217_parse_dt(struct platform_device *pdev)
+{
+ struct tps65217 *tps = dev_get_drvdata(pdev-dev.parent);
+ struct device_node *node = tps-dev-of_node;
+ struct tps65217_board *pdata;
+ struct device_node *regs;
+ int i, count;
+
+ regs = of_find_node_by_name(node, regulators);
+ if (!regs)
+ return NULL;
+
+ count = of_regulator_match(pdev-dev.parent, regs,
+ reg_matches, TPS65217_NUM_REGULATOR);
+ of_node_put(regs);
+ if ((count 0) || (count TPS65217_NUM_REGULATOR))
+ return NULL;
+
+ pdata = devm_kzalloc(pdev-dev, count * sizeof(*pdata),
GFP_KERNEL);
this allocates a struct tps65217_board for each regulator specified in
the device tree. the structure itself provides arrays for the pointers
to the regulator init data and the regulator device tree node, so only
one instance of it is needed
also the tps65217_board structure should be renamed to something like
tps65217_regulators, now that it is specific to the regulator
driver. besides the regulators the tps65217 can have other subdevices,
so for the non device tree use case it makes sense to keep a chip wide
platform data structure around which contains the subdevice specific
ones
best regards
--
Matthias Kaehlcke
Embedded Linux Developer
Amsterdam
If you pay peanuts, you get monkeys
(James Goldsmith)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
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 0/4] Add device tree data for omap5
The following patch series add i2c support for omap5. As well as enable I2C based devices like pressure and temperature through device tree. Also add onchip keypad dts data. Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Sourav Poddar (4): arm/dts: omap5-evm: Add I2C support arm/dts: omap5-evm: Add tmp102 sensor support arm/dts: omap5-evm: Add keypad data arm/dts: omap5-evm: Add bmp085 sensor support arch/arm/boot/dts/omap5-evm.dts | 30 + arch/arm/boot/dts/omap5.dtsi| 40 +++ 2 files changed, 70 insertions(+), 0 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
[PATCHv2 1/4] arm/dts: omap5-evm: Add I2C support
Add I2C data node in omap5 device tree file.
Tested on omap5430 evm.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..6b68dfe 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -145,6 +145,41 @@
#interrupt-cells = 1;
};
+ i2c1: i2c@4807 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c1;
+ };
+
+ i2c2: i2c@48072000 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c2;
+ };
+
+ i2c3: i2c@4806 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c3;
+ };
+
+ i2c4: i2c@4807A000 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c4;
+ };
+
+ i2c5: i2c@4807C000 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c5;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
ti,hwmods = uart1;
--
1.7.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
[PATCH 4/4] arm/dts: omap5-evm: Add bmp085 sensor support
Add bmp085 pressure sensor data in omap5 evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c2ea189..18e499c 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -39,3 +39,12 @@
reg = 0x48;
};
};
+
+i2c2 {
+ clock-frequency = 40;
+
+ bmp085@77 {
+ compatible = bosch,bmp085;
+ reg = 0x77;
+ };
+};
--
1.7.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
[PATCHv2 2/4] arm/dts: omap5-evm: Add tmp102 sensor support
Add tmp102 temperature sensor data in omap5 evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 200c39a..45a8aeb 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -18,3 +18,12 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c4 {
+ clock-frequency = 40;
+
+ tmp102@48{
+ compatible = ti,tmp102;
+ reg = 0x48;
+ };
+};
--
1.7.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
[PATCH 3/4] arm/dts: omap5-evm: Add keypad data
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2
Add key names as comments
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..c2ea189 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073 /* VOLUP */
+ 0x02030072 /* VOLDOWM */
+ 0x020400e7 /* SEND */
+ 0x02050066 /* HOME */
+ 0x0206006b /* END */
+ 0x020700d9 ; /* SEARCH */
+ linux,input-no-autorepeat;
+ };
};
i2c4 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6b68dfe..c38b823 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -216,4 +216,9 @@
clock-frequency = 4800;
};
};
+
+ keypad {
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
--
1.7.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
[PATCHv2 3/4] arm/dts: omap5-evm: Add keypad data
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in omap5-evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2
Add key names as comments
arch/arm/boot/dts/omap5-evm.dts | 12
arch/arm/boot/dts/omap5.dtsi|5 +
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 45a8aeb..c2ea189 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -17,6 +17,18 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ keypad {
+ keypad,num-rows = 8;
+ keypad,num-columns = 8;
+ linux,keymap = 0x02020073 /* VOLUP */
+ 0x02030072 /* VOLDOWM */
+ 0x020400e7 /* SEND */
+ 0x02050066 /* HOME */
+ 0x0206006b /* END */
+ 0x020700d9 ; /* SEARCH */
+ linux,input-no-autorepeat;
+ };
};
i2c4 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6b68dfe..c38b823 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -216,4 +216,9 @@
clock-frequency = 4800;
};
};
+
+ keypad {
+ compatible = ti,omap4-keypad;
+ ti,hwmods = kbd;
+ };
};
--
1.7.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
[PATCHv2 4/4] arm/dts: omap5-evm: Add bmp085 sensor support
Add bmp085 pressure sensor data in omap5 evm dts file.
Tested on omap5430 evm with 3.5 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c2ea189..18e499c 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -39,3 +39,12 @@
reg = 0x48;
};
};
+
+i2c2 {
+ clock-frequency = 40;
+
+ bmp085@77 {
+ compatible = bosch,bmp085;
+ reg = 0x77;
+ };
+};
--
1.7.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
[PATCH 0/5] ARM: OMAP: Few device tree patches for 3.7
These are the few device tree related patches which has been posted and reviewed on the list. They are intended for 3.7 merge window but I am posting them early enough to get into linux-next and linux-omap for testing. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.7/omap_dt for you to fetch changes up to bedee5fcb18062dfc933e0971e67fd6889c6446d: ARM: OMAP4: Add local timer support for Device Tree (2012-08-13 11:59:26 +0530) Aneesh V (3): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards Santosh Shilimkar (2): ARM: OMAP4: Add L2 Cache Controller in Device Tree ARM: OMAP4: Add local timer support for Device Tree .../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++ .../devicetree/bindings/lpddr2/lpddr2.txt | 102 .../bindings/memory-controllers/ti/emif.txt| 55 +++ arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 + arch/arm/boot/dts/omap4-panda.dts | 13 +++ arch/arm/boot/dts/omap4-sdp.dts| 13 +++ arch/arm/boot/dts/omap4.dtsi | 31 ++ arch/arm/mach-omap2/omap4-common.c |6 +- arch/arm/mach-omap2/timer.c|6 ++ 9 files changed, 344 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi Aneesh V (3): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards Santosh Shilimkar (2): ARM: OMAP4: Add L2 Cache Controller in Device Tree ARM: OMAP4: Add local timer support for Device Tree .../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++ .../devicetree/bindings/lpddr2/lpddr2.txt | 102 .../bindings/memory-controllers/ti/emif.txt| 55 +++ arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 + arch/arm/boot/dts/omap4-panda.dts | 13 +++ arch/arm/boot/dts/omap4-sdp.dts| 13 +++ arch/arm/boot/dts/omap4.dtsi | 31 ++ arch/arm/mach-omap2/omap4-common.c |6 +- arch/arm/mach-omap2/timer.c|6 ++ 9 files changed, 344 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi -- 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
[PATCH 2/5] dt: emif: device tree bindings for TI's EMIF sdram controller
From: Aneesh V ane...@ti.com
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.6-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
.../bindings/memory-controllers/ti/emif.txt| 55
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 000..938f8e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -0,0 +1,55 @@
+* EMIF family of TI SDRAM controllers
+
+EMIF - External Memory Interface - is an SDRAM controller used in
+TI SoCs. EMIF supports, based on the IP revision, one or more of
+DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
+of the EMIF IP and memory parts attached to it.
+
+Required properties:
+- compatible : Should be of the form ti,emif-ip-rev where ip-rev
+ is the IP revision of the specific EMIF instance.
+
+- phy-type : u32 indicating the DDR phy type. Following are the
+ allowed values
+ 1 : Attila PHY
+ 2 : Intelli PHY
+
+- device-handle: phandle to a lpddr2 node representing the memory
part
+
+- ti,hwmods: For TI hwmods processing and omap device creation
+ the value shall be emifn where n is the number of the EMIF
+ instance with base 1.
+
+Optional properties:
+- cs1-used : Have this property if CS1 of this EMIF
+ instance has a memory part attached to it. If there is a memory
+ part attached to CS1, it should be the same type as the one on CS0,
+ so there is no need to give the details of this memory part.
+
+- cal-resistor-per-cs : Have this property if the board has one
+ calibration resistor per chip-select.
+
+- hw-caps-read-idle-ctrl: Have this property if the controller
+ supports read idle window programming
+
+- hw-caps-dll-calib-ctrl: Have this property if the controller
+ supports dll calibration control
+
+- hw-caps-ll-interface : Have this property if the controller
+ has a low latency interface and corresponding interrupt events
+
+- hw-caps-temp-alert : Have this property if the controller
+ has capability for generating SDRAM temperature alerts
+
+Example:
+
+emif1: emif@0x4c00 {
+ compatible = ti,emif-4d;
+ ti,hwmods = emif2;
+ phy-type= 1;
+ device-handle = elpida_ECB240ABACN;
+ cs1-used;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+};
--
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
[PATCH 3/5] ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards
From: Aneesh V ane...@ti.com
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.6-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 +
arch/arm/boot/dts/omap4-panda.dts | 13 ++
arch/arm/boot/dts/omap4-sdp.dts | 13 ++
arch/arm/boot/dts/omap4.dtsi | 18
4 files changed, 111 insertions(+)
create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
new file mode 100644
index 000..f97f70f
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common devices used in different OMAP boards
+ */
+
+/ {
+ elpida_ECB240ABACN: lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+
+ timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 1;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9880c12..80cd6cb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 PandaBoard;
@@ -56,6 +57,18 @@
AFML, Line In,
AFMR, Line In;
};
+
+ ocp {
+ emif1: emif@0x4c00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+
+ emif2: emif@0x4d00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 72216e9..b6f8ec2 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 SDP board;
@@ -113,6 +114,18 @@
DMic, Digital Mic,
Digital Mic, Digital Mic1 Bias;
};
[PATCH 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |7 +++
arch/arm/mach-omap2/omap4-common.c |6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6717c71..cf1efb6 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,13 @@
};
};
+ L2: l2-cache-controller {
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index c29dee9..6f95992 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -16,6 +16,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/memblock.h
+#include linux/of.h
#include asm/hardware/gic.h
#include asm/hardware/cache-l2x0.h
@@ -171,7 +172,10 @@ static int __init omap_l2_cache_init(void)
/* Enable PL310 L2 Cache controller */
omap_smc1(0x102, 0x1);
- l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
+ if (of_have_populated_dt())
+ l2x0_of_init(aux_ctrl, L2X0_AUX_CTRL_MASK);
+ else
+ l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
/*
* Override default outer_cache.disable with a OMAP4
--
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
[PATCH 5/5] ARM: OMAP4: Add local timer support for Device Tree
Add cortex-a9 local timer support for all OMAP4 based
SOCs using DT.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |6 ++
arch/arm/mach-omap2/timer.c |6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index cf1efb6..640d807 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -43,6 +43,12 @@
cache-level = 2;
};
+ local-timer {
+ compatible = arm,cortex-a9-twd-timer;
+ reg = 0x48240600 0x20;
+ interrupts = 1 13 0x304;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..31f9c93 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include linux/clocksource.h
#include linux/clockchips.h
#include linux/slab.h
+#include linux/of.h
#include asm/mach/time.h
#include plat/dmtimer.h
@@ -386,6 +387,11 @@ static void __init omap4_timer_init(void)
if (omap_rev() != OMAP4430_REV_ES1_0) {
int err;
+ if (of_have_populated_dt()) {
+ twd_local_timer_of_register();
+ return;
+ }
+
err = twd_local_timer_register(twd_local_timer);
if (err)
pr_err(twd_local_timer_register failed %d\n, err);
--
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
[PATCH 1/5] dt: device tree bindings for LPDDR2 memories
From: Aneesh V ane...@ti.com
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against 3.6-rc]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
.../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++
.../devicetree/bindings/lpddr2/lpddr2.txt | 102
2 files changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
new file mode 100644
index 000..9ceb19e
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
@@ -0,0 +1,52 @@
+* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin
+
+Required properties:
+- compatible : Should be jedec,lpddr2-timings
+- min-freq : minimum DDR clock frequency for the speed-bin. Type is u32
+- max-freq : maximum DDR clock frequency for the speed-bin. Type is u32
+
+Optional properties:
+
+The following properties represent AC timing parameters from the memory
+data-sheet of the device for a given speed-bin. All these properties are
+of type u32 and the default unit is ps (pico seconds). Parameters with
+a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
+- tRCD
+- tWR
+- tRAS-min
+- tRRD
+- tWTR
+- tXP
+- tRTP
+- tDQSCK-max
+- tFAW
+- tZQCS
+- tZQinit
+- tRPab
+- tZQCL
+- tCKESR
+- tRAS-max-ns
+- tDQSCK-max-derated
+
+Example:
+
+timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+};
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
new file mode 100644
index 000..58354a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
@@ -0,0 +1,102 @@
+* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
+
+Required properties:
+- compatible : Should be one of - jedec,lpddr2-nvm, jedec,lpddr2-s2,
+ jedec,lpddr2-s4
+
+ ti,jedec-lpddr2-s2 should be listed if the memory part is LPDDR2-S2 type
+
+ ti,jedec-lpddr2-s4 should be listed if the memory part is LPDDR2-S4 type
+
+ ti,jedec-lpddr2-nvm should be listed if the memory part is LPDDR2-NVM type
+
+- density : u32 representing density in Mb (Mega bits)
+
+- io-width : u32 representing bus width. Possible values are 8, 16, and 32
+
+Optional properties:
+
+The following optional properties represent the minimum value of some AC
+timing parameters of the DDR device in terms of number of clock cycles.
+These values shall be obtained from the device data-sheet.
+- tRRD-min-tck
+- tWTR-min-tck
+- tXP-min-tck
+- tRTP-min-tck
+- tCKE-min-tck
+- tRPab-min-tck
+- tRCD-min-tck
+- tWR-min-tck
+- tRASmin-min-tck
+- tCKESR-min-tck
+- tFAW-min-tck
+
+Child nodes:
+- The lpddr2 node may have one or more child nodes of type lpddr2-timings.
+ lpddr2-timings provides AC timing parameters of the device for
+ a given speed-bin. The user may provide the timings for as many
+ speed-bins as is required. Please see Documentation/devicetree/
+ bindings/lpddr2/lpddr2-timings.txt for more information on lpddr2-timings
+
+Example:
+
+elpida_ECB240ABACN : lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+
[PATCH 0/2] ARM: OMAP5: Enable local timer support
Below are the couple of patches which enables the architected cpu local timer support for OMAP5 devices. Santosh Shilimkar (2): ARM: OMAP: Add initialisation for the real-time counter. ARM: OMAP5: Enable arch timer support arch/arm/boot/dts/omap5.dtsi |6 +++ arch/arm/mach-omap2/Kconfig |5 +++ arch/arm/mach-omap2/timer.c | 96 +- 3 files changed, 106 insertions(+), 1 deletion(-) -- 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
[PATCH 2/2] ARM: OMAP5: Enable arch timer support
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |6 ++
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..9686056 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -73,6 +73,12 @@
0x48212000 0x1000;
};
+ arch-timer {
+ compatible = arm,armv7-timer;
+ interrupts = 1 14 0x304;
+ clock-frequency = 614;
+ };
+
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2120f90..53fb77c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,7 @@ config SOC_OMAP5
select ARM_GIC
select HAVE_SMP
select SOC_HAS_REALTIME_COUNTER
+ select ARM_ARCH_TIMER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 9b17e6c..f74dbb2 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,6 +41,7 @@
#include plat/dmtimer.h
#include asm/smp_twd.h
#include asm/sched_clock.h
+#include asm/arch_timer.h
#include common.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -480,9 +481,15 @@ OMAP_SYS_TIMER(4)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_timer_init(void)
{
+ int err;
+
omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
realtime_counter_init();
+
+ err = arch_timer_of_register();
+ if (err)
+ pr_err(%s: arch_timer_register failed %d\n, __func__, err);
}
OMAP_SYS_TIMER(5)
#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
[PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.
The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/timer.c | 89 ++-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..2120f90 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,6 +24,9 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool OMAP2 SDRAM Controller support
+config SOC_HAS_REALTIME_COUNTER
+ bool Real time free running counter
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
@@ -69,6 +72,7 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select SOC_HAS_REALTIME_COUNTER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..9b17e6c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,6 +69,11 @@
#define OMAP3_SECURE_TIMER 1
#endif
+#define REALTIME_COUNTER_BASE 0x48243200
+#define INCREMENTER_NUMERATOR_OFFSET 0x10
+#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
+#define NUMERATOR_DENUMERATOR_MASK 0xf000
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -339,6 +344,83 @@ static void __init omap2_clocksource_init(int gptimer_id,
omap2_gptimer_clocksource_init(gptimer_id, fck_source);
}
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+/*
+ * The realtime counter also called master counter, is a free-running
+ * counter, which is related to real time. It produces the count used
+ * by the CPU local timer peripherals in the MPU cluster. The timer counts
+ * at a rate of 6.144 MHz. Because the device operates on different clocks
+ * in different power modes, the master counter shifts operation between
+ * clocks, adjusting the increment per clock in hardware accordingly to
+ * maintain a constant count rate.
+ */
+static void __init realtime_counter_init(void)
+{
+ void __iomem *base;
+ static struct clk *sys_clk;
+ unsigned long rate;
+ unsigned int reg, num, den;
+
+ base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
+ if (!base) {
+ pr_err(%s: ioremap failed\n, __func__);
+ return;
+ }
+ sys_clk = clk_get(NULL, sys_clkin_ck);
+ if (!sys_clk) {
+ pr_err(%s: failed to get system clock handle\n, __func__);
+ return;
+ }
+
+ rate = clk_get_rate(sys_clk);
+ switch (rate) {
+ case 120:
+ num = 64;
+ den = 125;
+ break;
+ case 130:
+ num = 768;
+ den = 1625;
+ break;
+ case 1920:
+ num = 8;
+ den = 25;
+ break;
+ case 260:
+ num = 384;
+ den = 1625;
+ break;
+ case 270:
+ num = 256;
+ den = 1125;
+ break;
+ case 3840:
+ num = 4;
+ den = 25;
+ break;
+ default:
+ /* Program it for 38.4 MHz */
+ num = 4;
+ den = 25;
+ break;
+ }
+
+ /* Program numerator and denumerator registers */
+ reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET)
+ NUMERATOR_DENUMERATOR_MASK;
+ reg |= num;
+ __raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
+
+ reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET)
+ NUMERATOR_DENUMERATOR_MASK;
+ reg |= den;
+ __raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+}
+#else
+static inline void __init realtime_counter_init(void)
+{}
+#endif
+
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, \
clksrc_nr, clksrc_src) \
static void __init omap##name##_timer_init(void) \
@@ -396,7 +478,12 @@ OMAP_SYS_TIMER(4)
#endif
#ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_TIMER_INIT(5, 1, OMAP4_CLKEV_SOURCE, 2, OMAP4_MPU_SOURCE)
+static void __init omap5_timer_init(void)
+{
+ omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
+ omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
+ realtime_counter_init();
+}
OMAP_SYS_TIMER(5)
#endif
--
1.7.9.5
--
To
Re: [PATCHv2 0/4] Add device tree data for omap5
Sourav, On Mon, Aug 13, 2012 at 3:35 PM, Sourav Poddar sourav.pod...@ti.com wrote: The following patch series add i2c support for omap5. As well as enable I2C based devices like pressure and temperature through device tree. Also add onchip keypad dts data. Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Sourav Poddar (4): arm/dts: omap5-evm: Add I2C support arm/dts: omap5-evm: Add tmp102 sensor support arm/dts: omap5-evm: Add keypad data arm/dts: omap5-evm: Add bmp085 sensor support arch/arm/boot/dts/omap5-evm.dts | 30 + arch/arm/boot/dts/omap5.dtsi| 40 +++ 2 files changed, 70 insertions(+), 0 deletions(-) The entire series looks fine to me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.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
[PATCH 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 428 +--
1 file changed, 273 insertions(+), 155 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5b289c5..11ca3f9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -81,6 +81,23 @@ struct dispc_irq_stats {
unsigned irqs[32];
};
+struct dispc_features {
+ int hp_max;
+ int vp_max;
+ int sw_max;
+ int sw_start;
+ int fp_start;
+ int bp_start;
+ int (*calc_scaling) (enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk);
+ unsigned long (*calc_core_clk) (enum omap_channel channel,
+ u16 width, u16 height, u16 out_width, u16 out_height);
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -101,6 +118,8 @@ static struct {
boolctx_valid;
u32 ctx[DISPC_SZ_REGS / sizeof(u32)];
+ const struct dispc_features *feat;
+
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
spinlock_t irq_stats_lock;
struct dispc_irq_stats irq_stats;
@@ -1939,7 +1958,18 @@ static unsigned long calc_core_clk_five_taps(enum
omap_channel channel,
return core_clk;
}
-static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
+static unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (height out_height width out_width)
+ return pclk * 4;
+ else
+ return pclk * 2;
+}
+
+static unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height)
{
unsigned int hf, vf;
@@ -1958,25 +1988,163 @@ static unsigned long calc_core_clk(enum omap_channel
channel, u16 width,
hf = 2;
else
hf = 1;
-
if (height out_height)
vf = 2;
else
vf = 1;
- if (cpu_is_omap24xx()) {
- if (vf 1 hf 1)
- return pclk * 4;
- else
- return pclk * 2;
- } else if (cpu_is_omap34xx()) {
- return pclk * vf * hf;
- } else {
- if (hf 1)
- return DIV_ROUND_UP(pclk, out_width) * width;
- else
- return pclk;
+ return pclk * vf * hf;
+}
+
+static unsigned long calc_core_clk_44xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (width out_width)
+ return DIV_ROUND_UP(pclk, out_width) * width;
+ else
+ return pclk;
+}
+
+static int dispc_ovl_calc_scaling_24xx(enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk)
+{
+ int error;
+ u16 in_width, in_height;
+ int min_factor = min(*decim_x, *decim_y);
+ const int maxsinglelinewidth =
+ dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ *five_taps = false;
+
+ do {
+ in_height = DIV_ROUND_UP(height, *decim_y);
+ in_width = DIV_ROUND_UP(width, *decim_x);
+ *core_clk = dispc.feat-calc_core_clk(channel, in_width,
+ in_height, out_width, out_height);
+ error = (in_width maxsinglelinewidth || !*core_clk ||
+ *core_clk dispc_core_clk_rate());
+ if (error) {
+ if (*decim_x == *decim_y) {
+ *decim_x = min_factor;
+ ++*decim_y;
+ } else {
+ swap(*decim_x, *decim_y);
+ if (*decim_x *decim_y)
+ ++*decim_x;
+ }
+ }
+
[PATCH 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dss.c | 115 ++---
1 file changed, 74 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 7b1c6ac..6ab236e 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -31,6 +31,7 @@
#include linux/clk.h
#include linux/platform_device.h
#include linux/pm_runtime.h
+#include linux/dma-mapping.h
#include video/omapdss.h
@@ -65,6 +66,13 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+struct dss_features {
+ u16 fck_div_max;
+ int factor;
+ char *clk_name;
+ bool (*check_cinfo_fck) (void);
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -83,6 +91,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_features *feat;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -91,6 +101,30 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_FCK] = DSS_FCK,
};
+static const struct __initdata dss_features omap2_dss_features = {
+ .fck_div_max= 16,
+ .factor = 2,
+ .clk_name = NULL,
+};
+
+static const struct __initdata dss_features omap34_dss_features = {
+ .fck_div_max= 16,
+ .factor = 2,
+ .clk_name = dpll4_m4_ck,
+};
+
+static const struct __initdata dss_features omap36_dss_features = {
+ .fck_div_max= 32,
+ .factor = 1,
+ .clk_name = dpll4_m4_ck,
+};
+
+static const struct __initdata dss_features omap4_dss_features = {
+ .fck_div_max= 32,
+ .factor = 1,
+ .clk_name = dpll_per_m5x2_ck,
+};
+
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -236,7 +270,6 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
-
void dss_dump_clocks(struct seq_file *s)
{
unsigned long dpll4_ck_rate;
@@ -259,18 +292,10 @@ void dss_dump_clocks(struct seq_file *s)
seq_printf(s, dpll4_ck %lu\n, dpll4_ck_rate);
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- seq_printf(s, %s (%s) = %lu / %lu = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
- else
- seq_printf(s, %s (%s) = %lu / %lu * 2 = %lu\n,
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
+ seq_printf(s, %s (%s) = %lu / %lu * %d = %lu\n,
+ fclk_name, fclk_real_name, dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate,
+ dss.feat-factor, fclk_rate);
} else {
seq_printf(s, %s (%s) = %lu\n,
fclk_name, fclk_real_name,
@@ -470,7 +495,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
unsigned long fck, max_dss_fck;
- u16 fck_div, fck_div_max = 16;
+ u16 fck_div;
int match = 0;
int min_fck_per_pck;
@@ -480,9 +505,8 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck
- ((cpu_is_omap34xx() prate == dss.cache_prate) ||
-dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck prate == dss.cache_prate
+ dss.cache_dss_cinfo.fck == fck) {
DSSDBG(dispc clock info found from cache.\n);
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
@@ -519,16 +543,10 @@ retry:
goto found;
}
Re: [PATCH v6] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
On 08/13/2012 08:49 AM, AnilKumar Ch wrote:
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good, minor style suggestion inline.
Marc
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
This patch is based on can-next/master
Changes from v5:
- Incorporated Marc's commets on v5
* changed runtime pm calls in c_can driver to handle
the drivers which are not using platform drivers.
* added device pointer protection in c_can driver if
not passed from platform/pci driver.
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 25 -
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c |6 ++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 4c538e3..64344b8 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,8 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
^
Is this still needed?
#include linux/can.h
#include linux/can/dev.h
@@ -201,6 +203,18 @@ static const struct can_bittiming_const
c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline void c_can_pm_runtime_get_sync(struct device *dev)
Use priv as parameter, not dev.
+{
+ if (dev)
+ pm_runtime_get_sync(dev);
+}
+
+static inline void c_can_pm_runtime_put_sync(struct device *dev)
dito
+{
+ if (dev)
+ pm_runtime_put_sync(dev);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -673,11 +687,15 @@ static int c_can_get_berr_counter(const struct
net_device *dev,
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
reg_err_counter = priv-read_reg(priv, C_CAN_ERR_CNT_REG);
bec-rxerr = (reg_err_counter ERR_CNT_REC_MASK)
ERR_CNT_REC_SHIFT;
bec-txerr = reg_err_counter ERR_CNT_TEC_MASK;
+ c_can_pm_runtime_put_sync(priv-device);
+
return 0;
}
@@ -1053,11 +1071,13 @@ static int c_can_open(struct net_device *dev)
int err;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
/* open the can device */
err = open_candev(dev);
if (err) {
netdev_err(dev, failed to open can device\n);
- return err;
+ goto exit_open_fail;
}
/* register interrupt handler */
@@ -1079,6 +1099,8 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
+exit_open_fail:
+ c_can_pm_runtime_put_sync(priv-device);
return err;
}
@@ -1091,6 +1113,7 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+ c_can_pm_runtime_put_sync(priv-device);
return 0;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 4e56baa..1437a6d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -153,6 +153,7 @@ struct c_can_priv {
struct can_priv can;/* must be the first member */
struct napi_struct napi;
struct net_device *dev;
+ struct device *device;
int tx_object;
int current_status;
int last_status;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0a66cf..197683b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pm_runtime.h
#include linux/can/dev.h
@@ -177,8 +178,11 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_enable(pdev-dev);
+
dev-irq = irq;
priv-base = addr;
+ priv-device = pdev-dev;
ELM module support in OMAP?
Hi, I am planning to support BCH8 error correction using ELM module in AM33xx. Please let me know if any work or plan is there to support ELM module in OMAP? Thanks Avinash Philip -- 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 V4 0/5] ARM: OMAP: HOST: TLL driver implementation
On Fri, Jul 27, 2012 at 5:44 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 8:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 7:38 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 23, 2012 at 07:31:10PM +0530, Munegowda, Keshava wrote: On Thu, Jul 19, 2012 at 3:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 Felipe/ Paul please let me know if you have any review comments on this v4 series. regards keshava Hi Felipe please let me know if you have any review comments on this series now. looks ok... pretty much just moving code around. -- balbi Thanks Felipe then I request please give your Ack by for this series. regards keshava Hi Paul do you have any review comments on this series? Felipe is OK with this series. if there are no review comments on this series I request your ack by for the same. Once this series gets in to mainline. i will start the Device tree conversion for usb2 host. regards keshava Hi Felipe please give you ack by this series , so that I request samuel to merge to mainline. regards keshava -- 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] omap: dmtimers: Fix locking issue in omap_dm_timer_request*()
* Timo Kokkonen timo.t.kokko...@iki.fi [120812 03:46]: Calling omap_dm_timer_prepare while the spinlock is held is not allowed as sleeping functions are called later on during the preparation (namely within clk_get()). dm_timer_lock is only required for protecting the omap_timer_list. After the timer is marked as reserved, the lock is no longer needed and should be freed. Thanks applying into fixes. 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/regulator: tps65217: Move regulator plat data handling to regulator
Hi Matthias,
On Mon, Aug 13, 2012 at 13:57:32, Matthias Kaehlcke wrote:
Hi,
El Fri, Jul 20, 2012 at 03:00:01PM +0530 AnilKumar Ch ha dit:
Regulator platform data handling was mistakenly added to MFD
driver. So we will see build errors if we compile MFD drivers
without CONFIG_REGULATOR. This patch moves regulator platform
data handling from TPS65217 MFD driver to regulator driver.
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
index 6caa222..9730f1d 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
+static struct tps65217_board *tps65217_parse_dt(struct platform_device
*pdev)
+{
+ struct tps65217 *tps = dev_get_drvdata(pdev-dev.parent);
+ struct device_node *node = tps-dev-of_node;
+ struct tps65217_board *pdata;
+ struct device_node *regs;
+ int i, count;
+
+ regs = of_find_node_by_name(node, regulators);
+ if (!regs)
+ return NULL;
+
+ count = of_regulator_match(pdev-dev.parent, regs,
+ reg_matches, TPS65217_NUM_REGULATOR);
+ of_node_put(regs);
+ if ((count 0) || (count TPS65217_NUM_REGULATOR))
+ return NULL;
+
+ pdata = devm_kzalloc(pdev-dev, count * sizeof(*pdata),
GFP_KERNEL);
this allocates a struct tps65217_board for each regulator specified in
the device tree. the structure itself provides arrays for the pointers
to the regulator init data and the regulator device tree node, so only
one instance of it is needed
Agree, I will fix that issue in my next version of patch
also the tps65217_board structure should be renamed to something like
tps65217_regulators, now that it is specific to the regulator
Not required because tps65217_board might contain platform data for WLED/
Battery charger driver if require. So the struct was named as tps65217_board
Regards
AnilKumar
--
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 v6] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Hi Marc,
Thanks for the review.
On Mon, Aug 13, 2012 at 17:40:22, Marc Kleine-Budde wrote:
On 08/13/2012 08:49 AM, AnilKumar Ch wrote:
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
Looks good, minor style suggestion inline.
Marc
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
This patch is based on can-next/master
Changes from v5:
- Incorporated Marc's commets on v5
* changed runtime pm calls in c_can driver to handle
the drivers which are not using platform drivers.
* added device pointer protection in c_can driver if
not passed from platform/pci driver.
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/net/can/c_can/c_can.c | 25 -
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c |6 ++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 4c538e3..64344b8 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,8 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
^
Is this still needed?
Not required, missed out while cleaning and now it's removed.
#include linux/can.h
#include linux/can/dev.h
@@ -201,6 +203,18 @@ static const struct can_bittiming_const
c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline void c_can_pm_runtime_get_sync(struct device *dev)
Use priv as parameter, not dev.
done
+{
+ if (dev)
+ pm_runtime_get_sync(dev);
+}
+
+static inline void c_can_pm_runtime_put_sync(struct device *dev)
ditto
done, I will send updated version.
Thanks
AnilKumar
--
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 v7] can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
This patch has been tested on AM335X EVM. Due to lack of hardware
I am not able to test c_can functionality. I appreciate if anyone
can test c_can functionality with this patch.
This patch is based on can-next/master
Changes from v6:
- Incorporated Marc's commets on v6
* changed dev pointer to priv
* removed platform_device.h include from c_can.c
Changes from v5:
- Incorporated Marc's commets on v5
* changed runtime pm calls in c_can driver to handle
the drivers which are not using platform drivers.
* added device pointer protection in c_can driver if
not passed from platform/pci driver.
Changes from v4:
- Incorporated Vaibhav H review comments on v4.
* Moved pm_runtime put/get_sync calls to appropriate positions.
- This patch is from Add DT support to C_CAN/D_CAN controller
patch series. Rest of the patches in this series were applied
so this v5 contains only this patch.
drivers/net/can/c_can/c_can.c | 24 +++-
drivers/net/can/c_can/c_can.h |1 +
drivers/net/can/c_can/c_can_platform.c |6 ++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 4c538e3..8174d43 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -34,6 +34,7 @@
#include linux/if_ether.h
#include linux/list.h
#include linux/io.h
+#include linux/pm_runtime.h
#include linux/can.h
#include linux/can/dev.h
@@ -201,6 +202,18 @@ static const struct can_bittiming_const
c_can_bittiming_const = {
.brp_inc = 1,
};
+static inline void c_can_pm_runtime_get_sync(struct device *priv)
+{
+ if (priv)
+ pm_runtime_get_sync(priv);
+}
+
+static inline void c_can_pm_runtime_put_sync(struct device *priv)
+{
+ if (priv)
+ pm_runtime_put_sync(priv);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv-tx_next C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -673,11 +686,15 @@ static int c_can_get_berr_counter(const struct net_device
*dev,
unsigned int reg_err_counter;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
reg_err_counter = priv-read_reg(priv, C_CAN_ERR_CNT_REG);
bec-rxerr = (reg_err_counter ERR_CNT_REC_MASK)
ERR_CNT_REC_SHIFT;
bec-txerr = reg_err_counter ERR_CNT_TEC_MASK;
+ c_can_pm_runtime_put_sync(priv-device);
+
return 0;
}
@@ -1053,11 +1070,13 @@ static int c_can_open(struct net_device *dev)
int err;
struct c_can_priv *priv = netdev_priv(dev);
+ c_can_pm_runtime_get_sync(priv-device);
+
/* open the can device */
err = open_candev(dev);
if (err) {
netdev_err(dev, failed to open can device\n);
- return err;
+ goto exit_open_fail;
}
/* register interrupt handler */
@@ -1079,6 +1098,8 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
+exit_open_fail:
+ c_can_pm_runtime_put_sync(priv-device);
return err;
}
@@ -1091,6 +1112,7 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+ c_can_pm_runtime_put_sync(priv-device);
return 0;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 4e56baa..1437a6d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -153,6 +153,7 @@ struct c_can_priv {
struct can_priv can;/* must be the first member */
struct napi_struct napi;
struct net_device *dev;
+ struct device *device;
int tx_object;
int current_status;
int last_status;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index d0a66cf..197683b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pm_runtime.h
#include linux/can/dev.h
@@ -177,8 +178,11 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
goto exit_free_device;
}
+ pm_runtime_enable(pdev-dev);
+
dev-irq = irq;
priv-base = addr;
+ priv-device = pdev-dev;
priv-can.clock.freq = clk_get_rate(clk);
priv-priv = clk;
@@ -198,6 +202,7 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
Re: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
On Mon, Aug 13, 2012 at 06:52:13PM +0530, Munegowda, Keshava wrote: On Fri, Jul 27, 2012 at 5:44 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 8:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 7:38 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 23, 2012 at 07:31:10PM +0530, Munegowda, Keshava wrote: On Thu, Jul 19, 2012 at 3:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 Felipe/ Paul please let me know if you have any review comments on this v4 series. regards keshava Hi Felipe please let me know if you have any review comments on this series now. looks ok... pretty much just moving code around. -- balbi Thanks Felipe then I request please give your Ack by for this series. regards keshava Hi Paul do you have any review comments on this series? Felipe is OK with this series. if there are no review comments on this series I request your ack by for the same. Once this series gets in to mainline. i will start the Device tree conversion for usb2 host. regards keshava Hi Felipe please give you ack by this series , so that I request samuel to merge to mainline. sure, here you go Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCH v2 1/9] ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver
Move the McBSP CLKS re-parenting code to ASoC driver from
arch/arm/mach-omap2.
The call fort the re-parenting has been already limited to OMAP2+ SoC in
the ASoC driver. There is no longer need to have callback function for it.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/mcbsp.c | 40 ---
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
sound/soc/omap/mcbsp.c | 31
3 files changed, 26 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 577cb77..ebc801e 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -101,45 +101,6 @@ static int omap4_mcbsp4_mux_rx_clk(struct device *dev,
const char *signal,
return 0;
}
-/* McBSP CLKS source switching function */
-static int omap2_mcbsp_set_clk_src(struct device *dev, struct clk *clk,
- const char *src)
-{
- struct clk *fck_src;
- char *fck_src_name;
- int r;
-
- if (!strcmp(src, clks_ext))
- fck_src_name = pad_fck;
- else if (!strcmp(src, clks_fclk))
- fck_src_name = prcm_fck;
- else
- return -EINVAL;
-
- fck_src = clk_get(dev, fck_src_name);
- if (IS_ERR_OR_NULL(fck_src)) {
- pr_err(omap-mcbsp: %s: could not clk_get() %s\n, clks,
- fck_src_name);
- return -EINVAL;
- }
-
- pm_runtime_put_sync(dev);
-
- r = clk_set_parent(clk, fck_src);
- if (IS_ERR_VALUE(r)) {
- pr_err(omap-mcbsp: %s: could not clk_set_parent() to %s\n,
- clks, fck_src_name);
- clk_put(fck_src);
- return -EINVAL;
- }
-
- pm_runtime_get_sync(dev);
-
- clk_put(fck_src);
-
- return 0;
-}
-
static int omap3_enable_st_clock(unsigned int id, bool enable)
{
unsigned int w;
@@ -181,7 +142,6 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
pdata-reg_size = 4;
pdata-has_ccr = true;
}
- pdata-set_clk_src = omap2_mcbsp_set_clk_src;
/* On OMAP2/3 the McBSP1 port has 6 pin configuration */
if (id == 1 oh-class-rev MCBSP_CONFIG_TYPE4)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 1881412..0a7d5ca 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -47,7 +47,6 @@ struct omap_mcbsp_platform_data {
bool has_wakeup; /* Wakeup capability */
bool has_ccr; /* Transceiver has configuration control registers */
int (*enable_st_clock)(unsigned int, bool);
- int (*set_clk_src)(struct device *dev, struct clk *clk, const char
*src);
int (*mux_signal)(struct device *dev, const char *signal, const char
*src);
};
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index d33c48b..d901fc0 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -24,6 +24,7 @@
#include linux/delay.h
#include linux/io.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include plat/mcbsp.h
@@ -726,19 +727,39 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx,
int rx)
int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id)
{
+ struct clk *fck_src;
const char *src;
+ int r;
if (fck_src_id == MCBSP_CLKS_PAD_SRC)
- src = clks_ext;
+ src = pad_fck;
else if (fck_src_id == MCBSP_CLKS_PRCM_SRC)
- src = clks_fclk;
+ src = prcm_fck;
else
return -EINVAL;
- if (mcbsp-pdata-set_clk_src)
- return mcbsp-pdata-set_clk_src(mcbsp-dev, mcbsp-fclk, src);
- else
+ fck_src = clk_get(mcbsp-dev, src);
+ if (IS_ERR_OR_NULL(fck_src)) {
+ dev_err(mcbsp-dev, CLKS: could not clk_get() %s\n, src);
return -EINVAL;
+ }
+
+ pm_runtime_put_sync(mcbsp-dev);
+
+ r = clk_set_parent(mcbsp-fclk, fck_src);
+ if (r) {
+ dev_err(mcbsp-dev, CLKS: could not clk_set_parent() to %s\n,
+ src);
+ clk_put(fck_src);
+ return r;
+ }
+
+ pm_runtime_get_sync(mcbsp-dev);
+
+ clk_put(fck_src);
+
+ return 0;
+
}
int omap_mcbsp_6pin_src_mux(struct omap_mcbsp *mcbsp, u8 mux)
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] ARM/ASoC: OMAP McBSP device tree support
Hello, Changes since v1: - ICLK workaround for the sidetone module has been kept for legacy mode. Intro mail ffrom v1 (updated): in order to be able to add DT support for the McBSP driver which is used on all OMAP platforms (OMAP1/2/3/4/5) I needed to make some cleanups to the stack: - Removing callbacks used by the driver for - clock re-parenting (code moved to sound driver) - FSR/CLKR mux configuration (from now on it need to be done at board level) This mux is board specific and depends on the wiring. - Replaced the cpu_is_omap* checks with future proof check. - The FIFO was not enabled on OMAP2430 SoC It has been tested on BeagleBoard (with legacy and DT boot). The series changes McBSP related files mostly. It would be great if the whole series could go via audio tree (if the patches are OK and it is fine by Tony). For DT booted kernel on OMAP3 proper ICLK woraround need to be implemented. At the moment I don't see this as a stopper since we can not properly boot OMAP3 devices (especially rx51 which is using the ST). Other OMAP revisions does not have ST block so the missing workaround is not going to hurt them. I'm working on a solution which can replace the current workaround with a generic implementation to support DT and non DT booted kernels. Regards, Peter --- Peter Ujfalusi (9): ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430 ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code ASoC: omap-mcbsp: Remove unused defines ASoC: omap-mcbsp: Remove cpu_is_omap* checks from the code ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data ASoC: omap-mcbsp: Add device tree bindings .../devicetree/bindings/sound/omap-mcbsp.txt | 45 +++ arch/arm/mach-omap2/board-am3517evm.c | 13 ++ arch/arm/mach-omap2/mcbsp.c| 126 +-- arch/arm/plat-omap/include/plat/mcbsp.h|2 - sound/soc/omap/am3517evm.c | 20 +--- sound/soc/omap/mcbsp.c | 54 - sound/soc/omap/mcbsp.h |3 - sound/soc/omap/omap-mcbsp.c| 106 +++- sound/soc/omap/omap-mcbsp.h| 20 --- 9 files changed, 162 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/omap-mcbsp.txt -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] ARM: OMAP: mcbsp: Enable FIFO use for OMAP2430
On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
the FIFO for the audio stack.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/mcbsp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index ebc801e..6e046e1 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -151,7 +151,10 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
if (id == 4 oh-class-rev == MCBSP_CONFIG_TYPE4)
pdata-mux_signal = omap4_mcbsp4_mux_rx_clk;
- if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
+ if (oh-class-rev == MCBSP_CONFIG_TYPE2) {
+ /* The FIFO has 128 locations */
+ pdata-buffer_size = 0x80;
+ } else if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
/* The FIFO has 1024 + 256 locations */
pdata-buffer_size = 0x500;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/9] ASoC: am3517evm: Do not configure McBSP1 CLKR/FSR signal muxing
The muxing is done at board level, no need to do it in the ASoC machine
driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
sound/soc/omap/am3517evm.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index 009533a..a997988 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -47,26 +47,10 @@ static int am3517evm_hw_params(struct snd_pcm_substream
*substream,
/* Set the codec system clock for DAC and ADC */
ret = snd_soc_dai_set_sysclk(codec_dai, 0,
CODEC_CLOCK, SND_SOC_CLOCK_IN);
- if (ret 0) {
+ if (ret 0)
printk(KERN_ERR can't set codec system clock\n);
- return ret;
- }
-
- ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
- SND_SOC_CLOCK_IN);
- if (ret 0) {
- printk(KERN_ERR can't set CPU system clock
OMAP_MCBSP_CLKR_SRC_CLKX\n);
- return ret;
- }
- snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
- SND_SOC_CLOCK_IN);
- if (ret 0) {
- printk(KERN_ERR can't set CPU system clock
OMAP_MCBSP_FSR_SRC_FSX\n);
- return ret;
- }
-
- return 0;
+ return ret;
}
static struct snd_soc_ops am3517evm_ops = {
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/9] ASoC: omap-mcbsp: Remove unused defines
NUM_LINKS is no longer in use by the code.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
sound/soc/omap/omap-mcbsp.h | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index baebcee..ba8386a 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -39,22 +39,6 @@ enum omap_mcbsp_div {
OMAP_MCBSP_CLKGDV, /* Sample rate generator divider */
};
-#if defined(CONFIG_SOC_OMAP2420)
-#define NUM_LINKS 2
-#endif
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-#undef NUM_LINKS
-#define NUM_LINKS 3
-#endif
-#if defined(CONFIG_ARCH_OMAP4)
-#undef NUM_LINKS
-#define NUM_LINKS 4
-#endif
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_OMAP2430)
-#undef NUM_LINKS
-#define NUM_LINKS 5
-#endif
-
int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime *rtd);
#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] ASoC: omap-mcbsp: Remove cpu_is_omap* checks from the code
We can use the has_ccr flag to replace the cpu_is_omap* checks.
This provides future proof implementation and we do not need to update the
code if new OMAP revision starts to use the McBSP driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
sound/soc/omap/omap-mcbsp.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 5061594..b9770ee 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -398,12 +398,14 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
/* Generic McBSP register settings */
regs-spcr2 |= XINTM(3) | FREE;
regs-spcr1 |= RINTM(3);
- /* RFIG and XFIG are not defined in 34xx */
- if (!cpu_is_omap34xx() !cpu_is_omap44xx()) {
+ /* RFIG and XFIG are not defined in 2430 and on OMAP3+ */
+ if (!mcbsp-pdata-has_ccr) {
regs-rcr2 |= RFIG;
regs-xcr2 |= XFIG;
}
- if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
+
+ /* Configure XCCR/RCCR only for revisions which have ccr registers */
+ if (mcbsp-pdata-has_ccr) {
regs-xccr = DXENDLY(1) | XDMAEN | XDISABLE;
regs-rccr = RFULL_CYCLE | RDMAEN | RDISABLE;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] ARM: OMAP2+: McBSP: Do not create legacy devices when booting with DT data
Only create the devices in a legacy way if we do not have the DT data.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/mcbsp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 660e00b..d57a357 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -15,6 +15,7 @@
#include linux/clk.h
#include linux/err.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/slab.h
@@ -113,7 +114,8 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
static int __init omap2_mcbsp_init(void)
{
- omap_hwmod_for_each_by_class(mcbsp, omap_init_mcbsp, NULL);
+ if (!of_have_populated_dt())
+ omap_hwmod_for_each_by_class(mcbsp, omap_init_mcbsp, NULL);
return 0;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 9/9] ASoC: omap-mcbsp: Add device tree bindings
Device tree support for McBSP modules on OMAP2+ SoC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../devicetree/bindings/sound/omap-mcbsp.txt | 45 +
sound/soc/omap/omap-mcbsp.c| 66 +++-
2 files changed, 110 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/omap-mcbsp.txt
diff --git a/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
new file mode 100644
index 000..447cb13
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
@@ -0,0 +1,45 @@
+* Texas Instruments OMAP2+ McBSP module
+
+Required properties:
+- compatible: ti,omap2420-mcbsp for McBSP on OMAP2420
+ ti,omap2430-mcbsp for McBSP on OMAP2430
+ ti,omap3-mcbsp for McBSP on OMAP3
+ ti,omap4-mcbsp for McBSP on OMAP4 and newer SoC
+- reg: Register location and size, for OMAP4+ as an array:
+ MPU access base address, size,
+ L3 interconnect address, size;
+- interrupts: Interrupt numbers for the McBSP port, as an array in case the
+ McBSP IP have more interrupt lines:
+ OCP compliant irq,
+ TX irq,
+ RX irq;
+- interrupt-parent: The parent interrupt controller
+- ti,buffer-size: Size of the FIFO on the port (OMAP2430 and newer SoC)
+- ti,hwmods: Name of the hwmod associated to the McBSP port
+
+Sidetone support for OMAP3 McBSP2 and 3 ports:
+- sidetone { }: Within this section the following parameters are required:
+- reg: Register location and size for the ST block
+- interrupts: The interrupt number for the ST block
+- interrupt-parent: The parent interrupt controller for the ST block
+
+Example:
+
+mcbsp2: mcbsp@49022000 {
+ compatible = ti,omap3-mcbsp;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x49022000 0xff;
+ interrupts = 0 17 0x4, /* OCP compliant interrup */
+0 62 0x4, /* TX interrup */
+0 63 0x4; /* RX interrup */
+ interrupt-parent = intc;
+ ti,buffer-size = 1280;
+ ti,hwmods = mcbsp2;
+
+ sidetone {
+ reg = 0x49028000 0xff;
+ interrupts = 0 4 0x4;
+ interrupt-parent = intc;
+ };
+};
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index b9770ee..2e1750e 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -26,6 +26,8 @@
#include linux/module.h
#include linux/device.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
#include sound/core.h
#include sound/pcm.h
#include sound/pcm_params.h
@@ -737,13 +739,74 @@ int omap_mcbsp_st_add_controls(struct snd_soc_pcm_runtime
*rtd)
}
EXPORT_SYMBOL_GPL(omap_mcbsp_st_add_controls);
+static struct omap_mcbsp_platform_data omap2420_pdata = {
+ .reg_step = 4,
+ .reg_size = 2,
+};
+
+static struct omap_mcbsp_platform_data omap2430_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+};
+
+static struct omap_mcbsp_platform_data omap3_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+ .has_wakeup = true,
+};
+
+static struct omap_mcbsp_platform_data omap4_pdata = {
+ .reg_step = 4,
+ .reg_size = 4,
+ .has_ccr = true,
+ .has_wakeup = true,
+};
+
+static const struct of_device_id omap_mcbsp_of_match[] = {
+ {
+ .compatible = ti,omap2420-mcbsp,
+ .data = omap2420_pdata,
+ },
+ {
+ .compatible = ti,omap2430-mcbsp,
+ .data = omap2430_pdata,
+ },
+ {
+ .compatible = ti,omap3-mcbsp,
+ .data = omap3_pdata,
+ },
+ {
+ .compatible = ti,omap4-mcbsp,
+ .data = omap4_pdata,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, omap_mcbsp_of_match);
+
static __devinit int asoc_mcbsp_probe(struct platform_device *pdev)
{
struct omap_mcbsp_platform_data *pdata = dev_get_platdata(pdev-dev);
struct omap_mcbsp *mcbsp;
+ const struct of_device_id *match;
int ret;
- if (!pdata) {
+ match = of_match_device(omap_mcbsp_of_match, pdev-dev);
+ if (match) {
+ struct device_node *node = pdev-dev.of_node;
+ int buffer_size;
+
+ pdata = devm_kzalloc(pdev-dev,
+sizeof(struct omap_mcbsp_platform_data),
+GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ memcpy(pdata, match-data, sizeof(*pdata));
+ if (!of_property_read_u32(node, ti,buffer-size, buffer_size))
+ pdata-buffer_size = buffer_size;
+ } else if (!pdata) {
dev_err(pdev-dev, missing platform data.\n);
return -EINVAL;
}
@@ -785,6
[PATCH v2 3/9] ARM: OMAP: board-am3517evm: Configure McBSP1 CLKR/FSR signal source
am3517evm board uses McBSP1 for audio with 4pin configuration.
The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
this case.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 18f6010..592812a 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -264,6 +264,16 @@ static __init void am3517_evm_musb_init(void)
usb_musb_init(musb_board_data);
}
+static __init void am3517_evm_mcbsp1_init(void)
+{
+ u32 devconf0;
+
+ /* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */
+ devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+ devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
+ omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
+}
+
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -373,6 +383,9 @@ static void __init am3517_evm_init(void)
/* MUSB */
am3517_evm_musb_init();
+ /* McBSP1 */
+ am3517_evm_mcbsp1_init();
+
/* MMC init function */
omap_hsmmc_init(mmc);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/9] ARM/ASoC: omap-mcbsp: Remove CLKR/FSR mux configuration code
Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
configuration.
When moving to devicetree these callback can no longer be used in a clean
way anymore.
If a board require to change the 6pin port to work in 4pin setup it needs
to set up the mux in the board file.
For OMAP2/3:
u32 devconf0;
/* McBSP1 CLKR/FSR signal to be connected to CLKX/FSX pin */
devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
For OMAP4:
u32 mcbsp_pad;
/* McBSP4 CLKR/FSR signal to be connected to CLKX/FSX pin */
mcbsp_pad = omap4_ctrl_pad_readl(OMAP2_CONTROL_DEVCONF0);
mcbsp_pad |= ((1 31) | (1 30));
omap4_ctrl_pad_writel(mcbsp_pad, OMAP2_CONTROL_DEVCONF0);
In case when the kernel is booted with DT blob the pinctrl-single will be
provided as soon as it is enabled on the platform.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap2/mcbsp.c | 77 ---
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
sound/soc/omap/mcbsp.c | 31
sound/soc/omap/mcbsp.h |3 -
sound/soc/omap/omap-mcbsp.c | 32 +
sound/soc/omap/omap-mcbsp.h |4 --
6 files changed, 3 insertions(+), 145 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 6e046e1..660e00b 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -25,8 +25,6 @@
#include plat/omap_device.h
#include linux/pm_runtime.h
-#include control.h
-
/*
* FIXME: Find a mechanism to enable/disable runtime the McBSP ICLK autoidle.
* Sidetone needs non-gated ICLK and sidetone autoidle is broken.
@@ -34,73 +32,6 @@
#include cm2xxx_3xxx.h
#include cm-regbits-34xx.h
-/* McBSP1 internal signal muxing function for OMAP2/3 */
-static int omap2_mcbsp1_mux_rx_clk(struct device *dev, const char *signal,
- const char *src)
-{
- u32 v;
-
- v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
-
- if (!strcmp(signal, clkr)) {
- if (!strcmp(src, clkr))
- v = ~OMAP2_MCBSP1_CLKR_MASK;
- else if (!strcmp(src, clkx))
- v |= OMAP2_MCBSP1_CLKR_MASK;
- else
- return -EINVAL;
- } else if (!strcmp(signal, fsr)) {
- if (!strcmp(src, fsr))
- v = ~OMAP2_MCBSP1_FSR_MASK;
- else if (!strcmp(src, fsx))
- v |= OMAP2_MCBSP1_FSR_MASK;
- else
- return -EINVAL;
- } else {
- return -EINVAL;
- }
-
- omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
-
- return 0;
-}
-
-/* McBSP4 internal signal muxing function for OMAP4 */
-#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX(1 31)
-#define OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX (1 30)
-static int omap4_mcbsp4_mux_rx_clk(struct device *dev, const char *signal,
- const char *src)
-{
- u32 v;
-
- /*
-* In CONTROL_MCBSPLP register only bit 30 (CLKR mux), and bit 31 (FSR
-* mux) is used */
- v = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
-
- if (!strcmp(signal, clkr)) {
- if (!strcmp(src, clkr))
- v = ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
- else if (!strcmp(src, clkx))
- v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_CLKX;
- else
- return -EINVAL;
- } else if (!strcmp(signal, fsr)) {
- if (!strcmp(src, fsr))
- v = ~OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
- else if (!strcmp(src, fsx))
- v |= OMAP4_CONTROL_MCBSPLP_ALBCTRLRX_FSX;
- else
- return -EINVAL;
- } else {
- return -EINVAL;
- }
-
- omap4_ctrl_pad_writel(v, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP);
-
- return 0;
-}
-
static int omap3_enable_st_clock(unsigned int id, bool enable)
{
unsigned int w;
@@ -143,14 +74,6 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
pdata-has_ccr = true;
}
- /* On OMAP2/3 the McBSP1 port has 6 pin configuration */
- if (id == 1 oh-class-rev MCBSP_CONFIG_TYPE4)
- pdata-mux_signal = omap2_mcbsp1_mux_rx_clk;
-
- /* On OMAP4 the McBSP4 port has 6 pin configuration */
- if (id == 4 oh-class-rev == MCBSP_CONFIG_TYPE4)
- pdata-mux_signal = omap4_mcbsp4_mux_rx_clk;
-
if (oh-class-rev == MCBSP_CONFIG_TYPE2) {
/* The FIFO has 128 locations */
pdata-buffer_size = 0x80;
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
Re: Infinite looping in omap2430.c USB driver
Hi,
On Mon, Aug 13, 2012 at 12:34:53PM +1000, NeilBrown wrote:
On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi ba...@ti.com wrote:
hehe, that's nasty. Please send a patch converting to a try count and a
udelay_range(), or something.
how's this?
Thanks,
NeilBrown
From: NeilBrown ne...@suse.de
Date: Mon, 13 Aug 2012 12:32:58 +1000
Subject: [PATCH] omap2430: don't loop indefinitely in interrupt.
When called during resume_irqs, omap2430_musb_set_vbus() is run with
interrupts disabled, In that case 'jiffies' never changes so the loop
can loop forever.
So impose a maximum loop count and add an 'mdelay' to ensure we wait
a reasonable amount of time for bit to be cleared.
This fixes a hang on resume.
Signed-of-by: NeilBrown ne...@suse.de
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index c7785e8..8a93381 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -34,6 +34,7 @@
#include linux/dma-mapping.h
#include linux/pm_runtime.h
#include linux/err.h
+#include linux/delay.h
#include musb_core.h
#include omap2430.h
@@ -145,6 +146,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
if (is_on) {
if (musb-xceiv-state == OTG_STATE_A_IDLE) {
+ int loops = 100;
/* start the session */
devctl |= MUSB_DEVCTL_SESSION;
musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
@@ -154,9 +156,11 @@ static void omap2430_musb_set_vbus(struct musb *musb,
int is_on)
*/
while (musb_readb(musb-mregs, MUSB_DEVCTL) 0x80) {
+ mdelay(5);
I would prefer udelay_range() as it will let scheduler group timers.
Something like:
udelay_range(3000, 5000);
should do, I gues...
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
On Mon, Aug 13, 2012 at 7:39 PM, Felipe Balbi ba...@ti.com wrote: On Mon, Aug 13, 2012 at 06:52:13PM +0530, Munegowda, Keshava wrote: On Fri, Jul 27, 2012 at 5:44 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 8:04 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 23, 2012 at 7:38 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 23, 2012 at 07:31:10PM +0530, Munegowda, Keshava wrote: On Thu, Jul 19, 2012 at 3:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 31 ++- arch/arm/plat-omap/include/plat/usb.h |7 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 238 ++--- drivers/mfd/omap-usb-tll.c| 471 + 8 files changed, 523 insertions(+), 240 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- 1.7.9.5 Felipe/ Paul please let me know if you have any review comments on this v4 series. regards keshava Hi Felipe please let me know if you have any review comments on this series now. looks ok... pretty much just moving code around. -- balbi Thanks Felipe then I request please give your Ack by for this series. regards keshava Hi Paul do you have any review comments on this series? Felipe is OK with this series. if there are no review comments on this series I request your ack by for the same. Once this series gets in to mainline. i will start the Device tree conversion for usb2 host. regards keshava Hi Felipe please give you ack by this series , so that I request samuel to merge to mainline. sure, here you go Acked-by: Felipe Balbi ba...@ti.com -- balbi Thanks Felipe Samuel I request please queue this series for the next merge window. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mfd/regulator: tps65217: Move regulator plat data handling to regulator
Regulator platform data handling was mistakenly added to MFD
driver. So we will see build errors if we compile MFD drivers
without CONFIG_REGULATOR. This patch moves regulator platform
data handling from TPS65217 MFD driver to regulator driver.
This makes MFD driver independent of REGULATOR framework so
build error is fixed if CONFIG_REGULATOR is not set.
drivers/built-in.o: In function `tps65217_probe':
tps65217.c:(.devinit.text+0x13e37): undefined reference
to `of_regulator_match'
This patch also fix allocation size of tps65217 platform data.
Current implementation allocates a struct tps65217_board for each
regulator specified in the device tree. But the structure itself
provides array of regulators so one instance of it is sufficient.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
This patch is tested on BeagleBone with regulator device node
additions. And this is based on mfd/master.
Changes from v1:
- Incorporated Matthias Kaehlcke's commets on v1
* Fixed allocation size of tps65217 platform data
drivers/mfd/tps65217.c | 130 +++-
drivers/regulator/tps65217-regulator.c | 124 ++
include/linux/mfd/tps65217.h | 12 ++-
3 files changed, 161 insertions(+), 105 deletions(-)
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 61c097a..3bc2744 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -24,11 +24,18 @@
#include linux/slab.h
#include linux/regmap.h
#include linux/err.h
-#include linux/regulator/of_regulator.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/core.h
#include linux/mfd/tps65217.h
+static struct mfd_cell tps65217s[] = {
+ {
+ .name = tps65217-pmic,
+ },
+};
+
/**
* tps65217_reg_read: Read a single tps65217 register.
*
@@ -133,83 +140,48 @@ int tps65217_clear_bits(struct tps65217 *tps, unsigned
int reg,
}
EXPORT_SYMBOL_GPL(tps65217_clear_bits);
-#ifdef CONFIG_OF
-static struct of_regulator_match reg_matches[] = {
- { .name = dcdc1, .driver_data = (void *)TPS65217_DCDC_1 },
- { .name = dcdc2, .driver_data = (void *)TPS65217_DCDC_2 },
- { .name = dcdc3, .driver_data = (void *)TPS65217_DCDC_3 },
- { .name = ldo1, .driver_data = (void *)TPS65217_LDO_1 },
- { .name = ldo2, .driver_data = (void *)TPS65217_LDO_2 },
- { .name = ldo3, .driver_data = (void *)TPS65217_LDO_3 },
- { .name = ldo4, .driver_data = (void *)TPS65217_LDO_4 },
-};
-
-static struct tps65217_board *tps65217_parse_dt(struct i2c_client *client)
-{
- struct device_node *node = client-dev.of_node;
- struct tps65217_board *pdata;
- struct device_node *regs;
- int count = ARRAY_SIZE(reg_matches);
- int ret, i;
-
- regs = of_find_node_by_name(node, regulators);
- if (!regs)
- return NULL;
-
- ret = of_regulator_match(client-dev, regs, reg_matches, count);
- of_node_put(regs);
- if ((ret 0) || (ret count))
- return NULL;
-
- count = ret;
- pdata = devm_kzalloc(client-dev, count * sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return NULL;
-
- for (i = 0; i count; i++) {
- if (!reg_matches[i].init_data || !reg_matches[i].of_node)
- continue;
-
- pdata-tps65217_init_data[i] = reg_matches[i].init_data;
- pdata-of_node[i] = reg_matches[i].of_node;
- }
-
- return pdata;
-}
-
-static struct of_device_id tps65217_of_match[] = {
- { .compatible = ti,tps65217, },
- { },
-};
-#else
-static struct tps65217_board *tps65217_parse_dt(struct i2c_client *client)
-{
- return NULL;
-}
-#endif
-
static struct regmap_config tps65217_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
};
+static const struct of_device_id tps65217_of_match[] = {
+ { .compatible = ti,tps65217, .data = (void *)TPS65217 },
+ { /* sentinel */ },
+};
+
static int __devinit tps65217_probe(struct i2c_client *client,
const struct i2c_device_id *ids)
{
struct tps65217 *tps;
- struct regulator_init_data *reg_data;
- struct tps65217_board *pdata = client-dev.platform_data;
- int i, ret;
unsigned int version;
+ unsigned int chip_id = ids-driver_data;
+ const struct of_device_id *match;
+ int ret;
- if (!pdata client-dev.of_node)
- pdata = tps65217_parse_dt(client);
+ if (client-dev.of_node) {
+ match = of_match_device(tps65217_of_match, client-dev);
+ if (!match) {
+ dev_err(client-dev,
+ Failed to find matching dt id\n);
+ return -EINVAL;
+ }
+ chip_id = (unsigned int)match-data;
+ }
+
+ if (!chip_id) {
+ dev_err(client-dev,
Re: [PATCH v2] mfd/regulator: tps65217: Move regulator plat data handling to regulator
On Mon, Aug 13, 2012 at 08:36:05PM +0530, AnilKumar Ch wrote: Regulator platform data handling was mistakenly added to MFD driver. So we will see build errors if we compile MFD drivers without CONFIG_REGULATOR. This patch moves regulator platform data handling from TPS65217 MFD driver to regulator driver. This makes MFD driver independent of REGULATOR framework so build error is fixed if CONFIG_REGULATOR is not set. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This patch also fix allocation size of tps65217 platform data. Current implementation allocates a struct tps65217_board for each regulator specified in the device tree. But the structure itself provides array of regulators so one instance of it is sufficient. Signed-off-by: AnilKumar Ch anilku...@ti.com --- This patch is tested on BeagleBone with regulator device node additions. And this is based on mfd/master. formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- 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/9] ARM/ASoC: omap-mcbsp: Move OMAP2+ clock parenting code to ASoC driver
On Mon, Aug 13, 2012 at 05:22:40PM +0300, Peter Ujfalusi wrote:
+ fck_src = clk_get(mcbsp-dev, src);
+ if (IS_ERR_OR_NULL(fck_src)) {
I know the same error is in the original code, but let's stop propagating
it. IS_ERR() only here please.
--
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: OMAP: Add initialisation for the real-time counter.
On 8/13/2012 4:37 PM, Santosh Shilimkar wrote:
The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.
The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/timer.c | 89
++-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..2120f90 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,6 +24,9 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool OMAP2 SDRAM Controller support
+config SOC_HAS_REALTIME_COUNTER
+ bool Real time free running counter
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
@@ -69,6 +72,7 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select SOC_HAS_REALTIME_COUNTER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..9b17e6c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,6 +69,11 @@
#define OMAP3_SECURE_TIMER 1
#endif
+#define REALTIME_COUNTER_BASE0x48243200
+#define INCREMENTER_NUMERATOR_OFFSET 0x10
+#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET0x14
+#define NUMERATOR_DENUMERATOR_MASK 0xf000
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -339,6 +344,83 @@ static void __init omap2_clocksource_init(int gptimer_id,
omap2_gptimer_clocksource_init(gptimer_id, fck_source);
}
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+/*
+ * The realtime counter also called master counter, is a free-running
+ * counter, which is related to real time. It produces the count used
+ * by the CPU local timer peripherals in the MPU cluster. The timer counts
+ * at a rate of 6.144 MHz. Because the device operates on different clocks
+ * in different power modes, the master counter shifts operation between
+ * clocks, adjusting the increment per clock in hardware accordingly to
+ * maintain a constant count rate.
+ */
+static void __init realtime_counter_init(void)
+{
+ void __iomem *base;
+ static struct clk *sys_clk;
+ unsigned long rate;
+ unsigned int reg, num, den;
+
+ base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
+ if (!base) {
+ pr_err(%s: ioremap failed\n, __func__);
+ return;
+ }
+ sys_clk = clk_get(NULL, sys_clkin_ck);
+ if (!sys_clk) {
+ pr_err(%s: failed to get system clock handle\n, __func__);
+ return;
Don't want to unmap the ioremap'ed space?
+ }
+
+ rate = clk_get_rate(sys_clk);
+ switch (rate) {
+ case 120:
+ num = 64;
+ den = 125;
+ break;
+ case 130:
+ num = 768;
+ den = 1625;
+ break;
+ case 1920:
+ num = 8;
+ den = 25;
+ break;
+ case 260:
+ num = 384;
+ den = 1625;
+ break;
+ case 270:
+ num = 256;
+ den = 1125;
+ break;
+ case 3840:
+ num = 4;
+ den = 25;
+ break;
+ default:
+ /* Program it for 38.4 MHz */
+ num = 4;
+ den = 25;
+ break;
You can simply do something like,
case 3840:
/* Program it for 38.4 MHz */
default:
num = 4;
den = 25;
break;
Also, suggest to mention about why 38.4MHz as default? I believe it is
reset value, right?
Also, does it make sense to get rid of hardcoded values above?
Thanks,
Vaibhav
+ }
+
+ /* Program numerator and denumerator registers */
+ reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET)
+ NUMERATOR_DENUMERATOR_MASK;
+ reg |= num;
+ __raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
+
+ reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET)
+ NUMERATOR_DENUMERATOR_MASK;
+ reg |= den;
+ __raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
+}
+#else
+static inline void __init realtime_counter_init(void)
+{}
+#endif
+
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,
\
clksrc_nr, clksrc_src)
Re: [PATCHv2 0/2] Add Nokia N900 (RX51) IR diode support
Hi, On 08/10/12 13:16, Timo Kokkonen wrote: These patches add the support for sending IR remote controller codes on the Nokia N900 phone. The code is taken from the public N900 kernel release and modified to work with today's kernel. The code has been tested with a real Nokia N900 device and confirmed to work. I can identify only one known issue; The IR pulses being sent become *veeery* long if the device chooses to go into any sleep modes during transmitting the IR pulses. The driver makes an attempt to set up PM latency constraints, but apparently those don't apply as there is currently only no-op PM layer available. Therefore, I guess this driver doesn't actually work properly unless there is some background load that prevents the device from enterint sleep modes or the sleep modes are disabled altogether. However, once a proper PM layer implementation becomes available, I expect this problem to resolve itself. The same code used to work with the actual N900 kernel that has those implemented. Any comments regarding the patches are welcome. I guess media list won't take in omap patches and omap list doesn't take media patches. So I wrote the patches so that they can be applied independently. If you want me to remove the #ifdef hacks from the board file (that is needed to break the build dependency between the patches), then the ir-rx51.c patch needs to be applied before the board file patch. But I though it would be more flexible this way. I'm open to suggestions on how you are willing to accept the patches. --- Changes since v1: - Move ir-rx51.h into include/media directory Any comments on these? Anything still missing before you can consider accepting these? Thanks! -Timo Timo Kokkonen (2): media: rc: Introduce RX51 IR transmitter driver ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile|1 + drivers/media/rc/ir-rx51.c | 496 ++ include/media/ir-rx51.h | 10 + 5 files changed, 547 insertions(+), 0 deletions(-) create mode 100644 drivers/media/rc/ir-rx51.c create mode 100644 include/media/ir-rx51.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: debug needed: twl4030 RTC wakeups: repeated attempts fail on Beagle
NeilBrown ne...@suse.de writes: On Fri, 10 Aug 2012 11:49:27 -0700 Kevin Hilman khil...@ti.com wrote: Hello, In doing some automated testing of suspend/resume I noticed that repeated attempts to suspend and resume via RTC wakeup fail on 3530/Beagle and 3730/Beagle-xM, but work fine on 3430/n900, 3530/Overo, 3730/OveroSTORM and 4430/Panda. When RTC wakeup fails, a UART wakeup will work, and in the logs, you'll see this: [ 316.036132] twl: i2c_read failed to transfer all messages [ 316.036163] twl4030: I2C error -13 reading PIH ISR My guess about what might be happening is that very late in the suspend process (during the noirq hooks), a PMIC interrupt fires, but by this time the I2C driver is runtime suspended (and clock gated.) Since runtime PM is disabled at this point, I2C reads fail, so the twl4030 IRQ driver cannot talk over I2C to the PMIC to determine the interrupt source. This area seems to be rife with opportunity for bugs. I wrote about some of it here: https://lwn.net/Articles/482345/ Yeah, that was a great article. I don't know that I saw quite what you are seeing though. If a PMIC interrupt fires during the noirq phase, the interrupt handler shouldn't be run (it isn't marked NOSUSPEND). However there is probably room for a race between the 'suspend' phase and the 'noirq' phase. When the suspend processing handles the I2C device, the last thing that __device_suspend does is __pm_runtime_disable(dev, false); which will freeze the current runtime_pm state of the I2C device. If it is off, it stays off. If on, it stays on. Correct. As the noirq phase hasn't been entered yet an interrupt from the PMIC could still be handled. If it is, you get exactly the error you see. Right, this is what I suspect is happening. I just haven't had the time to confirm and/or fix. I'm not convinced that the __pm_runtime_disable call is correct. It think we need to stop async runtime_suspends, but we don't need to stop sync runtime_resumes. So just a pm_runtime_get should be enough. But there is possibly an important point I am missing. Yes, I went back and forth with Rafael on the interactions between system PM and runtime PM and he pursuaded me that there were a handful of reasons that system PM needed to block runtime PM transitions. I don't recall what they are at the moment (my brain is already being pre-flushed in preparation for some time off.) However if my analysis is correct, then this can be 'fixed' by changing the omap i2c suspend routine to do a pm_runtime_get, and the resume routine to do a pm_runtime_put. The I2C will still be put to sleep during suspend by the noirq suspend handler, but we will be sure of it being awake during the crucial suspend and resume transition. Hmm, that's a good idea. Hopefully someone can give it a try before I get back from vacation. :) Thanks for the suggestion. See also https://lwn.net/Articles/505683/. Particularly (towards the end) If the device might be needed to power down other devices, such as an I2C controller that might be needed to tell some regulator to turn off, then the device should be activated for runtime PM purposes so that it will still be active when runtime PM is disabled. (Rafael reviewed this article so it shouldn't be very far from the mark). The real mystery is why this happens on Beagle and Beagle-xM, but none of the other OMAP3 boards (at least the ones I have.) Maybe didn't components of the PMIC are active and have the potential to generate an interrupt at an awkward time. USB and battery chargers seem good at that. Or maybe due to the particular components active and the particular timing, the pm_runtime_disable ends up freezing the runtime_pm state in 'on' rather than 'off'. Reproducing is easy. Simply run rtcwake in a loop: # while true; do rtcwake -m mem -s 1; done In my tests, this happens using omap2plus_defconfig (+ initramfs) on v3.6-rc1, v3.5, v3.4, v3.3 but seems to work fine on v3.2. I'm going on vacation for a few weeks, so any help debugging this would be greatly appreciated. Enjoy your vacation! I don't suppose it ends up in San Diego in late August for one of the multitude of conferences there? No, I'll miss the summer conferences this year, this vacation will be unplugged. 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: [PATCHv2 1/2] media: rc: Introduce RX51 IR transmitter driver
On Fri, Aug 10, 2012 at 01:16:36PM +0300, Timo Kokkonen wrote:
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt to the changes that has happen in the kernel during the past
five years, such as the change in the include paths
- The OMAP DM-timers require much more care nowadays. The timers need
to be enabled and disabled or otherwise many actions fail. Timers
must not be freed without first stopping them or otherwise the timer
cannot be requested again.
The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-rx51.c | 496
include/media/ir-rx51.h| 10 +
4 files changed, 517 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/ir-rx51.c
create mode 100644 include/media/ir-rx51.h
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 5180390..ab35d2e 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -270,6 +270,16 @@ config IR_IGUANA
To compile this driver as a module, choose M here: the module will
be called iguanair.
+config IR_RX51
+ tristate Nokia N900 IR transmitter diode
+ depends on MACH_NOKIA_RX51 OMAP_DM_TIMER
+ ---help---
+Say Y or M here if you want to enable support for the IR
+transmitter diode built in the Nokia N900 (RX51) device.
+
+The driver uses omap DM timers for gereating the carrier
+wave and pulses.
+
config RC_LOOPBACK
tristate Remote Control Loopback Driver
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f871d19..d384f30 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
+obj-$(CONFIG_IR_RX51) += ir-rx51.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
new file mode 100644
index 000..9487dd3
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.c
@@ -0,0 +1,496 @@
+/*
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Based on lirc_serial.c
+ *
+ * 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
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/uaccess.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/wait.h
+
+#include plat/dmtimer.h
+#include plat/clock.h
+#include plat/omap-pm.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+#include media/ir-rx51.h
+
+#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE |\
+LIRC_CAN_SET_SEND_CARRIER | \
+LIRC_CAN_SEND_PULSE)
+
+#define DRIVER_NAME lirc_rx51
+
+#define WBUF_LEN 256
+
+#define TIMER_MAX_VALUE 0x
+
+struct lirc_rx51 {
+ struct omap_dm_timer *pwm_timer;
+ struct omap_dm_timer *pulse_timer;
+ struct device*dev;
+ struct lirc_rx51_platform_data *pdata;
+ wait_queue_head_t wqueue;
+
+ unsigned long fclk_khz;
+ unsigned intfreq; /* carrier frequency */
+ unsigned intduty_cycle; /* carrier duty cycle */
+ unsigned intirq_num;
+ unsigned intmatch;
+ int wbuf[WBUF_LEN];
+ int wbuf_index;
+ unsigned long device_is_open;
+ unsigned intpwm_timer_num;
+};
+
+static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
+{
+ omap_dm_timer_set_pwm(lirc_rx51-pwm_timer, 0, 1,
+
Re: [PATCHv2 1/2] media: rc: Introduce RX51 IR transmitter driver
On 08/13/12 21:36, Sean Young wrote:
On Fri, Aug 10, 2012 at 01:16:36PM +0300, Timo Kokkonen wrote:
+static ssize_t lirc_rx51_write(struct file *file, const char *buf,
+ size_t n, loff_t *ppos)
+{
+int count, i;
+struct lirc_rx51 *lirc_rx51 = file-private_data;
+
+if (n % sizeof(int))
+return -EINVAL;
+
+count = n / sizeof(int);
+if ((count WBUF_LEN) || (count % 2 == 0))
+return -EINVAL;
+
+/* Wait any pending transfers to finish */
+wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
If a signal arrives then this could return ERESTARTSYS and the condition
might not have evaluated to true.
hmm.. The whole point of it is to wait if for any possibly pending
transfers to finish. However, we don't allow the device to be opened
more than once and parallel access doesn't make much sense here anyway.
Only way we can end up waiting here is that the process is having
multiple threads writing to the same file descriptor (or has inherited
it from its parent), which doesn't make any sense.
I think we could simply return -EBUSY in case previous transfer is still
going on. I don't see any reason why we should wait here.
+
+if (copy_from_user(lirc_rx51-wbuf, buf, n))
+return -EFAULT;
+
+/* Sanity check the input pulses */
+for (i = 0; i count; i++)
+if (lirc_rx51-wbuf[i] 0)
+return -EINVAL;
+
+init_timing_params(lirc_rx51);
+if (count WBUF_LEN)
+lirc_rx51-wbuf[count] = -1; /* Insert termination mark */
+
+/*
+ * Adjust latency requirements so the device doesn't go in too
+ * deep sleep states
+ */
+lirc_rx51-pdata-set_max_mpu_wakeup_lat(lirc_rx51-dev, 50);
+
+lirc_rx51_on(lirc_rx51);
+lirc_rx51-wbuf_index = 1;
+pulse_timer_set_timeout(lirc_rx51, lirc_rx51-wbuf[0]);
+
+/*
+ * Don't return back to the userspace until the transfer has
+ * finished
+ */
+wait_event_interruptible(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0);
same here.
BTW so the semantics for lirc write() are that they complete when the
data has been transmitted. This doesn't play well with signals, polling
or non-blocking I/O. Is this deliberate or historical?
I guess a lirc write() handler should ignore signals completely.
I'll change it to wait_event_timeout instead.
+
+struct platform_driver lirc_rx51_platform_driver = {
+.probe = lirc_rx51_probe,
+.remove = __exit_p(lirc_rx51_remove),
+.suspend= lirc_rx51_suspend,
+.resume = lirc_rx51_resume,
+.remove = __exit_p(lirc_rx51_remove),
.remove is here twice.
hehe.. I remember I was supposed to write a patch for that five years
ago but I was busy :) Thanks for your review. Will send round three.
-Timo
--
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/regulator: tps65217: Move regulator plat data handling to regulator
Hi AnilKumar, El Mon, Aug 13, 2012 at 01:35:55PM + AnilKumar, Chimata ha dit: also the tps65217_board structure should be renamed to something like tps65217_regulators, now that it is specific to the regulator Not required because tps65217_board might contain platform data for WLED/ Battery charger driver if require. So the struct was named as tps65217_board the patch moves the allocation of the structure to the regulator driver, so either it should be a subdevice specific structure or a chip specific one which is allocated in the mfd driver. otherwise the regulator driver will allocate memory which is never used when struct tps65217_board is extended for other subdevices. and the same would happen in the other subdevice drivers if they choose to allocate their own struct tps65217_board instead of a sub-structure with just the fields needed by the specific driver regards -- Matthias Kaehlcke Embedded Linux Developer Amsterdam Yo soy como soy y tú eres como eres, construyamos un mundo donde yo pueda ser sin dejar de ser yo, donde tú puedas ser sin dejar de ser tú, y donde ni yo ni tú obliguemos al otro a ser como yo o como tú .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[git:v4l-dvb/for_v3.7] [media] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
Author: Timo Kokkonen timo.t.kokko...@iki.fi
Date:Fri Aug 10 06:16:37 2012 -0300
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=322c183cdc5f041d0f6a25fe519c7836649a6c8b
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..ca07264 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -46,6 +47,10 @@
#include ../drivers/staging/iio/light/tsl2563.h
#include linux/lis3lv02d.h
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include media/ir-rx51.h
+#endif
+
#include mux.h
#include hsmmc.h
#include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+ .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+ .pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+ .name = lirc_rx51,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_lirc_data,
+ },
+};
+
+static void __init rx51_init_lirc(void)
+{
+ platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+ rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] media: rc: Introduce RX51 IR transmitter driver
Author: Timo Kokkonen timo.t.kokko...@iki.fi
Date:Fri Aug 10 06:16:36 2012 -0300
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt to the changes that has happen in the kernel during the past
five years, such as the change in the include paths
- The OMAP DM-timers require much more care nowadays. The timers need
to be enabled and disabled or otherwise many actions fail. Timers
must not be freed without first stopping them or otherwise the timer
cannot be requested again.
The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: Sakari Ailus sakari.ai...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-rx51.c | 496
include/media/ir-rx51.h| 10 +
4 files changed, 517 insertions(+), 0 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 64be610..016f9ab 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -287,6 +287,16 @@ config IR_TTUSBIR
To compile this driver as a module, choose M here: the module will
be called ttusbir.
+config IR_RX51
+ tristate Nokia N900 IR transmitter diode
+ depends on MACH_NOKIA_RX51 OMAP_DM_TIMER
+ ---help---
+ Say Y or M here if you want to enable support for the IR
+ transmitter diode built in the Nokia N900 (RX51) device.
+
+ The driver uses omap DM timers for gereating the carrier
+ wave and pulses.
+
config RC_LOOPBACK
tristate Remote Control Loopback Driver
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 66c8bae..56bacf0 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
+obj-$(CONFIG_IR_RX51) += ir-rx51.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
new file mode 100644
index 000..9487dd3
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.c
@@ -0,0 +1,496 @@
+/*
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Based on lirc_serial.c
+ *
+ * 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
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/uaccess.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/wait.h
+
+#include plat/dmtimer.h
+#include plat/clock.h
+#include plat/omap-pm.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+#include media/ir-rx51.h
+
+#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE | \
+ LIRC_CAN_SET_SEND_CARRIER | \
+ LIRC_CAN_SEND_PULSE)
+
+#define DRIVER_NAME lirc_rx51
+
+#define WBUF_LEN 256
+
+#define TIMER_MAX_VALUE 0x
+
+struct lirc_rx51 {
+ struct omap_dm_timer *pwm_timer;
+ struct omap_dm_timer *pulse_timer;
+ struct device*dev;
+ struct lirc_rx51_platform_data *pdata;
+ wait_queue_head_t wqueue;
+
+ unsigned long fclk_khz;
+ unsigned intfreq; /* carrier frequency */
+ unsigned intduty_cycle; /* carrier duty cycle */
+ unsigned intirq_num;
+ unsigned
Re: Infinite looping in omap2430.c USB driver
On Mon, 13 Aug 2012 17:32:34 +0300 Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Aug 13, 2012 at 12:34:53PM +1000, NeilBrown wrote:
On Thu, 9 Aug 2012 14:15:51 +0300 Felipe Balbi ba...@ti.com wrote:
hehe, that's nasty. Please send a patch converting to a try count and a
udelay_range(), or something.
how's this?
Thanks,
NeilBrown
From: NeilBrown ne...@suse.de
Date: Mon, 13 Aug 2012 12:32:58 +1000
Subject: [PATCH] omap2430: don't loop indefinitely in interrupt.
When called during resume_irqs, omap2430_musb_set_vbus() is run with
interrupts disabled, In that case 'jiffies' never changes so the loop
can loop forever.
So impose a maximum loop count and add an 'mdelay' to ensure we wait
a reasonable amount of time for bit to be cleared.
This fixes a hang on resume.
Signed-of-by: NeilBrown ne...@suse.de
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index c7785e8..8a93381 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -34,6 +34,7 @@
#include linux/dma-mapping.h
#include linux/pm_runtime.h
#include linux/err.h
+#include linux/delay.h
#include musb_core.h
#include omap2430.h
@@ -145,6 +146,7 @@ static void omap2430_musb_set_vbus(struct musb *musb,
int is_on)
if (is_on) {
if (musb-xceiv-state == OTG_STATE_A_IDLE) {
+ int loops = 100;
/* start the session */
devctl |= MUSB_DEVCTL_SESSION;
musb_writeb(musb-mregs, MUSB_DEVCTL, devctl);
@@ -154,9 +156,11 @@ static void omap2430_musb_set_vbus(struct musb *musb,
int is_on)
*/
while (musb_readb(musb-mregs, MUSB_DEVCTL) 0x80) {
+ mdelay(5);
I would prefer udelay_range() as it will let scheduler group timers.
Something like:
udelay_range(3000, 5000);
should do, I gues...
Except that there is no udelay_range :-(
There is a usleep_range, but that can only be used from non-atomic context
and in the problem case interrupts are disabled and a spinlock is held so we
very definitely are not in non-atomic context. If we need a delay at all, it
has to be udelay or mdelay.
If we could do this in a work function rather than directly from the
interrupt handler that would be best but I have no idea what dependencies
there are.. Would it be safe for musb_stage0_irq() to ask a workqueue to run
musb_platform_set_vbus rather than doing it directly?
NeilBrown
signature.asc
Description: PGP signature
RE: [PATCH v2] mfd/regulator: tps65217: Move regulator plat data handling to regulator
Hi Greg, On Mon, Aug 13, 2012 at 20:53:54, Greg KH wrote: On Mon, Aug 13, 2012 at 08:36:05PM +0530, AnilKumar Ch wrote: Regulator platform data handling was mistakenly added to MFD driver. So we will see build errors if we compile MFD drivers without CONFIG_REGULATOR. This patch moves regulator platform data handling from TPS65217 MFD driver to regulator driver. This makes MFD driver independent of REGULATOR framework so build error is fixed if CONFIG_REGULATOR is not set. drivers/built-in.o: In function `tps65217_probe': tps65217.c:(.devinit.text+0x13e37): undefined reference to `of_regulator_match' This patch also fix allocation size of tps65217 platform data. Current implementation allocates a struct tps65217_board for each regulator specified in the device tree. But the structure itself provides array of regulators so one instance of it is sufficient. Signed-off-by: AnilKumar Ch anilku...@ti.com --- This patch is tested on BeagleBone with regulator device node additions. And this is based on mfd/master. formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. My bad, I will take care from next time onwards. Thanks AnilKumar -- 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
