Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Monday 15 October 2012 09:31 PM, Tony Lindgren wrote: * Mohammed, Afzalaf...@ti.com [121015 05:42]: On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote: Yes, then please do a second pull request for what's needed to apply the minimal DT bindings. For the DT binding, let's just leave out the timings for now as we can load those from auxdata. Then the binding for the timings can be added later on. So just the minimal binding using standard features for the iorange and interrupt. Ok, I will keep timings aside for now and proceed with DT (avoiding auxdata usage with generic routine looked to me a saner approach though, with an initial DT'fy delay) Oh well if you think it's easier to do the timings too in the DT binding, please go ahead with that. It may take some longer discussion on the lists for the binding though. But up to you. I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. Let me discuss internally and get back. Regards Afzal -- 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: [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
Hi Kevin,
Here's an updated version of this one, with the erratum coverage expanded
to include OMAP34xx/35xx.
I think this one can replace Tero's [PATCHv6 06/11] ARM: OMAP:
clockdomain: add support for preventing autodep delete and [PATCHv6
07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle. Tero,
please let us know if you feel otherwise.
The patch seems to pass testing on 37xx. Was not able to really test it
on 35xx due to PM regressions in v3.7-rc1.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Tue, 16 Oct 2012 00:08:53 -0600
Subject: [PATCH] ARM: OMAP3: PM: apply part of the erratum i582 workaround
On OMAP34xx/35xx, and OMAP36xx chips with ES 1.2, if the PER
powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
unusable. This is erratum i582 in the OMAP36xx Silicon Errata
document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 30 --
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 686137d..67d6613 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -91,6 +91,7 @@ extern void omap3_save_scratchpad_contents(void);
#define PM_RTA_ERRATUM_i608(1 0)
#define PM_SDRC_WAKEUP_ERRATUM_i583(1 1)
+#define PM_PER_MEMORIES_ERRATUM_i582 (1 2)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3)
extern u16 pm34xx_errata;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c0f8a78..2e0c9e8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -651,14 +651,17 @@ static void __init pm_errata_configure(void)
/* Enable the l2 cache toggling in sleep logic */
enable_omap3630_toggle_l2_on_restore();
if (omap_rev() OMAP3630_REV_ES1_2)
- pm34xx_errata |= PM_SDRC_WAKEUP_ERRATUM_i583;
+ pm34xx_errata |= (PM_SDRC_WAKEUP_ERRATUM_i583 |
+ PM_PER_MEMORIES_ERRATUM_i582);
+ } else if (cpu_is_omap34xx()) {
+ pm34xx_errata |= PM_PER_MEMORIES_ERRATUM_i582;
}
}
int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
- struct clockdomain *neon_clkdm, *mpu_clkdm;
+ struct clockdomain *neon_clkdm, *mpu_clkdm, *per_clkdm, *wkup_clkdm;
int ret;
if (!omap3_has_io_chain_ctrl())
@@ -710,6 +713,8 @@ int __init omap3_pm_init(void)
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
+ per_clkdm = clkdm_lookup(per_clkdm);
+ wkup_clkdm = clkdm_lookup(wkup_clkdm);
#ifdef CONFIG_SUSPEND
omap_pm_suspend = omap3_pm_suspend;
@@ -726,6 +731,27 @@ int __init omap3_pm_init(void)
if (IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))
omap3630_ctrl_disable_rta();
+ /*
+* The UART3/4 FIFO and the sidetone memory in McBSP2/3 are
+* not correctly reset when the PER powerdomain comes back
+* from OFF or OSWR when the CORE powerdomain is kept active.
+* See OMAP36xx Erratum i582 PER Domain reset issue after
+* Domain-OFF/OSWR Wakeup. This wakeup dependency is not a
+* complete workaround. The kernel must also prevent the PER
+* powerdomain from going to OSWR/OFF while the CORE
+* powerdomain is not going to OSWR/OFF. And if PER last
+* power state was off while CORE last power state was ON, the
+* UART3/4 and McBSP2/3 SIDETONE devices need to run a
+* self-test using their loopback tests; if that fails, those
+* devices are unusable until the PER/CORE can complete a transition
+* from ON to OSWR/OFF and then back to ON.
+*
+* XXX Technically this workaround is only needed if off-mode
+* or OSWR is enabled.
+*/
+ if (IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))
+
Re: omap DSS fails with tft410 driver panel?
On 2012-10-15 19:08, Enric Balletbo Serra wrote: Hi Tomi, Thanks for your answer. 2012/10/12 Tomi Valkeinen tomi.valkei...@ti.com: On 2012-10-11 18:58, Enric Balletbo Serra wrote: Hi all, I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi - tfp410) changes the panel driver used on some boards. I tested current linux-next-20101011 kernel with my IGEPv2 board and DSS fails with following error (see http://pastebin.com/VjPGCQDt for full log) : [ 21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.236236] omapfb omapfb: setup_plane failed Before checking what happens there is a known issue with this ? Works fine for me, although only with a quite minimal test environment. I tried with a minimal environment (without X) and I don't see the error, so looks you've reason and the problem is with my userspace application (X). OTOH, I don't see the video output. I remember that this worked before, but seems now is broken. I'll check mux and others hints to try to solve the problem .. It's not about muxing, but something else. So an earlier kernel works with the exact same userspace and kernel boot arguments? Then we probably have a bug in the kernel driver. But I can't say much from the debug prints, except that probably something goes wrong in the SETUP_PLANE ioctl. If you can, please add debug prints to omapfb-ioctl.c's omapfb_setup_plane() and print out the data in the omapfb_plane_info parameter, and also prints to the error code paths in the function. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2 0/2] USB: dwc3-exynos: Adding device tree support
Changes from v1: - Removed setting-up of dev.coherent_dma_mask, since of/platform.c itself takes care of it. Vivek Gautam (2): USB: dwc3-exynos: Add support for device tree USB: DWC3: EXYNOS: Remove platform data for dwc3-exynos drivers/usb/dwc3/dwc3-exynos.c | 36 1 files changed, 20 insertions(+), 16 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] USB: DWC3: EXYNOS: Remove platform data for dwc3-exynos
We are removing plat data which was used till now to init and
exit phy. We no longer need this since dwc3-core takes care of
initializing and shutting-down the phy using usb_phy_init()
and usb_phy_shutdown().
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index d11ef49..5a2a73f 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -92,7 +92,6 @@ static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
- struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
struct platform_device *dwc3;
struct dwc3_exynos *exynos;
struct clk *clk;
@@ -150,14 +149,6 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
clk_enable(exynos-clk);
- /* PHY initialization */
- if (!pdata) {
- dev_dbg(pdev-dev, missing platform data\n);
- } else {
- if (pdata-phy_init)
- pdata-phy_init(pdev, pdata-phy_type);
- }
-
ret = platform_device_add_resources(dwc3, pdev-resource,
pdev-num_resources);
if (ret) {
@@ -174,9 +165,6 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
return 0;
err4:
- if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, pdata-phy_type);
-
clk_disable(clk);
clk_put(clk);
err3:
@@ -192,7 +180,6 @@ err0:
static int __devexit dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
- struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
@@ -200,9 +187,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
dwc3_put_device_id(exynos-dwc3-id);
- if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, pdata-phy_type);
-
clk_disable(exynos-clk);
clk_put(exynos-clk);
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, ma, 2012-10-15 kello 18:02 -0700, Tony Lindgren kirjoitti: * Kevin Hilman khil...@deeprootsystems.com [121015 10:32]: Kalle Jokiniemi kalle.jokini...@jollamobile.com writes: Does not work for me :( As I said, the issue occurs for me when I enter static suspend (echo mem /sys/power/autosleep or /sys/power/state). I don't think doing this just in runtime pm will fix my issue. Or do those handlers get run in the normal suspend path as well? If the I2C device is still active during the suspend path, these handlers will get run by the PM domain code (in omap_device.) However, now that I think about it, the current omap_device PM domain code calls these at the noirq level, not the late/early level, so it does not address your original problem. :( I suspect we'll need this and your original patch. Have you checked that this is not related to flushing the posted write? If it is, reading back any register from the i2c controller after writing to it ensures the write actually reaches the i2c controller. The twl4030-irq handler (handle_twl4030_pih) function just reads the PIH irq status over the i2c and calls handle_nested_irq for each set module (like USB, GPIO, etc) irq bit. This does not clear the interrupt however, that is done in the nested interrupt, once it runs (by clearing the actual interrupt inside the module). I'm thinking now that it's actually this PIH handler that should be postponed until resume_noirq has finished. I had another idea as well yesterday to mark the secondary irq handlers with IRQF_EARLY_RESUME flag. Though that did not work on the quick test I did. Anyway new patch coming soon :) - Kalle 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
[PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..d11ef49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
#include core.h
@@ -87,6 +88,8 @@ err1:
return ret;
}
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we move to full device tree support this will vanish off.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
+
platform_set_drvdata(pdev, exynos);
devid = dwc3_get_device_id();
@@ -200,11 +211,20 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_dwc3_match[] = {
+ { .compatible = samsung,exynos-dwc3 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
+#endif
+
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name = exynos-dwc3,
+ .of_match_table = of_match_ptr(exynos_dwc3_match),
},
};
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: hwmod data: Fix wrong lostcontext_mask for OMAP4 l4_abe
The following commit added the support for the lostcontext_mask
along with the usage of the flag for l4_abe.
commit ce80979aedfce937926a8dd40a1f92fd4bc2fd53
Author: Tero Kristo t-kri...@ti.com
Date: Sun Sep 23 17:28:19 2012 -0600
ARM: OMAP4: hwmod data: add support for lostcontext_mask
Unfortunately, the l4_abe does not contain this memory and thus
cannot contain that flag.
Remove the flag from the l4_abe hwmod.
Change as well the mask for omap44xx_aess_hwmod to avoid missing
the status in case LOSTMEM_AESSMEM is set. The AESS logic does
not support retention and thus only the memory state is useful.
It is even mandatory to avoid a crash in the case of the AESS
resume.
TBD: Ideally each hwmod should contain an extra entry for memory
context attached to it. The AESS does contain only one, but some
IP like the IVAHD does have three memories with dedicated status.
The granularity is never used, but at least one global information
for all the memory banks is useful.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..c820de2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -203,9 +203,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
- .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
- .flags= HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
};
@@ -351,7 +349,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTCONTEXT_DFF_MASK,
+ .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OMAPDSS: HDMI: Create platform device to support audio
On 10/16/2012 03:27 AM, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accesory
devices. Such devices are then used by domain-specific drivers; audio in
this case.
Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
...
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].flags = IORESOURCE_MEM;
+
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
+ if (!res) {
+ DSSERR(can't get IORESOURCE_DMA HDMI\n);
+ return -EINVAL;
+ }
+
+ /* Pass this resource to audio_pdev */
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].flags = IORESOURCE_DMA;
+
+ /* create platform device for HDMI audio driver */
+ hdmi.audio_pdev = platform_device_register_simple(
+ omap_hdmi_audio,
+ -1, hdmi_aud_res,
+
ARRAY_SIZE(hdmi_aud_res));
Should you also update arch/arm/mach-omap2/devices.c to not register the same
device?
When we do not boot with DT devices.c will create the same device earlier
(without pdata) which will prevent this device to be created and at the end
will prevent omap_hdmi_audio driver to probe due to missing pdata...
+ if (IS_ERR(hdmi.audio_pdev)) {
+ DSSERR(Can't instantiate hdmi-audio\n);
+ return PTR_ERR(hdmi.audio_pdev);
+ }
+
+ return 0;
+}
+
--
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
[PATCH v3 0/3] USB: dwc3: Add suspend/resume support
Changes from v2: - Changed CONFIG_PM to CONFIG_PM_SLEEP - Used SET_SYSTEM_SLEEP_PM_OPS in dev_pm_ops - Modified the commit log for each of the patch - Added dwc3_core_init() during resume and dwc3_core_exit() during suspend in core.c Based on 'usb-next' of greg's tree. Tested USB detection and enumeration across multiple cycles of suspend/resume using 2.0 and 3.0 devices on D-link SS hub. Vikas Sajjan (3): usb: dwc3: Add the suspend/resume functionality usb: xhci: Add the suspend/resume functionality exynos5: usb: dwc3: Add suspend/resume functionality drivers/usb/dwc3/core.c| 44 drivers/usb/dwc3/dwc3-exynos.c | 31 drivers/usb/host/xhci-plat.c | 28 + 3 files changed, 103 insertions(+), 0 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] usb: dwc3: Add the suspend/resume functionality
Adds suspend and resume callbacks as part of the power management
support to DWC3 controller Driver.
This patch facilitates transition of DWC3 controller between D0 and D3
power states during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/core.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5db4c76..9f35cf8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = dwc3_core_init(dwc);
+ if (ret 0)
+ return ret;
+
+ switch (dwc-mode) {
+ case DWC3_MODE_DEVICE:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ break;
+ case DWC3_MODE_HOST:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+ break;
+ case DWC3_MODE_DRD:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ }
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
+ dwc3_core_exit(dwc);
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dwc3_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+};
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name = dwc3,
+ .pm = dwc3_pm_ops,
},
};
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] usb: xhci: Add the suspend/resume functionality
Adds power management support to XHCI platform driver.
This patch facilitates the transition of xHCI host controller
between S0 and S3/S4 power states, during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/host/xhci-plat.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..eaf3a07 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,39 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd= dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ /* Make sure that the HCD Core has set state to HC_STATE_SUSPENDED */
+ if (hcd-state != HC_STATE_SUSPENDED ||
+ xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+ return -EINVAL;
+
+ return xhci_suspend(xhci);
+}
+
+static int xhci_plat_resume(struct device *dev)
+{
+ struct usb_hcd *hcd= dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ return xhci_resume(xhci, 0);
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops xhci_plat_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+};
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
+ .pm = xhci_plat_pm_ops,
},
};
MODULE_ALIAS(platform:xhci-hcd);
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] exynos5: usb: dwc3: Add suspend/resume functionality
Adds suspend and resume callbacks to exynos dwc3 driver as part of
power management support.
This change does gating of dwc3 clock during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/dwc3-exynos.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..8623b70 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -15,6 +15,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
@@ -200,11 +201,41 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ clk_disable(exynos-clk);
+
+ return 0;
+}
+
+static int dwc3_exynos_resume(struct device *dev)
+{
+ struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+ clk_enable(exynos-clk);
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dwc3_exynos_suspend, dwc3_exynos_resume)
+};
+
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name = exynos-dwc3,
+ .pm = dwc3_exynos_pm_ops,
},
};
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..d11ef49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
#include core.h
@@ -87,6 +88,8 @@ err1:
return ret;
}
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+ * Right now device-tree probed devices don't get dma_mask set.
+ * Since shared usb code relies on it, set it here for now.
+ * Once we move to full device tree support this will vanish off.
+ */
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
says who ?
$ git grep -e dma_mask drivers/of/
drivers/of/platform.c: dev-dev.dma_mask = dev-archdata.dma_mask;
drivers/of/platform.c: dev-archdata.dma_mask = 0xUL;
drivers/of/platform.c: dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
drivers/of/platform.c: dev-dev.coherent_dma_mask = ~0;
drivers/of/platform.c: dev-dma_mask = ~0;
-ECONFUSED
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 2/3] usb: xhci: Add the suspend/resume functionality
Hi,
On Tue, Oct 16, 2012 at 03:15:37PM +0530, Vikas Sajjan wrote:
Adds power management support to XHCI platform driver.
This patch facilitates the transition of xHCI host controller
between S0 and S3/S4 power states, during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/host/xhci-plat.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..eaf3a07 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,39 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd= dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ /* Make sure that the HCD Core has set state to HC_STATE_SUSPENDED */
+ if (hcd-state != HC_STATE_SUSPENDED ||
+ xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+ return -EINVAL;
+
+ return xhci_suspend(xhci);
this is pretty much what xhci_pci_suspend() is doing. Sarah, would you
be ok with a patch such as:
usb: host: xhci: move HC_STATE_SUSPENDED check to xhci_suspend()
[ STILL NEED TO WRITE A PROPER COMMIT LOG ]
NYET-Signed-off-by: Felipe Balbi ba...@ti.com
---
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8345d7c..aeb3973 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -218,15 +218,8 @@ static void xhci_pci_remove(struct pci_dev *dev)
static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- int retval = 0;
- if (hcd-state != HC_STATE_SUSPENDED ||
- xhci-shared_hcd-state != HC_STATE_SUSPENDED)
- return -EINVAL;
-
- retval = xhci_suspend(xhci);
-
- return retval;
+ return xhci_suspend(xhci);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8d7fcbb..b85029e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -879,6 +879,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
struct usb_hcd *hcd = xhci_to_hcd(xhci);
u32 command;
+ if (hcd-state != HC_STATE_SUSPENDED ||
+ xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+ return -EINVAL;
+
spin_lock_irq(xhci-lock);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
clear_bit(HCD_FLAG_HW_ACCESSIBLE, xhci-shared_hcd-flags);
do you think there is any reason to keep replicating the
HC_STATE_SUSPENDED test all over the place ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..d11ef49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
#include core.h
@@ -87,6 +88,8 @@ err1:
return ret;
}
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we move to full device tree support this will vanish off.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
says who ?
$ git grep -e dma_mask drivers/of/
drivers/of/platform.c: dev-dev.dma_mask = dev-archdata.dma_mask;
drivers/of/platform.c: dev-archdata.dma_mask = 0xUL;
drivers/of/platform.c: dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
drivers/of/platform.c: dev-dev.coherent_dma_mask = ~0;
drivers/of/platform.c: dev-dma_mask = ~0;
-ECONFUSED
dma_mask is set under some ifdef except for dev-dma_mask = ~0;.
However I agree with you for coherent_dma_mask case.
Thanks
Kishon
--
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 1/3] usb: dwc3: Add the suspend/resume functionality
Hi,
On Tue, Oct 16, 2012 at 03:15:36PM +0530, Vikas Sajjan wrote:
Adds suspend and resume callbacks as part of the power management
support to DWC3 controller Driver.
This patch facilitates transition of DWC3 controller between D0 and D3
power states during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/core.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5db4c76..9f35cf8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = dwc3_core_init(dwc);
+ if (ret 0)
+ return ret;
+
+ switch (dwc-mode) {
+ case DWC3_MODE_DEVICE:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ break;
+ case DWC3_MODE_HOST:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+ break;
+ case DWC3_MODE_DRD:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ }
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
there is one check you need to do here. If you are playing the
peripheral role, you can't allow suspend unless link is in U3 or you're
not enumerated.
Have you tested running 'echo mem /sys/power/state' on your device
while you're transferring data in a USB session with the Host ?
I'll ask again, how was this tested ? What did you actually run (which
commands, which use cases have you validated) ? I'm not asking only
which platform you used, I need to know how you exercised this feature,
how did you trigger suspend/resume, in which conditions (enumerated ?
bus suspended ? no cable attached ?), etc.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi,
On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
Hi,
On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
This patch adds support to parse probe data for
dwc3-exynos driver using device tree.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..d11ef49 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
#include core.h
@@ -87,6 +88,8 @@ err1:
return ret;
}
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
{
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
goto err0;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we move to full device tree support this will vanish off.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = dwc3_exynos_dma_mask;
says who ?
$ git grep -e dma_mask drivers/of/
drivers/of/platform.c: dev-dev.dma_mask = dev-archdata.dma_mask;
drivers/of/platform.c: dev-archdata.dma_mask = 0xUL;
drivers/of/platform.c: dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
drivers/of/platform.c: dev-dev.coherent_dma_mask = ~0;
drivers/of/platform.c: dev-dma_mask = ~0;
-ECONFUSED
dma_mask is set under some ifdef except for dev-dma_mask = ~0;.
However I agree with you for coherent_dma_mask case.
indeed. Should we try to patch that instead ?
Rob, should we set dma_mask at the driver or do you have a nicer way to
handle it ??
--
balbi
signature.asc
Description: Digital signature
[PATCH 00/11] Minimum set of omap serial patches to fix merge window breakage
Hi, During the merge window, a series of patches from various people went in, allegedly fixing various problems with the OMAP serial driver. Unfortunately, there was not a full understanding of the issues I brought up here back in April, and so the fixes, while being individually correct, result in a worse situation with the driver than before. Specifically, this patch: commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 Author: Vikram Pandita vikram.pand...@ti.com Date: Thu Sep 6 15:45:37 2012 +0300 serial: omap: fix software flow control Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. does what it says on the tin - it fixes the register definitions so that we do end up enabling the right two software flow control bits. The down side is that there are other bugs in this area which have been exposed. For example: 1. the XON/XOFF registers aren't written to; their address is, but we will not be writing to the right registers because their access rules are not respected by the driver. These are by default zero. This means that with hardware assisted software flow control enabled, the port will now transmit an 0x00 byte for XON and XOFF events. 2. the driver set_termios function is not called for changes in software flow control settings if not accompanied by some other change. 3. the there isn't actually a way for the hardware assisted flow control to be used other than by increasing interrupt latency to cause the receiver hardware FIFO to fill. This will cause 0x00 bytes to be transmitted. There are two options to resolve this. The first one is to revert this patch to bring the driver back down to the pre-merge window state. The other is to apply this series of patches, which frankly I don't think is -rc material, even with the above regressions. Given that the above regressions were caused by a lack of due care and correct process (I had declared to TI that I had investigated these issues back in April), I believe that the right answer is to revert at least commit 957ee7270d, which should re-hide these other bugs in the driver. -- 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: UART: fix console UART mismatched runtime PM status
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Reviewed-by: Felipe Balbi ba...@ti.com
sorry for the issues caused.
--
balbi
signature.asc
Description: Digital signature
[PATCH 01/11] SERIAL: core: use local variable uport in uart_set_termios()
This is to make the following change more clear.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/serial_core.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0fcfd98..bc2065d 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1210,6 +1210,7 @@ static void uart_set_termios(struct tty_struct *tty,
struct ktermios *old_termios)
{
struct uart_state *state = tty-driver_data;
+ struct uart_port *uport = state-uart_port;
unsigned long flags;
unsigned int cflag = tty-termios.c_cflag;
@@ -1232,31 +1233,31 @@ static void uart_set_termios(struct tty_struct *tty,
/* Handle transition to B0 status */
if ((old_termios-c_cflag CBAUD) !(cflag CBAUD))
- uart_clear_mctrl(state-uart_port, TIOCM_RTS | TIOCM_DTR);
+ uart_clear_mctrl(uport, TIOCM_RTS | TIOCM_DTR);
/* Handle transition away from B0 status */
else if (!(old_termios-c_cflag CBAUD) (cflag CBAUD)) {
unsigned int mask = TIOCM_DTR;
if (!(cflag CRTSCTS) ||
!test_bit(TTY_THROTTLED, tty-flags))
mask |= TIOCM_RTS;
- uart_set_mctrl(state-uart_port, mask);
+ uart_set_mctrl(uport, mask);
}
/* Handle turning off CRTSCTS */
if ((old_termios-c_cflag CRTSCTS) !(cflag CRTSCTS)) {
- spin_lock_irqsave(state-uart_port-lock, flags);
+ spin_lock_irqsave(uport-lock, flags);
tty-hw_stopped = 0;
__uart_start(tty);
- spin_unlock_irqrestore(state-uart_port-lock, flags);
+ spin_unlock_irqrestore(uport-lock, flags);
}
/* Handle turning on CRTSCTS */
else if (!(old_termios-c_cflag CRTSCTS) (cflag CRTSCTS)) {
- spin_lock_irqsave(state-uart_port-lock, flags);
- if (!(state-uart_port-ops-get_mctrl(state-uart_port)
TIOCM_CTS)) {
+ spin_lock_irqsave(uport-lock, flags);
+ if (!(uport-ops-get_mctrl(uport) TIOCM_CTS)) {
tty-hw_stopped = 1;
- state-uart_port-ops-stop_tx(state-uart_port);
+ uport-ops-stop_tx(uport);
}
- spin_unlock_irqrestore(state-uart_port-lock, flags);
+ spin_unlock_irqrestore(uport-lock, flags);
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] SERIAL: core: add hardware assisted s/w flow control support
Ports which are capable of handling s/w flow control in hardware to
know when the s/w flow control termios settings are changed. Add a
flag to allow the low level serial drivers to indicate that they
support this, and these changes should be propagated to them.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/serial_core.c | 16 ++--
include/linux/serial_core.h |2 ++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index bc2065d..bd10bbd 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1213,7 +1213,19 @@ static void uart_set_termios(struct tty_struct *tty,
struct uart_port *uport = state-uart_port;
unsigned long flags;
unsigned int cflag = tty-termios.c_cflag;
+ unsigned int iflag_mask = IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK;
+ bool sw_changed = false;
+ /*
+* Drivers doing software flow control also need to know
+* about changes to these input settings.
+*/
+ if (uport-flags UPF_SOFT_FLOW) {
+ iflag_mask |= IXANY|IXON|IXOFF;
+ sw_changed =
+ tty-termios.c_cc[VSTART] != old_termios-c_cc[VSTART] ||
+ tty-termios.c_cc[VSTOP] != old_termios-c_cc[VSTOP];
+ }
/*
* These are the bits that are used to setup various
@@ -1221,11 +1233,11 @@ static void uart_set_termios(struct tty_struct *tty,
* bits in c_cflag; c_[io]speed will always be set
* appropriately by set_termios() in tty_ioctl.c
*/
-#define RELEVANT_IFLAG(iflag) ((iflag) (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
if ((cflag ^ old_termios-c_cflag) == 0
tty-termios.c_ospeed == old_termios-c_ospeed
tty-termios.c_ispeed == old_termios-c_ispeed
- RELEVANT_IFLAG(tty-termios.c_iflag ^ old_termios-c_iflag) == 0) {
+ ((tty-termios.c_iflag ^ old_termios-c_iflag) iflag_mask) == 0
+ !sw_changed) {
return;
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 3c43022..0005138 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -163,6 +163,8 @@ struct uart_port {
#define UPF_BUGGY_UART ((__force upf_t) (1 14))
#define UPF_NO_TXEN_TEST ((__force upf_t) (1 15))
#define UPF_MAGIC_MULTIPLIER ((__force upf_t) (1 16))
+/* Port has hardware-assisted s/w flow control */
+#define UPF_SOFT_FLOW ((__force upf_t) (1 22))
#define UPF_CONS_FLOW ((__force upf_t) (1 23))
#define UPF_SHARE_IRQ ((__force upf_t) (1 24))
#define UPF_EXAR_EFR ((__force upf_t) (1 25))
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] SERIAL: core: add hardware assisted h/w flow control support
Ports which are handling h/w flow control in hardware must not have
their RTS state altered depending on the tty's hardware-stopped state.
Avoid this additional logic when setting the termios state.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/serial_core.c |7 +++
include/linux/serial_core.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index bd10bbd..9d8796e 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1255,6 +1255,13 @@ static void uart_set_termios(struct tty_struct *tty,
uart_set_mctrl(uport, mask);
}
+ /*
+* If the port is doing h/w assisted flow control, do nothing.
+* We assume that tty-hw_stopped has never been set.
+*/
+ if (uport-flags UPF_HARD_FLOW)
+ return;
+
/* Handle turning off CRTSCTS */
if ((old_termios-c_cflag CRTSCTS) !(cflag CRTSCTS)) {
spin_lock_irqsave(uport-lock, flags);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 0005138..e2cda5d 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -163,6 +163,8 @@ struct uart_port {
#define UPF_BUGGY_UART ((__force upf_t) (1 14))
#define UPF_NO_TXEN_TEST ((__force upf_t) (1 15))
#define UPF_MAGIC_MULTIPLIER ((__force upf_t) (1 16))
+/* Port has hardware-assisted h/w flow control (iow, auto-RTS *not* auto-CTS)
*/
+#define UPF_HARD_FLOW ((__force upf_t) (1 21))
/* Port has hardware-assisted s/w flow control */
#define UPF_SOFT_FLOW ((__force upf_t) (1 22))
#define UPF_CONS_FLOW ((__force upf_t) (1 23))
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] SERIAL: core: add throttle/unthrottle callbacks for hardware assisted flow control
Add two callbacks for hardware assisted flow control; we need to know
when the tty layers want us to stop and restart due to their buffer
levels.
Call a driver specific throttle/unthrottle function if and only if the
driver indicates that it is using an enabled hardware assisted flow
control method, otherwise fall back to the non-hardware assisted
methods.
Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/serial_core.c | 31 +++
include/linux/serial_core.h |2 ++
2 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9d8796e..098bb99 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -610,27 +610,50 @@ static void uart_send_xchar(struct tty_struct *tty, char
ch)
static void uart_throttle(struct tty_struct *tty)
{
struct uart_state *state = tty-driver_data;
+ struct uart_port *port = state-uart_port;
+ uint32_t mask = 0;
if (I_IXOFF(tty))
+ mask |= UPF_SOFT_FLOW;
+ if (tty-termios.c_cflag CRTSCTS)
+ mask |= UPF_HARD_FLOW;
+
+ if (port-flags mask) {
+ port-ops-throttle(port);
+ mask = ~port-flags;
+ }
+
+ if (mask UPF_SOFT_FLOW)
uart_send_xchar(tty, STOP_CHAR(tty));
- if (tty-termios.c_cflag CRTSCTS)
- uart_clear_mctrl(state-uart_port, TIOCM_RTS);
+ if (mask UPF_HARD_FLOW)
+ uart_clear_mctrl(port, TIOCM_RTS);
}
static void uart_unthrottle(struct tty_struct *tty)
{
struct uart_state *state = tty-driver_data;
struct uart_port *port = state-uart_port;
+ uint32_t mask = 0;
- if (I_IXOFF(tty)) {
+ if (I_IXOFF(tty))
+ mask |= UPF_SOFT_FLOW;
+ if (tty-termios.c_cflag CRTSCTS)
+ mask |= UPF_HARD_FLOW;
+
+ if (port-flags mask) {
+ port-ops-unthrottle(port);
+ mask = ~port-flags;
+ }
+
+ if (mask UPF_SOFT_FLOW) {
if (port-x_char)
port-x_char = 0;
else
uart_send_xchar(tty, START_CHAR(tty));
}
- if (tty-termios.c_cflag CRTSCTS)
+ if (mask UPF_HARD_FLOW)
uart_set_mctrl(port, TIOCM_RTS);
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index e2cda5d..c6690a2 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -46,6 +46,8 @@ struct uart_ops {
unsigned int(*get_mctrl)(struct uart_port *);
void(*stop_tx)(struct uart_port *);
void(*start_tx)(struct uart_port *);
+ void(*throttle)(struct uart_port *);
+ void(*unthrottle)(struct uart_port *);
void(*send_xchar)(struct uart_port *, char ch);
void(*stop_rx)(struct uart_port *);
void(*enable_ms)(struct uart_port *);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/11] SERIAL: omap: allow hardware assisted rts/cts modes to be disabled
There is nothing which clears the auto RTS/CTS bits, so once hardware
flow control gets enabled, there's no possibility to disable it.
So, clear these bits when CRTSCTS is cleared.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/omap-serial.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ede6fd..c55af63 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -921,6 +921,13 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr | UART_MCR_RTS);
serial_out(up, UART_LCR, cval);
+ } else {
+ /* Disable AUTORTS and AUTOCTS */
+ up-efr = ~(UART_EFR_CTS | UART_EFR_RTS);
+
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
+ serial_out(up, UART_LCR, cval);
}
serial_omap_set_mctrl(up-port, up-port.mctrl);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH 3.6.0- 3/6] ARM/pxa: use module_platform_driver macro
On 10/12/12 09:11, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
This patch removes some code duplication by using
module_platform_driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
index 7dbe3cc..e329cce 100644
--- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
+++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
@@ -384,18 +384,7 @@ static struct platform_driver pxa3xx_u2d_ulpi_driver = {
.probe = pxa3xx_u2d_probe,
.remove = pxa3xx_u2d_remove,
};
-
-static int pxa3xx_u2d_ulpi_init(void)
-{
- return platform_driver_register(pxa3xx_u2d_ulpi_driver);
-}
-module_init(pxa3xx_u2d_ulpi_init);
-
-static void __exit pxa3xx_u2d_ulpi_exit(void)
-{
- platform_driver_unregister(pxa3xx_u2d_ulpi_driver);
-}
-module_exit(pxa3xx_u2d_ulpi_exit);
+module_platform_driver(pxa3xx_u2d_ulpi_driver);
MODULE_DESCRIPTION(PXA3xx U2D ULPI driver);
MODULE_AUTHOR(Igor Grinberg);
--
Regards,
Igor.
--
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 07/11] SERIAL: omap: remove setting of EFR SCD bit
The SCD (special character detect) bit enables comparisons with XOFF2, which we do not program. As the XOFF2 character remains unprogrammed, there's little point enabling this feature along with its associated interrupt. Remove this, and ensure that the SCD bit is cleared. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/tty/serial/omap-serial.c |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 7c313c2..71db4e6 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -704,13 +704,8 @@ serial_omap_configure_xonxoff serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG); - /* Enable special char function UARTi.EFR_REG[5] and -* load the new software flow control mode IXON or IXOFF -* and restore the UARTi.EFR_REG[4] ENHANCED_EN value. -*/ - serial_out(up, UART_EFR, up-efr | UART_EFR_SCD); + serial_out(up, UART_EFR, up-efr); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); - serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR); serial_out(up, UART_LCR, up-lcr); } @@ -843,6 +838,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); up-efr = serial_in(up, UART_EFR); + up-efr = ~UART_EFR_SCD; serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] SERIAL: omap: no need to re-read EFR
There's no need to re-read EFR after we've recently written it; the register is a configuration register which doesn't change its value without us writing to it. The last value which was written to this register was up-efr. Removing this re-reading avoids the possibility that we end up with up-efr having unintended bits set, which should only be temporarily set when accessing the enhanced features. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/tty/serial/omap-serial.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 71db4e6..c8a0425 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -873,8 +873,6 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_out(up, UART_OMAP_MDR1, up-mdr1); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); - - up-efr = serial_in(up, UART_EFR); serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, 0); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/11] SERIAL: omap: fix set_mctrl() breakage
c538d20c7f (and maybe previous commits) broke set_mctrl() by making
it only capable of setting bits in the MCR register. This prevents
software controlled flow control and modem control line manipulation
via TIOCMSET/TIOCMBIC from working correctly.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/omap-serial.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c8a0425..537829f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -504,7 +504,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port
*port)
static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- unsigned char mcr = 0;
+ unsigned char mcr = 0, old_mcr;
dev_dbg(up-port.dev, serial_omap_set_mctrl+%d\n, up-port.line);
if (mctrl TIOCM_RTS)
@@ -519,8 +519,10 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
mcr |= UART_MCR_LOOP;
pm_runtime_get_sync(up-dev);
- up-mcr = serial_in(up, UART_MCR);
- up-mcr |= mcr;
+ old_mcr = serial_in(up, UART_MCR);
+ old_mcr = ~(UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_OUT1 |
+UART_MCR_DTR | UART_MCR_RTS);
+ up-mcr = old_mcr | mcr;
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] SERIAL: omap: allow hardware assisted IXANY mode to be disabled
Nothing was clearing the UART_MCR_XONANY bit, so once the ixany mode gets set, there's no possibility to disable it. Clear this bit when IXANY mode is cleared. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/tty/serial/omap-serial.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index c55af63..7c313c2 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -698,6 +698,8 @@ serial_omap_configure_xonxoff */ if (termios-c_iflag IXANY) up-mcr |= UART_MCR_XONANY; + else + up-mcr = ~UART_MCR_XONANY; serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] SERIAL: omap: fix MCR TCRTLR bit handling
The MCR TCRTLR bit can only be changed when ECB is set in the EFR.
Unfortunately, several places were trying to alter this bit while ECB
was clear:
- serial_omap_configure_xonxoff() was attempting to clear the bit after
explicitly clearing the ECB bit.
- serial_omap_set_termios() was trying the same trick after setting the
SCR, and when trying to change the TCR register when hardware flow
control was enabled.
Fix this by ensuring that we always have ECB set whenever the TCRTLR bit
is changed.
Moreover, we start out by reading the EFR and MCR registers, which may
have indeterminent bit settings for the ECB and TCRTLR bits. Ensure
that these bits always start off in a known state.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/omap-serial.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 537829f..7cc151c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -706,9 +706,10 @@ serial_omap_configure_xonxoff
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, up-lcr);
}
@@ -729,7 +730,6 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
{
struct uart_omap_port *up = to_uart_omap_port(port);
unsigned char cval = 0;
- unsigned char efr = 0;
unsigned long flags = 0;
unsigned int baud, quot;
@@ -839,12 +839,12 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- up-efr = serial_in(up, UART_EFR);
+ up-efr = serial_in(up, UART_EFR) ~UART_EFR_ECB;
up-efr = ~UART_EFR_SCD;
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
- up-mcr = serial_in(up, UART_MCR);
+ up-mcr = serial_in(up, UART_MCR) ~UART_MCR_TCRTLR;
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
/* FIFO ENABLE, DMA MODE */
@@ -863,9 +863,12 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_OMAP_SCR, up-scr);
- serial_out(up, UART_EFR, up-efr);
+ /* Reset UART_MCR_TCRTLR: this must be done with the EFR_ECB bit set */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
/* Protocol, Baud Rate, and Interrupt Settings */
@@ -904,20 +907,21 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
/* Hardware Flow Control Configuration */
if (termios-c_cflag CRTSCTS) {
- efr |= (UART_EFR_CTS | UART_EFR_RTS);
- serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
-
- up-mcr = serial_in(up, UART_MCR);
- serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
-
+ /* Enable access to TCR/TLR */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- up-efr = serial_in(up, UART_EFR);
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
+ serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- serial_out(up, UART_EFR, efr); /* Enable AUTORTS and AUTOCTS */
- serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
+
+ /* Enable AUTORTS and AUTOCTS */
+ up-efr |= UART_EFR_CTS | UART_EFR_RTS;
+
+ /* Disable access to TCR/TLR */
serial_out(up, UART_MCR, up-mcr | UART_MCR_RTS);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, cval);
} else {
/* Disable AUTORTS and AUTOCTS */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11] SERIAL: omap: fix hardware assisted flow control
When the UART device has hardware flow control enabled, it ignores the
MCR RTS bit in the MCR register, and keeps RTS asserted as long as we
continue to read characters from the UART receiver FIFO. This means
that when the TTY buffers become full, the UART doesn't tell the remote
end to stop sending, which causes the TTY layer to start dropping
characters.
A similar problem exists with software flow control. We need the FIFO
register to fill when software flow control is enabled to provoke the
UART to send the XOFF character.
Fix this by implementing the throttle/unthrottle callbacks, and use
these to disable receiver interrupts. This in turn means that the UART
FIFO will fill, which will then cause the UART's hardware to deassert
the RTS signal and/or send the XOFF character, stopping the remote end.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/omap-serial.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 7cc151c..aabc94d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -303,6 +303,34 @@ static void serial_omap_start_tx(struct uart_port *port)
pm_runtime_put_autosuspend(up-dev);
}
+static void serial_omap_throttle(struct uart_port *port)
+{
+ struct uart_omap_port *up = to_uart_omap_port(port);
+ unsigned long flags;
+
+ pm_runtime_get_sync(up-dev);
+ spin_lock_irqsave(up-port.lock, flags);
+ up-ier = ~(UART_IER_RLSI | UART_IER_RDI);
+ serial_out(up, UART_IER, up-ier);
+ spin_unlock_irqrestore(up-port.lock, flags);
+ pm_runtime_mark_last_busy(up-dev);
+ pm_runtime_put_autosuspend(up-dev);
+}
+
+static void serial_omap_unthrottle(struct uart_port *port)
+{
+ struct uart_omap_port *up = to_uart_omap_port(port);
+ unsigned long flags;
+
+ pm_runtime_get_sync(up-dev);
+ spin_lock_irqsave(up-port.lock, flags);
+ up-ier |= UART_IER_RLSI | UART_IER_RDI;
+ serial_out(up, UART_IER, up-ier);
+ spin_unlock_irqrestore(up-port.lock, flags);
+ pm_runtime_mark_last_busy(up-dev);
+ pm_runtime_put_autosuspend(up-dev);
+}
+
static unsigned int check_modem_status(struct uart_omap_port *up)
{
unsigned int status;
@@ -1000,6 +1028,7 @@ static void serial_omap_config_port(struct uart_port
*port, int flags)
dev_dbg(up-port.dev, serial_omap_config_port+%d\n,
up-port.line);
up-port.type = PORT_OMAP;
+ up-port.flags |= UPF_SOFT_FLOW | UPF_HARD_FLOW;
}
static int
@@ -1203,6 +1232,8 @@ static struct uart_ops serial_omap_pops = {
.get_mctrl = serial_omap_get_mctrl,
.stop_tx= serial_omap_stop_tx,
.start_tx = serial_omap_start_tx,
+ .throttle = serial_omap_throttle,
+ .unthrottle = serial_omap_unthrottle,
.stop_rx= serial_omap_stop_rx,
.enable_ms = serial_omap_enable_ms,
.break_ctl = serial_omap_break_ctl,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/11] SERIAL: omap: fix MCR TCRTLR bit handling
On Tue, Oct 16, 2012 at 12:01:06PM +0100, Russell King wrote:
The MCR TCRTLR bit can only be changed when ECB is set in the EFR.
Unfortunately, several places were trying to alter this bit while ECB
was clear:
- serial_omap_configure_xonxoff() was attempting to clear the bit after
explicitly clearing the ECB bit.
- serial_omap_set_termios() was trying the same trick after setting the
SCR, and when trying to change the TCR register when hardware flow
control was enabled.
Fix this by ensuring that we always have ECB set whenever the TCRTLR bit
is changed.
Moreover, we start out by reading the EFR and MCR registers, which may
have indeterminent bit settings for the ECB and TCRTLR bits. Ensure
that these bits always start off in a known state.
Note - this patch unfortunately exposes some of the bugs in their full
glory as we now write to the correct registers and actually end up
programming the hardware correctly.
I've reduced the window as far as possible by putting this one next to
patch 11 which fixes it, but no amount of reordering can hide some kind
of breakage along the way.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/tty/serial/omap-serial.c | 32 ++--
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 537829f..7cc151c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -706,9 +706,10 @@ serial_omap_configure_xonxoff
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, up-lcr);
}
@@ -729,7 +730,6 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
{
struct uart_omap_port *up = to_uart_omap_port(port);
unsigned char cval = 0;
- unsigned char efr = 0;
unsigned long flags = 0;
unsigned int baud, quot;
@@ -839,12 +839,12 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- up-efr = serial_in(up, UART_EFR);
+ up-efr = serial_in(up, UART_EFR) ~UART_EFR_ECB;
up-efr = ~UART_EFR_SCD;
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
- up-mcr = serial_in(up, UART_MCR);
+ up-mcr = serial_in(up, UART_MCR) ~UART_MCR_TCRTLR;
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
/* FIFO ENABLE, DMA MODE */
@@ -863,9 +863,12 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
serial_out(up, UART_OMAP_SCR, up-scr);
- serial_out(up, UART_EFR, up-efr);
+ /* Reset UART_MCR_TCRTLR: this must be done with the EFR_ECB bit set */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up-mcr);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
/* Protocol, Baud Rate, and Interrupt Settings */
@@ -904,20 +907,21 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
/* Hardware Flow Control Configuration */
if (termios-c_cflag CRTSCTS) {
- efr |= (UART_EFR_CTS | UART_EFR_RTS);
- serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
-
- up-mcr = serial_in(up, UART_MCR);
- serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
-
+ /* Enable access to TCR/TLR */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- up-efr = serial_in(up, UART_EFR);
serial_out(up, UART_EFR, up-efr | UART_EFR_ECB);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
+ serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- serial_out(up, UART_EFR, efr); /* Enable AUTORTS and AUTOCTS */
- serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
+
+ /* Enable AUTORTS and AUTOCTS */
+ up-efr |= UART_EFR_CTS | UART_EFR_RTS;
+
+ /* Disable access to TCR/TLR */
serial_out(up, UART_MCR, up-mcr | UART_MCR_RTS);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ serial_out(up, UART_EFR, up-efr);
serial_out(up, UART_LCR, cval);
} else {
/* Disable AUTORTS and AUTOCTS */
--
1.7.4.4
Re: [PATCH 6/6] OMAPDSS: HDMI: Create platform device to support audio
Hi Peter,
Thanks for reviewing!
On 10/16/2012 04:30 AM, Péter Ujfalusi wrote:
On 10/16/2012 03:27 AM, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the design of drivers such
as MFD, in which a single entity handles the creation of the accesory
devices. Such devices are then used by domain-specific drivers; audio in
this case.
Also, this is in line with the DT implementation of HDMI, in which we will
have a single node to describe this feature of the OMAP SoC.
...
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_MEM_RESOURCE].flags = IORESOURCE_MEM;
+
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0);
+ if (!res) {
+ DSSERR(can't get IORESOURCE_DMA HDMI\n);
+ return -EINVAL;
+ }
+
+ /* Pass this resource to audio_pdev */
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].start = res-start;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].end = res-end;
+ hdmi_aud_res[HDMI_AUDIO_DMA_RESOURCE].flags = IORESOURCE_DMA;
+
+ /* create platform device for HDMI audio driver */
+ hdmi.audio_pdev = platform_device_register_simple(
+ omap_hdmi_audio,
+ -1, hdmi_aud_res,
+
ARRAY_SIZE(hdmi_aud_res));
Should you also update arch/arm/mach-omap2/devices.c to not register the same
device?
When we do not boot with DT devices.c will create the same device earlier
(without pdata) which will prevent this device to be created and at the end
will prevent omap_hdmi_audio driver to probe due to missing pdata...
Yes, I have already a set of patches to remove the device creation from
devices.c. I decided to send this patch set first to see if Tomi and the
reviewers are OK with it. After they are accepted I will send the
updates to devices.c and ASoC.
BR
Ricardo
+ if (IS_ERR(hdmi.audio_pdev)) {
+ DSSERR(Can't instantiate hdmi-audio\n);
+ return PTR_ERR(hdmi.audio_pdev);
+ }
+
+ return 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 00/11] Minimum set of omap serial patches to fix merge window breakage
On Tue, Oct 16, 2012 at 11:14:58AM +0100, Russell King - ARM Linux wrote: During the merge window, a series of patches from various people went in, allegedly fixing various problems with the OMAP serial driver. Unfortunately, there was not a full understanding of the issues I brought up here back in April, and so the fixes, while being individually correct, result in a worse situation with the driver than before. Specifically, this patch: commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 Author: Vikram Pandita vikram.pand...@ti.com Date: Thu Sep 6 15:45:37 2012 +0300 serial: omap: fix software flow control Software flow control register bits were not defined correctly. Also clarify the IXON and IXOFF logic to reflect what userspace wants. does what it says on the tin - it fixes the register definitions so that we do end up enabling the right two software flow control bits. The down side is that there are other bugs in this area which have been exposed. For example: 1. the XON/XOFF registers aren't written to; their address is, but we will not be writing to the right registers because their access rules are not respected by the driver. These are by default zero. This means that with hardware assisted software flow control enabled, the port will now transmit an 0x00 byte for XON and XOFF events. 2. the driver set_termios function is not called for changes in software flow control settings if not accompanied by some other change. 3. the there isn't actually a way for the hardware assisted flow control to be used other than by increasing interrupt latency to cause the receiver hardware FIFO to fill. This will cause 0x00 bytes to be transmitted. There are two options to resolve this. The first one is to revert this patch to bring the driver back down to the pre-merge window state. The other is to apply this series of patches, which frankly I don't think is -rc material, even with the above regressions. Given that the above regressions were caused by a lack of due care and correct process (I had declared to TI that I had investigated these issues back in April), I believe that the right answer is to revert at least commit 957ee7270d, which should re-hide these other bugs in the driver. Note: these patches are not as well validated as my previous set; I haven't even build-tested just this set, but only my full set. YMMV. -- 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 1/3] usb: dwc3: Add the suspend/resume functionality
Hi Felipe,
On 16 October 2012 15:36, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 16, 2012 at 03:15:36PM +0530, Vikas Sajjan wrote:
Adds suspend and resume callbacks as part of the power management
support to DWC3 controller Driver.
This patch facilitates transition of DWC3 controller between D0 and D3
power states during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/core.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5db4c76..9f35cf8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = dwc3_core_init(dwc);
+ if (ret 0)
+ return ret;
+
+ switch (dwc-mode) {
+ case DWC3_MODE_DEVICE:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ break;
+ case DWC3_MODE_HOST:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+ break;
+ case DWC3_MODE_DRD:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ }
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
there is one check you need to do here. If you are playing the
peripheral role, you can't allow suspend unless link is in U3 or you're
not enumerated.
Have you tested running 'echo mem /sys/power/state' on your device
while you're transferring data in a USB session with the Host ?
we have tested only when DWC3 is in HOST mode.
I'll ask again, how was this tested ? What did you actually run (which
commands, which use cases have you validated) ? I'm not asking only
which platform you used, I need to know how you exercised this feature,
how did you trigger suspend/resume, in which conditions (enumerated ?
bus suspended ? no cable attached ?), etc.
1) We have tested by connecting a USB Mouse, USB 2.0 Mass Storage Device and
USB 3.0 Mass Storage Device on a SS hub connected on USB 3.0 port to
Exynos5250 board, in which DWC3 is configured for HOST mode.
2) We tested by running command
echo +20 /sys/class/rtc/rtc0/wakealarmecho mem /sys/power/state
cheers
--
balbi
--
Thanks and Regards
Vikas Sajjan
--
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] OMAPDSS: Correct check for the callback pointer in dss_dsi_disable_pads()
Appear to be a copy-paste bug: the code was checking board_data-dsi_enable_pads
while calling board_data-dsi_disable_pads.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tomi,
not sure if this need to be included to 3.7
Regards,
Peter
drivers/video/omap2/dss/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b2af72d..7afaf61 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -122,7 +122,7 @@ void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
- if (!board_data-dsi_enable_pads)
+ if (!board_data-dsi_disable_pads)
return;
return board_data-dsi_disable_pads(dsi_id, lane_mask);
--
1.7.12.3
--
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] i2c: omap: revert i2c: omap: switch to threaded IRQ support
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote: Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to threaded IRQ support) causes communication with I2C devices to fail after system suspend/resume on all OMAP3 devices: Could you tell me which omap3 platform On Beagle Xm after mount /dev/mmcblk /mmcfs # mount /dev/mmcblk0p2 /mmcfs/ [ 412.480041] kjournald starting. Commit interval 5 seconds [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode # # cd /mmcfs/ # # # ls bin omap3_usb_prcm.sh usb_prcm.sh dev omap3_usbhs_off.shusb_uhh_show.sh etc omap3_usbhs_on.sh usb_uhh_tll.sh init proc usbhs_clk_disable.sh lib readmem.dat usbhs_clk_enable.sh lost+foundroot usbhs_set_sm.sh mnt sbin usbhs_show.sh modules sys usr msc tmp var omap3_ehcidump.sh usb_omap3.sh # # # echo mem /sys/power/state [ 464.785461] PM: Syncing filesystems ... done. [ 464.791442] PM: Preparing system for mem sleep [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 464.858703] PM: Entering mem sleep [ 464.862304] Suspending console(s) (use no_console_suspend to debug) [ 464.994415] PM: suspend of devices complete after 121.002 msecs [ 464.998107] PM: late suspend of devices complete after 3.662 msecs [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs [ 465.003173] Disabling non-boot CPUs ... [ 466.225585] Successfully put all powerdomains to target state [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs [ 466.232421] PM: early resume of devices complete after 2.349 msecs [ 467.492645] PM: resume of devices complete after 1260.131 msecs [ 467.546936] PM: Finishing wakeup. [ 467.550415] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # echo mem /sys/power/state [ 1492.225311] PM: Syncing filesystems ... done. [ 1492.232177] PM: Preparing system for mem sleep [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1492.299804] PM: Entering mem sleep [ 1492.303375] Suspending console(s) (use no_console_suspend to debug) [ 1492.435333] PM: suspend of devices complete after 120.880 msecs [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs [ 1492.444091] Disabling non-boot CPUs ... [ 1493.745544] Successfully put all powerdomains to target state [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs [ 1493.752319] PM: early resume of devices complete after 2.319 msecs [ 1494.794067] PM: resume of devices complete after 1041.625 msecs [ 1494.848388] PM: Finishing wakeup. [ 1494.851867] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # Anyways will retry with fs on mmc. -- 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] OMAPDSS: Correct check for the callback pointer in dss_dsi_disable_pads()
On 2012-10-16 14:51, Peter Ujfalusi wrote: Appear to be a copy-paste bug: the code was checking board_data-dsi_enable_pads while calling board_data-dsi_disable_pads. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tomi, not sure if this need to be included to 3.7 Thanks. Probably not needed for 3.7, as we never hit that bug with the current kernel: if dsi_enable_pads is defined we also always define dsi_disable_pads. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support
Hi, + Thomas Gleixner On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote: On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote: Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to threaded IRQ support) causes communication with I2C devices to fail after system suspend/resume on all OMAP3 devices: Could you tell me which omap3 platform On Beagle Xm after mount /dev/mmcblk /mmcfs # mount /dev/mmcblk0p2 /mmcfs/ [ 412.480041] kjournald starting. Commit interval 5 seconds [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode # # cd /mmcfs/ # # # ls bin omap3_usb_prcm.sh usb_prcm.sh dev omap3_usbhs_off.shusb_uhh_show.sh etc omap3_usbhs_on.sh usb_uhh_tll.sh init proc usbhs_clk_disable.sh lib readmem.dat usbhs_clk_enable.sh lost+foundroot usbhs_set_sm.sh mnt sbin usbhs_show.sh modules sys usr msc tmp var omap3_ehcidump.sh usb_omap3.sh # # # echo mem /sys/power/state [ 464.785461] PM: Syncing filesystems ... done. [ 464.791442] PM: Preparing system for mem sleep [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 464.858703] PM: Entering mem sleep [ 464.862304] Suspending console(s) (use no_console_suspend to debug) [ 464.994415] PM: suspend of devices complete after 121.002 msecs [ 464.998107] PM: late suspend of devices complete after 3.662 msecs [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs [ 465.003173] Disabling non-boot CPUs ... [ 466.225585] Successfully put all powerdomains to target state [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs [ 466.232421] PM: early resume of devices complete after 2.349 msecs [ 467.492645] PM: resume of devices complete after 1260.131 msecs [ 467.546936] PM: Finishing wakeup. [ 467.550415] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # echo mem /sys/power/state [ 1492.225311] PM: Syncing filesystems ... done. [ 1492.232177] PM: Preparing system for mem sleep [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1492.299804] PM: Entering mem sleep [ 1492.303375] Suspending console(s) (use no_console_suspend to debug) [ 1492.435333] PM: suspend of devices complete after 120.880 msecs [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs [ 1492.444091] Disabling non-boot CPUs ... [ 1493.745544] Successfully put all powerdomains to target state [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs [ 1493.752319] PM: early resume of devices complete after 2.319 msecs [ 1494.794067] PM: resume of devices complete after 1041.625 msecs [ 1494.848388] PM: Finishing wakeup. [ 1494.851867] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # Anyways will retry with fs on mmc. rootfs has to be on MMC to trigger this. The problem happens because omap_hsmmc calls enable_irq() on its resume method. That IRQ line is actually a GPIO from TWL4030, so twl4030-irq.c::twl4030_sih_bus_sync_unlock() will be called, which will trigger an I2C transfer. The problem I see is that even though we properly return IRQ_WAKE_THREAD and wake_up_process() manages to wakeup the IRQ thread (it returns 1), the thread is never scheduled. To make things even worse, ouw irq thread runs once, but doesn't run on a consecutive call. Here's some (rather nasty) debug prints showing the problem: [ 78.709381] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913 [ 78.715026] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038 [ 78.720733] omap_i2c omap_i2c.1: omap_i2c_xfer 655 [ 78.725769] omap_i2c omap_i2c.1: omap_i2c_xfer 659 [ 78.730804] omap_i2c omap_i2c.1: omap_i2c_xfer 663 [ 78.735870] omap_i2c omap_i2c.1: omap_i2c_xfer 668 [ 78.850708] PM: suspend of devices complete after 1287.841 msecs [ 78.860870] PM: late suspend of devices complete after 3.753 msecs [ 78.872283] try_to_wake_up 1411 [ 78.875701] try_to_wake_up 1411 [ 78.879028] try_to_wake_up 1411 [ 78.882537] omap_i2c omap_i2c.1: omap_i2c_runtime_suspend 1359 [ 78.888763] omap_i2c omap_i2c.1: omap_i2c_low_level_suspend 1261
Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support
Hi again, On Tue, Oct 16, 2012 at 04:33:56PM +0300, Felipe Balbi wrote: Hi, + Thomas Gleixner On Tue, Oct 16, 2012 at 06:28:13PM +0530, Shubhrajyoti Datta wrote: On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote: Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to threaded IRQ support) causes communication with I2C devices to fail after system suspend/resume on all OMAP3 devices: Could you tell me which omap3 platform On Beagle Xm after mount /dev/mmcblk /mmcfs # mount /dev/mmcblk0p2 /mmcfs/ [ 412.480041] kjournald starting. Commit interval 5 seconds [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode # # cd /mmcfs/ # # # ls bin omap3_usb_prcm.sh usb_prcm.sh dev omap3_usbhs_off.shusb_uhh_show.sh etc omap3_usbhs_on.sh usb_uhh_tll.sh init proc usbhs_clk_disable.sh lib readmem.dat usbhs_clk_enable.sh lost+foundroot usbhs_set_sm.sh mnt sbin usbhs_show.sh modules sys usr msc tmp var omap3_ehcidump.sh usb_omap3.sh # # # echo mem /sys/power/state [ 464.785461] PM: Syncing filesystems ... done. [ 464.791442] PM: Preparing system for mem sleep [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 464.858703] PM: Entering mem sleep [ 464.862304] Suspending console(s) (use no_console_suspend to debug) [ 464.994415] PM: suspend of devices complete after 121.002 msecs [ 464.998107] PM: late suspend of devices complete after 3.662 msecs [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs [ 465.003173] Disabling non-boot CPUs ... [ 466.225585] Successfully put all powerdomains to target state [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs [ 466.232421] PM: early resume of devices complete after 2.349 msecs [ 467.492645] PM: resume of devices complete after 1260.131 msecs [ 467.546936] PM: Finishing wakeup. [ 467.550415] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # echo mem /sys/power/state [ 1492.225311] PM: Syncing filesystems ... done. [ 1492.232177] PM: Preparing system for mem sleep [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1492.299804] PM: Entering mem sleep [ 1492.303375] Suspending console(s) (use no_console_suspend to debug) [ 1492.435333] PM: suspend of devices complete after 120.880 msecs [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs [ 1492.444091] Disabling non-boot CPUs ... [ 1493.745544] Successfully put all powerdomains to target state [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs [ 1493.752319] PM: early resume of devices complete after 2.319 msecs [ 1494.794067] PM: resume of devices complete after 1041.625 msecs [ 1494.848388] PM: Finishing wakeup. [ 1494.851867] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # Anyways will retry with fs on mmc. rootfs has to be on MMC to trigger this. The problem happens because omap_hsmmc calls enable_irq() on its resume method. That IRQ line is actually a GPIO from TWL4030, so twl4030-irq.c::twl4030_sih_bus_sync_unlock() will be called, which will trigger an I2C transfer. The problem I see is that even though we properly return IRQ_WAKE_THREAD and wake_up_process() manages to wakeup the IRQ thread (it returns 1), the thread is never scheduled. To make things even worse, ouw irq thread runs once, but doesn't run on a consecutive call. Here's some (rather another detail here: if I drop the disable_irq()/enable_irq() from omap_hsmmc driver, everything ends up being fine, so I'm wondering if we have a race between omap_hsmmc, twl4030 card detect GPIO and I2C, but I'm not sure yet. nasty) debug prints showing the problem: [ 78.709381] omap_i2c omap_i2c.1: omap_i2c_isr_thread 913 [ 78.715026] omap_i2c omap_i2c.1: omap_i2c_isr_thread 1038 [ 78.720733] omap_i2c omap_i2c.1: omap_i2c_xfer 655 [ 78.725769] omap_i2c omap_i2c.1: omap_i2c_xfer 659 [ 78.730804] omap_i2c omap_i2c.1: omap_i2c_xfer 663 [ 78.735870]
Re: [PATCH v3 1/3] usb: dwc3: Add the suspend/resume functionality
Hi,
On Tue, Oct 16, 2012 at 05:10:39PM +0530, Vikas Sajjan wrote:
Hi Felipe,
On 16 October 2012 15:36, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 16, 2012 at 03:15:36PM +0530, Vikas Sajjan wrote:
Adds suspend and resume callbacks as part of the power management
support to DWC3 controller Driver.
This patch facilitates transition of DWC3 controller between D0 and D3
power states during suspend/resume cycles.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/core.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5db4c76..9f35cf8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = dwc3_core_init(dwc);
+ if (ret 0)
+ return ret;
+
+ switch (dwc-mode) {
+ case DWC3_MODE_DEVICE:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+ break;
+ case DWC3_MODE_HOST:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+ break;
+ case DWC3_MODE_DRD:
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ }
+
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+
there is one check you need to do here. If you are playing the
peripheral role, you can't allow suspend unless link is in U3 or you're
not enumerated.
Have you tested running 'echo mem /sys/power/state' on your device
while you're transferring data in a USB session with the Host ?
we have tested only when DWC3 is in HOST mode.
I'm very sorry but this isn't enough :-( We need to make sure there are
no regressions on peripheral role.
I'll ask again, how was this tested ? What did you actually run (which
commands, which use cases have you validated) ? I'm not asking only
which platform you used, I need to know how you exercised this feature,
how did you trigger suspend/resume, in which conditions (enumerated ?
bus suspended ? no cable attached ?), etc.
1) We have tested by connecting a USB Mouse, USB 2.0 Mass Storage Device and
USB 3.0 Mass Storage Device on a SS hub connected on USB 3.0 port to
Exynos5250 board, in which DWC3 is configured for HOST mode.
did you have a transfer going through when you suspended ? If you
didn't, then you haven't stressed well enough.
2) We tested by running command
echo +20 /sys/class/rtc/rtc0/wakealarmecho mem /sys/power/state
that's ok, but try something like:
# dd if=/dev/urandom of=/dev/sdXX bs=1M count=
# echo +20 /sys/class/rtc/rtc0/wakealarmecho mem /sys/power/state
Better yet, generate a big (and I really mean big :-) file with a known
pattern (make a sequence from 0x00 to 0xff and back to zero, over and
over again) then write that file to the mass storage device, while
transfer is on the fly, suspend, then resume and see if transfer
continues, then later verify the bytes by reading back the data and
comparing with original source file.
Do this for both Host and Peripheral roles. I have a rather big
suspicion that it won't work, in which case we need to make sure to
prevent suspend while transfers are on the fly or do something else.
--
balbi
signature.asc
Description: Digital signature
[PATCH] Revert serial: omap: fix software flow control
This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Cc: Russell King li...@arm.linux.org.uk Signed-off-by: Felipe Balbi ba...@ti.com --- Hi Greg, you might prefer to do the revert yourself, in that case just revert commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6. thanks arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++-- drivers/tty/serial/omap-serial.c | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index f4a4cd0..1957a85 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -40,10 +40,10 @@ #define OMAP_UART_WER_MOD_WKUP 0X7F /* Enable XON/XOFF flow control on output */ -#define OMAP_UART_SW_TX0x8 +#define OMAP_UART_SW_TX0x04 /* Enable XON/XOFF flow control on input */ -#define OMAP_UART_SW_RX0x2 +#define OMAP_UART_SW_RX0x04 #define OMAP_UART_SYSC_RESET 0X07 #define OMAP_UART_TCR_TRIG 0X0F diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6ede6fd..6d3d26a 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -671,19 +671,19 @@ serial_omap_configure_xonxoff /* * IXON Flag: -* Flow control for OMAP.TX -* OMAP.RX should listen for XON/XOFF +* Enable XON/XOFF flow control on output. +* Transmit XON1, XOFF1 */ if (termios-c_iflag IXON) - up-efr |= OMAP_UART_SW_RX; + up-efr |= OMAP_UART_SW_TX; /* * IXOFF Flag: -* Flow control for OMAP.RX -* OMAP.TX should send XON/XOFF +* Enable XON/XOFF flow control on input. +* Receiver compares XON1, XOFF1. */ if (termios-c_iflag IXOFF) - up-efr |= OMAP_UART_SW_TX; + up-efr |= OMAP_UART_SW_RX; serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); -- 1.8.0.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] OMAP 3 CSI-2 configuration
Hi Sakari, Thanks for the patches. For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Tony, do you want to take patch 1/3 in your tree, or can I push the whole series through mine ? On Sunday 14 October 2012 13:31:22 Sakari Ailus wrote: Hi all, This is an update to an old patchset for CSI-2 configuration for OMAP 3430 and 3630. The patches have been tested on the 3630 only so far, and I don't plan to test them on 3430 in the near future. I've made changes according to Laurent's suggestions to the patches, with the exception of alignment of a certain line. I think it's exactly as it should be. :-) I'm not quite certain about the comment regarding the control register state dependency to the CORE power domain, and why exactly this isn't an issue. We know the MPU must stay powered since the ISP can't wake up MPU, but how is this related to CORE? In the end it seems to work. If you think this should be changed and you also know how, please provide me the text. :-) /* * The PHY configuration is lost in off mode, that's not an * issue since the MPU power domain is forced on whilst the * ISP is in use. */ Comments, questions and other kind of feedback is very welcome. Kind regards, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] twl4030: Fix chained irq handling on resume from suspend
The irqs are enabled one-by-one in pm core resume_noirq phase. This leads to situation where the twl4030 primary interrupt handler (PIH) is enabled before the chained secondary handlers (SIH). As the PIH cannot clear the pending interrupt, and SIHs have not been enabled yet, a flood of interrupts hangs the device. Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME flags, so they get enabled before the PIH. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com --- drivers/mfd/twl4030-irq.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index ad733d7..cdd1173 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -672,7 +672,8 @@ int twl4030_sih_setup(struct device *dev, int module, int irq_base) irq = sih_mod + twl4030_irq_base; irq_set_handler_data(irq, agent); agent-irq_name = kasprintf(GFP_KERNEL, twl4030_%s, sih-name); - status = request_threaded_irq(irq, NULL, handle_twl4030_sih, 0, + status = request_threaded_irq(irq, NULL, handle_twl4030_sih, + IRQF_EARLY_RESUME, agent-irq_name ?: sih-name, NULL); dev_info(dev, %s (irq %d) chaining IRQs %d..%d\n, sih-name, -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] twl4030: Fix chained irq handling on resume from suspend
Hi, ti, 2012-10-16 kello 17:59 +0300, Kalle Jokiniemi kirjoitti: The irqs are enabled one-by-one in pm core resume_noirq phase. This leads to situation where the twl4030 primary interrupt handler (PIH) is enabled before the chained secondary handlers (SIH). As the PIH cannot clear the pending interrupt, and SIHs have not been enabled yet, a flood of interrupts hangs the device. Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME flags, so they get enabled before the PIH. Did it this way now, since the tl4030_irq is not really a driver that could do normal suspend / resume calls... and this is what the flag is for. Added Samuel to recipients, as get_maintainer reported him as maintainer. - Kalle Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com --- drivers/mfd/twl4030-irq.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index ad733d7..cdd1173 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -672,7 +672,8 @@ int twl4030_sih_setup(struct device *dev, int module, int irq_base) irq = sih_mod + twl4030_irq_base; irq_set_handler_data(irq, agent); agent-irq_name = kasprintf(GFP_KERNEL, twl4030_%s, sih-name); - status = request_threaded_irq(irq, NULL, handle_twl4030_sih, 0, + status = request_threaded_irq(irq, NULL, handle_twl4030_sih, + IRQF_EARLY_RESUME, agent-irq_name ?: sih-name, NULL); dev_info(dev, %s (irq %d) chaining IRQs %d..%d\n, sih-name, -- 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] Revert serial: omap: fix software flow control
* Felipe Balbi ba...@ti.com [121016 07:16]: This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Cc: Russell King li...@arm.linux.org.uk Signed-off-by: Felipe Balbi ba...@ti.com This seems like the best way to go for the -rc series: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: omap: adopt pinctrl support
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch takes advantage of defer probe feature
and pin control in order to wait until pin control probing before
GPIO driver probing. It has been tested on OMAP5 board with TCA6424
driver.
log:
[0.482299] omap_i2c i2c.15: could not find pctldev for node /ocp/pinmux@4a00
2840/pinmux_i2c5_pins, deferring probe
[0.482330] platform i2c.15: Driver omap_i2c requests probe deferral
[0.484466] Advanced Linux Sound Architecture Driver Initialized.
[4.746917] omap_i2c i2c.15: bus 4 rev2.4.0 at 100 kHz
[4.755279] gpiochip_find_base: found new base at 477
[4.761169] gpiochip_add: registered GPIOs 477 to 500 on device: tca6424a
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..661d8a2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -44,6 +44,7 @@
#include linux/i2c-omap.h
#include linux/pm_runtime.h
#include linux/pm_qos.h
+#include linux/pinctrl/consumer.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -213,6 +214,8 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+
+ struct pinctrl *pins;
};
static const u8 reg_map_ip_v1[] = {
@@ -1107,6 +1110,16 @@ omap_i2c_probe(struct platform_device *pdev)
dev-dtrev = pdata-rev;
}
+ dev-pins = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(dev-pins)) {
+ if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ dev_warn(pdev-dev, did not get pins for i2c error: %li\n,
+PTR_ERR(dev-pins));
+ dev-pins = NULL;
+ }
+
dev-dev = pdev-dev;
dev-irq = irq;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP4: devices: fixup OMAP4 DMIC platform device error message
Correct DMIC hwmod lockup error message and replace printk() by
pr_err().
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/mach-omap2/devices.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..cba60e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -341,7 +341,7 @@ static void __init omap_init_dmic(void)
oh = omap_hwmod_lookup(dmic);
if (!oh) {
- printk(KERN_ERR Could not look up mcpdm hw_mod\n);
+ pr_err(Could not look up dmic hw_mod\n);
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] Minimum set of omap serial patches to fix merge window breakage
* Russell King - ARM Linux li...@arm.linux.org.uk [121016 03:16]: There are two options to resolve this. The first one is to revert this patch to bring the driver back down to the pre-merge window state. The other is to apply this series of patches, which frankly I don't think is -rc material, even with the above regressions. Yes reverting it is the way to go as we discussed in some off-list emails. I think everybody agrees that this is too intrusive for the -rc series :) 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: [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
Hi, On Thu, Sep 20, 2012 at 05:03:38PM +0100, Will Deacon wrote: From: Matthew Leach matthew.le...@arm.com Ensure that the memory regions that are set within the segments correspond to physical contiguous memory regions. This patch seems to break kexec for me in 3.7-rc1 (commit c564df4db85aac8d1d65a56176a0a25f46138064, bisected). kexec -l fails with the following output: kexec_load failed: Invalid argument entry = 0x80008000 flags = 28 nr_segments = 2 segment[0].buf = 0xc48008 segment[0].bufsz = 230 segment[0].mem = 0x80001000 segment[0].memsz = 1000 segment[1].buf = 0xb6a9b008 segment[1].bufsz = 3a4668 segment[1].mem = 0x80008000 segment[1].memsz = 3a5000 Could not load the kexec kernel: n800-zImage The board is OMAP2420 / Nokia N800. A. -- 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 v4? 0/7] Adaptive Body-Bias for OMAP
* Mike Turquette mturque...@ti.com [121011 15:27]: Quoting Nishanth Menon (2012-10-11 06:33:04) On 18:26-20121003, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org [...] arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/abb.c | 322 + arch/arm/mach-omap2/abb.h | 94 [...] arch/arm/plat-omap/include/plat/voltage.h |1 + 18 files changed, 699 insertions(+), 37 deletions(-) create mode 100644 arch/arm/mach-omap2/abb.c create mode 100644 arch/arm/mach-omap2/abb.h create mode 100644 arch/arm/mach-omap2/abb36xx_data.c create mode 100644 arch/arm/mach-omap2/abb44xx_data.c dumb question: with the request to move everything out of mach-omap2 directory, do we still want to add more files into mach-omap2? Not a dumb question at all. I approached this problem by modeling it after existing voltage layer code (in particular the vp and vc drivers). My hope is to get it merged as-is and then bundle the abb code up with the vp/vc migration to drivers/* when that happens some day. People using omap36xx and above need this code now, so it seems prudent to take this approach today. This is needed, but makes moving the vc code to drivers a bit more complex. So we also need a plan to move this all to drivers in the follow up patches. And we need a maintainer for the code. Who is going to be doing all that? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
* Tony Lindgren t...@atomide.com [121010 17:46]:
Hi,
* Kishon Vijay Abraham I kis...@ti.com [121007 23:01]:
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
...
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
#include linux/io.h
#include linux/platform_data/gpio-omap.h
#include linux/power/smartreflex.h
+#include linux/platform_data/omap_ocp2scp.h
#include plat/omap_hwmod.h
#include plat/i2c.h
@@ -2681,6 +2682,32 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
.sysc = omap44xx_ocp2scp_sysc,
};
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+ {
+ .name = usb_phy,
+ .start = 0x4a0ad080,
+ .end= 0x4a0ae000,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .name = ctrl_dev,
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ { }
+};
Why don't you set the CONTROL_DEV_CONF as a fixed regulator?
After some more investigating, we may be able to set it up as a
regulator or clock later on. But as a regression fix, this seems
OK for me.
Benoit, is this OK for you?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
* Kishon Vijay Abraham I kis...@ti.com [121007 23:01]: ocp2scp was not having pdata support which makes *musb* fail for non-dt boot in OMAP platform. The pdata will have information about the devices that is connected to ocp2scp. ocp2scp driver will now make use of this information to create the devices that is attached to ocp2scp. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com This fixes the regression on my panda es for musb port: Acked-by: Tony Lindgren t...@atomide.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: [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
On Tue, Oct 16, 2012 at 05:32:26PM +0100, Will Deacon wrote: On Tue, Oct 16, 2012 at 05:10:21PM +0100, Aaro Koskinen wrote: On Thu, Sep 20, 2012 at 05:03:38PM +0100, Will Deacon wrote: From: Matthew Leach matthew.le...@arm.com Ensure that the memory regions that are set within the segments correspond to physical contiguous memory regions. This patch seems to break kexec for me in 3.7-rc1 (commit c564df4db85aac8d1d65a56176a0a25f46138064, bisected). kexec -l fails with the following output: kexec_load failed: Invalid argument entry = 0x80008000 flags = 28 nr_segments = 2 segment[0].buf = 0xc48008 segment[0].bufsz = 230 segment[0].mem = 0x80001000 segment[0].memsz = 1000 segment[1].buf = 0xb6a9b008 segment[1].bufsz = 3a4668 segment[1].mem = 0x80008000 segment[1].memsz = 3a5000 Could not load the kexec kernel: n800-zImage The board is OMAP2420 / Nokia N800. Interesting, it sounds like kexec thinks that you don't have contiguous memory from 0x80008000 to 0x803ad000. Can you provide some more information about your physical memory map please? Well, I think it's because the patch is wrong. Shouldn't it be: diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c index e29c333..a80192e 100644 --- a/arch/arm/kernel/machine_kexec.c +++ b/arch/arm/kernel/machine_kexec.c @@ -47,7 +47,7 @@ int machine_kexec_prepare(struct kimage *image) err = memblock_is_region_memory(current_segment-mem, current_segment-memsz); - if (err) + if (!err) return - EINVAL; err = get_user(header, (__be32*)current_segment-buf); A. -- 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] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
On 10/15/2012 12:53 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [121014 22:26]: After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 (ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig: [3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB [3.915954] mmcblk0: p1 [4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [4.093719] Modules linked in: [4.096954] CPU: 0Not tainted (3.6.0-02232-g759e00b #570) [4.103149] PC is at vfp_reload_hw+0x1c/0x44 [4.107666] LR is at __und_usr_fault_32+0x0/0x8 It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 (ARM: 6203/1: Make VFPv3 usable on ARMv6). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP. Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers: http://marc.info/?l=linux-arm-kernelm=135013547905283w=2 and some feedback from Måns to clarify the name of the HWCAP flag. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com Cc: Dave Martin dave.mar...@linaro.org Cc: Måns Rullgård mans.rullg...@linaro.org This fixes the error above on my 2430sdp: Tested-by: Tony Lindgren t...@atomide.com Fixes same error on 2420 H4. Tested-by: Jon Hunter jon-hun...@ti.com Cheers Jon -- 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: [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
On Tue, Oct 16, 2012 at 06:09:00PM +0100, Aaro Koskinen wrote: On Tue, Oct 16, 2012 at 05:32:26PM +0100, Will Deacon wrote: Interesting, it sounds like kexec thinks that you don't have contiguous memory from 0x80008000 to 0x803ad000. Can you provide some more information about your physical memory map please? Well, I think it's because the patch is wrong. Shouldn't it be: diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c index e29c333..a80192e 100644 --- a/arch/arm/kernel/machine_kexec.c +++ b/arch/arm/kernel/machine_kexec.c @@ -47,7 +47,7 @@ int machine_kexec_prepare(struct kimage *image) err = memblock_is_region_memory(current_segment-mem, current_segment-memsz); - if (err) + if (!err) return - EINVAL; err = get_user(header, (__be32*)current_segment-buf); Oops, that's a howler! Thanks for spotting it. We should probably reflow the code a bit because !err sounds like everything should be ok. Fancy reworking the patch or do you want me to take care of this? Cheers, Will -- 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/6] OMAP: iommu: hwmod, reset handling and runtime PM
* Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]: These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. For this series I just dropped the patches already included in mainline. These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu when I have that pushed out as that removes plat/*iommu*.h files. Regards, Tony Previous work can be found at: [v2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg75701.html [v1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html [old iteration without reset, save/restore and device tree] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html Omar Ramirez Luna (6): ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP3/4: iommu: adapt to runtime pm ARM: OMAP: iommu: pm runtime save and restore context ARM: OMAP: iommu: optimize save and restore routines ARM: OMAP: iommu: add device tree support arm/dts: OMAP3/4: Add iommu nodes .../devicetree/bindings/arm/omap/iommu.txt | 10 ++ arch/arm/boot/dts/omap3.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 17 +- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/iommu2.c | 74 ++-- arch/arm/mach-omap2/omap-iommu.c | 176 +--- arch/arm/plat-omap/include/plat/iommu.h| 20 ++- arch/arm/plat-omap/include/plat/iommu2.h |4 - drivers/iommu/omap-iommu.c | 163 ++ 9 files changed, 245 insertions(+), 233 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
* Matt Porter mpor...@ti.com [121010 07:38]: On Wed, Oct 10, 2012 at 10:35:01AM -0400, Matt Porter wrote: On Wed, Oct 10, 2012 at 02:19:40PM +, Vaibhav Hiremath wrote: On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote: On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote: With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Afzal Mohammed af...@ti.com Cc: Tony Lindgren t...@atomide.com Cc Paul Walmsley p...@pwsan.com --- This should go in for rc1, as this breaks AM33xx boot. Fixes BeagleBone on mainline. Tested-by: Matt Porter mpor...@ti.com Thanks Matt and Afzal, Tony can this be picked up for rc1?? I know you have already sent pull request for rc1, but by any chance you are planning to send another request? I also found a separate problem with the mcasp clock data that's needed for rc1. I just posted a patch for that as I need both this patch and the clock data fix to boot from current mainline. Disregard now that you got me pointed to the pull request with this :) Thanks applying $Subject patch into omap-for-v3.7-rc1/fixes-part2 and ignoring the comments about the mcasp clock as it sounds like the mcasp is already fixed. 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] OMAP4: devices: fixup OMAP4 DMIC platform device error message
* Sebastien Guiriec s-guir...@ti.com [121016 08:32]: Correct DMIC hwmod lockup error message and replace printk() by pr_err(). Thanks applying into omap-for-v3.7-rc1/fixes-part2. 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] ARM: OMAP2+: hwmod data: Fix wrong lostcontext_mask for OMAP4 l4_abe
* Benoit Cousson b-cous...@ti.com [121016 01:56]: The following commit added the support for the lostcontext_mask along with the usage of the flag for l4_abe. commit ce80979aedfce937926a8dd40a1f92fd4bc2fd53 Author: Tero Kristo t-kri...@ti.com Date: Sun Sep 23 17:28:19 2012 -0600 ARM: OMAP4: hwmod data: add support for lostcontext_mask Unfortunately, the l4_abe does not contain this memory and thus cannot contain that flag. Remove the flag from the l4_abe hwmod. Change as well the mask for omap44xx_aess_hwmod to avoid missing the status in case LOSTMEM_AESSMEM is set. The AESS logic does not support retention and thus only the memory state is useful. It is even mandatory to avoid a crash in the case of the AESS resume. TBD: Ideally each hwmod should contain an extra entry for memory context attached to it. The AESS does contain only one, but some IP like the IVAHD does have three memories with dedicated status. The granularity is never used, but at least one global information for all the memory banks is useful. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tero Kristo t-kri...@ti.com Thanks applying into omap-for-v3.7-rc1/fixes-part2. 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 00/14] OMAP-GPMC related cleanup for common zImage
* Ivan Djelic ivan.dje...@parrot.com [121010 09:40]: I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 tag. All BCH error correcting tests passed successfully. I occasionally had weird read errors though, especially when reading blank pages: the omap driver returned 512-byte sectors containing something like: 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff instead of: I was able to reproduce the problem also on l2-mtd tip, albeit less often. The problem seems to occur quite randomly, it may be a hardware issue on my board... Things like this typically happen in the GPMC timings are not correct. Maybe add #define DEBUG to top of gpmc.c and compare the timings before and after Afzal's patches? Anyway, the ECC handling part looks OK to me. 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] ARM: OMAP: resolve sparse warning concerning debug_card_init()
* Igor Grinberg grinb...@compulab.co.il [121010 00:02]: On 10/09/12 22:29, Paul Walmsley wrote: Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 (ARM: OMAP: move debug_card_init() function) results in the following new sparse warning: arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static? Fix by implementing Tony's suggestion to add a sideways include to the new location of the debug-devices.h file in arch/arm/mach-omap2/. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Tony Lindgren t...@atomide.com Acked-by: Igor Grinberg grinb...@compulab.co.il Thanks, applying into omap-for-v3.7-rc1/fixes-part2. Regards, Tony --- arch/arm/plat-omap/debug-devices.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/plat-omap/debug-devices.c b/arch/arm/plat-omap/debug-devices.c index c7a4c09..5a4678e 100644 --- a/arch/arm/plat-omap/debug-devices.c +++ b/arch/arm/plat-omap/debug-devices.c @@ -16,6 +16,7 @@ #include linux/smc91x.h #include mach/hardware.h +#include ../mach-omap2/debug-devices.h /* Many OMAP development platforms reuse the same debug board; these * platforms include H2, H3, H4, and Perseus2. -- Regards, Igor. -- 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
* Ohad Ben-Cohen o...@wizery.com [121014 11:32]:
On Fri, Oct 12, 2012 at 6:24 PM, Tony Lindgren t...@atomide.com wrote:
Error setting wl12xx data: -38
..
Ohad, can you please take a look?
Sure, -38 is -ENOSYS which is returned when the wl12xx driver isn't
configured.
This isn't an error (it's a user decision, and it shouldn't elicit any
error) and the patch below (also attached) should make it go away on:
From 374f145568585c8d6a8d5e4b8b5d3e6baedd2f39 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@wizery.com
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
configured
Stop intimidating users with scary wlan error messages in case wl12xx
support wasn't even built.
In addition, when wl12xx_set_platform_data() fails, don't bother
registering wl12xx's fixed regulator device (on the relevant
boards).
While we're at it, extract the wlan init code to a dedicated function to
make (the relevant boards') init code look a bit nicer.
Reported-by: Russell King li...@arm.linux.org.uk
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Thanks applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
---
arch/arm/mach-davinci/board-da850-evm.c | 7 ++-
arch/arm/mach-omap2/board-4430sdp.c | 13 ++--
arch/arm/mach-omap2/board-omap3evm.c | 11 +-
arch/arm/mach-omap2/board-omap3pandora.c | 9 -
arch/arm/mach-omap2/board-omap4panda.c | 30
++--
arch/arm/mach-omap2/board-zoom-peripherals.c | 20 ---
6 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 32ee3f8..1b19415 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1404,8 +1404,13 @@ static __init int da850_wl12xx_init(void)
da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data);
+ /* bail out silently in case wl12xx isn't configured */
+ if (ret == -ENOSYS)
+ goto free_wlan_irq;
+
+ /* bail out verbosely on any other error */
if (ret) {
- pr_err(Could not set wl12xx data: %d\n, ret);
+ pr_err(error setting wl12xx data: %d\n, ret);
goto free_wlan_irq;
}
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..d1dd81a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,9 +826,18 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
- if (ret)
- pr_err(Error setting wl12xx data: %d\n, ret);
+ /* bail out silently in case wl12xx isn't configured */
+ if (ret == -ENOSYS)
+ return;
+
+ /* bail out verbosely on any other error */
+ if (ret) {
+ pr_err(error setting wl12xx data: %d\n, ret);
+ return;
+ }
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..7f72e44 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -637,9 +637,18 @@ static void __init omap3_evm_wl12xx_init(void)
/* WL12xx WLAN Init */
omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
ret = wl12xx_set_platform_data(omap3evm_wlan_data);
- if (ret)
+ /* bail out silently in case wl12xx isn't configured */
+ if (ret == -ENOSYS)
+ return;
+
+ /* bail out verbosely on any other error */
+ if (ret) {
pr_err(error setting wl12xx data: %d\n, ret);
+ return;
+ }
+
ret = platform_device_register(omap3evm_wlan_regulator);
if (ret)
pr_err(error registering wl12xx device: %d\n, ret);
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 00a1f4a..bbc4001 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -549,8 +549,15 @@ static void __init pandora_wl1251_init(void)
pandora_wl1251_pdata.use_eeprom = true;
ret = wl12xx_set_platform_data(pandora_wl1251_pdata);
- if (ret 0)
+ /* bail out silently in case wl12xx isn't configured */
+ if (ret == -ENOSYS)
+ goto fail_irq;
+
+ /* bail out verbosely on any other error */
+ if (ret) {
+ pr_err(error setting wl12xx data: %d\n, ret);
goto fail_irq;
+ }
Re: [PATCH] ARM: OMAP4: hwmod data: gpmc main clk
* Benoit Cousson b-cous...@ti.com [121015 03:02]:
Hi Afzal,
On 10/15/2012 07:47 AM, Afzal Mohammed wrote:
gpmc has been converted to a driver. It requests clock with
con-id fck, if not available, probe fails. Clock for gpmc
device with con-id fck is created (aliased) along with
hwmod device, and for that to happen, main_clk needs to be
specified in hwmod entry, add it for OMAP4.
Well, in this case, this is not the preferred way. The hwmod data are
supposed to reflect the real HW capabilities.
We'd better add the alias in the already existing dummy clock node.
Here is the patch to do that.
Thanks,
Benoit
---
From: Benoit Cousson b-cous...@ti.com
Date: Mon, 15 Oct 2012 11:41:42 +0200
Subject: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy
fck
The GPMC code has been converted to a driver by the following commit:
commit da496873970c57c4b31e186d967933da0ffa0d7c
Author: Afzal Mohammed af...@ti.com
Date: Sun Sep 23 17:28:25 2012 -0600
ARM: OMAP2+: gpmc: minimal driver support
It now requests a clock with con-id fck otherwise the probe will fails.
[0.342010] omap-gpmc omap-gpmc: error: clk_get
[0.346771] omap-gpmc: probe of omap-gpmc failed with error -2
Add the omap-gmpc dev-id and fck con-id to the already existing
gmpc-fck dummy clock.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Afzal Mohammed af...@ti.com
Thanks applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d661d13..6efc30c 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3294,7 +3294,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, auxclk5_src_ck, auxclk5_src_ck,
CK_443X),
CLK(NULL, auxclk5_ck, auxclk5_ck,
CK_443X),
CLK(NULL, auxclkreq5_ck,auxclkreq5_ck,
CK_443X),
- CLK(NULL, gpmc_ck, dummy_ck,
CK_443X),
+ CLK(omap-gpmc,fck, dummy_ck,
CK_443X),
CLK(omap_i2c.1, ick, dummy_ck,
CK_443X),
CLK(omap_i2c.2, ick, dummy_ck,
CK_443X),
CLK(omap_i2c.3, ick, dummy_ck,
CK_443X),
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
* Mohammed, Afzal af...@ti.com [121014 23:00]: Hi, On Fri, Oct 12, 2012 at 21:54:52, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]: omap-gpmc omap-gpmc: error: clk_get omap-gpmc: probe of omap-gpmc failed with error -2 I think Afzal posted something about this already? Looks like this too could be sparse IRQ related regression.. Patch has been posted to resolve the issue, ARM: OMAP4: hwmod data: gpmc main clk. OK thanks I'll pick that up. 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
* Tony Lindgren t...@atomide.com [121016 11:12]: * Ohad Ben-Cohen o...@wizery.com [121014 11:32]: On Fri, Oct 12, 2012 at 6:24 PM, Tony Lindgren t...@atomide.com wrote: Error setting wl12xx data: -38 .. Ohad, can you please take a look? Sure, -38 is -ENOSYS which is returned when the wl12xx driver isn't configured. This isn't an error (it's a user decision, and it shouldn't elicit any error) and the patch below (also attached) should make it go away on: From 374f145568585c8d6a8d5e4b8b5d3e6baedd2f39 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen o...@wizery.com Date: Sun, 14 Oct 2012 20:16:01 +0200 Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't configured Stop intimidating users with scary wlan error messages in case wl12xx support wasn't even built. In addition, when wl12xx_set_platform_data() fails, don't bother registering wl12xx's fixed regulator device (on the relevant boards). While we're at it, extract the wlan init code to a dedicated function to make (the relevant boards') init code look a bit nicer. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Ohad Ben-Cohen o...@wizery.com Thanks applying into omap-for-v3.7-rc1/fixes-part2. Hmm looking at it repeats the same code over again. Can you rather add some wl12xx_board_init() helper function to mach-omap2/devices.c to do it? Dropping this for now. 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Hi Tony, On 10/16/2012 08:12 PM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [121014 23:00]: Hi, On Fri, Oct 12, 2012 at 21:54:52, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]: omap-gpmc omap-gpmc: error: clk_get omap-gpmc: probe of omap-gpmc failed with error -2 I think Afzal posted something about this already? Looks like this too could be sparse IRQ related regression.. Patch has been posted to resolve the issue, ARM: OMAP4: hwmod data: gpmc main clk. OK thanks I'll pick that up. In fact you should not pick that one, the one I sent superseded it: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck BTW, I cannot find your omap-for-v3.7-rc1/fixes-part2 branch, did you already pushed it? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On 10/15/2012 02:16 PM, Richard Cochran wrote: From: hvaib...@ti.com hvaib...@ti.com With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. I am not sure I completely follow the logic here. Won't this problem occur if the bootloader does not configure the gpmc cs space AND we are not using DT? Is the csvalid bit set because we are booting from the internal ROM? I guess I don't see why csvalid bit being set and a base-address of 0x0 should not be allowed. That should be a valid combination. One problem I see with gpmc_mem_init() is that it assumes that BOOT_ROM_SPACE is 1MB for all devices starting at 0x0 apart from the apollon board. For newer devices such as OMAP4, there is only 48KB of internal ROM and only mapped to 0x0 when booting from internal ROM. So this needs to be fixed. How much internal ROM does the AM335x have and where is it mapped? This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. Yes, but we do actually still allow some platform devices to be probed (such as dmtimers) when booting with DT that don't support DT yet. So this change prevents us from using the gpmc on boards when booting with DT. I am not convinced that this is addressing the underlying problem with gpmc_mem_init(). Cheers Jon -- 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
* Benoit Cousson b-cous...@ti.com [121016 12:26]: Hi Tony, On 10/16/2012 08:12 PM, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [121014 23:00]: Hi, On Fri, Oct 12, 2012 at 21:54:52, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121012 08:56]: omap-gpmc omap-gpmc: error: clk_get omap-gpmc: probe of omap-gpmc failed with error -2 I think Afzal posted something about this already? Looks like this too could be sparse IRQ related regression.. Patch has been posted to resolve the issue, ARM: OMAP4: hwmod data: gpmc main clk. OK thanks I'll pick that up. In fact you should not pick that one, the one I sent superseded it: [PATCH] ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck OK yeah looks like I have the right one then. BTW, I cannot find your omap-for-v3.7-rc1/fixes-part2 branch, did you already pushed it? Not yet, was running randconfig builds on it while I was out for lunch :) Just pushed it out. 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 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
* Richard Cochran richardcoch...@gmail.com [121015 12:18]:
From: hvaib...@ti.com hvaib...@ti.com
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not configure gpmc cs space
will result into kernel BUG() inside gpmc_mem_init() function,
as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
gpmc_config7[0].baseaddress is set to '0' on reset.
This use-case is applicable for any board/EVM which doesn't have
any peripheral connected to gpmc cs0, for example BeagleXM and
BeagleBone, so DT boot mode fails.
This patch adds of_have_populated_dt() check before creating
device, so that for DT boot mode, gpmc probe will not be called
which is expected behavior, as gpmc is not supported yet from DT.
I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
Next time, please also cc linux-omap@vger.kernel.org for series
like this. I'm sure the people reading the omap list are interested
in these.
This patch appears to be masking an underlying issue. How about
something like the following ...
Cheers
Jon
From 753a4928bf6f7baa4c001bdca3d15a85e999db4c Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Tested on AM335x beagle bone board.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..8f0d3c8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,17 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, base, size);
- if (gpmc_cs_insert_mem(cs, base, size) 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc))
+ return rc;
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +940,11 @@ static __devinit int gpmc_probe(struct platform_device
*pdev)
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ dev_err(gpmc_dev, failed to reserve memory\n);
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09.5/16] mmc: omap: Remove cpu_is_omap usage from the driver
* Chris Ball c...@laptop.org [121005 11:24]: On Fri, Oct 05 2012, Tony Lindgren wrote: Chris, I can set up a minimal immutable branch with omap header changes that you can also pull into MMC tree if these two MMC patches look ackable to you. Thanks, sounds good. Chris, I've now pushed out branch omap-for-v3.8/cleanup-headers-mmc based on -rc1. The branch is located at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git It contains two omap MMC related patches that you can also merge into the MMC tree if needed as now include plat/mmc.h is gone for omaps. 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] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
* Felipe Balbi ba...@ti.com [121016 03:32]:
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Applying into omap-for-v3.7-rc1/fixes-take3.
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 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
* Jon Hunter jon-hun...@ti.com [121016 14:00]: Hi Tony, On 10/16/2012 12:48 PM, Tony Lindgren wrote: * Richard Cochran richardcoch...@gmail.com [121015 12:18]: From: hvaib...@ti.com hvaib...@ti.com With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. I'm applying this one into omap-for-v3.7-rc1/fixes-part2. Next time, please also cc linux-omap@vger.kernel.org for series like this. I'm sure the people reading the omap list are interested in these. This patch appears to be masking an underlying issue. How about something like the following ... OK that looks good to me. I'll drop the earlier fix and use yours instead. 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: [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
Mike Turquette mturque...@ti.com writes: Quoting Tony Lindgren (2012-10-16 09:32:25) * Mike Turquette mturque...@ti.com [121011 15:27]: Quoting Nishanth Menon (2012-10-11 06:33:04) On 18:26-20121003, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org [...] arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/abb.c | 322 + arch/arm/mach-omap2/abb.h | 94 [...] arch/arm/plat-omap/include/plat/voltage.h |1 + 18 files changed, 699 insertions(+), 37 deletions(-) create mode 100644 arch/arm/mach-omap2/abb.c create mode 100644 arch/arm/mach-omap2/abb.h create mode 100644 arch/arm/mach-omap2/abb36xx_data.c create mode 100644 arch/arm/mach-omap2/abb44xx_data.c dumb question: with the request to move everything out of mach-omap2 directory, do we still want to add more files into mach-omap2? Not a dumb question at all. I approached this problem by modeling it after existing voltage layer code (in particular the vp and vc drivers). My hope is to get it merged as-is and then bundle the abb code up with the vp/vc migration to drivers/* when that happens some day. People using omap36xx and above need this code now, so it seems prudent to take this approach today. This is needed, but makes moving the vc code to drivers a bit more complex. So we also need a plan to move this all to drivers in the follow up patches. And we need a maintainer for the code. Who is going to be doing all that? Is there already somebody committed to moving vp/vc code out to drivers? Yes, VC/VP is part of the bigger PRM/CM move in progress. For now, I'm ok with adding a little more VC/VP stuff since it's already well isolated in the prm.c files (though it might need a rebase on Paul's recent PRM/CM cleanup stuff.) If so then I can take responsibility for moving the abb code and coordinate with that person. 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-GPMC cleanup for common zImage
* Afzal Mohammed af...@ti.com [121015 05:15]:
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
g...@gitorious.org:x0148406-public/linux-kernel.git tags/gpmc-czimage
for you to fetch changes up to 3ef5d0071cf6c8b9a00b559232bb700ad5d7:
ARM: OMAP2+: gpmc: localize gpmc header (2012-10-15 14:42:15 +0530)
gpmc cleanup for common ARM zImage
Thanks pulling into omap-for-v3.8/cleanup-headers-gpmc
I ended up using the following url instead:
git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-czimage
Regards,
Tony
Afzal Mohammed (16):
ARM: OMAP2+: nand: unify init functions
ARM: OMAP2+: onenand: refactor for clarity
ARM: OMAP2+: gpmc: remove cs# in sync clk div calc
mtd: onenand: omap: cleanup gpmc dependency
mtd: nand: omap: free region as per resource size
mtd: nand: omap: read nand using register address
ARM: OMAP2+: onenand: connected soc info in pdata
mtd: onenand: omap: use pdata info instead of cpu_is
ARM: OMAP2+: onenand: header cleanup
ARM: OMAP2+: nand: header cleanup
mtd: nand: omap: bring in gpmc nand macros
ARM: OMAP2+: nand: bch capability check
ARM: OMAP2+: gpmc: nand register helper bch update
mtd: nand: omap: handle gpmc bch[48]
ARM: OMAP2+: gpmc: remove exported nand functions
ARM: OMAP2+: gpmc: localize gpmc header
Jon Hunter (1):
ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function
arch/arm/mach-omap2/board-2430sdp.c| 2 +-
arch/arm/mach-omap2/board-3430sdp.c| 2 +-
arch/arm/mach-omap2/board-apollon.c| 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 5 +-
arch/arm/mach-omap2/board-cm-t3517.c | 5 +-
arch/arm/mach-omap2/board-devkit8000.c | 10 +-
arch/arm/mach-omap2/board-flash.c | 50 +--
arch/arm/mach-omap2/board-flash.h | 8 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 5 +-
arch/arm/mach-omap2/board-ldp.c| 6 +-
arch/arm/mach-omap2/board-n8x0.c | 1 +
arch/arm/mach-omap2/board-omap3beagle.c| 10 +-
arch/arm/mach-omap2/board-omap3evm.c | 8 +-
arch/arm/mach-omap2/board-omap3logic.c | 2 +-
arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 10 +-
arch/arm/mach-omap2/board-overo.c | 9 +-
arch/arm/mach-omap2/board-rm680.c | 3 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +-
arch/arm/mach-omap2/board-rx51.c | 2 +-
arch/arm/mach-omap2/board-zoom-debugboard.c| 2 +-
arch/arm/mach-omap2/board-zoom.c | 5 +-
arch/arm/mach-omap2/common-board-devices.c | 46 ---
arch/arm/mach-omap2/common-board-devices.h | 1 -
arch/arm/mach-omap2/gpmc-nand.c| 85 ++--
arch/arm/mach-omap2/gpmc-nand.h| 27 ++
arch/arm/mach-omap2/gpmc-onenand.c | 214 +-
arch/arm/mach-omap2/gpmc-onenand.h | 24 ++
arch/arm/mach-omap2/gpmc-smc91x.c | 2 +-
arch/arm/mach-omap2/gpmc-smsc911x.c| 2 +-
arch/arm/mach-omap2/gpmc.c | 459
+
.../{plat-omap/include/plat = mach-omap2}/gpmc.h | 61 +--
arch/arm/mach-omap2/pm34xx.c | 2 +-
arch/arm/mach-omap2/usb-tusb6010.c | 2 +-
drivers/mtd/nand/omap2.c | 125 +-
drivers/mtd/onenand/omap2.c| 9 +-
include/linux/platform_data/mtd-nand-omap2.h | 46 ++-
include/linux/platform_data/mtd-onenand-omap2.h| 28 +-
40 files changed, 493 insertions(+), 797 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.h
create mode 100644 arch/arm/mach-omap2/gpmc-onenand.h
rename arch/arm/{plat-omap/include/plat = mach-omap2}/gpmc.h (67%)
--
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 v4? 0/7] Adaptive Body-Bias for OMAP
* Kevin Hilman khil...@deeprootsystems.com [121016 14:51]: Mike Turquette mturque...@ti.com writes: Quoting Tony Lindgren (2012-10-16 09:32:25) * Mike Turquette mturque...@ti.com [121011 15:27]: Quoting Nishanth Menon (2012-10-11 06:33:04) On 18:26-20121003, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org [...] arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/abb.c | 322 + arch/arm/mach-omap2/abb.h | 94 [...] arch/arm/plat-omap/include/plat/voltage.h |1 + 18 files changed, 699 insertions(+), 37 deletions(-) create mode 100644 arch/arm/mach-omap2/abb.c create mode 100644 arch/arm/mach-omap2/abb.h create mode 100644 arch/arm/mach-omap2/abb36xx_data.c create mode 100644 arch/arm/mach-omap2/abb44xx_data.c dumb question: with the request to move everything out of mach-omap2 directory, do we still want to add more files into mach-omap2? Not a dumb question at all. I approached this problem by modeling it after existing voltage layer code (in particular the vp and vc drivers). My hope is to get it merged as-is and then bundle the abb code up with the vp/vc migration to drivers/* when that happens some day. People using omap36xx and above need this code now, so it seems prudent to take this approach today. This is needed, but makes moving the vc code to drivers a bit more complex. So we also need a plan to move this all to drivers in the follow up patches. And we need a maintainer for the code. Who is going to be doing all that? Is there already somebody committed to moving vp/vc code out to drivers? Yes, VC/VP is part of the bigger PRM/CM move in progress. For now, I'm ok with adding a little more VC/VP stuff since it's already well isolated in the prm.c files (though it might need a rebase on Paul's recent PRM/CM cleanup stuff.) If so then I can take responsibility for moving the abb code and coordinate with that person. Thanks Mike Kevin, sounds good to me. 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
[PATCH] genirq: provide means to retrigger parent
From: Thomas Gleixner t...@linutronix.de
Attempts to retrigger nested threaded IRQs currently fail because they
have no primary handler. In order to support retrigger of nested
IRQs, the parent IRQ needs to be retriggered.
To fix, when an IRQ needs to be resent, if the interrupt has a parent
IRQ and runs in the context of the parent IRQ, then resend the parent.
Also, handle_nested_irq() needs to clear the replay flag like the
other handlers, otherwise check_irq_resend() will set it and it will
never be cleared. Without clearing, it results in the first resend
working fine, but check_irq_resend() returning early on subsequent
resends because the replay flag is still set.
Problem discovered on ARM/OMAP platforms where a nested IRQ that's
also a wakeup IRQ happens late in suspend and needed to be retriggered
during the resume process.
Reported-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
[khil...@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
Applies on v3.7-rc1
include/linux/irq.h |9 +
include/linux/irqdesc.h |3 +++
kernel/irq/chip.c |1 +
kernel/irq/manage.c | 16
kernel/irq/resend.c |8
5 files changed, 37 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 216b0ba..526f10a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -392,6 +392,15 @@ static inline void irq_move_masked_irq(struct irq_data
*data) { }
extern int no_irq_affinity;
+#ifdef CONFIG_HARDIRQS_SW_RESEND
+int irq_set_parent(int irq, int parent_irq);
+#else
+static inline int irq_set_parent(int irq, int parent_irq)
+{
+ return 0;
+}
+#endif
+
/*
* Built-in IRQ handlers for various IRQ types,
* callable via desc-handle_irq()
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 0ba014c..623325e 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -11,6 +11,8 @@
struct irq_affinity_notify;
struct proc_dir_entry;
struct module;
+struct irq_desc;
+
/**
* struct irq_desc - interrupt descriptor
* @irq_data: per irq and chip data passed down to chip functions
@@ -65,6 +67,7 @@ struct irq_desc {
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *dir;
#endif
+ int parent_irq;
struct module *owner;
const char *name;
} cacheline_internodealigned_in_smp;
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 57d86d0..3aca9f2 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -272,6 +272,7 @@ void handle_nested_irq(unsigned int irq)
raw_spin_lock_irq(desc-lock);
+ desc-istate = ~(IRQS_REPLAY | IRQS_WAITING);
kstat_incr_irqs_this_cpu(irq, desc);
action = desc-action;
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 4c69326..d06a396 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -616,6 +616,22 @@ int __irq_set_trigger(struct irq_desc *desc, unsigned int
irq,
return ret;
}
+#ifdef CONFIG_HARDIRQS_SW_RESEND
+int irq_set_parent(int irq, int parent_irq)
+{
+ unsigned long flags;
+ struct irq_desc *desc = irq_get_desc_lock(irq, flags, 0);
+
+ if (!desc)
+ return -EINVAL;
+
+ desc-parent_irq = parent_irq;
+
+ irq_put_desc_unlock(desc, flags);
+ return 0;
+}
+#endif
+
/*
* Default primary interrupt handler for threaded interrupts. Is
* assigned as primary handler when request_threaded_irq is called
diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
index 6454db7..9065107 100644
--- a/kernel/irq/resend.c
+++ b/kernel/irq/resend.c
@@ -74,6 +74,14 @@ void check_irq_resend(struct irq_desc *desc, unsigned int
irq)
if (!desc-irq_data.chip-irq_retrigger ||
!desc-irq_data.chip-irq_retrigger(desc-irq_data)) {
#ifdef CONFIG_HARDIRQS_SW_RESEND
+ /*
+* If the interrupt has a parent irq and runs
+* in the thread context of the parent irq,
+* retrigger the parent.
+*/
+ if (desc-parent_irq
+ irq_settings_is_nested_thread(desc))
+ irq = desc-parent_irq;
/* Set it pending and activate the softirq: */
set_bit(irq, irqs_resend);
tasklet_schedule(resend_tasklet);
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genirq: provide means to retrigger parent
On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote: From: Thomas Gleixner t...@linutronix.de Attempts to retrigger nested threaded IRQs currently fail because they have no primary handler. In order to support retrigger of nested IRQs, the parent IRQ needs to be retriggered. To fix, when an IRQ needs to be resent, if the interrupt has a parent IRQ and runs in the context of the parent IRQ, then resend the parent. Also, handle_nested_irq() needs to clear the replay flag like the other handlers, otherwise check_irq_resend() will set it and it will never be cleared. Without clearing, it results in the first resend working fine, but check_irq_resend() returning early on subsequent resends because the replay flag is still set. Problem discovered on ARM/OMAP platforms where a nested IRQ that's also a wakeup IRQ happens late in suspend and needed to be retriggered during the resume process. Reported-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com [khil...@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()] Signed-off-by: Thomas Gleixner t...@linutronix.de Umm, we also have the converse situation. We have platforms where the resend has to be done from the child IRQ, and the parent must not be touched. I hope that doesn't break those. -- 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
Updated status of the removal of plat headers
Hi all, Here's a quick status update on the removal of remaining #include plat/*.h files. Most files are now fixed up, and we only have the following remaining: cpu.h wrapper only left, will be removed as soon as drivers are fixed dmtimer.h Jon is fixing this mailbox.h Omar, are you fixing this? omap-serial.h this will be dealt with mostly by Russell prcm.h Paul has posted patches for this, missing move of the header sdrc.h Paul has posted patches for this, missing move of the header timex.h Igor is looking into this usb.h Felipe, Kishon Keshawa, are you fixing this? vram.h Tomi is fixing this vrfb.h Tomi is fixing this I have not yet posted my omap-for-v3.8/cleanup-headers branch as I'm waiting for a minimal tty branch from Greg for the 8250 changes, and acks for the menelaus and iommu changes. 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 1/1] twl4030: Fix chained irq handling on resume from suspend
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes: The irqs are enabled one-by-one in pm core resume_noirq phase. This leads to situation where the twl4030 primary interrupt handler (PIH) is enabled before the chained secondary handlers (SIH). As the PIH cannot clear the pending interrupt, and SIHs have not been enabled yet, a flood of interrupts hangs the device. Fixed the issue by setting the SIH irqs with IRQF_EARLY_RESUME flags, so they get enabled before the PIH. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com Acked-by: Kevin Hilman khil...@ti.com Thanks, I like this better than the I2C driver fix. Samuel, feel free to take this for v3.7 Kevin --- drivers/mfd/twl4030-irq.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index ad733d7..cdd1173 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -672,7 +672,8 @@ int twl4030_sih_setup(struct device *dev, int module, int irq_base) irq = sih_mod + twl4030_irq_base; irq_set_handler_data(irq, agent); agent-irq_name = kasprintf(GFP_KERNEL, twl4030_%s, sih-name); - status = request_threaded_irq(irq, NULL, handle_twl4030_sih, 0, + status = request_threaded_irq(irq, NULL, handle_twl4030_sih, + IRQF_EARLY_RESUME, agent-irq_name ?: sih-name, NULL); dev_info(dev, %s (irq %d) chaining IRQs %d..%d\n, sih-name, -- 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: Updated status of the removal of plat headers
Hi On Tue, 16 Oct 2012, Tony Lindgren wrote: prcm.hPaul has posted patches for this, missing move of the header sdrc.hPaul has posted patches for this, missing move of the header Just to clarify these, I've only posted 1 of 2 series to clean up prcm.h. With luck the second one will be posted within a week. Also I haven't yet posted a sdrc.h cleanup patch, but it's coming shortly. - 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
Re: [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
Paul Walmsley p...@pwsan.com writes: Hi Kevin, Here's an updated version of this one, with the erratum coverage expanded to include OMAP34xx/35xx. I think this one can replace Tero's [PATCHv6 06/11] ARM: OMAP: clockdomain: add support for preventing autodep delete and [PATCHv6 07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle. Tero, please let us know if you feel otherwise. The patch seems to pass testing on 37xx. Was not able to really test it on 35xx due to PM regressions in v3.7-rc1. With workarounds for some of the other regressions, this passes ret/off idle/suspend tests on 3530/Overo, 3730/OveroSTORM and 3730/Beagle-xM. Queueing for v3.7-rc. 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
[PATCH] ARM: OMAP: move plat-omap/include/plat/sdrc.h into mach-omap2/sdrc.h
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in cleaning out arch/arm/plat-omap/, as his upstreams request. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- This has a dependency on Tomi's OMAP: VRFB: convert to platform device series. arch/arm/mach-omap2/board-omap3logic.c |1 - arch/arm/mach-omap2/clkt2xxx_dpllcore.c|2 +- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c |1 - arch/arm/mach-omap2/control.c |4 +- arch/arm/mach-omap2/gpmc.c |1 - arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/pm34xx.c |1 - arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h |2 +- arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h |2 +- arch/arm/mach-omap2/sdram-nokia.c |2 +- arch/arm/mach-omap2/sdram-numonyx-m65kam.h |2 +- .../mach-omap2/sdram-qimonda-hyb18m512160af-6.h|2 +- arch/arm/mach-omap2/sdrc.c |1 - arch/arm/mach-omap2/sdrc.h | 153 +- arch/arm/mach-omap2/sdrc2xxx.c |1 - arch/arm/plat-omap/include/plat/sdrc.h | 164 17 files changed, 156 insertions(+), 187 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/sdrc.h diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c index 7bd8253..cbcea42 100644 --- a/arch/arm/mach-omap2/board-omap3logic.c +++ b/arch/arm/mach-omap2/board-omap3logic.c @@ -36,7 +36,6 @@ #include gpmc-smsc911x.h #include plat/gpmc.h -#include plat/sdrc.h #include plat/usb.h #include common.h diff --git a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c index 4ae4392..3507659 100644 --- a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c +++ b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c @@ -27,13 +27,13 @@ #include plat/clock.h #include plat/sram.h -#include plat/sdrc.h #include clock.h #include clock2xxx.h #include opp2xxx.h #include cm2xxx_3xxx.h #include cm-regbits-24xx.h +#include sdrc.h /* #define DOWN_VARIABLE_DPLL 1 */ /* Experimental */ diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c index 3524f0e..0cf63e7 100644 --- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c +++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c @@ -35,7 +35,6 @@ #include plat/clock.h #include plat/sram.h -#include plat/sdrc.h #include soc.h #include clock.h @@ -43,6 +42,7 @@ #include opp2xxx.h #include cm2xxx_3xxx.h #include cm-regbits-24xx.h +#include sdrc.h const struct prcm_config *curr_prcm_set; const struct prcm_config *rate_table; diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c index 7c6da2f..aff6ca4 100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -23,7 +23,6 @@ #include plat/clock.h #include plat/sram.h -#include plat/sdrc.h #include clock.h #include clock3xxx.h diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index d1ff839..bf2be5c 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -1,7 +1,7 @@ /* * OMAP2/3 System Control Module register access * - * Copyright (C) 2007 Texas Instruments, Inc. + * Copyright (C) 2007, 2012 Texas Instruments, Inc. * Copyright (C) 2007 Nokia Corporation * * Written by Paul Walmsley @@ -15,8 +15,6 @@ #include linux/kernel.h #include linux/io.h -#include plat/sdrc.h - #include soc.h #include iomap.h #include common.h diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 5ac5cf3..e7f2b80 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -31,7 +31,6 @@ #include plat/cpu.h #include plat/gpmc.h -#include plat/sdrc.h #include plat/omap_device.h #include soc.h diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 4234d28..ab82dbe 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -26,7 +26,6 @@ #include asm/mach/map.h #include plat/sram.h -#include plat/sdrc.h #include plat/serial.h #include plat/omap-pm.h #include plat/omap_hwmod.h @@ -43,6 +42,7 @@ #include clock2xxx.h #include clock3xxx.h #include clock44xx.h +#include sdrc.h /* * The machine specific code may provide the extra mapping besides the diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index ba670db..ee0bffc 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -38,7 +38,6 @@ #include plat/sram.h #include clockdomain.h #include powerdomain.h -#include plat/sdrc.h #include plat/prcm.h #include
Re: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
Tony Lindgren t...@atomide.com writes:
* Felipe Balbi ba...@ti.com [121016 03:32]:
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Applying into omap-for-v3.7-rc1/fixes-take3.
Doh, this isn't quite right yet. Some more PM testing shows that UART
wakeups are broken, so this isn't ready for v3.7 yet.
To be continued...
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] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
* Kevin Hilman khil...@deeprootsystems.com [121016 18:04]: Doh, this isn't quite right yet. Some more PM testing shows that UART wakeups are broken, so this isn't ready for v3.7 yet. OK I'll drop it then. 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: [PATCHv6 01/11] ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
On Tue, 25 Sep 2012, Tero Kristo wrote: Previously the code only acquired spinlock after increasing / decreasing the usecount value, which is wrong. This leaves a small window where a task switch may occur between the check of the usecount and the actual wakeup / sleep of the domain. Fixed by moving the spinlock locking before the usecount access. Left the usecount as atomic_t if someone wants an easy access to the parameter through atomic_read. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - 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
Re: [PATCHv6 01/11] ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
* Paul Walmsley p...@pwsan.com [121016 19:26]: On Tue, 25 Sep 2012, Tero Kristo wrote: Previously the code only acquired spinlock after increasing / decreasing the usecount value, which is wrong. This leaves a small window where a task switch may occur between the check of the usecount and the actual wakeup / sleep of the domain. Fixed by moving the spinlock locking before the usecount access. Left the usecount as atomic_t if someone wants an easy access to the parameter through atomic_read. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Paul Walmsley p...@pwsan.com OK I'll apply this into omap-for-v3.7-rc1/fixes-take4. 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 00/14] OMAP-GPMC related cleanup for common zImage
Hi Ivan, On Tuesday 16 October 2012 11:36 PM, Tony Lindgren wrote: * Ivan Djelicivan.dje...@parrot.com [121010 09:40]: I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 tag. All BCH error correcting tests passed successfully. I occasionally had weird read errors though, especially when reading blank pages: the omap driver returned 512-byte sectors containing something like: I was able to reproduce the problem also on l2-mtd tip, albeit less often. The problem seems to occur quite randomly, it may be a hardware issue on my board... Things like this typically happen in the GPMC timings are not correct. Maybe add #define DEBUG to top of gpmc.c and compare the timings before and after Afzal's patches? Latest series for gpmc related cleanup for common zImage removed dependency on minor timing cleanups (this series was dependent on on another series that did minor timing cleanups). A pull request for the new series on gpmc cleanup for common zImage that does not contain timing related changes and without dependency on timing related changes has been sent to Tony (forwarded to you now). He has pulled those changes onto l-o in omap-for-v3.8/cleanup-headers-gpmc As there are no changes w.r.t timing's in the new series, behaviour should be same as without. Anyway, the ECC handling part looks OK to me. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. I commented on auxdata usage without visualising in more detail how it can be implemented, it was bad of me. I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Let me discuss internally and get back. Regards Afzal -- 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
