Re: [PATCH V4 2/2] arm: dts: dra7: add crossbar device binding
* Lokesh Vutla lokeshvu...@ti.com [140709 23:00]: Hi Tony, On Wednesday 09 July 2014 09:14 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140626 03:28]: * Sricharan R r.sricha...@ti.com [140626 01:36]: Hi Tony, On Thursday 26 June 2014 01:14 PM, Tony Lindgren wrote: * Sricharan R r.sricha...@ti.com [140626 00:29]: From: R Sricharan r.sricha...@ti.com There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The Peripheral irq requests are connected to only one crossbar input and the output of the crossbar is connected to only one controller's input line. The crossbar device is used to map a peripheral input to a free mpu's interrupt controller line. Here, adding a new crossbar device node and replacing all the peripheral interrupt numbers with its fixed crossbar input lines. I think these two patches need to be a single patch to avoid breaking booting for git bisect inbetween these patches? This does not cause booting issues. irq_desc gets allocated linearly, but that does not create boot issues. OK These are now applied on top of Jason's immutable irqchip branch and merged and pushed out into omap-for-v3.17/dt. Can you guys please test? I have tested omap-for-v3.17/dt on DRA7 EVM. Crossbar is working fine. Looks good to me. lokesh@a0131933lt:~/working/mainline/linux$ git describe v3.16-rc1-34-g6464099 Please find the logs here: http://paste.ubuntu.com/7773616/ OK great thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] tty: serial: 8250 core: add runtime pm
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 10:52]:
While comparing the OMAP-serial and the 8250 part of this I noticed that
the the latter does not use runtime-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access.
If I understand this correct, it should do nothing as long as
pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
device.
...
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -571,7 +573,17 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
serial_out(p, UART_EFR, 0);
serial_out(p, UART_LCR, 0);
}
+
+ if (!device_may_wakeup(p-port.dev)) {
+ if (sleep)
+ pm_runtime_forbid(p-port.dev);
+ else
+ pm_runtime_allow(p-port.dev);
+ }
}
+out:
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
}
The device_may_wakeup logic here is wrong as I described in the
earlier thread. For runtime PM, the wake-up events should be
always enabled. So the device_may_wakeup checks should be only
done for suspend and resume.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-dmic: use managed interfaces
On 07/10/2014 12:21 AM, Himangi Saraogi wrote:
This patch moves data allocated using clk_put and
snd_soc_register_component to the corresponding managed interfaces and
does away with the functions to free memory in the probe and remove
functions. The probe function is no longer required and is completely
removed.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c | 35 ---
1 file changed, 8 insertions(+), 27 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 6925d71..b315b27 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -466,7 +466,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
mutex_init(dmic-mutex);
- dmic-fclk = clk_get(dmic-dev, fck);
+ dmic-fclk = devm_clk_get(dmic-dev, fck);
if (IS_ERR(dmic-fclk)) {
dev_err(dmic-dev, cant get fck\n);
return -ENODEV;
@@ -475,8 +475,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, dma);
if (!res) {
dev_err(dmic-dev, invalid dma memory resource\n);
- ret = -ENODEV;
- goto err_put_clk;
+ return -ENODEV;
}
dmic-dma_data.addr = res-start + OMAP_DMIC_DATA_REG;
@@ -484,34 +483,17 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
dmic-io_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(dmic-io_base)) {
- ret = PTR_ERR(dmic-io_base);
- goto err_put_clk;
- }
-
+ if (IS_ERR(dmic-io_base))
+ return PTR_ERR(dmic-io_base);
- ret = snd_soc_register_component(pdev-dev, omap_dmic_component,
- omap_dmic_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev, omap_dmic_component,
+ omap_dmic_dai, 1);
if (ret)
- goto err_put_clk;
+ return ret;
ret = omap_pcm_platform_register(pdev-dev);
if (ret)
- goto err_put_clk;
-
- return 0;
-
-err_put_clk:
- clk_put(dmic-fclk);
- return ret;
-}
-
-static int asoc_dmic_remove(struct platform_device *pdev)
-{
- struct omap_dmic *dmic = platform_get_drvdata(pdev);
-
- snd_soc_unregister_component(pdev-dev);
- clk_put(dmic-fclk);
+ return ret;
return 0;
}
@@ -529,7 +511,6 @@ static struct platform_driver asoc_dmic_driver = {
.of_match_table = omap_dmic_of_match,
},
.probe = asoc_dmic_probe,
- .remove = asoc_dmic_remove,
};
module_platform_driver(asoc_dmic_driver);
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 09:35]: On 07/09/2014 05:12 PM, Tony Lindgren wrote: And also please note that for runtime PM the wake-up events need to be always enabled, so the device_may_wakeup() checks should be only implemented for suspend and resume. I think I got that corrected for most part in omap-serial.c recently, but knowing that might reduce the confusion a bit :) Ehm. I also added it to omap_8250_pm() as it is done in omap-serial (in serial_omap_pm()). Should I get rid of it in the latter? Yes, I commented on that patch also. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140709 10:52]: v1…v2: - added runtime PM. Could somebody could plese double check this? I seems to be enabled and nothing explodes. However serial_omap_get_context_loss_count() enable_wakeup() are NULL pointer (in the omap-serial driver). So I am not sure how this supposed to work :) - added omap_8250_set_termios() You can test this pretty easily on beagleboard xm for example using v3.16-r4: 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 ... I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14] (do_sys_open+0x100/0x1d0) [5.821777] [c011cd14] (do_sys_open) from [c07b7ce0] (kernel_init_freeable+0x124/0x1c8) [5.830200] [c07b7ce0] (kernel_init_freeable) from [c054eb90] (kernel_init+0x8/0xe4) [5.838348] [c054eb90] (kernel_init) from [c000e868] (ret_from_fork+0x14/0x2c) Sounds like the clocks are not enabled properly? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] [RFC] ARM: OMAP2+: gpmc: fix gpmc_hwecc_bch_capable
On Tue, 2014-07-08 at 06:25 +, Gupta, Pekon wrote: Do you plan to re-spin this patch with above comments, and mark it for stable? It would be helpful for all OMAP3 users. Thanks for the reminder. I'll respin the patchset this weekend. -- Christoph -- 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] ASoC: omap-dmic: use managed interfaces
On Thu, Jul 10, 2014 at 02:51:12AM +0530, Himangi Saraogi wrote: This patch moves data allocated using clk_put and snd_soc_register_component to the corresponding managed interfaces and does away with the functions to free memory in the probe and remove functions. The probe function is no longer required and is completely removed. This doesn't apply against current code, please check and resend. signature.asc Description: Digital signature
[PATCH 0/3] ARM: DTS: omap5-uevm: Enable audio (for 3.17)
Hi, This set is to enable audio (finally) on the omap5-uevm. We have been waiting for the palmas 32K clock driver to make it to upstream, which it did and it is already in linux-next. With the three patch we can have audio working on omap5-uevm with linux-next. Regards, Peter --- Peter Ujfalusi (3): ARM: DTS: omap5-uevm: Enable palmas clk32kgaudio clock ARM: DTS: omap5-uevm: Add node for twl6040 audio codec ARM: DTS: omap5-uevm: Enable basic audio (McPDM - twl6040) arch/arm/boot/dts/omap5-uevm.dts | 68 1 file changed, 62 insertions(+), 6 deletions(-) -- 2.0.0 -- 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/3] ARM: DTS: omap5-uevm: Enable palmas clk32kgaudio clock
clk32kg-audio clock is needed for twl6040 codec.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1e1b05768cec..9166d479ac1b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -306,6 +306,11 @@
ti,wakeup;
};
+ clk32kgaudio: palmas_clk32k@1 {
+ compatible = ti,palmas-clk32kgaudio;
+ #clock-cells = 0;
+ };
+
palmas_pmic {
compatible = ti,palmas-pmic;
interrupt-parent = palmas;
--
2.0.0
--
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/3] ARM: DTS: omap5-uevm: Add node for twl6040 audio codec
The board uses twl6040 as audio codec. Move the corresponding pinctrl as
well under the node.
twl6040 needs 32k clock from palams.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 9166d479ac1b..c9286166fad5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -105,7 +105,6 @@
omap5_pmx_core {
pinctrl-names = default;
pinctrl-0 =
- twl6040_pins
mcpdm_pins
mcbsp1_pins
mcbsp2_pins
@@ -494,6 +493,25 @@
};
};
};
+
+ twl6040: twl@4b {
+ compatible = ti,twl6040;
+ reg = 0x4b;
+
+ pinctrl-names = default;
+ pinctrl-0 = twl6040_pins;
+
+ interrupts = GIC_SPI 119 IRQ_TYPE_NONE; /* IRQ_SYS_2N
cascaded to gic */
+ interrupt-parent = gic;
+ ti,audpwron-gpio = gpio5 13 0; /* gpio line 141 */
+
+ vio-supply = smps7_reg;
+ v2v1-supply = smps9_reg;
+ enable-active-high;
+
+ clocks = clk32kgaudio;
+ clock-names = clk32k;
+ };
};
i2c5 {
--
2.0.0
--
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/3] ARM: DTS: omap5-uevm: Enable basic audio (McPDM - twl6040)
The board uses twl6040 codec connected via McPDM link. McBSP1 and McBSP2 can
be used for FM/BT.
At the same time move the pinctrl handling to the correct place - under the
corresponding nodes.
Audio connectors on the board:
Headset in/out
Stereo Line out
Stereo Line in.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 43 +++-
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index c9286166fad5..159720d6c956 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -100,14 +100,33 @@
};
};
};
+
+ sound: sound {
+ compatible = ti,abe-twl6040;
+ ti,model = omap5-uevm;
+
+ ti,mclk-freq = 1920;
+
+ ti,mcpdm = mcpdm;
+
+ ti,twl6040 = twl6040;
+
+ /* Audio routing */
+ ti,audio-routing =
+ Headset Stereophone, HSOL,
+ Headset Stereophone, HSOR,
+ Line Out, AUXL,
+ Line Out, AUXR,
+ HSMIC, Headset Mic,
+ Headset Mic, Headset Mic Bias,
+ AFML, Line In,
+ AFMR, Line In;
+ };
};
omap5_pmx_core {
pinctrl-names = default;
pinctrl-0 =
- mcpdm_pins
- mcbsp1_pins
- mcbsp2_pins
usbhost_pins
led_gpio_pins
;
@@ -528,8 +547,22 @@
};
};
-mcbsp3 {
- status = disabled;
+mcpdm {
+ pinctrl-names = default;
+ pinctrl-0 = mcpdm_pins;
+ status = okay;
+};
+
+mcbsp1 {
+ pinctrl-names = default;
+ pinctrl-0 = mcbsp1_pins;
+ status = okay;
+};
+
+mcbsp2 {
+ pinctrl-names = default;
+ pinctrl-0 = mcbsp2_pins;
+ status = okay;
};
usbhshost {
--
2.0.0
--
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 10/16] i2c: i2c-omap: Drop class based scanning to improve bootup time
This driver has been flagged to drop class based instantiation. The removal improves boot-up time and is unneeded for embedded controllers. Users have been warned to switch for some time now, so we can actually do the removal. Keep the DEPRECATED flag, so the core can inform users that the behaviour finally changed now. After another transition period, this flag can go, too. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b182793a4051..0dffb0e62c3b 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1236,7 +1236,7 @@ omap_i2c_probe(struct platform_device *pdev) adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; - adap-class = I2C_CLASS_HWMON | I2C_CLASS_DEPRECATED; + adap-class = I2C_CLASS_DEPRECATED; strlcpy(adap-name, OMAP I2C adapter, sizeof(adap-name)); adap-algo = omap_i2c_algo; adap-dev.parent = pdev-dev; -- 2.0.0 -- 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 00/16] i2c: drop class based instantiaion for selected drivers
Some drivers were flagged to remove class based instantiation soon to improve
boot-up time. Originally, I was planning for a longer deprecation time so users
could switch over to some other kind of instantiation. However, the demand for
the speed up is high enough and class based instantiation is used rarely, so
the removal takes place now. To make up for the deprecation time, another
warning is added to the i2c core pointing out that the behaviour has now
changed:
+ /* Warn that the adapter lost class based instantiation */
+ if (adapter-class == I2C_CLASS_DEPRECATED) {
+ dev_dbg(adapter-dev,
+ This adapter dropped support for I2C classes and
+ won't auto-detect %s devices anymore. If you need it,
check
+ 'Documentation/i2c/instantiating-devices' for
alternatives.\n,
+ driver-driver.name);
+ return 0;
+ }
A branch can be found here (with two other cleanups - driver removals):
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/deprecate_stuff
I hope this meets all the needs. Please comment, ack, test...
Thanks,
Wolfram
Wolfram Sang (16):
i2c: add debug info when class instantiation was dropped
i2c: i2c-at91: Drop class based scanning to improve bootup time
i2c: i2c-bcm2835: Drop class based scanning to improve bootup time
i2c: i2c-bfin-twi: Drop class based scanning to improve bootup time
i2c: i2c-davinci: Drop class based scanning to improve bootup time
i2c: i2c-designware-platdrv: Drop class based scanning to improve
bootup time
i2c: i2c-mv64xxx: Drop class based scanning to improve bootup time
i2c: i2c-nomadik: Drop class based scanning to improve bootup time
i2c: i2c-ocores: Drop class based scanning to improve bootup time
i2c: i2c-omap: Drop class based scanning to improve bootup time
i2c: i2c-rcar: Drop class based scanning to improve bootup time
i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
i2c: i2c-sirf: Drop class based scanning to improve bootup time
i2c: i2c-stu300: Drop class based scanning to improve bootup time
i2c: i2c-tegra: Drop class based scanning to improve bootup time
i2c: i2c-xiic: Drop class based scanning to improve bootup time
drivers/i2c/busses/i2c-at91.c | 2 +-
drivers/i2c/busses/i2c-bcm2835.c| 2 +-
drivers/i2c/busses/i2c-bfin-twi.c | 2 +-
drivers/i2c/busses/i2c-davinci.c| 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-mv64xxx.c| 2 +-
drivers/i2c/busses/i2c-nomadik.c| 8
drivers/i2c/busses/i2c-ocores.c | 12 ++--
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-rcar.c | 14 +++---
drivers/i2c/busses/i2c-s3c2410.c| 8
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-stu300.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 12 ++--
drivers/i2c/i2c-core.c | 10 ++
16 files changed, 47 insertions(+), 37 deletions(-)
--
2.0.0
--
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] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
On Wed, Jul 09, 2014 at 03:52:59PM +0530, Keerthy wrote: Add fixed_uV fields for dcdc5 and dcdc6. Applied, but don't bury new patches into the middle of old threads - it's a good way to get your patch ignored. signature.asc Description: Digital signature
Re: [PATCH 00/16] i2c: drop class based instantiaion for selected drivers
Hi,
Wolfram Sang wrote:
Some drivers were flagged to remove class based instantiation soon to improve
boot-up time. Originally, I was planning for a longer deprecation time so
users
could switch over to some other kind of instantiation. However, the demand for
the speed up is high enough and class based instantiation is used rarely, so
the removal takes place now. To make up for the deprecation time, another
warning is added to the i2c core pointing out that the behaviour has now
changed:
+ /* Warn that the adapter lost class based instantiation */
+ if (adapter-class == I2C_CLASS_DEPRECATED) {
+ dev_dbg(adapter-dev,
+ This adapter dropped support for I2C classes and
+ won't auto-detect %s devices anymore. If you need it,
check
+ 'Documentation/i2c/instantiating-devices' for
alternatives.\n,
It's usually a bad idea to split kernel messages across source lines
because it makes searching for the corresponding source line for a
message found in the log difficult.
You could at least do the split at the sentence boundary.
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
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 07/14] cpufreq: cpu0: OPPs can be populated at runtime
On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 9 July 2014 20:14, Santosh Shilimkar santosh.shilim...@ti.com wrote:
Assuming you are updating bidnings as suggested by Stephen,
patch looks good to me.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Why do you still have a separate cpufreq driver for omap?
Would this patch help getting that out?
I see this for omap:
static inline void omap_init_cpufreq(void)
{
struct platform_device_info devinfo = { };
if (!of_have_populated_dt())
devinfo.name = omap-cpufreq;
else
devinfo.name = cpufreq-generic;
platform_device_register_full(devinfo);
}
and it makes me believe that you were just waiting for this patch?
Sorry, am away on vacation and slow on emails. The plan was to kill
omap cpufreq once all platforms convert to device tree only boot. Only
platform left is OMAP3 based platforms - though the date for removing
non-dt support has changed a couple of kernel revisions - but we
should be able to remove that entire file with this change.
We will need this support to go with the solution recommended for opp
modifier series[1] - where platform code will populate or add OPPs
based on speed grade sample detection.
[1]http://comments.gmane.org/gmane.linux.ports.arm.kernel/309466
---
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
On Thursday 10 July 2014 05:42 PM, Mark Brown wrote: On Wed, Jul 09, 2014 at 03:52:59PM +0530, Keerthy wrote: Add fixed_uV fields for dcdc5 and dcdc6. Applied, but don't bury new patches into the middle of old threads - it's a good way to get your patch ignored. Okay. I thought only one patch had to be redone on top of the other branch so did it this way. I will resend a new series next time onwards. Thanks. Regards, Keerthy -- 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 00/16] i2c: drop class based instantiaion for selected drivers
+ /* Warn that the adapter lost class based instantiation */
+ if (adapter-class == I2C_CLASS_DEPRECATED) {
+ dev_dbg(adapter-dev,
+ This adapter dropped support for I2C classes and
+ won't auto-detect %s devices anymore. If you need it,
check
+ 'Documentation/i2c/instantiating-devices' for
alternatives.\n,
It's usually a bad idea to split kernel messages across source lines
Yes, usually. Not for this message, though, it's specific. The lines
would have been quite long.
You could at least do the split at the sentence boundary.
OK, this would have been a compromise.
signature.asc
Description: Digital signature
Re: [PATCH v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Tue, Jul 08, 2014 at 08:53:32AM +0100, Lee Jones wrote: On Tue, 08 Jul 2014, Maxime Coquelin wrote: On 07/05/2014 08:25 AM, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Maxime Coquelin maxime.coque...@st.com Maxime, Once Acked by Felipe, I think this should go in via your tree to avoid conflicts with other ARM/STI ARCHITECTURE additions. there are still many unresolved comments on patches 1 and 2. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
On Wednesday 09 July 2014 05:21 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 04:03]: On Wednesday 09 July 2014 02:01 PM, Tony Lindgren wrote: * Keerthy j-keer...@ti.com [140708 22:40]: The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Are the .dts changes safe to apply separately without breaking anything? Tony, Patch 1/7 had to be re-based on Mark's latest branch for tps65218. Other patches can be taken as is. These patches are boot tested on both am437x-gp-evm and am43x-epos-evm. OK thanks applying patches 4 - 7 into omap-for-v3.17/dt. Tony Thanks Tony. Mark, Could you please pull patch 2 and patch 3? The documentation is missing. Kind Regards, Keerthy -- 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 07/14] cpufreq: cpu0: OPPs can be populated at runtime
On Thursday 10 July 2014 08:39 AM, Nishanth Menon wrote:
On Thu, Jul 10, 2014 at 6:19 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 9 July 2014 20:14, Santosh Shilimkar santosh.shilim...@ti.com wrote:
Assuming you are updating bidnings as suggested by Stephen,
patch looks good to me.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Why do you still have a separate cpufreq driver for omap?
Would this patch help getting that out?
I see this for omap:
static inline void omap_init_cpufreq(void)
{
struct platform_device_info devinfo = { };
if (!of_have_populated_dt())
devinfo.name = omap-cpufreq;
else
devinfo.name = cpufreq-generic;
platform_device_register_full(devinfo);
}
and it makes me believe that you were just waiting for this patch?
Sorry, am away on vacation and slow on emails. The plan was to kill
omap cpufreq once all platforms convert to device tree only boot. Only
platform left is OMAP3 based platforms - though the date for removing
non-dt support has changed a couple of kernel revisions - but we
should be able to remove that entire file with this change.
We will need this support to go with the solution recommended for opp
modifier series[1] - where platform code will populate or add OPPs
based on speed grade sample detection.
Yep. Last time I blocked the series because all the DT conversions
were not done. Considering now the cpufreq-generic can work on non
DT platforms, I am ok to remove the omap-cpufreq.
Regards,
Santosh
--
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 07/14] cpufreq: cpu0: OPPs can be populated at runtime
On 10 July 2014 19:01, Santosh Shilimkar santosh.shilim...@ti.com wrote: Yep. Last time I blocked the series because all the DT conversions were not done. Considering now the cpufreq-generic can work on non DT platforms, I am ok to remove the omap-cpufreq. Great. -- 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 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Thu, 10 Jul 2014, Felipe Balbi wrote: On Tue, Jul 08, 2014 at 08:53:32AM +0100, Lee Jones wrote: On Tue, 08 Jul 2014, Maxime Coquelin wrote: On 07/05/2014 08:25 AM, Peter Griffin wrote: Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Maxime Coquelin maxime.coque...@st.com Maxime, Once Acked by Felipe, I think this should go in via your tree to avoid conflicts with other ARM/STI ARCHITECTURE additions. there are still many unresolved comments on patches 1 and 2. Once Acked ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
On Thursday 10 July 2014 06:55 PM, Keerthy wrote: On Wednesday 09 July 2014 05:21 PM, Tony Lindgren wrote: * Keerthy a0393...@ti.com [140709 04:03]: On Wednesday 09 July 2014 02:01 PM, Tony Lindgren wrote: * Keerthy j-keer...@ti.com [140708 22:40]: The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Are the .dts changes safe to apply separately without breaking anything? Tony, Patch 1/7 had to be re-based on Mark's latest branch for tps65218. Other patches can be taken as is. These patches are boot tested on both am437x-gp-evm and am43x-epos-evm. OK thanks applying patches 4 - 7 into omap-for-v3.17/dt. Tony Thanks Tony. Mark, Could you please pull patch 2 and patch 3? The documentation is missing. https://patchwork.kernel.org/patch/4511721/ and https://patchwork.kernel.org/patch/4511751/ Regards, Keerthy Kind Regards, Keerthy -- 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/6] tty: serial: 8250 core: provide a function to export uart_8250_port
On Wed, Jul 9, 2014 at 7:49 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: + * The lock assumption made here is none because runtime-pm suspend/resume + * callbacks should not be invoked there is any operation performed on the port. I think there's a missing if? Best, OG. -- 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] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
On Thu, Jul 10, 2014 at 06:40:39PM +0530, Keerthy wrote: On Thursday 10 July 2014 05:42 PM, Mark Brown wrote: Applied, but don't bury new patches into the middle of old threads - it's a good way to get your patch ignored. Okay. I thought only one patch had to be redone on top of the other branch so did it this way. I will resend a new series next time onwards. Thanks. For something like this where there's actually no dependencies it's OK to resend the patch as a standalone thing. signature.asc Description: Digital signature
Re: [PATCH 5/6] tty: serial: 8250-core: add rs485 support
static inline void __stop_tx(struct uart_8250_port *p)
{
+ if (p-rs485.flags SER_RS485_ENABLED) {
+ int ret;
+
+ ret = (p-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
+ if (gpio_get_value(p-rts_gpio) != ret) {
+ if (p-rs485.delay_rts_after_send 0)
+ mdelay(p-rs485.delay_rts_after_send);
+ gpio_set_value(p-rts_gpio, ret);
+ }
RTS is not normally a GPIO. We should be controlling the UART RTS here,
and if the UART has a magic special case RTS wired to a GPIO then really
the hardware specific part should handle that gunge. I don't care whether
the drive does it via serial_out magic or a more explicit hook but it
doesn't belong here in core code.
Likewise the mdelay probably should be in the device specific bits or
controlled by a flag as not all hardware is so braindead.
@@ -1330,6 +1356,20 @@ static void serial8250_start_tx(struct uart_port *port)
if (up-dma !serial8250_tx_dma(up)) {
Ditto
+int serial8250_probe_rs485(struct uart_8250_port *up,
+ struct device *dev)
+{
+ struct serial_rs485 *rs485conf = up-rs485;
+ struct device_node *np = dev-of_node;
+ u32 rs485_delay[2];
+ enum of_gpio_flags flags;
+ int ret;
+
+ rs485conf-flags = 0;
+ if (!np)
+ return 0;
+
+ /* check for tx enable gpio */
+ up-rts_gpio = of_get_named_gpio_flags(np, rts-gpio, 0, flags);
No of_ dependencies in core 8250.c either please. That looks a perfectly
good implementation of serial8250_of_probe_rs485 however, just belongs in
the right place.
+static int serial8250_ioctl(struct uart_port *port, unsigned int cmd,
+ unsigned long arg)
+{
+ struct serial_rs485 rs485conf;
+ struct uart_8250_port *up;
+
+ up = container_of(port, struct uart_8250_port, port);
+ switch (cmd) {
+ case TIOCSRS485:
+ if (!gpio_is_valid(up-rts_gpio))
+ return -ENODEV;
GPIO assumption again needs to go
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 0ec21ec..056a73f 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -78,6 +78,7 @@ struct uart_8250_port {
unsigned char acr;
unsigned char ier;
unsigned char lcr;
+ unsigned char fcr;
unsigned char mcr;
unsigned char mcr_mask; /* mask of user bits */
unsigned char mcr_force; /* mask of forced bits */
@@ -94,6 +95,9 @@ struct uart_8250_port {
unsigned char msr_saved_flags;
struct uart_8250_dma*dma;
+ struct serial_rs485 rs485;
+ int rts_gpio;
+ boolrts_gpio_valid;
Keeping the gpio here doesn't look unreasonable if one is in use.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] tty: serial: 8250 core: allow to overwrite export serial8250_startup()
On Wed, 9 Jul 2014 19:49:33 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wakeup irq which should to be requested enabled at -startup() time and disabled at -shutdown() time. v1…v2: add shutdown callback Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de 1,2 4 Acked by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] tty: serial: 8250 core: allow to overwrite export serial8250_startup()
On 07/09/2014 07:49 PM, Sebastian Andrzej Siewior wrote: The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wakeup irq which should to be requested enabled at -startup() time and disabled at -shutdown() time. v1…v2: add shutdown callback forgot to copy the callbacks in serial8250_register_8250_port(). Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
Hi Felipe, Maxime, Once Acked by Felipe, I think this should go in via your tree to avoid conflicts with other ARM/STI ARCHITECTURE additions. there are still many unresolved comments on patches 1 and 2. Yes, sorry I've been a bit busy this week on other activities to send a V3. I will get this fixed up addressing the comments received so far, and sent out a V3 early next week. regards, Peter. -- 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 6/6] tty: serial: Add 8250-core based omap driver
On 07/10/2014 09:09 AM, Tony Lindgren wrote: You can test this pretty easily on beagleboard xm for example using v3.16-r4: I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even want to show MLO/U-boot) with the same result. 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. EHCI was already disabled in the config. OTG was not connected. 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle I had network up and configured. Was that okay? I also tried ifconfig eth0 down; sleep 10; ifconfig eth0 up to see if it works. 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. So something is not right. Since Dra7 has some things missing I tried it on am335x with the same behavior. Should it work here? ... I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14] (do_sys_open+0x100/0x1d0) [5.821777] [c011cd14] (do_sys_open) from [c07b7ce0] (kernel_init_freeable+0x124/0x1c8) [5.830200] [c07b7ce0] (kernel_init_freeable) from [c054eb90] (kernel_init+0x8/0xe4) [5.838348] [c054eb90] (kernel_init) from [c000e868] (ret_from_fork+0x14/0x2c) Sounds like the clocks are not enabled properly? puh. So after staring a while at your backtrace I realized that shutdown startup callbacks are not overwritten properly. Well, thanks for that. Anyway, even serial8250_do_startup() has pm_runtime_get_sync() before first register access so I have no idea where this is coming from. Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More
Re: [PATCH 5/6] tty: serial: 8250-core: add rs485 support
On 07/09/2014 09:01 PM, Lennart Sorensen wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index c7c3bf7..bf06a4c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1281,10 +1283,34 @@ static void autoconfig_irq(struct uart_8250_port *up)
static inline void __stop_tx(struct uart_8250_port *p)
{
+if (p-rs485.flags SER_RS485_ENABLED) {
+int ret;
+
+ret = (p-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
+if (gpio_get_value(p-rts_gpio) != ret) {
+if (p-rs485.delay_rts_after_send 0)
+mdelay(p-rs485.delay_rts_after_send);
+gpio_set_value(p-rts_gpio, ret);
Usually the delay for RS485 is done in bit times, not msec. Not sure
how you expect this to work. Not sure doing it in software is precise
enough either. It probably should be calculated based on the current
baudrate with a bit time rather than msec in the DT data. No one wants
to have to change the DT data to change the baud rate. After all this
is very often used with modbus and the modbus rules specify turn around
times in bit times.
My understanding is that this is not baudrate related. This is the
delay that the hardware (the transceiver) to perform the change and
work.
There is the ioctl() interface which can change the delay, too. The
only required thing is the gpio.
I hope TI puts this into the UART in future designs where it belongs
(similar to what Exar and many others already did).
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On 07/10/2014 11:47 AM, Sebastian Andrzej Siewior wrote: That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? To wakeup from UART you need: 1) Append no_console_suspend to bootargs 2) echo enabled /sys/devices/ocp.3/4806a000.serial/tty/ttyO0/power/wakeup -- 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: Anybody working on tidspbridge?
On Thu, Jul 10, 2014 at 08:54:18AM +0300, Ivaylo Dimitrov wrote: On 9.07.2014 10:07, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140708 11:40]: Hi Peter, On 07/08/2014 09:36 AM, Greg KH wrote: On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh. Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. I agree with Greg here. In fact, the current TODO does not do enough justice to the amount of work required to make it even work on the latest kernel. Most of the TIers who worked on this driver have moved on as Kristina would have figured with her bounced emails. So I do suggest that this driver be deleted from the kernel tree. If there are enough number of folks using it (not sure how many are out there), it can be worked on out-of-tree and brought back in a cleaner fashion rather than keeping a broken stale driver in the kernel. I agree, not much has improved with this driver since it got added into staging except just compile fixes. Regards, Tony Well, recently I've sent a couple of patches which implement stuff from TODO [1]. However, with the migration to DT, my focus now is to have a kernel/userspace that boots at all and this leaves no free cycles for DSP. Maybe tidspbridge can be left in staging until DT migration is finished, that way me (and maybe other people) will have the time needed to try to implement what remains in TODO. Also, keep in mind there will (hopefully) be another omap3 end-user device released by the end of the year (Neo900), which most probably will gain more developers interested in fixing the DSP driver. I'm really tired of people saying, maybe sometime in the future we will work on this for this driver. It's not the first time I've heard it, and it has _never_ come true. Honestly, I really don't believe it will ever happen, given that TI doesn't care about this code at all. If in the future, someone does want to work on this, a simple revert of the patch that removes the driver will be all that is needed. Let's do that instead of hoping that sometime, someone, somewhere, will do this work. thanks, greg k-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: [PATCH 6/6] tty: serial: Add 8250-core based omap driver
On Thu, Jul 10, 2014 at 11:03 AM, Carlos Hernandez c...@ti.com wrote: 1) Append no_console_suspend to bootargs Not needed. ideally with pinctrl wakeup capability, this should work. if you do no_console_suspend, the module is not powered down. -- 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: Anybody working on tidspbridge?
On Thu, Jul 10, 2014 at 12:11 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 10, 2014 at 08:54:18AM +0300, Ivaylo Dimitrov wrote: On 9.07.2014 10:07, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140708 11:40]: Hi Peter, On 07/08/2014 09:36 AM, Greg KH wrote: On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh. Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. I agree with Greg here. In fact, the current TODO does not do enough justice to the amount of work required to make it even work on the latest kernel. Most of the TIers who worked on this driver have moved on as Kristina would have figured with her bounced emails. So I do suggest that this driver be deleted from the kernel tree. If there are enough number of folks using it (not sure how many are out there), it can be worked on out-of-tree and brought back in a cleaner fashion rather than keeping a broken stale driver in the kernel. I agree, not much has improved with this driver since it got added into staging except just compile fixes. Regards, Tony Well, recently I've sent a couple of patches which implement stuff from TODO [1]. However, with the migration to DT, my focus now is to have a kernel/userspace that boots at all and this leaves no free cycles for DSP. Maybe tidspbridge can be left in staging until DT migration is finished, that way me (and maybe other people) will have the time needed to try to implement what remains in TODO. Also, keep in mind there will (hopefully) be another omap3 end-user device released by the end of the year (Neo900), which most probably will gain more developers interested in fixing the DSP driver. I'm really tired of people saying, maybe sometime in the future we will work on this for this driver. It's not the first time I've heard it, and it has _never_ come true. Honestly, I really don't believe it will ever happen, given that TI doesn't care about this code at all. If in the future, someone does want to work on this, a simple revert of the patch that removes the driver will be all that is needed. Let's do that instead of hoping that sometime, someone, somewhere, will do this work. Makes sense to me. FYI, it will come back again on newer TI ARM+DSP devices. Those aren't going away, but I'm also not aware of anyone imminently pushing patches. thanks, greg k-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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes against v3.16-rc4
On Wed, Jul 09, 2014 at 08:35:52AM -0700, Tony Lindgren wrote: The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.16/fixes-rc4 for you to fetch changes up to 1d29a0722f6c38f79785c9ffb911730598de84e2: ARM: OMAP2+: Remove non working OMAP HDMI audio initialization (2014-07-08 01:08:44 -0700) Fixes for omaps for the -rc series. It's mostly fixes for clock rates, restart handling and phy regulators and SATA interconnect data. It's a little surprising to see a SATA fix about a week after enablement went in during -rc -- enabling it that late should ideally have been better tested than this. Also few build fixes related to the DSP driver in staging, and trivial stuff like removal of broken and soon to be unused platform data init for HDMI audio that would be good to get into the -rc series if not too late. Thanks, merged. Definitely time for regressions only from here on out though. -Olof -- 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 v4 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hello, This series adds suspend/resume support for am335x. Version 3 of this series can be found at [1]. I apologize for the large delay between this and the previous revision. This code has been heavily refined since the last version based on the various comments received for v3. The major change from previous version is moving all wkup_m3 code into a remoteproc based driver. The new driver handles all IPC and fw loading and exposes a small API to be used by PM code to achieve low power states. Firmware that can be used for testing this can be found at [2] on branch pm-remote-proc-v3, using am335x-pm-firmware.elf found in bin directory. Please note this has changed from all previous versions and is no longer the .bin file. Firmware can be built into kernel or placed in /lib/firmware in rootfs for automatic loading during boot. This series has several dependencies. The wkup_m3_rproc utilizes a mailbox to communicate with the cm3 and depends on Suman's series for omap mbox support [3], which has several dependencies of it's own, listed in the cover letter. Also, a few changes to remoteproc itself were needed and have been provided by Suman here [4]. The edma patch included in this series was previously submitted by Daniel Mack and after discussion with him we agreed to include an updated version with this series as resume has a direct dependency on it due to hangs in mmc without it. Because of the high number of dependencies I have pushed a branch for testing here [6] if anyone desires to try it out on branch pm-ds0-v3.16. As is this series will only suspend and resume one time and then fail to resume afterwards due to the removal of direct PM code control of hwmods that do not properly assert their MSTANDBY signal after a context loss, discussed here [7]. In particular it is due to the usb_otg_hs hwmod that currently has no driver controlling it in the kernel. The main cause of the issue is that the SYSCONFIG register present within the IP must be reprogrammed after every suspend cycle and this only happens at boot if no driver is present. Work is in progress to allow suspend to function with or without drivers for the troublesome hwmods (cpgmac, usb_otg_hs, and tptc1-3) and will be provided in a separate future patch. The previous suggestion of allowing omap_device to handle it proved to be too invasive into both omap_device and omap_hwmod and the approach of allowing the firmware to handle it is not possible due to the inability of the CM3 to access the IPs causing the issue. I'd be happy to discuss this at length if anybody is interested. Regards, Dave [1] http://www.spinics.net/lists/linux-omap/msg95305.html [2] https://github.com/dgerlach/am33x-cm3 [3] http://www.spinics.net/lists/linux-omap/msg108595.html [4] http://www.spinics.net/lists/linux-omap/msg109173.html [5] http://www.spinics.net/lists/linux-omap/msg100606.html [6] https://github.com/dgerlach/linux-pm [7] http://www.spinics.net/lists/linux-omap/msg95353.html Daniel Mack (1): ARM: omap: edma: add suspend suspend/resume hooks Dave Gerlach (8): memory: emif: Move EMIF register defines to include/linux/ ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset Documentation: dt: add ti,am3353_wkup_m3 bindings remoteproc: wkup_m3: Add wkup_m3 remote proc driver ARM: dts: am33xx: Update wkup_m3 node ARM: OMAP2+: AM33XX: Add assembly code for PM operations ARM: OMAP2+: AM33XX: Basic suspend resume support ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds Vaibhav Bedia (2): ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec .../bindings/remoteproc/wkup_m3_rproc.txt | 46 ++ arch/arm/boot/dts/am33xx.dtsi | 9 +- arch/arm/common/edma.c | 86 +++- arch/arm/mach-omap2/Kconfig| 1 + arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-generic.c| 2 +- arch/arm/mach-omap2/common.c | 32 ++ arch/arm/mach-omap2/common.h | 13 + arch/arm/mach-omap2/io.c | 2 + arch/arm/mach-omap2/pdata-quirks.c | 12 + arch/arm/mach-omap2/pm.h | 5 + arch/arm/mach-omap2/pm33xx.c | 346 + arch/arm/mach-omap2/pm33xx.h | 64 +++ arch/arm/mach-omap2/sleep33xx.S| 380 ++ arch/arm/mach-omap2/sram.c | 10 +- arch/arm/mach-omap2/sram.h | 2 + arch/arm/mach-omap2/timer.c| 28 ++ drivers/memory/emif.h | 543 +--- drivers/remoteproc/Kconfig | 15 + drivers/remoteproc/Makefile| 1 + drivers/remoteproc/wkup_m3_rproc.c | 512
[PATCH v4 03/11] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
From: Vaibhav Bedia vaibhav.be...@ti.com
OMAP timer code registers two timers - one as clocksource
and one as clockevent. Since AM33XX has only one usable timer
in the WKUP domain one of the timers needs suspend-resume
support to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Only use for am33xx soc now.
arch/arm/mach-omap2/timer.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 43d03fb..6fc1748 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -128,6 +128,29 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ struct omap_hwmod *oh;
+
+ oh = omap_hwmod_lookup(clockevent_gpt.name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
static struct clock_event_device clockevent_gpt = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
@@ -333,6 +356,11 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
clkev.id = gptimer_id;
clkev.errata = omap_dm_timer_get_errata();
+ if (soc_is_am33xx()) {
+ clockevent_gpt.suspend = omap_clkevt_suspend;
+ clockevent_gpt.resume = omap_clkevt_resume;
+ }
+
/*
* For clock-event timers we never read the timer counter and
* so we are not impacted by errata i103 and i767. Therefore,
--
1.9.0
--
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 v4 01/11] ARM: omap: edma: add suspend suspend/resume hooks
From: Daniel Mack zon...@gmail.com
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.
All information can be reconstructed by already known runtime
information.
As we now use some functions that were previously only used from __init
context, annotations had to be dropped.
[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
[d-gerl...@ti.com: updated to remove queue_tc_mapping use]
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/common/edma.c | 86 --
1 file changed, 84 insertions(+), 2 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 485be42..8b1b9aa 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -244,6 +244,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
+ struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
* channel is in use ... by ARM or DSP, for QDMA, or whatever.
*/
@@ -295,7 +297,7 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7 bit), queue_no bit);
}
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
{
int bit = queue_no * 4;
@@ -314,7 +316,7 @@ static void __init assign_priority_to_queue(unsigned ctlr,
int queue_no,
* included in that particular EDMA variant (Eg : dm646x)
*
*/
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
{
int i;
for (i = 0; i EDMA_MAX_DMACH; i++)
@@ -1762,15 +1764,95 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+ edma_cc[j]-info = info[j];
arch_num_cc++;
}
return 0;
}
+static int edma_pm_suspend(struct device *dev)
+{
+ int j, r;
+
+ r = pm_runtime_get_sync(dev);
+ if (r 0) {
+ dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+ return r;
+ }
+
+ for (j = 0; j arch_num_cc; j++) {
+ struct edma *ecc = edma_cc[j];
+
+ disable_irq(ecc-irq_res_start);
+ disable_irq(ecc-irq_res_end);
+ }
+
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+ int i, j, r;
+
+ r = pm_runtime_get_sync(dev);
+ if (r 0) {
+ dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+ return r;
+ }
+
+ for (j = 0; j arch_num_cc; j++) {
+ struct edma *cc = edma_cc[j];
+
+ s8 (*queue_priority_mapping)[2];
+
+ queue_priority_mapping = cc-info-queue_priority_mapping;
+
+ /* Event queue priority mapping */
+ for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+ assign_priority_to_queue(j,
+queue_priority_mapping[i][0],
+queue_priority_mapping[i][1]);
+
+ /*
+* Map the channel to param entry if channel mapping logic
+* exist
+*/
+ if (edma_read(j, EDMA_CCCFG) CHMAP_EXIST)
+ map_dmach_param(j);
+
+ for (i = 0; i cc-num_channels; i++) {
+ if (test_bit(i, cc-edma_inuse)) {
+ /* ensure access through shadow region 0 */
+ edma_or_array2(j, EDMA_DRAE, 0, i 5,
+ BIT(i 0x1f));
+
+ setup_dma_interrupt(i,
+ cc-intr_data[i].callback,
+ cc-intr_data[i].data);
+ }
+ }
+
+ enable_irq(cc-irq_res_start);
+ enable_irq(cc-irq_res_end);
+ }
+
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops edma_pm_ops = {
+ .suspend_late = edma_pm_suspend,
+ .resume_early = edma_pm_resume,
+};
+
static struct platform_driver edma_driver = {
.driver = {
.name = edma,
+ .pm = edma_pm_ops,
.of_match_table = edma_of_ids,
},
.probe = edma_probe,
--
1.9.0
--
To unsubscribe from this list: send
[PATCH v4 04/11] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset
Use pdata-quirks to reset the wkup_m3 during boot.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c| 12
include/linux/platform_data/wkup_m3.h | 17 +
2 files changed, 29 insertions(+)
create mode 100644 include/linux/platform_data/wkup_m3.h
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 90c88d4..8e4a541 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -17,6 +17,7 @@
#include linux/platform_data/pinctrl-single.h
#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/wkup_m3.h
#include am35xx.h
#include common.h
@@ -255,6 +256,13 @@ static void __init nokia_n900_legacy_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
+#ifdef CONFIG_SOC_AM33XX
+static struct wkup_m3_platform_data wkup_m3_data = {
+ .reset_name = wkup_m3,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
@@ -348,6 +356,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,am3517-emac, 0x5c00, davinci_emac.0,
am35xx_emac_pdata),
#endif
+#ifdef CONFIG_SOC_AM33XX
+ OF_DEV_AUXDATA(ti,am3353-wkup-m3, 0x44d0, 44d0.wkup_m3,
+ wkup_m3_data),
+#endif
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
diff --git a/include/linux/platform_data/wkup_m3.h
b/include/linux/platform_data/wkup_m3.h
new file mode 100644
index 000..07282bd
--- /dev/null
+++ b/include/linux/platform_data/wkup_m3.h
@@ -0,0 +1,17 @@
+/*
+ * omap wkup_m3: platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Dave Gerlach d-gerl...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+struct wkup_m3_platform_data {
+ const char *reset_name;
+
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
+};
--
1.9.0
--
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 v4 02/11] memory: emif: Move EMIF register defines to include/linux/
OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Reviewed-by: Russ Dill russ.d...@ti.com Acked-by: Santosh Shililmar santosh.shilim...@ti.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- v3-v4: patch unchanged from original: http://www.spinics.net/lists/linux-omap/msg95314.html drivers/memory/emif.h | 543 +- include/linux/ti_emif.h | 558 2 files changed, 559 insertions(+), 542 deletions(-) create mode 100644 include/linux/ti_emif.h diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h index bfe08ba..8214f07 100644 --- a/drivers/memory/emif.h +++ b/drivers/memory/emif.h @@ -12,548 +12,7 @@ #ifndef __EMIF_H #define __EMIF_H -/* - * Maximum number of different frequencies supported by EMIF driver - * Determines the number of entries in the pointer array for register - * cache - */ -#define EMIF_MAX_NUM_FREQUENCIES 6 - -/* State of the core voltage */ -#define DDR_VOLTAGE_STABLE 0 -#define DDR_VOLTAGE_RAMPING1 - -/* Defines for timing De-rating */ -#define EMIF_NORMAL_TIMINGS0 -#define EMIF_DERATED_TIMINGS 1 - -/* Length of the forced read idle period in terms of cycles */ -#define EMIF_READ_IDLE_LEN_VAL 5 - -/* - * forced read idle interval to be used when voltage - * is changed as part of DVFS/DPS - 1ms - */ -#define READ_IDLE_INTERVAL_DVFS(1*100) - -/* - * Forced read idle interval to be used when voltage is stable - * 50us - or maximum value will do - */ -#define READ_IDLE_INTERVAL_NORMAL (50*100) - -/* DLL calibration interval when voltage is NOT stable - 1us */ -#define DLL_CALIB_INTERVAL_DVFS(1*100) - -#define DLL_CALIB_ACK_WAIT_VAL 5 - -/* Interval between ZQCS commands - hw team recommended value */ -#define EMIF_ZQCS_INTERVAL_US (50*1000) -/* Enable ZQ Calibration on exiting Self-refresh */ -#define ZQ_SFEXITEN_ENABLE 1 -/* - * ZQ Calibration simultaneously on both chip-selects: - * Needs one calibration resistor per CS - */ -#defineZQ_DUALCALEN_DISABLE0 -#defineZQ_DUALCALEN_ENABLE 1 - -#define T_ZQCS_DEFAULT_NS 90 -#define T_ZQCL_DEFAULT_NS 360 -#define T_ZQINIT_DEFAULT_NS1000 - -/* DPD_EN */ -#define DPD_DISABLE0 -#define DPD_ENABLE 1 - -/* - * Default values for the low-power entry to be used if not provided by user. - * OMAP4/5 has a hw bug(i735) due to which this value can not be less than 512 - * Timeout values are in DDR clock 'cycles' and frequency threshold in Hz - */ -#define EMIF_LP_MODE_TIMEOUT_PERFORMANCE 2048 -#define EMIF_LP_MODE_TIMEOUT_POWER 512 -#define EMIF_LP_MODE_FREQ_THRESHOLD4 - -/* DDR_PHY_CTRL_1 values for EMIF4D - ATTILA PHY combination */ -#define EMIF_DDR_PHY_CTRL_1_BASE_VAL_ATTILAPHY 0x049FF000 -#define EMIF_DLL_SLAVE_DLY_CTRL_400_MHZ_ATTILAPHY 0x41 -#define EMIF_DLL_SLAVE_DLY_CTRL_200_MHZ_ATTILAPHY 0x80 -#define EMIF_DLL_SLAVE_DLY_CTRL_100_MHZ_AND_LESS_ATTILAPHY 0xFF - -/* DDR_PHY_CTRL_1 values for EMIF4D5 INTELLIPHY combination */ -#define EMIF_DDR_PHY_CTRL_1_BASE_VAL_INTELLIPHY0x0E084200 -#define EMIF_PHY_TOTAL_READ_LATENCY_INTELLIPHY_PS 1 - -/* TEMP_ALERT_CONFIG - corresponding to temp gradient 5 C/s */ -#define TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS360 - -#define EMIF_T_CSTA3 -#define EMIF_T_PDLL_UL 128 - -/* External PHY control registers magic values */ -#define EMIF_EXT_PHY_CTRL_1_VAL0x04020080 -#define EMIF_EXT_PHY_CTRL_5_VAL0x04010040 -#define EMIF_EXT_PHY_CTRL_6_VAL0x01004010 -#define EMIF_EXT_PHY_CTRL_7_VAL0x1004 -#define EMIF_EXT_PHY_CTRL_8_VAL0x04010040 -#define EMIF_EXT_PHY_CTRL_9_VAL
[PATCH v4 06/11] remoteproc: wkup_m3: Add wkup_m3 remote proc driver
Add a remoteproc driver to load the firmware for and boot the wkup_m3 present on am33xx. The wkup_m3 is an integrated Cortex M3 that allows the SoC to enter the lowest possible power state by taking control from the MPU after it has gone into its own low power state and shutting off any additional peripherals. Communication between the MPU and CM3 is handled by several IPC registers in the control module and a mailbox. An API is exposed for programming the aforementioned IPC registers and notifying the wkup_m3 of pending data using the mailbox. The wkup_m3 has the ability to trigger an interrupt back to the MPU to allow for bidirectional communication through these registers. Two callbacks are provided. rproc_ready allows code to hook into the driver to see when firmware has been loaded and execute other code and txev_handler allows external code to run when the wkup_m3 triggers an interrupt back to the m3. The driver expects a resource table to be present in the wkup_m3 to define the required memory resources needed by wkup_m3, at least the data memory so that the firmware can be copied for the proper place for execution. Signed-off-by: Dave Gerlach d-gerl...@ti.com CC: Ohad Ben-Cohen o...@wizery.com --- drivers/remoteproc/Kconfig | 15 ++ drivers/remoteproc/Makefile| 1 + drivers/remoteproc/wkup_m3_rproc.c | 512 + include/linux/wkup_m3.h| 71 + 4 files changed, 599 insertions(+) create mode 100644 drivers/remoteproc/wkup_m3_rproc.c create mode 100644 include/linux/wkup_m3.h diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 5e343ba..4b00c21 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -41,6 +41,21 @@ config STE_MODEM_RPROC This can be either built-in or a loadable module. If unsure say N. +config WKUP_M3_RPROC + bool AM33xx wkup-m3 remoteproc support +depends on SOC_AM33XX +select REMOTEPROC + select MAILBOX + select OMAP2PLUS_MBOX + default n + help + Say y here to support AM33xx wkup-m3. + + Required for Suspend-to-ram and CPUIdle on AM33xx. Allows for + loading of firmware and communication with CM3 PM coproccesor + that is present on AM33xx family of SoCs + If unsure say N. + config DA8XX_REMOTEPROC tristate DA8xx/OMAP-L13x remoteproc support depends on ARCH_DAVINCI_DA8XX diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile index ac2ff75..81b04d1 100644 --- a/drivers/remoteproc/Makefile +++ b/drivers/remoteproc/Makefile @@ -9,4 +9,5 @@ remoteproc-y+= remoteproc_virtio.o remoteproc-y += remoteproc_elf_loader.o obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o +obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c new file mode 100644 index 000..58aeaf2 --- /dev/null +++ b/drivers/remoteproc/wkup_m3_rproc.c @@ -0,0 +1,512 @@ +/* + * AMx3 Wkup M3 Remote Processor driver + * + * Copyright (C) 2014 Texas Instruments, Inc. + * + * Dave Gerlach d-gerl...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed 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. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/err.h +#include linux/platform_device.h +#include linux/irq.h +#include linux/interrupt.h +#include linux/elf.h +#include linux/pm_runtime.h +#include linux/firmware.h +#include linux/remoteproc.h +#include linux/omap-mailbox.h +#include linux/mailbox_client.h +#include linux/wkup_m3.h +#include linux/kthread.h +#include remoteproc_internal.h + +#include linux/platform_data/wkup_m3.h + +#define WKUP_M3_WAKE_SRC_MASK 0xFF + +#define WKUP_M3_STATUS_RESP_SHIFT 16 +#define WKUP_M3_STATUS_RESP_MASK (0x 16) + +#define WKUP_M3_FW_VERSION_SHIFT 0 +#define WKUP_M3_FW_VERSION_MASK0x + +/* AM33XX M3_TXEV_EOI register */ +#define AM33XX_CONTROL_M3_TXEV_EOI 0x00 + +#define AM33XX_M3_TXEV_ACK (0x1 0) +#define AM33XX_M3_TXEV_ENABLE (0x0 0) + +/* AM33XX IPC message registers */ +#define AM33XX_CONTROL_IPC_MSG_REG00x04 +#define AM33XX_CONTROL_IPC_MSG_REG10x08 +#define AM33XX_CONTROL_IPC_MSG_REG20x0c +#define AM33XX_CONTROL_IPC_MSG_REG30x10 +#define AM33XX_CONTROL_IPC_MSG_REG40x14 +#define
[PATCH v4 05/11] Documentation: dt: add ti,am3353_wkup_m3 bindings
Add the device tree bindings document for am3353 wkup_m3.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
CC: Ohad Ben-Cohen o...@wizery.com
CC: Benoit Cousson bcous...@baylibre.com
---
.../bindings/remoteproc/wkup_m3_rproc.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
new file mode 100644
index 000..e9dd909
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
@@ -0,0 +1,46 @@
+Wakeup M3 Remote Proc Driver
+=
+
+TI AMx3 Family devices use a Cortex M3 co-processor to help with various
+low power tasks that cannot be controlled from the MPU. The CM3 requires
+a firmware binary to accomplish this and communicates with the MPU through
+IPC registers present in the SoCs control module. The wkup_m3 remoteproc
+driver handles the loading of the firmware and exposes an API to
+communicate with the wkup_m3 through the use of the IPC registers and a
+mailbox.
+
+Wkup M3 Device Node:
+
+A wkup_m3 device node is used to represent a wakeup M3 IP instance within
+a SoC. The sub-mailboxes are represented as child node of this parent node.
+
+Required properties:
+
+- compatible: Should be ti,am3353-wkup-m3 for AM33xx SoCs
+- reg: Contains the wkup_m3 register address ranges for
+ umem, dmem, and ipc-regs.
+- reg-names: Names for reg addresses given above
+- interrupts: Contains the interrupt information for the wkup_m3
+ interrupt that signals the MPU.
+- ti,hwmods: Name of the hwmod associated with the mailbox
+- ti,no-reset-on-init: Reset is handled after fw has been loaded, not at
+ init of hwmod.
+- mbox-names: Name of the mbox channel for the IPC framework
+- mbox:Phandle used by IPC framework to get correct
mbox
+ channel for communication.
+
+Example:
+
+/* AM33xx */
+wkup_m3: wkup_m3@44d0 {
+ compatible = ti,am3353-wkup-m3;
+ reg = 0x44d0 0x4000
+ 0x44d8 0x2000
+ 0x44e11324 0x0024;
+ reg-names = m3_umem, m3_dmem, ipc_regs;
+ interrupts = 78;
+ ti,hwmods = wkup_m3;
+ ti,no-reset-on-init;
+ mbox-names = wkup_m3;
+ mbox = mailbox mbox_wkupm3;
+};
--
1.9.0
--
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 v4 07/11] ARM: dts: am33xx: Update wkup_m3 node
Allow interrupt for wkup_m3 to be set from DT, add regs for
IPC regs to allow pm code to communicate with wkup_m3, and add data
needed for mailbox channel.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
CC: Ohad Ben-Cohen o...@wizery.com
CC: Benoit Cousson bcous...@baylibre.com
---
arch/arm/boot/dts/am33xx.dtsi | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6f8f7cf..fe0cff5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -736,10 +736,15 @@
wkup_m3: wkup_m3@44d0 {
compatible = ti,am3353-wkup-m3;
- reg = 0x44d0 0x4000/* M3 UMEM */
- 0x44d8 0x2000; /* M3 DMEM */
+ reg = 0x44d0 0x4000
+ 0x44d8 0x2000
+ 0x44e11324 0x0024;
+ reg-names = m3_umem, m3_dmem, ipc_regs;
+ interrupts = 78;
ti,hwmods = wkup_m3;
ti,no-reset-on-init;
+ mbox-names = wkup_m3;
+ mbox = mailbox mbox_wkupm3;
};
elm: elm@4808 {
--
1.9.0
--
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 v4 08/11] ARM: OMAP2+: AM33XX: Reserve memory to comply with EMIF spec
From: Vaibhav Bedia vaibhav.be...@ti.com
SDRAM controller on AM33XX requires that a modification of certain
bit-fields in PWR_MGMT_CTRL register (ref. section 7.3.5.13 in
AM335x-Rev H) is followed by a dummy read access to SDRAM. This
scenario arises when entering a low power state like DeepSleep.
To ensure that the read is not from a cached region we reserve
some memory during bootup using the arm_memblock_steal() API. The
original call to omap_reserve is removed as it is not used in any
way on am335x.
A subsequent patch will pass along the location of the reserved
memory location to the AM335x suspend handler which modifies the
PWR_MGMT_CTRL register in the EMIF.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Left as is because of use in sram code when EMIF is off to avoid
copying additional code. Also uses hardcoded virtual address now
to avoid problems with himem
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/common.c| 32
arch/arm/mach-omap2/common.h| 4
arch/arm/mach-omap2/io.c| 1 +
4 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 9480997..d2c435e 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -163,7 +163,7 @@ static const char *am33xx_boards_compat[] __initconst = {
};
DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device Tree))
- .reserve= omap_reserve,
+ .reserve= am33xx_reserve,
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
.init_irq = omap_intc_of_init,
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9e..df6394e 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -15,10 +15,14 @@
#include linux/kernel.h
#include linux/init.h
#include linux/platform_data/dsp-omap.h
+#include asm/memblock.h
+#include asm/mach/map.h
#include common.h
#include omap-secure.h
+#define AM33XX_DRAM_SYNC_VA 0xfe60
+
/*
* Stub function for OMAP2 so that common files
* continue to build when custom builds are used
@@ -34,3 +38,31 @@ void __init omap_reserve(void)
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
}
+
+static phys_addr_t am33xx_paddr;
+static u32 am33xx_size;
+
+/* Steal one page physical memory for uncached read DeepSleep */
+void __init am33xx_reserve(void)
+{
+ am33xx_size = ALIGN(PAGE_SIZE, SZ_1M);
+ am33xx_paddr = arm_memblock_steal(am33xx_size, SZ_1M);
+
+ omap_reserve();
+}
+
+void __iomem *am33xx_dram_sync;
+
+void __init am33xx_dram_sync_init(void)
+{
+ struct map_desc dram_io_desc[1];
+
+ dram_io_desc[0].virtual = AM33XX_DRAM_SYNC_VA;
+ dram_io_desc[0].pfn = __phys_to_pfn(am33xx_paddr);
+ dram_io_desc[0].length = am33xx_size;
+ dram_io_desc[0].type = MT_MEMORY_RW_SO;
+
+ iotable_init(dram_io_desc, ARRAY_SIZE(dram_io_desc));
+
+ am33xx_dram_sync = (void __iomem *) dram_io_desc[0].virtual;
+}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b2d252b..1536338 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -316,6 +316,10 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap2_hsmmc_info;
extern void omap_reserve(void);
+extern void am33xx_reserve(void);
+extern void am33xx_dram_sync_init(void);
+extern void __iomem *am33xx_dram_sync;
+
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 8f55945..4d4d150 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -313,6 +313,7 @@ void __init ti81xx_map_io(void)
void __init am33xx_map_io(void)
{
iotable_init(omapam33xx_io_desc, ARRAY_SIZE(omapam33xx_io_desc));
+ am33xx_dram_sync_init();
}
#endif
--
1.9.0
--
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 v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x Technical Reference Manual.
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate the resume process. As part of
the boot process, the assembly code is copied over to OCMCRAM
using the OMAP SRAM code so it can be executed to turn of the
EMIF.
AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 and Standby entry and exit. WKUP_M3 takes care
of the clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep.
The WKUP_M3 is managed by a remoteproc driver. The PM code hooks
into the remoteproc driver through an rproc_ready callback to
allow PM features to become available once the firmware for the
wkup_m3 has been loaded. This code maintains its own state machine
for the wkup_m3 so that it can be used in the manner intended for
low power modes.
In the current implementation when the suspend process
is initiated, MPU interrupts the WKUP_M3 to let it know about
the intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM. The assembly code puts the external RAM in self-refresh
mode, gates the MPU clock, and then finally executes the WFI
instruction. Execution of the WFI instruction with MPU clock gated
triggers another interrupt to the WKUP_M3 which then continues
with the power down sequence wherein the clockdomain and
powerdomain transition takes place. As part of the sleep sequence,
WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
execution on WKUP_M3 causes the hardware to disable the main
oscillator of the SoC and from here system remains in sleep state
until a wake source brings the system into resume path.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
Code is based on work by Vaibhav Bedia.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Remove all direct wkup_m3 usage and moved to rproc driver introduced
in previous patch.
arch/arm/mach-omap2/pm33xx.c | 346 +++
arch/arm/mach-omap2/pm33xx.h | 64
2 files changed, 410 insertions(+)
create mode 100644 arch/arm/mach-omap2/pm33xx.c
create mode 100644 arch/arm/mach-omap2/pm33xx.h
diff --git a/arch/arm/mach-omap2/pm33xx.c b/arch/arm/mach-omap2/pm33xx.c
new file mode 100644
index 000..30d0f7d
--- /dev/null
+++ b/arch/arm/mach-omap2/pm33xx.c
@@ -0,0 +1,346 @@
+/*
+ * AM33XX Power Management Routines
+ *
+ * Copyright (C) 2012-2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia, Dave Gerlach
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/cpu.h
+#include linux/err.h
+#include linux/firmware.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/suspend.h
+#include linux/completion.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/ti_emif.h
+#include linux/omap-mailbox.h
+#include linux/sizes.h
+
+#include asm/suspend.h
+#include asm/proc-fns.h
+#include asm/fncpy.h
+#include asm/system_misc.h
+
+#include pm.h
+#include cm33xx.h
+#include pm33xx.h
+#include common.h
+#include clockdomain.h
+#include powerdomain.h
+#include soc.h
+#include sram.h
+
+static void __iomem *am33xx_emif_base;
+static struct powerdomain *cefuse_pwrdm, *gfx_pwrdm, *per_pwrdm, *mpu_pwrdm;
+static struct clockdomain *gfx_l4ls_clkdm;
+
+static struct am33xx_pm_context *am33xx_pm;
+
+static DECLARE_COMPLETION(am33xx_pm_sync);
+
+static void (*am33xx_do_wfi_sram)(struct am33xx_suspend_params *);
+
+static struct am33xx_suspend_params susp_params;
+
+#ifdef CONFIG_SUSPEND
+
+static int am33xx_do_sram_idle(long unsigned int unused)
+{
+ am33xx_do_wfi_sram(susp_params);
+ return 0;
+}
+
[PATCH v4 11/11] ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds
With all the requisite changes in place we can now enable the basic
PM support for AM33xx. This patch updates the various OMAP files
to enable suspend-resume on AM33xx.
Because the suspend resume functionality is different on AM33xx
than other OMAP platforms due to the need for M3 firmware and an
IPC channel to be in place, separate PM ops are used instead of
omap_pm_ops. These are now set using omap2_common_suspend_init
so the AM33xx can make a decision at runtime to enable suspend based
on the availabilty of aforementioned requirements.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Updated for rproc usage now.
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/Makefile | 2 ++
arch/arm/mach-omap2/common.h | 9 +
arch/arm/mach-omap2/io.c | 1 +
arch/arm/mach-omap2/pm.h | 5 +
arch/arm/mach-omap2/sram.c | 10 +-
arch/arm/mach-omap2/sram.h | 2 ++
7 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1c1ed73..f8a56e5 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -59,6 +59,7 @@ config SOC_AM33XX
select ARCH_OMAP2PLUS
select ARCH_HAS_OPP
select ARM_CPU_SUSPEND if PM
+ select WKUP_M3_RPROC if PM
config SOC_AM43XX
bool TI AM43x
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8ca99e9..3c8d30c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o
obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_AM33XX) += pm33xx.o sleep33xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
@@ -97,6 +98,7 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
+AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 1536338..1bcd475 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -75,6 +75,15 @@ static inline int omap4_pm_init_early(void)
}
#endif
+#if defined(CONFIG_PM) defined(CONFIG_SOC_AM33XX)
+int am33xx_pm_init(void);
+#else
+static inline int am33xx_pm_init(void)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_OMAP_MUX
int omap_mux_late_init(void);
#else
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4d4d150..fb23f83 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -590,6 +590,7 @@ void __init am33xx_init_early(void)
void __init am33xx_init_late(void)
{
omap_common_late_init();
+ am33xx_pm_init();
}
#endif
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index e150102..b6f72a4 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,6 +81,11 @@ extern unsigned int omap3_do_wfi_sz;
/* ... and its pointer from SRAM after copy */
extern void (*omap3_do_wfi_sram)(void);
+/* am33xx_do_wfi function pointer and size, for copy to SRAM */
+extern void am33xx_do_wfi(void);
+extern unsigned int am33xx_do_wfi_sz;
+extern unsigned int am33xx_resume_offset;
+
/* save_secure_ram_context function pointer and size, for copy to SRAM */
extern int save_secure_ram_context(u32 *addr);
extern unsigned int save_secure_ram_context_sz;
diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index ddf1818..2227f20 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -154,7 +154,7 @@ static void __init omap2_map_sram(void)
omap_sram_size -= SZ_16K;
}
#endif
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || soc_is_am33xx()) {
/*
* SRAM must be marked as non-cached on OMAP3 since the
* CORE DPLL M2 divider change code (in SRAM) runs with the
@@ -285,10 +285,18 @@ static inline int omap34xx_sram_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
+#ifdef CONFIG_SOC_AM33XX
static inline int am33xx_sram_init(void)
{
+ am33xx_push_sram_idle();
return 0;
}
+#else
+static inline int am33xx_sram_init(void)
+{
+ return 0;
+}
+#endif
int __init omap_sram_init(void)
{
diff --git a/arch/arm/mach-omap2/sram.h b/arch/arm/mach-omap2/sram.h
index ca7277c..24788b5 100644
--- a/arch/arm/mach-omap2/sram.h
+++ b/arch/arm/mach-omap2/sram.h
@@ -62,8 +62,10 @@ extern unsigned long omap3_sram_configure_core_dpll_sz;
#ifdef CONFIG_PM
extern void omap_push_sram_idle(void);
+extern void am33xx_push_sram_idle(void);
#else
static inline void
[PATCH v4 09/11] ARM: OMAP2+: AM33XX: Add assembly code for PM operations
In preparation for suspend-resume support for AM33XX, add
the assembly file with the code which is copied to internal
memory (OCMC RAM) during bootup and runs from there.
As part of the low power entry (DeepSleep0 mode in AM33XX TRM),
the code running from OCMC RAM does the following
1. Stores the EMIF configuration
2. Puts external memory in self-refresh
3. Disables EMIF clock
4. Executes WFI after writing to MPU_CLKCTRL register.
If no interrupts have come, WFI execution on MPU gets registered
as an interrupt with the WKUP-M3. WKUP-M3 takes care of disabling
some clocks which MPU should not (L3, L4, OCMC RAM etc) and takes
care of clockdomain and powerdomain transitions as part of the
DeepSleep0 mode entry.
In case a late interrupt comes in, WFI ends up as a NOP and MPU
continues execution from internal memory. The 'abort path' code
undoes whatever was done as part of the low power entry and indicates
a suspend failure by passing a non-zero value to the cpu_resume routine.
The 'resume path' code is similar to the 'abort path' with the key
difference of MMU being enabled in the 'abort path' but being
disabled in the 'resume path' due to MPU getting powered off.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
v3-v4:
Added macros for magic numbers, some optimizations to avoid
hangs spotted when bringing DDR3 out of self refresh.
arch/arm/mach-omap2/sleep33xx.S | 380
1 file changed, 380 insertions(+)
create mode 100644 arch/arm/mach-omap2/sleep33xx.S
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
new file mode 100644
index 000..98772a6
--- /dev/null
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -0,0 +1,380 @@
+/*
+ * Low level suspend code for AM33XX SoCs
+ *
+ * Copyright (C) 2012-2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Vaibhav Bedia, Dave Gerlach
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/linkage.h
+#include linux/ti_emif.h
+#include asm/memory.h
+#include asm/assembler.h
+
+#include iomap.h
+#include cm33xx.h
+#include pm33xx.h
+#include prm33xx.h
+
+#define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES 0x00a0
+#define EMIF_POWER_MGMT_SR_TIMER_MASK 0x00f0
+
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE 0x0200
+#define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK 0x0700
+#define EMIF_POWER_MGMT_DELAY_PERIOD 0x1000
+
+#define AM33XX_CM_CLKCTRL_MODULEMODE_DISABLE 0x0003
+#define AM33XX_CM_CLKCTRL_MODULEMODE_ENABLE0x0002
+
+ .text
+ .align 3
+
+/*
+ * This routine is executed from internal RAM and expects some
+ * parameters to be passed in r0 _strictly_ in following order:
+ * 1) emif_addr_virt - ioremapped EMIF address
+ * 2) mem_type - 2 - DDR2, 3- DDR3
+ * 3) dram_sync_word - uncached word in SDRAM
+ *
+ * The code loads these values taking r0 value as reference to
+ * the array in registers starting from r0, i.e emif_addr_virt
+ * goes to r1, mem_type goes to r2 and and so on. These are
+ * then saved into memory locations before proceeding with the
+ * sleep sequence and hence registers r0, r1 etc can still be
+ * used in the rest of the sleep code.
+ */
+
+ENTRY(am33xx_do_wfi)
+ stmfd sp!, {r4 - r11, lr} @ save registers on stack
+
+ ldm r0, {r1-r3} @ gather values passed
+
+ /* Save the values passed */
+ str r1, emif_addr_virt
+ str r2, mem_type
+ str r3, dram_sync_word
+
+ /*
+* Flush all data from the L1 and L2 data cache before disabling
+* SCTLR.C bit.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ /*
+* Clear the SCTLR.C bit to prevent further data cache
+* allocation. Clearing SCTLR.C would make all the data accesses
+* strongly ordered and would not hit the cache.
+*/
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
+ /*
+* Invalidate L1 and L2 data cache.
+*/
+ ldr r1, kernel_flush
+ blx r1
+
+ /* Save EMIF configuration */
+ ldr r0, emif_addr_virt
+ ldr r1, [r0, #EMIF_SDRAM_CONFIG]
+ str r1, emif_sdcfg_val
+ ldr r1, [r0, #EMIF_SDRAM_REFRESH_CONTROL]
+ str r1, emif_ref_ctrl_val
+ ldr r1, [r0, #EMIF_SDRAM_TIMING_1]
+ str r1, emif_timing1_val
+
[PATCH] ASoC: omap-dmic: Use devm_clk_get
This patch introduces the use of managed interfaces like devm_clk_get
and does away with the clk_puts in the probe and remove functions. A
label is also done away with.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
---
This is a follow up to ASoC: omap-dmic: use managed interfaces which
failed to apply as the other devm_ functions were introduced by a patch
ASoC: omap-dmic: Use devm_snd_soc_register_component.
sound/soc/omap/omap-dmic.c | 29 ++---
1 file changed, 6 insertions(+), 23 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index f125eb9..0f34e28 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -466,7 +466,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
mutex_init(dmic-mutex);
- dmic-fclk = clk_get(dmic-dev, fck);
+ dmic-fclk = devm_clk_get(dmic-dev, fck);
if (IS_ERR(dmic-fclk)) {
dev_err(dmic-dev, cant get fck\n);
return -ENODEV;
@@ -475,8 +475,7 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, dma);
if (!res) {
dev_err(dmic-dev, invalid dma memory resource\n);
- ret = -ENODEV;
- goto err_put_clk;
+ return -ENODEV;
}
dmic-dma_data.addr = res-start + OMAP_DMIC_DATA_REG;
@@ -484,34 +483,19 @@ static int asoc_dmic_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
dmic-io_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(dmic-io_base)) {
- ret = PTR_ERR(dmic-io_base);
- goto err_put_clk;
- }
+ if (IS_ERR(dmic-io_base))
+ return PTR_ERR(dmic-io_base);
ret = devm_snd_soc_register_component(pdev-dev,
omap_dmic_component,
omap_dmic_dai, 1);
if (ret)
- goto err_put_clk;
+ return ret;
ret = omap_pcm_platform_register(pdev-dev);
if (ret)
- goto err_put_clk;
-
- return 0;
-
-err_put_clk:
- clk_put(dmic-fclk);
- return ret;
-}
-
-static int asoc_dmic_remove(struct platform_device *pdev)
-{
- struct omap_dmic *dmic = platform_get_drvdata(pdev);
-
- clk_put(dmic-fclk);
+ return ret;
return 0;
}
@@ -529,7 +513,6 @@ static struct platform_driver asoc_dmic_driver = {
.of_match_table = omap_dmic_of_match,
},
.probe = asoc_dmic_probe,
- .remove = asoc_dmic_remove,
};
module_platform_driver(asoc_dmic_driver);
--
1.9.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
