Re: [PATCH v2 09/26] irqchip: mxs: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:24AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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 v2 22/26] ARM: imx: avic: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:37AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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 v2 23/26] ARM: imx: tzic: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:38AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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 v14 1/6] mmc: omap_hsmmc: Enable SDIO interrupt
Hi Tony, Andreas, On 08/24/2014 08:41 PM, Tony Lindgren wrote: * Florian Vaussard florian.vauss...@epfl.ch [140824 01:29]: --- a/arch/arm/boot/dts/omap3-overo-base.dtsi +++ b/arch/arm/boot/dts/omap3-overo-base.dtsi @@ -119,7 +119,7 @@ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_clk.sdmmc2_clk */ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_cmd.sdmmc2_cmd */ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat0.sdmmc2_dat0 */ -OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */ +OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* sdmmc2_dat1.sdmmc2_dat1 */ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat2.sdmmc2_dat2 */ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc2_dat3.sdmmc2_dat3 */ ; No need to have PIN_OFF_WAKEUPENABLE any longer here, it gets enabled automatically after you do request_irq on it. Good to know. @@ -195,6 +195,9 @@ vmmc_aux-supply = w3cbw003c_wifi_nreset; bus-width = 4; cap-sdio-irq; + +interrupts-extended = intc 86, + gpio5 5 GPIO_ACTIVE_HIGH; /* gpio_133 (mmc2.dat1) */ non-removable; }; The second interrupt here just needs to be omap3_pmx_core (or omap3_pmx_core2 depending where it's located) with the offset to the dat1 pin from it's padconf area. For example, on mmc3 it should be: interrupts-extended = intc 94 omap3_pmx_core2 0x46; So you need to look it up from the TRM to figure out the right offset for mmc2. So now I have: interrupts-extended = intc 86 omap3_pmx_core OMAP_IOPAD_OFFSET(0x215e, 0x2030); I checked that I have the right offset in the .dtb for mmc2_dat according to the TRM (0x12E). But the wake-up path seems to be not working any more. I get several timeouts and a BUG() inside libertas SDIO driver. [ 16.286407] libertas_sdio mmc0:0001:1 (unregistered net_device): 00:19:88:15:b7:c0, fw 9.70.3p24, cap 0x0303 [ 16.292938] libertas_sdio mmc0:0001:1 wlan0: Marvell WLAN 802.11 adapter [ 16.302703] cfg80211: Calling CRDA to update world regulatory domain [ 24.758880] libertas_sdio mmc0:0001:1 wlan0: command 0x0006 timed out [ 24.759582] libertas_sdio mmc0:0001:1 wlan0: Timeout submitting command 0x0006 [ 24.761962] libertas_sdio mmc0:0001:1 wlan0: PREP_CMD: command 0x0006 failed: -110 [ 24.762084] libertas_sdio: Resetting card... [ 29.768890] libertas_sdio mmc0:0001:1 wlan0: command 0x0006 timed out [ 29.769378] libertas_sdio mmc0:0001:1 wlan0: Timeout submitting command 0x0006 [ 29.769531] libertas_sdio mmc0:0001:1 wlan0: PREP_CMD: command 0x0006 failed: -110 [ 29.770538] [ cut here ] [ 29.775421] kernel BUG at drivers/net/wireless/libertas/if_sdio.c:226! [ 29.782287] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM [ 29.788055] Modules linked in: [ 29.791290] CPU: 0 PID: 471 Comm: ksdioirqd/mmc0 Not tainted 3.16.1mobovero-00014-g9e1602f-dirty #690 [ 29.800994] task: dd81c480 ti: def48000 task.ti: def48000 [ 29.806671] PC is at if_sdio_interrupt+0x1b4/0x330 [ 29.811737] LR is at if_sdio_interrupt+0x194/0x330 [ 29.816772] pc : [c0428e68]lr : [c0428e48]psr: 200e0093 [ 29.816772] sp : def49ed0 ip : def49ed0 fp : def49efc [ 29.828826] r10: r9 : r8 : dece0024 [ 29.834320] r7 : 016e r6 : 0001 r5 : 800e0013 r4 : decc43c0 [ 29.841186] r3 : 051b r2 : 03b3 r1 : 0001 r0 : 0001 [ 29.848052] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 29.855834] Control: 10c5387d Table: 9edd4019 DAC: 0015 [ 29.861877] Process ksdioirqd/mmc0 (pid: 471, stack limit = 0xdef48240) [ 29.868835] Stack: (0xdef49ed0 to 0xdef4a000) [ 29.873413] 9ec0: c04d82b0 0001 [ 29.882019] 9ee0: df4c9000 dec7f400 0001 def49f34 def49f00 c04d010c c0428cc0 [ 29.890624] 9f00: 00100100 00200200 def49f34 dec7f400 def48000 dec7f400 def48000 7fff [ 29.899230] 9f20: 0001 def49f64 def49f38 c04d02f8 c04d00d4 c04d024c 0001 [ 29.907836] 9f40: dd9bda40 dec7f400 c04d024c def49fac def49f68 [ 29.916442] 9f60: c005c724 c04d0258 def49f94 c0066e50 dec7f400 def49f7c [ 29.925048] 9f80: def49f7c def49f88 def49f88 dd9bda40 c005c644 [ 29.933654] 9fa0: def49fb0 c000f1a8 c005c650 [ 29.942260] 9fc0: [ 29.950866] 9fe0: 0013
Re: [PATCH v14 1/6] mmc: omap_hsmmc: Enable SDIO interrupt
Hi Andreas, On 08/24/2014 07:46 PM, Andreas Fenkart wrote: Hi Florian 2014-08-24 10:26 GMT+02:00 Florian Vaussard florian.vauss...@epfl.ch: Hi Andreas, On 05/29/2014 10:28 AM, Andreas Fenkart wrote: There have been various patches floating around for enabling the SDIO IRQ for hsmmc, but none of them ever got merged. [...] For now, only support SDIO interrupt if we are booted with a separate wake-irq configued via device tree. This is because omaps need the wake-irq for idle states, and some omaps need special quirks. And we don't want to add new legacy mux platform init code callbacks any longer as we are moving to DT based booting anyways. To use it, you need to specify the wake-irq using the interrupts-extended property. First, thanks a lot for your tenacity on this patchset, this was a long needed feature. I enabled the SDIO interrupt, and got the throughput of my 88W8686-based chip multiplied by 15. Nice! I just have an issue with the wake-up path, and maybe you could help me. According to the DM3730 TRM, the MMC2 has the SWAKEUP path. So first I tried to give the same wake-irq as the MMC's one, but omap_hsmmc_configure_wake_irq() fails to request it, as they are not IRQF_SHARED. Why can't it be shared? I first tried interrupts-extended = intc 86 intc 86; but devm_request_irq() in omap_hsmmc_configure_wake_irq() fails. But this is probably not the good approach, as Tony pointed out. Regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 27/27] OMAPDSS: connector-analog-tv: Add DT support
On 26/08/14 19:58, Laurent Pinchart wrote:
Hi Tomi,
On Monday 16 December 2013 16:56:34 Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 ++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
b/drivers/video/omap2/displays-new/connector-analog-tv.c index
ccd9073f706f..ebed25a86487 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings =
{ .interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in-ops.atv-set_timings(in, ddata-timings);
in-ops.atv-set_type(in, ddata-connector_type);
-in-ops.atv-invert_vid_out_polarity(in, ddata-invert_polarity);
+
+if (!ddata-dev-of_node)
+in-ops.atv-invert_vid_out_polarity(in,
+ddata-invert_polarity);
r = in-ops.atv-enable(in);
if (r)
@@ -205,6 +215,35 @@ static int tvc_probe_pdata(struct platform_device
*pdev) return 0;
}
+static int tvc_probe_of(struct platform_device *pdev)
+{
+struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+struct device_node *node = pdev-dev.of_node;
+struct omap_dss_device *in;
+const struct of_device_id *match;
+const struct tvc_of_data *data;
+
+match = of_match_node(tvc_of_match, pdev-dev.of_node);
+if (!match) {
+dev_err(pdev-dev, unsupported device\n);
+return -ENODEV;
+}
+
+data = match-data;
+
+in = omapdss_of_find_source_for_first_ep(node);
+if (IS_ERR(in)) {
+dev_err(pdev-dev, failed to find video source\n);
+return PTR_ERR(in);
+}
+
+ddata-in = in;
+
+ddata-connector_type = data-connector_type;
+
+return 0;
+}
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +261,10 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+} else if (pdev-dev.of_node) {
+r = tvc_probe_of(pdev);
+if (r)
+return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device
*pdev) return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+.connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+{
+.compatible = svideo-connector,
+.data = tv_svideo_data,
+},
+{
+.compatible = composite-video-connector,
I've just noticed that this doesn't match the bindings that document the
compatible value to be composite-connector.
Thanks. arch/arm/boot/dts/omap3-n900.dts uses the same value as in the
bindings document, so I think the proper fix is to change the compatible
value for this driver. I'll make a patch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] clk: ti: change clock init to use generic of_clk_init
On 08/21/2014 04:49 PM, Tero Kristo wrote: Previously, the TI clock driver initialized all the clocks hierarchically under each separate clock provider node. Now, each clock that requires IO access will instead check their parent node to find out which IO range to use. This patch allows the TI clock driver to use a few new features provided by the generic of_clk_init, and also allows registration of clock nodes outside the clock hierarchy (for example, any external clocks.) Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Mike Turquette mturque...@linaro.org Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Jyri Sarha jsa...@ti.com Cc: Stefan Assmann sassm...@kpanic.de Tested-by: Jyri Sarha jsa...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFI] OMAP4 ISS: l3_interrupt_handler Errors due to wrong initialized iss_fck?
Hi,
I am trying to get both CSI2 interfaces up and running through the ISS
on the v3.16 kernel for the TI OMAP4 Blaze platform (omap4430 ES 2.3
revision).
Trough a omap_device_build() call (using the iss omap_hwmod) I call the
iss_probe function. It devm_clk_get's both the iss_ctrlclk and the iss_fck.
Since I am building the kernel with the omap4-sdp-es23plus device tree
appended, I figured I need to define the iss_fck in the omap44xx-clocks.dtsi
file, right after the iss_ctrlclk, as following:
iss_fck: iss_fck {
#clock-cells = 0;
compatible = ti,gate-clock;
clocks = ducati_clk_mux_ck;
ti,bit-shift = 1;
reg = 0x1020;
};
For that, I used the information in [1], the TI clock tree tool and the
Linux documentation.
Now the omap4iss_get() call throws L3 Standard Errors, right after the first
time the interrupts, set in iss_enable_interrupts, occur. I am pretty sure the
cause for that is a wrong initialization of the iss_fck (since I haven't
changed much more), even though the kernel runs through and the
cat clk_summary ¦ grep iss command in /sys/kernel/debug/clk/ writes:
iss_ctrlclk 019600 0
iss_fck 01 4 0
Could there be an error in the device tree entry stated above? Or might I be
missing something else? Has anyone ever enabled iss_fck through device tree?
BTW I've also added iss_fck as an opt_clk in omap_hwmod_44xx_data and added
the clock to the ti_dt_clk struct.
Thanks,
Martin
[1] http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAJ.zip
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
On Mon, 25 Aug 2014, Tony Lindgren wrote:
Looks like MUSB cable removal can cause wake-up interrupts to
stop working for device tree based booting at least for UART3
even as nothing is dynamically remuxed. This can be fixed by
calling reconfigure_io_chain() for device tree based booting
in hwmod code.
Weird, nice find. Do you know if this applies to all OMAPs, or just
OMAP3?
Note that we already do that for legacy booting
if the legacy mux is configured.
My guess is that this is related to UART3 and MUSB ULPI
hsusb0_data0 and hsusb0_data1 support for Carkit mode that
somehow affect the configured IO chain for UART3 and require
rearming the wake-up interrupts.
In general, for device tree based booting, pinctrl-single
calls the rearm hook that in turn calls reconfigure_io_chain
so calling reconfigure_io_chain should not be needed from the
hwmod code for other events.
So let's limit the hwmod rearming of iochain only to
HWMOD_FORCE_MSTANDBY where MUSB is currently the only user
of it. If we see other devices needing similar changes we can
add more checks for it.
Could you please add a new hwmod flag for this case? Maybe something like
HWMOD_RECONFIG_IO_CHAIN? I think that would make the code easier to read
and more maintainable, since the workaround would then be explicitly
connected with that particular workaround's flag. Looks like we have
several flag bits left. Plus if we wind up having to set
HWMOD_FORCE_MSTANDBY for other devices that might not need the I/O chain
reconfiguration, we won't have to reimplement this flag workaround.
regards
- Paul
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2185,6 +2185,8 @@ static int _enable(struct omap_hwmod *oh)
oh-mux-pads_dynamic))) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_ENABLED);
_reconfigure_io_chain();
+ } else if (oh-flags HWMOD_FORCE_MSTANDBY) {
+ _reconfigure_io_chain();
}
_add_initiator_dep(oh, mpu_oh);
@@ -2291,6 +2293,8 @@ static int _idle(struct omap_hwmod *oh)
if (oh-mux oh-mux-pads_dynamic) {
omap_hwmod_mux(oh-mux, _HWMOD_STATE_IDLE);
_reconfigure_io_chain();
+ } else if (oh-flags HWMOD_FORCE_MSTANDBY) {
+ _reconfigure_io_chain();
}
oh-_state = _HWMOD_STATE_IDLE;
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.17-rc1
Here are some basic OMAP test results for Linux v3.17-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc1/20140821122707/ Test summary Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm Boot to userspace: FAIL ( 1/14): 2430sdp skip ( 1/14): 5912osk Pass (12/14): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm PM: chip off via dynamic idle: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm vmlinux object size (delta in bytes from test_v3.16 (19583ca584d6f574384e17fe7613dfaeadcdc4a6)): text data bsstotal kernel +32887 -316+2432 +35003 omap1_defconfig +32855 -276+2464 +35043 omap1_defconfig_1510innovator_only +32887 -284+2432 +35035 omap1_defconfig_5912osk_only +481763 +66520+1216 +549499 multi_v7_defconfig +54469 -34424+1728 +21773 omap2plus_defconfig +64694+3072+1896 +69662 omap2plus_defconfig_2430sdp_only +62773+3248+1856 +67877 omap2plus_defconfig_am33xx_only +67285+3960+1792 +73037 omap2plus_defconfig_am43xx_only +54745 -34392+1728 +22081 omap2plus_defconfig_cpupm +68357+7408+1856 +77621 omap2plus_defconfig_dra7xx_only +31837 -38048+1508-4703 omap2plus_defconfig_n800_multi_omap2xxx +34917 -16112+1508 +20313 omap2plus_defconfig_n800_only_a +49829 -34536+1792 +17085 omap2plus_defconfig_no_pm +50337 -39096+1856 +13097 omap2plus_defconfig_omap2_4_only +63013+3184+1728 +67925 omap2plus_defconfig_omap3_4_only +67805+3312+1792 +72909 omap2plus_defconfig_omap5_only +13572 +184 -804 +12952 rmk_omap3430_ldp_allnoconfig +30262+1140 +992 +32394 rmk_omap3430_ldp_oldconfig +13964 +376+3372 +17712 rmk_omap4430_sdp_allnoconfig +37282 +952 +788 +39022 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.16 (19583ca584d6f574384e17fe7613dfaeadcdc4a6)) avail rsrvd high freed board kconfig -160k 160k . . 2420n800 omap2plus_defconfig_n800_only_a -160k 160k . . 2430sdpomap2plus_defconfig -16k16k . . 3517evmomap2plus_defconfig -16k16k . . 3530es3beagle omap2plus_defconfig -16k16k . . 3730beaglexm omap2plus_defconfig -16k16k . . 37xxevmomap2plus_defconfig -16k16k . . 4430es2panda omap2plus_defconfig -16k16k . . 4460pandaesomap2plus_defconfig -16k16k . . 4460varsomom omap2plus_defconfig -24k24k . . 5430es2uevmomap2plus_defconfig -68k68k . . am335xbone
OMAP baseline test results for v3.17-rc2
Here are some basic OMAP test results for Linux v3.17-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc2/20140825183438/ Test summary Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 1/14): 2430sdp skip ( 1/14): 5912osk Pass (12/14): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm PM: chip off via dynamic idle: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm vmlinux object size (delta in bytes from test_v3.17-rc1 (7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9)): text data bsstotal kernel +980 +320+1012 omap1_defconfig +1012 -80+1004 omap1_defconfig_1510innovator_only +101200+1012 omap1_defconfig_5912osk_only +1644 +160+1660 multi_v7_defconfig +900 +160 +916 omap2plus_defconfig +836 -160 +820 omap2plus_defconfig_2430sdp_only +836 +80 +844 omap2plus_defconfig_am33xx_only +900 +80 +908 omap2plus_defconfig_am43xx_only +900 +480 +948 omap2plus_defconfig_cpupm +836 +80 +844 omap2plus_defconfig_dra7xx_only +316 +80 +324 omap2plus_defconfig_n800_multi_omap2xxx +316 -160 +300 omap2plus_defconfig_n800_only_a +900 -240 +876 omap2plus_defconfig_no_pm +900 -160 +884 omap2plus_defconfig_omap2_4_only +836 +80 +844 omap2plus_defconfig_omap3_4_only +836 -160 +820 omap2plus_defconfig_omap5_only +180 +16 -32 +164 rmk_omap3430_ldp_allnoconfig +852 +80 +860 rmk_omap3430_ldp_oldconfig +212 +12 -32 +192 rmk_omap4430_sdp_allnoconfig +852 -160 +836 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.17-rc1 (7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled
* Paul Walmsley p...@pwsan.com [140827 09:38]: On Mon, 25 Aug 2014, Tony Lindgren wrote: Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Weird, nice find. Do you know if this applies to all OMAPs, or just OMAP3? I guess it may also apply to others too, but so far I've only seen this on omap3 occasionally. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Could you please add a new hwmod flag for this case? Maybe something like HWMOD_RECONFIG_IO_CHAIN? I think that would make the code easier to read and more maintainable, since the workaround would then be explicitly connected with that particular workaround's flag. Looks like we have several flag bits left. Plus if we wind up having to set HWMOD_FORCE_MSTANDBY for other devices that might not need the I/O chain reconfiguration, we won't have to reimplement this flag workaround. OK that's a good idea as this may not be always HWMOD_FORCE_MSTANDBY. I guess I initially assumed that this was always related to HWMOD_FORCE_MSTANDBY as that's what seemed to hang the system until I figured it was just the wake-up events that stopped working :) I'll do that as a follow-up patch as I already sent the pull request for the $subject one as it was hanging my tests occasionally. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 21/26] irqchip: or1k-pic: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:36AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com This (and the other two openrisc related patches in this series) works fine in my setup at least. Acked-by: Stefan Kristiansson stefan.kristians...@saunalahti.fi -- 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/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
Nishanth Menon n...@ti.com writes:
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Signed-off-by: Nishanth Menon n...@ti.com
---
nit: this is part of a fixes series, but it's more of a new feature.
That being said, the feature is needed and looks OK, except for...
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* BUG if we have messed up database */
+ BUG_ON(new_pwrst PWRDM_POWER_ON);
I don't think this is BUG() worthy, and should have a saner way to recover.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
On Wed, Aug 27, 2014 at 1:27 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Nishanth Menon n...@ti.com writes:
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Signed-off-by: Nishanth Menon n...@ti.com
---
nit: this is part of a fixes series, but it's more of a new feature.
That being said, the feature is needed and looks OK, except for...
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* BUG if we have messed up database */
+ BUG_ON(new_pwrst PWRDM_POWER_ON);
I don't think this is BUG() worthy, and should have a saner way to recover.
it is not even a legal value to have a power state higher than ON. I
mean, yeah, we can do
if (new_pwrst PWRDM_POWER_ON) {
pr_debug(powerdomain: %s: fix my powerdomain max to ON\n,
pwrdm-name);
return PWRDM_POWER_ON;
}
if that is your suggestion here, personally, I would use a WARN at least here..
--
---
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 0/7] ARM: OMAP4+: powerdomain fixes
On Friday 22 August 2014 09:49 AM, Nishanth Menon wrote: Hi, The following series are various fixes and improvements for powerdomain support in OMAP4+. This is part 1/6 series which eventually enables framework for suspend-to-ram and cpuidle for OMAP5 and DRA7 Each of series is based on v3.17-rc1 and this specific series is available: weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/powerdomain-fixes Series looks good to me. The achievable power state doesn't apeal much but with so many variations of SOCs, descopes etc, it probably makes sense. Once you update Kevin's BUG() comments, feel free to add my ack. 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 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
On Wed, Aug 27, 2014 at 11:35 AM, Nishanth Menon n...@ti.com wrote:
On Wed, Aug 27, 2014 at 1:27 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Nishanth Menon n...@ti.com writes:
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Signed-off-by: Nishanth Menon n...@ti.com
---
nit: this is part of a fixes series, but it's more of a new feature.
That being said, the feature is needed and looks OK, except for...
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* BUG if we have messed up database */
+ BUG_ON(new_pwrst PWRDM_POWER_ON);
I don't think this is BUG() worthy, and should have a saner way to recover.
it is not even a legal value to have a power state higher than ON. I
mean, yeah, we can do
if (new_pwrst PWRDM_POWER_ON) {
pr_debug(powerdomain: %s: fix my powerdomain max to ON\n,
pwrdm-name);
return PWRDM_POWER_ON;
}
if that is your suggestion here, personally, I would use a WARN at least
here..
WARN, pr_warn() as you like.
The point is that BUG* calls panic() and locks up the system tight.
As what your'e adding is not fatal to the entire system, you should
not be using bug. From asm-generic/bug.h:
*
* Don't use BUG() or BUG_ON() unless there's really no way out; one
* example might be detecting data structure corruption in the middle
* of an operation that can't be backed out of. If the (sub)system
* can somehow continue operating, perhaps with reduced functionality,
* it's probably not BUG-worthy.
*
* If you're tempted to BUG(), think again: is completely giving up
* really the *only* solution? There are usually better options, where
* users don't need to reboot ASAP and can mostly shut down cleanly.
*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ARM: OMAP3+: PRM: fix up prm_handling
On Friday 22 August 2014 09:51 AM, Nishanth Menon wrote: The following series are various fixes and improvements for PRM for I/O Daisy chain support in OMAP4+ with device tree. This is part 2/6 series which eventually enables framework for suspend-to-ram and cpuidle for OMAP5 and DRA7 Each of series is based on v3.17-rc1 and this specific series is available: weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/prm-fixes Series also looks reasonable. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
Nishanth Menon n...@ti.com writes: From: Santosh Shilimkar santosh.shilim...@ti.com With EMIF clock-domain put under hardware supervised control, memory corruption and untraceable crashes are observed on OMAP5. Further investigation revealed that there is a weakness in the PRCM on this specific dynamic depedency. hmm, weakness. That's a rather polite way of saying bug. :) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
powerdomain configuration in OMAP is done using PWRSTCTRL register for
each power domain. However, PRCM lets us write any value we'd like to
the logic and power domain target states, however the SoC integration
tends to actually function only at a few discrete states. These valid
states are already in our powerdomains_xxx_data.c file.
So, provide a function to easily query valid low power state that the
power domain is allowed to go to.
Based on work originally done by Jean Pihet j-pi...@ti.com
https://patchwork.kernel.org/patch/1325091/ . There is no attempt to
create a new powerdomain solution here, except fixing issues seen
attempting invalid programming attempts. Future consolidation to the
generic powerdomain framework should consider this requirement as
well.
Similar solutions have been done in product kernels in the past such
as:
https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c
Reviewed-by: Kevin Hilman khil...@linaro.org
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Not posting the entire series again and updating just this patch..
V2: drop BUG in favor of WARN, picked up Santosh and Kevin's acks.
V1: https://patchwork.kernel.org/patch/4764131/
arch/arm/mach-omap2/powerdomain.c | 76 +
arch/arm/mach-omap2/powerdomain.h |3 ++
2 files changed, 79 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index f391948..7fb033e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1081,6 +1081,82 @@ int pwrdm_post_transition(struct powerdomain *pwrdm)
}
/**
+ * pwrdm_get_valid_lp_state() - Find best match deep power state
+ * @pwrdm: power domain for which we want to find best match
+ * @is_logic_state: Are we looking for logic state match here? Should
+ * be one of PWRDM_xxx macro values
+ * @req_state: requested power state
+ *
+ * Returns: closest match for requested power state. default fallback
+ * is RET for logic state and ON for power state.
+ *
+ * This does a search from the power domain data looking for the
+ * closest valid power domain state that the hardware can achieve.
+ * PRCM definitions for PWRSTCTRL allows us to program whatever
+ * configuration we'd like, and PRCM will actually attempt such
+ * a transition, however if the powerdomain does not actually support it,
+ * we endup with a hung system. The valid power domain states are already
+ * available in our powerdomain data files. So this function tries to do
+ * the following:
+ * a) find if we have an exact match to the request - no issues.
+ * b) else find if a deeper power state is possible.
+ * c) failing which, it tries to find closest higher power state for the
+ * request.
+ */
+u8 pwrdm_get_valid_lp_state(struct powerdomain *pwrdm,
+ bool is_logic_state, u8 req_state)
+{
+ u8 pwrdm_states = is_logic_state ? pwrdm-pwrsts_logic_ret :
+ pwrdm-pwrsts;
+ /* For logic, ret is highest and others, ON is highest */
+ u8 default_pwrst = is_logic_state ? PWRDM_POWER_RET : PWRDM_POWER_ON;
+ u8 new_pwrst;
+ bool found;
+
+ /* If it is already supported, nothing to search */
+ if (pwrdm_states BIT(req_state))
+ return req_state;
+
+ if (!req_state)
+ goto up_search;
+
+ /*
+* So, we dont have a exact match
+* Can we get a deeper power state match?
+*/
+ new_pwrst = req_state - 1;
+ found = true;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ /* No match even at OFF? Not available */
+ if (new_pwrst == PWRDM_POWER_OFF) {
+ found = false;
+ break;
+ }
+ new_pwrst--;
+ }
+
+ if (found)
+ goto done;
+
+up_search:
+ /* OK, no deeper ones, can we get a higher match? */
+ new_pwrst = req_state + 1;
+ while (!(pwrdm_states BIT(new_pwrst))) {
+ if (new_pwrst PWRDM_POWER_ON) {
+ WARN(1, powerdomain: %s: Fix max powerstate to ON\n,
+pwrdm-name);
+ return PWRDM_POWER_ON;
+ }
+
+ if (new_pwrst == default_pwrst)
+ break;
+ new_pwrst++;
+ }
+done:
+ return new_pwrst;
+}
+
+/**
* omap_set_pwrdm_state - change a powerdomain's current power state
* @pwrdm: struct powerdomain * to change the power state of
* @pwrst: power state to change to
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index a754c82..11bd4dd 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -220,6 +220,9 @@ struct voltagedomain *pwrdm_get_voltdm(struct powerdomain
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
Kevin
+ save_state = 0;
+ break;
+ }
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
b/arch/arm/mach-omap2/omap-wakeupgen.c
index e844e16..87c1c0d 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -381,7 +381,7 @@ static struct notifier_block irq_notifier_block = {
static void __init irq_pm_init(void)
{
/* FIXME: Remove this when MPU OSWR support is added */
- if (!soc_is_omap54xx())
+ if (!soc_is_omap54xx() !soc_is_dra7xx())
cpu_pm_register_notifier(irq_notifier_block);
}
#else
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index b6f243d..c063833 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -36,6 +36,8 @@ struct power_state {
struct list_head node;
};
+static u32 cpu_suspend_state = PWRDM_POWER_OFF;
+
static LIST_HEAD(pwrst_list);
#ifdef CONFIG_SUSPEND
@@ -66,7 +68,7 @@ static int omap4_pm_suspend(void)
* domain CSWR is not supported by hardware.
* More details can be found in OMAP4430 TRM section 4.3.4.2.
*/
- omap4_enter_lowpower(cpu_id, PWRDM_POWER_OFF);
+ omap4_enter_lowpower(cpu_id, cpu_suspend_state);
/* Restore next powerdomain state */
list_for_each_entry(pwrst, pwrst_list, node) {
@@ -112,8 +114,11 @@ static int __init pwrdms_setup(struct powerdomain
*pwrdm, void *unused)
* through hotplug path and CPU0 explicitly programmed
* further down in the code path
*/
- if (!strncmp(pwrdm-name, cpu, 3))
+ if (!strncmp(pwrdm-name, cpu, 3)) {
+ if (soc_is_omap54xx() || soc_is_dra7xx())
+ cpu_suspend_state = PWRDM_POWER_RET;
return 0;
+ }
pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
if (!pwrst)
--
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/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
--
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 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
Nishanth Menon n...@ti.com writes: The following series are various fixes and improvements for supporting suspend-to-ram. This depends on the following for basic functionality: series 1/6 where powerdomain fixes were involved. I had a look through this series, and it looks good overall. I think Daniel needs to weigh in on the CPUidle driver, otherwise. Reviewed-by: Kevin Hilman khil...@linaro.org I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch. Tested-by: Kevin Hilman khil...@linaro.org Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
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 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
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/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
On 08/27/2014 02:43 PM, Santosh Shilimkar wrote:
On Wednesday 27 August 2014 03:41 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140827 12:05]:
On 08/27/2014 01:58 PM, Kevin Hilman wrote:
Nishanth Menon n...@ti.com writes:
From: Rajendra Nayak rna...@ti.com
On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
and instead attempt a CPU RET and side effect, MPU RET in suspend.
Signed-off-by: Rajendra Nayak rna...@ti.com
[n...@ti.com: update to do save_state only on DRA7]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4
arch/arm/mach-omap2/omap-wakeupgen.c |2 +-
arch/arm/mach-omap2/pm44xx.c |9 +++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 207fce2..0d640eb 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -242,6 +242,10 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
+ if (soc_is_omap54xx() || soc_is_dra7xx()) {
Aren't we trying to get away from these soc_* checks for anything other
than init code?
I would expect that to take place in stages as part of which the next
level of cleanup is to move PRM into drivers. Currently our wakeupgen,
prm code does have quiet a few needs of dealing with soc_is checks
primarily from having to re-architect code in two different directions
- we want to move into just one direction eventually - to prm drivers
and as less code in mach-omap2 which is already in the works.
Why don't you just set some flag at init time based on the
soc_is check and then test that here? That limits the use of
soc_is to init code only which makes it easier to phase it
out completely eventually.
Indeed. Infact the version of the code I tried posting last year was
using a flag which was initialised during init. Same can be
done her.
OK. will try something along that line in the next rev.
--
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 15/15] tty: serial: 8250: omap: add dma support
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
OK and if the DMA works with PM, then I don't see why we would not
want to have it automatically enabled.
I re-did that part where the registers are restored. Mostly for that
reason to use function in runtime_resume() as in set_termios(). I think
that is cute :) _And_ if somebody changes here something and breaks it
then it doesn't work with and without runtime-pm. It looks like the
omap-serial doesn't restore the XON1 XOFF1 registers.
While at it I made sure that it works as good as I could and that means:
core_pwrdm
(ON),OFF:182,RET:21,INA:131,ON:335,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
The core off part with DMA looks like a no no:
I #if 0 the block in where it assigned up.dma. With this I hit
core-off. Step two was
|static void omap8250_update_scr(struct uart_8250_port *up,
| struct omap8250_priv *priv)
|{
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL |
OMAP_UART_SCR_DMAMODE_1);
|serial_out(up, UART_OMAP_SCR, priv-scr | |OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr);
|}
which means I just enable DMA mode in UART and disable it. No DMA
operations were performed.
With this change I see a lost character now and then which means the
UART-IP goes into off and loses its context. Good. However I don't see
core off anymore. This looks like a bug beyond my responsibilities :)
I added code to cancel and start DMA transfers in runtime suspend
callbacks.
However core-off with DMA won't work. I think we could document this in
the binding document. What do you think?
BTW, looks like the ports move around now though. If set a port
to disabled with status = disabled; in the .dts file, you'll get
a different console which does not happen with omap-serial I believe.
You a right. I fixed it in the 8250-core code.
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140827 12:54]:
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
OK and if the DMA works with PM, then I don't see why we would not
want to have it automatically enabled.
I re-did that part where the registers are restored. Mostly for that
reason to use function in runtime_resume() as in set_termios(). I think
that is cute :) _And_ if somebody changes here something and breaks it
then it doesn't work with and without runtime-pm. It looks like the
omap-serial doesn't restore the XON1 XOFF1 registers.
While at it I made sure that it works as good as I could and that means:
core_pwrdm
(ON),OFF:182,RET:21,INA:131,ON:335,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
Hey that's great, that's the ultimate torture test here!
There's nothing like rebooting the system every time you hit
idle and still have drivers working :)
The core off part with DMA looks like a no no:
I #if 0 the block in where it assigned up.dma. With this I hit
core-off. Step two was
|static void omap8250_update_scr(struct uart_8250_port *up,
| struct omap8250_priv *priv)
|{
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL |
OMAP_UART_SCR_DMAMODE_1);
|serial_out(up, UART_OMAP_SCR, priv-scr | |OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr);
|}
which means I just enable DMA mode in UART and disable it. No DMA
operations were performed.
With this change I see a lost character now and then which means the
UART-IP goes into off and loses its context. Good. However I don't see
core off anymore. This looks like a bug beyond my responsibilities :)
OK, that sounds like a bug still lurking around somewhere. The core
domain won't hit idle if there are any hardware pieces blocking.
I added code to cancel and start DMA transfers in runtime suspend
callbacks.
Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or
also the dmaengine calls?
However core-off with DMA won't work. I think we could document this in
the binding document. What do you think?
There should not be such a limitation though. Maybe dump out the values
of cm_idlest_per and cm_idlest1_core for working and failing off idle
cases and see what the difference is?
It could be the either the dma or the uart hardware blocking. I guess
it could be also an issue with runtime pm use somewhere.
BTW, looks like the ports move around now though. If set a port
to disabled with status = disabled; in the .dts file, you'll get
a different console which does not happen with omap-serial I believe.
You a right. I fixed it in the 8250-core code.
OK 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 V2 4/7] ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
Nishanth Menon n...@ti.com writes: powerdomain configuration in OMAP is done using PWRSTCTRL register for each power domain. However, PRCM lets us write any value we'd like to the logic and power domain target states, however the SoC integration tends to actually function only at a few discrete states. These valid states are already in our powerdomains_xxx_data.c file. So, provide a function to easily query valid low power state that the power domain is allowed to go to. Based on work originally done by Jean Pihet j-pi...@ti.com https://patchwork.kernel.org/patch/1325091/ . There is no attempt to create a new powerdomain solution here, except fixing issues seen attempting invalid programming attempts. Future consolidation to the generic powerdomain framework should consider this requirement as well. Similar solutions have been done in product kernels in the past such as: https://android.googlesource.com/kernel/omap.git/+blame/android-omap-panda-3.0/arch/arm/mach-omap2/pm44xx.c Reviewed-by: Kevin Hilman khil...@linaro.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- Not posting the entire series again and updating just this patch.. V2: drop BUG in favor of WARN, picked up Santosh and Kevin's acks. Looks good, thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes against v3.17-rc2
On Tue, Aug 26, 2014 at 03:14:13PM -0700, Tony Lindgren wrote: The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef: Linux 3.17-rc2 (2014-08-25 15:36:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/fixes-against-rc2 for you to fetch changes up to 8fd46439e1f5a7f86d76a08733459b74debd9468: ARM: dts: omap54xx-clocks: Fix the l3 and l4 clock rates (2014-08-26 13:04:00 -0700) Pulled, thanks. -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 0/5] Clean-up for twl4030-usb
Hi, Here are few more patches for v3.18 to clean up twl4030-usb. These are based on the two regression fixes I sent earlier: [PATCH] usb: phy: twl4030-usb: Fix regressions to runtime PM on omaps [PATCH] usb: phy: twl4030-usb: Fix lost interrupts after ID pin goes down For testing with v3.17-rc2, you probably also want to revert commit a9232076374334ca2bc2a448dfde96d38a54349a until that hits the mainline tree. And you may also want to apply the following patch if testing with PM: [PATCH] mfd: twl4030-power: Fix PM idle pin configuration to not conflict with regulators I've also pushed these patches with the optional patches into a temporary testing branch at [1]. Regards, Tony [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.17/testing-pending-usb Tony Lindgren (5): usb: phy: twl4030-usb: Remove unused irq_enabled usb: phy: twl4030-usb: Simplify phy init to use runtime PM usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls usb: phy: twl4030-usb: Remove asleep and rely on runtime PM usb: phy: twl4030-usb: Use mutex instead of spinlock for protecting the data drivers/phy/phy-twl4030-usb.c | 124 ++ drivers/usb/phy/phy-twl6030-usb.c | 2 - 2 files changed, 46 insertions(+), 80 deletions(-) -- 1.8.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls
We don't need twl4030_phy_power() any longer now that we have
the runtime PM calls. Let's get rid of it as it's confusing.
No functional changes, just move the code and use res instead
of ret as we are not returning that value.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 72 +++
1 file changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index a292db0..519cc90 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -383,45 +383,6 @@ static void __twl4030_phy_power(struct twl4030_usb *twl,
int on)
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) 0);
}
-static void twl4030_phy_power(struct twl4030_usb *twl, int on)
-{
- int ret;
-
- if (on) {
- ret = regulator_enable(twl-usb3v1);
- if (ret)
- dev_err(twl-dev, Failed to enable usb3v1\n);
-
- ret = regulator_enable(twl-usb1v8);
- if (ret)
- dev_err(twl-dev, Failed to enable usb1v8\n);
-
- /*
-* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
-* in twl4030) resets the VUSB_DEDICATED2 register. This reset
-* enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to
-* SLEEP. We work around this by clearing the bit after usv3v1
-* is re-activated. This ensures that VUSB3V1 is really active.
-*/
- twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
-
- ret = regulator_enable(twl-usb1v5);
- if (ret)
- dev_err(twl-dev, Failed to enable usb1v5\n);
-
- __twl4030_phy_power(twl, 1);
- twl4030_usb_write(twl, PHY_CLK_CTRL,
- twl4030_usb_read(twl, PHY_CLK_CTRL) |
- (PHY_CLK_CTRL_CLOCKGATING_EN |
- PHY_CLK_CTRL_CLK32K_EN));
- } else {
- __twl4030_phy_power(twl, 0);
- regulator_disable(twl-usb1v5);
- regulator_disable(twl-usb1v8);
- regulator_disable(twl-usb3v1);
- }
-}
-
static int twl4030_usb_runtime_suspend(struct device *dev)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
@@ -430,7 +391,10 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
if (twl-asleep)
return 0;
- twl4030_phy_power(twl, 0);
+ __twl4030_phy_power(twl, 0);
+ regulator_disable(twl-usb1v5);
+ regulator_disable(twl-usb1v8);
+ regulator_disable(twl-usb3v1);
twl-asleep = 1;
return 0;
@@ -439,12 +403,38 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
static int twl4030_usb_runtime_resume(struct device *dev)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
+ int res;
dev_dbg(twl-dev, %s\n, __func__);
if (!twl-asleep)
return 0;
- twl4030_phy_power(twl, 1);
+ res = regulator_enable(twl-usb3v1);
+ if (res)
+ dev_err(twl-dev, Failed to enable usb3v1\n);
+
+ res = regulator_enable(twl-usb1v8);
+ if (res)
+ dev_err(twl-dev, Failed to enable usb1v8\n);
+
+ /*
+* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
+* in twl4030) resets the VUSB_DEDICATED2 register. This reset
+* enables VUSB3V1_SLEEP bit that remaps usb3v1 ACTIVE state to
+* SLEEP. We work around this by clearing the bit after usv3v1
+* is re-activated. This ensures that VUSB3V1 is really active.
+*/
+ twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
+
+ res = regulator_enable(twl-usb1v5);
+ if (res)
+ dev_err(twl-dev, Failed to enable usb1v5\n);
+
+ __twl4030_phy_power(twl, 1);
+ twl4030_usb_write(twl, PHY_CLK_CTRL,
+ twl4030_usb_read(twl, PHY_CLK_CTRL) |
+ (PHY_CLK_CTRL_CLOCKGATING_EN |
+ PHY_CLK_CTRL_CLK32K_EN));
twl-asleep = 0;
return 0;
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] usb: phy: twl4030-usb: Use mutex instead of spinlock for protecting the data
We're using threaded irq on a I2C bus and we're sleeping in
twl4030_usb_irq() as it calls twl4030_usb_linkstat() which
calls the i2c functions. If we ever need to lock for longer
I2C transaction sequences a mutex will allow us to do that
easily.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 24ff3c6..1e0e2d1 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -28,7 +28,6 @@
#include linux/init.h
#include linux/interrupt.h
#include linux/platform_device.h
-#include linux/spinlock.h
#include linux/workqueue.h
#include linux/io.h
#include linux/delay.h
@@ -155,7 +154,7 @@ struct twl4030_usb {
struct regulator*usb3v1;
/* for vbus reporting with irqs disabled */
- spinlock_t lock;
+ struct mutexlock;
/* pin configuration */
enum twl4030_usb_mode usb_mode;
@@ -516,13 +515,12 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct twl4030_usb *twl = dev_get_drvdata(dev);
- unsigned long flags;
int ret = -EINVAL;
- spin_lock_irqsave(twl-lock, flags);
+ mutex_lock(twl-lock);
ret = sprintf(buf, %s\n,
twl-vbus_supplied ? on : off);
- spin_unlock_irqrestore(twl-lock, flags);
+ mutex_unlock(twl-lock);
return ret;
}
@@ -536,12 +534,12 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
status = twl4030_usb_linkstat(twl);
- spin_lock_irq(twl-lock);
+ mutex_lock(twl-lock);
if (status = 0 status != twl-linkstat) {
twl-linkstat = status;
status_changed = true;
}
- spin_unlock_irq(twl-lock);
+ mutex_unlock(twl-lock);
if (status_changed) {
/* FIXME add a set_power() method so that B-devices can
@@ -695,8 +693,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- /* init spinlock for workqueue */
- spin_lock_init(twl-lock);
+ /* init mutex for workqueue */
+ mutex_init(twl-lock);
INIT_DELAYED_WORK(twl-id_workaround_work, twl4030_id_workaround_work);
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: phy: twl4030-usb: Remove asleep and rely on runtime PM
There's no longer need for tracking the phy state in the driver
with asleep, we can now rely on runtime PM.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 519cc90..24ff3c6 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -163,7 +163,6 @@ struct twl4030_usb {
int irq;
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
- u8 asleep;
struct delayed_work id_workaround_work;
};
@@ -388,14 +387,13 @@ static int twl4030_usb_runtime_suspend(struct device *dev)
struct twl4030_usb *twl = dev_get_drvdata(dev);
dev_dbg(twl-dev, %s\n, __func__);
- if (twl-asleep)
+ if (pm_runtime_suspended(dev))
return 0;
__twl4030_phy_power(twl, 0);
regulator_disable(twl-usb1v5);
regulator_disable(twl-usb1v8);
regulator_disable(twl-usb3v1);
- twl-asleep = 1;
return 0;
}
@@ -406,7 +404,7 @@ static int twl4030_usb_runtime_resume(struct device *dev)
int res;
dev_dbg(twl-dev, %s\n, __func__);
- if (!twl-asleep)
+ if (pm_runtime_active(dev))
return 0;
res = regulator_enable(twl-usb3v1);
@@ -435,7 +433,6 @@ static int twl4030_usb_runtime_resume(struct device *dev)
twl4030_usb_read(twl, PHY_CLK_CTRL) |
(PHY_CLK_CTRL_CLOCKGATING_EN |
PHY_CLK_CTRL_CLK32K_EN));
- twl-asleep = 0;
return 0;
}
@@ -560,10 +557,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
*/
if ((status == OMAP_MUSB_VBUS_VALID) ||
(status == OMAP_MUSB_ID_GROUND)) {
- if (twl-asleep)
+ if (pm_runtime_suspended(twl-dev))
pm_runtime_get_sync(twl-dev);
} else {
- if (!twl-asleep) {
+ if (pm_runtime_active(twl-dev)) {
pm_runtime_mark_last_busy(twl-dev);
pm_runtime_put_autosuspend(twl-dev);
}
@@ -572,7 +569,7 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
}
/* don't schedule during sleep - irq works right then */
- if (status == OMAP_MUSB_ID_GROUND !twl-asleep) {
+ if (status == OMAP_MUSB_ID_GROUND pm_runtime_active(twl-dev)) {
cancel_delayed_work(twl-id_workaround_work);
schedule_delayed_work(twl-id_workaround_work, HZ);
}
@@ -674,7 +671,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-irq= platform_get_irq(pdev, 0);
twl-vbus_supplied = false;
twl-linkstat = -EINVAL;
- twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-phy.dev= twl-dev;
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] usb: phy: twl4030-usb: Remove unused irq_enabled
It's not being used any longer.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 2 --
drivers/usb/phy/phy-twl6030-usb.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 9cd33a4..bc28ecc 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -164,7 +164,6 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
u8 asleep;
- boolirq_enabled;
struct delayed_work id_workaround_work;
};
@@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* set_host() and/or set_peripheral() ... OTG_capable boards
* need both handles, otherwise just one suffices.
*/
- twl-irq_enabled = true;
status = devm_request_threaded_irq(twl-dev, twl-irq, NULL,
twl4030_usb_irq, IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT, twl4030_usb, twl);
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 04778cf..44ea082 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -104,7 +104,6 @@ struct twl6030_usb {
int irq2;
enum omap_musb_vbus_id_status linkstat;
u8 asleep;
- boolirq_enabled;
boolvbus_enable;
const char *regulator;
};
@@ -373,7 +372,6 @@ static int twl6030_usb_probe(struct platform_device *pdev)
INIT_WORK(twl-set_vbus_work, otg_set_vbus_work);
- twl-irq_enabled = true;
status = request_threaded_irq(twl-irq1, NULL, twl6030_usbotg_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
twl6030_usb, twl);
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] usb: phy: twl4030-usb: Simplify phy init to use runtime PM
We can now let the interrupt and delayed work do all that's
needed with runtime PM.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index bc28ecc..a292db0 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -471,16 +471,8 @@ static int twl4030_phy_power_on(struct phy *phy)
twl4030_usb_set_mode(twl, twl-usb_mode);
if (twl-usb_mode == T2_USB_MODE_ULPI)
twl4030_i2c_access(twl, 0);
+ schedule_delayed_work(twl-id_workaround_work, 0);
- /*
-* XXX When VBUS gets driven after musb goes to A mode,
-* ID_PRES related interrupts no longer arrive, why?
-* Register itself is updated fine though, so we must poll.
-*/
- if (twl-linkstat == OMAP_MUSB_ID_GROUND) {
- cancel_delayed_work(twl-id_workaround_work);
- schedule_delayed_work(twl-id_workaround_work, HZ);
- }
return 0;
}
@@ -612,16 +604,9 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
static int twl4030_phy_init(struct phy *phy)
{
struct twl4030_usb *twl = phy_get_drvdata(phy);
- enum omap_musb_vbus_id_status status;
pm_runtime_get_sync(twl-dev);
- status = twl4030_usb_linkstat(twl);
- twl-linkstat = status;
-
- if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
- omap_musb_mailbox(twl-linkstat);
-
- sysfs_notify(twl-dev-kobj, NULL, vbus);
+ schedule_delayed_work(twl-id_workaround_work, 0);
pm_runtime_mark_last_busy(twl-dev);
pm_runtime_put_autosuspend(twl-dev);
@@ -698,6 +683,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
twl-vbus_supplied = false;
+ twl-linkstat = -EINVAL;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: phy: twl4030-usb: Remove unused irq_enabled
Hi,
On Wed, Aug 27, 2014 at 04:28:07PM -0700, Tony Lindgren wrote:
It's not being used any longer.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/phy/phy-twl4030-usb.c | 2 --
drivers/usb/phy/phy-twl6030-usb.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 9cd33a4..bc28ecc 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -164,7 +164,6 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
u8 asleep;
- boolirq_enabled;
struct delayed_work id_workaround_work;
};
@@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* set_host() and/or set_peripheral() ... OTG_capable boards
* need both handles, otherwise just one suffices.
*/
- twl-irq_enabled = true;
status = devm_request_threaded_irq(twl-dev, twl-irq, NULL,
twl4030_usb_irq, IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT, twl4030_usb, twl);
can you split this into two patches ? drivers/phy will be taken by
Kishon and drivers/usb/phy by me. another possibility is that I get an
Acked-by from Kishon and I can take $subject as is.
--
balbi
signature.asc
Description: Digital signature
