re: mmc: omap: Fix DMA configuration to not rely on device id
Hello Tony Lindgren,
This is a semi-automatic email about new static checker warnings.
The patch 31ee9181eb92: mmc: omap: Fix DMA configuration to not rely
on device id from Nov 26, 2013, leads to the following Smatch
complaint:
drivers/mmc/host/omap.c:1468 mmc_omap_probe()
error: we previously assumed 'res' could be null (see line 1410)
drivers/mmc/host/omap.c
1409 res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
1410 if (res)
^^^
Patch introduces a check.
1411 sig = res-start;
1412 host-dma_rx = dma_request_slave_channel_compat(mask,
1413 omap_dma_filter_fn, sig, pdev-dev,
rx);
1414 if (!host-dma_rx)
1415 dev_warn(host-dev, unable to obtain RX DMA engine
channel %u\n,
1416 sig);
1417
1418 ret = request_irq(host-irq, mmc_omap_irq, 0, DRIVER_NAME,
host);
1419 if (ret)
1420 goto err_free_dma;
1421
1422 if (pdata-init != NULL) {
1423 ret = pdata-init(pdev-dev);
1424 if (ret 0)
1425 goto err_free_irq;
1426 }
1427
1428 host-nr_slots = pdata-nr_slots;
1429 host-reg_shift = (mmc_omap7xx() ? 1 : 2);
1430
1431 host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
1432 if (!host-mmc_omap_wq)
1433 goto err_plat_cleanup;
1434
1435 for (i = 0; i pdata-nr_slots; i++) {
1436 ret = mmc_omap_new_slot(host, i);
1437 if (ret 0) {
1438 while (--i = 0)
1439 mmc_omap_remove_slot(host-slots[i]);
1440
1441 goto err_destroy_wq;
1442 }
1443 }
1444
1445 return 0;
1446
1447 err_destroy_wq:
1448 destroy_workqueue(host-mmc_omap_wq);
1449 err_plat_cleanup:
1450 if (pdata-cleanup)
1451 pdata-cleanup(pdev-dev);
1452 err_free_irq:
1453 free_irq(host-irq, host);
1454 err_free_dma:
1455 if (host-dma_tx)
1456 dma_release_channel(host-dma_tx);
1457 if (host-dma_rx)
1458 dma_release_channel(host-dma_rx);
1459 clk_put(host-fclk);
1460 err_free_iclk:
1461 clk_disable(host-iclk);
1462 clk_put(host-iclk);
1463 err_free_mmc_host:
1464 iounmap(host-virt_base);
1465 err_ioremap:
1466 kfree(host);
1467 err_free_mem_region:
1468 release_mem_region(res-start, resource_size(res));
^^
Existing unchecked dereferences.
1469 return ret;
1470 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe 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] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Hi David,
On 11/29/2013 03:17 PM, David Laight wrote:
From: Of Roger Quadros
With u-boot 2013.10, USB devices are sometimes not detected
on OMAP4 Panda. To make us independent of what bootloader does
with the USB Host module, we must RESET it to get it to a known
good state. This patch Soft RESETs the USB Host module.
...
+++ b/drivers/mfd/omap-usb-host.c
@@ -43,14 +43,18 @@
/* UHH Register Set */
#define OMAP_UHH_REVISION (0x00)
#define OMAP_UHH_SYSCONFIG (0x10)
-#define OMAP_UHH_SYSCONFIG_MIDLEMODE(1 12)
+#define OMAP_UHH_SYSCONFIG_MIDLEMASK(3 12)
+#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12)
(tab/space issue)
Weird, original code seems to use a tab instead of space after #define.
Wouldn't it be clearer to define these in the opposite order with:
+#define OMAP_UHH_SYSCONFIG_MIDLEMASK(3
OMAP_UHH_SYSCONFIG_MIDLESHIFT)
Right.
...
+static void omap_usbhs_rev1_reset(struct device *dev)
+{
+struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+u32 reg;
+unsigned long timeout;
+
+reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
+
+/* Soft Reset */
+usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
+reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
+
+timeout = jiffies + msecs_to_jiffies(100);
+while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
+ OMAP_UHH_SYSSTATUS_RESETDONE)) {
+cpu_relax();
You mean use msleep(1) here instead of cpu_relax()?
Shouldn't be a problem IMO, but can you please tell me why that is better
as the reset seems to complete usually in the first iteration.
+
+if (time_after(jiffies, timeout)) {
+dev_err(dev, Soft RESET operation timed out\n);
+break;
+}
+}
+
+/* Set No-Standby */
+reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
+reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
+ OMAP_UHH_SYSCONFIG_MIDLESHIFT;
+
+/* Set No-Idle */
+reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
+reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
+ OMAP_UHH_SYSCONFIG_SIDLESHIFT;
Why not pass in the mask and value and avoid replicating the
entire function. I can't see any other significant differences,
the udelay(2) won't be significant.
OK, I can pass the mask and value, but still there is a difference
in the way reset complete is checked between v1 and v2. But that
be in omap_usbhs_softreset() and the individual reset functions can be
replaced by a single omap_usbhs_set_sysconfig().
It seems the udelay() is not required for the USB Host module, so I'll
get rid of that.
I'm not sure of the context this code runs in, but if the reset
is likely to take a significant portion of the 100ms timeout
period, why not just sleep for a few ms between status polls.
covered in the related code above.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
+Benoit, Tony, Paul.
Hi Michael,
On 11/30/2013 06:48 AM, Michael Trimarchi wrote:
Hi Roger
On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
With u-boot 2013.10, USB devices are sometimes not detected
on OMAP4 Panda. To make us independent of what bootloader does
with the USB Host module, we must RESET it to get it to a known
good state. This patch Soft RESETs the USB Host module.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.10+
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 115
+---
1 file changed, 109 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..d4bd464 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -43,14 +43,18 @@
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
-#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 12)
+#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3 12)
+#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12)
#defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 8)
-#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 3)
+#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3 3)
+#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT (3)
#defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2)
#defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 1)
#defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1 0)
#defineOMAP_UHH_SYSSTATUS (0x14)
+#define OMAP_UHH_SYSSTATUS_RESETDONE (1 0)
+
#defineOMAP_UHH_HOSTCONFIG (0x40)
#defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1 0)
#defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS (1 0)
@@ -66,10 +70,10 @@
#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 31)
/* OMAP4-specific defines */
-#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 2)
-#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 2)
-#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 4)
-#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 4)
+#define OMAP4_UHH_SYSCONFIG_MIDLEMASK (3 2)
+#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
+#define OMAP4_UHH_SYSCONFIG_SIDLEMASK (3 4)
+#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
#define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0)
#define OMAP4_P1_MODE_CLEAR(3 16)
@@ -81,6 +85,12 @@
#defineOMAP_UHH_DEBUG_CSR (0x44)
+/* MIDLE modes */
+#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
+
+/* SIDLE modes */
+#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
+
/* Values of UHH_REVISION - Note: these are not given in the TRM */
#define OMAP_USBHS_REV10x0010 /* OMAP3 */
#define OMAP_USBHS_REV20x50700100 /* OMAP4 */
@@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
usbhs_hcd_omap *omap,
return reg;
}
I'm digging in the code but as I understand this should be done by
omap_hwmod and
i660 avoid reset of the ehci module. This is done by ocp_softreset?
It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod
data [1].
Question is do we do it in the driver of leave it to hwmod?
The other concern about i660 is in this comment [1]
/*
* During system boot; If the hwmod framework resets the module
* the module will have smart idle settings; which can lead to deadlock
* (above Errata Id:i660); so, dont reset the module during boot;
* Use HWMOD_INIT_NO_RESET.
*/
But if you look at the errata document [2], Advisory 1.108, it doesn't say that
we can't be in smart-idle, but
only that we should put the module in force-idle, before cutting the module's
functional clock. It also states
that the only way to recover from a lockup condition is to soft reset the
module. So I'm not sure if the above comment
in the code is really valid. What if the lockup happens in the bootloader? In
that case we will have to reset the module in
the kernel.
Doing the reset in probe does solve a problem for now i.e. eliminates
dependency on bootloader.
[1] -
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c#n2024
[2] - http://www.ti.com/litv/pdf/sprz318e
+static void omap_usbhs_rev1_reset(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ u32
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Michael,
On 11/29/2013 05:32 PM, Michael Trimarchi wrote:
Hi Roger
On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
With u-boot 2013.10, USB devices are sometimes not detected
on OMAP4 Panda. To make us independent of what bootloader does
with the USB Host module, we must RESET it to get it to a known
good state. This patch Soft RESETs the USB Host module.
Do you think that we need something similar of usb musb?
I have seen the OTG_SYSCONFIG is touched in uboot and
only readed in omap2430.c.
I'm not sure about musb. Maybe Sebastian/Felipe have better idea.
In general I believe that all modules must be reset by the kernel.
cheers,
-roger
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.10+
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 115
+---
1 file changed, 109 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..d4bd464 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -43,14 +43,18 @@
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
-#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 12)
+#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3 12)
+#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12)
#defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 8)
-#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 3)
+#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3 3)
+#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT (3)
#defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2)
#defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 1)
#defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1 0)
#defineOMAP_UHH_SYSSTATUS (0x14)
+#define OMAP_UHH_SYSSTATUS_RESETDONE (1 0)
+
#defineOMAP_UHH_HOSTCONFIG (0x40)
#defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1 0)
#defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS (1 0)
@@ -66,10 +70,10 @@
#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 31)
/* OMAP4-specific defines */
-#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 2)
-#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 2)
-#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 4)
-#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 4)
+#define OMAP4_UHH_SYSCONFIG_MIDLEMASK (3 2)
+#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
+#define OMAP4_UHH_SYSCONFIG_SIDLEMASK (3 4)
+#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
#define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0)
#define OMAP4_P1_MODE_CLEAR(3 16)
@@ -81,6 +85,12 @@
#defineOMAP_UHH_DEBUG_CSR (0x44)
+/* MIDLE modes */
+#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
+
+/* SIDLE modes */
+#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
+
/* Values of UHH_REVISION - Note: these are not given in the TRM */
#define OMAP_USBHS_REV10x0010 /* OMAP3 */
#define OMAP_USBHS_REV20x50700100 /* OMAP4 */
@@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
usbhs_hcd_omap *omap,
return reg;
}
+static void omap_usbhs_rev1_reset(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ u32 reg;
+ unsigned long timeout;
+
+ reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
+
+ /* Soft Reset */
+ usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
+ reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
+
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
+OMAP_UHH_SYSSTATUS_RESETDONE)) {
+ cpu_relax();
+
+ if (time_after(jiffies, timeout)) {
+ dev_err(dev, Soft RESET operation timed out\n);
+ break;
+ }
+ }
+
+ /* Set No-Standby */
+ reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
+ reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
+OMAP_UHH_SYSCONFIG_MIDLESHIFT;
+
+ /* Set No-Idle */
+ reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
+ reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
+OMAP_UHH_SYSCONFIG_SIDLESHIFT;
+
+ usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
+}
+
+static void omap_usbhs_rev2_reset(struct device *dev)
+{
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Hi Roger On Mon, Dec 2, 2013 at 10:39 AM, Roger Quadros rog...@ti.com wrote: +Benoit, Tony, Paul. Hi Michael, On 11/30/2013 06:48 AM, Michael Trimarchi wrote: Hi Roger On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote: With u-boot 2013.10, USB devices are sometimes not detected on OMAP4 Panda. To make us independent of what bootloader does with the USB Host module, we must RESET it to get it to a known good state. This patch Soft RESETs the USB Host module. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: sta...@vger.kernel.org # 3.10+ Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 115 +--- 1 file changed, 109 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 142650f..d4bd464 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -43,14 +43,18 @@ /* UHH Register Set */ #defineOMAP_UHH_REVISION (0x00) #defineOMAP_UHH_SYSCONFIG (0x10) -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 12) +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3 12) +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12) #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 8) -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 3) +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3 3) +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT (3) #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2) #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 1) #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1 0) #defineOMAP_UHH_SYSSTATUS (0x14) +#define OMAP_UHH_SYSSTATUS_RESETDONE (1 0) + #defineOMAP_UHH_HOSTCONFIG (0x40) #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1 0) #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS (1 0) @@ -66,10 +70,10 @@ #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 31) /* OMAP4-specific defines */ -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 2) -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 2) -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 4) -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 4) +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK (3 2) +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2) +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK (3 4) +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4) #define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0) #define OMAP4_P1_MODE_CLEAR(3 16) @@ -81,6 +85,12 @@ #defineOMAP_UHH_DEBUG_CSR (0x44) +/* MIDLE modes */ +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1) + +/* SIDLE modes */ +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1) + /* Values of UHH_REVISION - Note: these are not given in the TRM */ #define OMAP_USBHS_REV10x0010 /* OMAP3 */ #define OMAP_USBHS_REV20x50700100 /* OMAP4 */ @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct usbhs_hcd_omap *omap, return reg; } I'm digging in the code but as I understand this should be done by omap_hwmod and i660 avoid reset of the ehci module. This is done by ocp_softreset? It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod data [1]. Question is do we do it in the driver of leave it to hwmod? The other concern about i660 is in this comment [1] I don't find any description of this errata for omap4. Is this errata valid? My change was to remove the NO_INIT and add 2uS as you have done /* * During system oot; If the hwmod framework resets the module * the module will have smart idle settings; which can lead to deadlock * (above Errata Id:i660); so, dont reset the module during boot; * Use HWMOD_INIT_NO_RESET. */ But if you look at the errata document [2], Advisory 1.108, it doesn't say that we can't be in smart-idle, but only that we should put the module in force-idle, before cutting the module's functional clock. It also states that the only way to recover from a lockup condition is to soft reset the module. So I'm not sure if the above comment in the code is really valid. What if the lockup happens in the bootloader? In that case we will have to reset the module in the kernel. Michael Doing the reset in probe does solve a problem for now i.e. eliminates dependency on bootloader. [1] -
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi Mark, Sorry for delayed response. I was away for some time. On Friday 15 November 2013 04:53 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: Hi Mark, On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly +connected from the peripherals, but are routed dynamically +by a crossbar/multiplexer preceding the GIC. The GIC irq +input line is assigned dynamically when the corresponding +peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. We did try using interrupts= property for all peripherals and mapping them as crossbar's parent. But that approach of representing crossbar as a interrupt parent was not accepted, since the crossbar was just routing the interrupts from peripherals to GIC and nothing more. Also mapping all the interrupts using interrupt-map like property by a fixed way in DTS itself was considered hacky I'm not suggesting you should interrupt-map. I agree that that interrupt-map is not suitable for a dynamically configurable device like the crossbar. When you say that the crossbar is just routing the interrupts, at what level is it doing so? Does it accept a logical interrupt and output another logical interrupt, or does it just connect the two lines electrically? As Santosh, already mentioned this just makes a physical connection and thats it We don't necessarily have to use the interrupts property, but I still think that the set of GIC input IRQ lines that the crossbar is wired to should be described on the crossbar node. Listing 160 interrupts in the crossbar node is clearly something we don't want to have to do. If we had a property that we could use to define a range (or multiple ranges) of interrupts, then the crossbar driver could go and request those ranges from its interrupt-parent (the GIC) and the GIC driver could reserve/allocate the irqdomain at that time. Again, this kind of approach of crossbar requesting irqs from GIC was tried earlier and it did not go anywhere. Subsequently after lot of discussions this design was considered the best one. http://www.spinics.net/lists/linux-omap/msg97085.html As far as I can see, the
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Tested this with 3.13-rc1, and it somewhat works, but causes some ECC error messages: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 10.423736] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd-read(0x100 bytes from 0x4) returned ECC error [ 10.480743] jffs2: mtd-read(0x100 bytes from 0x6) returned ECC error [ 10.489013] jffs2: mtd-read(0x100 bytes from 0x8) returned ECC error [ 10.497283] jffs2: mtd-read(0x100 bytes from 0xa) returned ECC error [ 10.505126] jffs2: mtd-read(0x100 bytes from 0xc) returned ECC error [ 10.513458] jffs2: mtd-read(0x100 bytes from 0xe) returned ECC error [ 10.521667] jffs2: mtd-read(0x100 bytes from 0x10) returned ECC error [ 10.529968] jffs2: mtd-read(0x100 bytes from 0x12) returned ECC error [ 10.538269] jffs2: mtd-read(0x100 bytes from 0x14) returned ECC error [ 10.546295] jffs2: mtd-read(0x100 bytes from 0x16) returned ECC error [ 10.554534] jffs2: mtd-read(0x100 bytes from 0x18) returned ECC error [ 10.563323] jffs2: mtd-read(0x100 bytes from 0x1a) returned ECC error [ 10.571685] jffs2: mtd-read(0x100 bytes from 0x1c) returned ECC error [ 10.579986] jffs2: mtd-read(0x100 bytes from 0x1e) returned ECC error [ 10.588287] jffs2: mtd-read(0x100 bytes from 0x20) returned ECC error [ 10.596313] jffs2: mtd-read(0x100 bytes from 0x22) returned ECC error [ 10.604522] jffs2: mtd-read(0x100 bytes from 0x24) returned ECC error [ 10.613037] jffs2: mtd-read(0x100 bytes from 0x26) returned ECC error [ 10.621307] jffs2: mtd-read(0x100 bytes from 0x28) returned ECC error [ 10.629608] jffs2: mtd-read(0x100 bytes from 0x2a) returned ECC error [ 10.637908] jffs2: mtd-read(0x100 bytes from 0x2c) returned ECC error [ 10.645843] jffs2: mtd-read(0x100 bytes from 0x2e) returned ECC error [ 10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # # # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK This is with a JFFS2 image flashed after doing nandecc sw in U-Boot. Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. However, this works perfectly fine, with the same JFFS2 image, flashed in the same way in U-Boot: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 19.789306] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
Since currently nobody uses TWL603x platform data and all new
Hmm... when you say nobody, how did you come to this conclusion?
Without digging into it and probably not that relevant, it
appears there is some references to it in platform data still:
$ git grep twl603 -- arch/ | grep -v dts
arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers);
arch/arm/mach-omap2/omap4-common.c:static int
omap4_twl6030_hsmmc_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: irq =
twl6030_mmc_card_detect_config();
arch/arm/mach-omap2/omap4-common.c:
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
arch/arm/mach-omap2/omap4-common.c:static __init void
omap4_twl6030_hsmmc_set_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: pdata-init =
omap4_twl6030_hsmmc_late_init;
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap4-common.c:
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap_twl.c:static unsigned long
twl6030_vsel_to_uv(const u8 vsel)
arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned
long
uv)
arch/arm/mach-omap2/omap_twl.c: if (uv twl6030_vsel_to_uv(0x39)) {
arch/arm/mach-omap2/omap_twl.c: __func__, uv,
twl6030_vsel_to_uv(0x39));
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
Looks like some misunderstanding is here. This patch *only* removes
platform data for TWL603x
which were used to create TWL sub-devices like regulators, adc's,
watchdogs, etc.
Previously it was set up in twl_common.c by omap4_pmic_init(), which was
called from board files
with specific pmic config.
Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
OMAP4 board files
have been removed omap4_pmic_init() is never called and all TWL603x
sub-devices are created
from device tree data.
I'm not overly familiar with this driver (it looks like a big
historical mess to me), or the current state of the OMAP4 platform, so
I would like a second opinion on this.
Tony would you be kind enough to oblige?
We've moved omap4 to boot based on device tree only, so that legacy
platform data is no longer being used. It might be worth checking if
we do have bindings in place for all of that, or if some of it may
still be needed to be passed as auxdata while we wait for the bindings.
Ruslan, do you know the answer to these concerns?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] NAND bus-width detection extreme makeover
Hello. Here's my proposal, based in Pekon's latest work. This patch removes the flash device bus-width configuration, prior to the device detection. With this modification, a NAND driver is no longer able to force the device width, and instead can only obtain the detected bus-width after the call to nand_scan_ident(). ... Alexander: Could you try this patch and see if it's suitable for your needs? I think you should be able to use it to set the bus-width, without any need for a new DT property. You will have to split your nand_scan() call in an initial call to nand_scan_ident() and a final call to nand_scan_tail(). 16-bit ONFI: ONFI param page 0 valid ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0xca (Micron MT29F2G16ABAEAWP), 256MiB, page size: 2048, OOB size: 64 Scanning device for bad blocks 1 ofpart partitions found on MTD device MT29F2G16ABAEAWP Creating 1 MTD partitions on MT29F2G16ABAEAWP: 0x-0x1000 : nand-gpio 8-bit non-ONFI: NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit), 64MiB, page size: 512, OOB size: 16 Scanning device for bad blocks 1 ofpart partitions found on MTD device NAND 64MiB 3,3V 8-bit Creating 1 MTD partitions on NAND 64MiB 3,3V 8-bit: 0x-0x0400 : nand-gpio Cannot test 8-bit ONFI, since have not such chip. ---
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
- sta...@vger.kernel.org since they probably don't care about this unless the patch is merged. On 12/02/2013 10:41 AM, Roger Quadros wrote: Michael, On 11/29/2013 05:32 PM, Michael Trimarchi wrote: Hi Roger On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote: With u-boot 2013.10, USB devices are sometimes not detected on OMAP4 Panda. To make us independent of what bootloader does with the USB Host module, we must RESET it to get it to a known good state. This patch Soft RESETs the USB Host module. Do you think that we need something similar of usb musb? I have seen the OTG_SYSCONFIG is touched in uboot and only readed in omap2430.c. I'm not sure about musb. Maybe Sebastian/Felipe have better idea. In general I believe that all modules must be reset by the kernel. based on the code at the bottom it touches the first few register(s) sysconfig. Isn't hwmod actually doing this idle stuff and resting the device during boot? cheers, -roger Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
Michael, On 12/02/2013 11:51 AM, Michael Trimarchi wrote: Hi Roger On Mon, Dec 2, 2013 at 10:39 AM, Roger Quadros rog...@ti.com wrote: +Benoit, Tony, Paul. Hi Michael, On 11/30/2013 06:48 AM, Michael Trimarchi wrote: Hi Roger On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote: With u-boot 2013.10, USB devices are sometimes not detected on OMAP4 Panda. To make us independent of what bootloader does with the USB Host module, we must RESET it to get it to a known good state. This patch Soft RESETs the USB Host module. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: sta...@vger.kernel.org # 3.10+ Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 115 +--- 1 file changed, 109 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c index 142650f..d4bd464 100644 --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -43,14 +43,18 @@ /* UHH Register Set */ #defineOMAP_UHH_REVISION (0x00) #defineOMAP_UHH_SYSCONFIG (0x10) -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1 12) +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3 12) +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT (12) #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1 8) -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1 3) +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3 3) +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT (3) #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1 2) #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1 1) #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1 0) #defineOMAP_UHH_SYSSTATUS (0x14) +#define OMAP_UHH_SYSSTATUS_RESETDONE (1 0) + #defineOMAP_UHH_HOSTCONFIG (0x40) #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1 0) #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS (1 0) @@ -66,10 +70,10 @@ #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 31) /* OMAP4-specific defines */ -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3 2) -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1 2) -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3 4) -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1 4) +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK (3 2) +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2) +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK (3 4) +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4) #define OMAP4_UHH_SYSCONFIG_SOFTRESET (1 0) #define OMAP4_P1_MODE_CLEAR(3 16) @@ -81,6 +85,12 @@ #defineOMAP_UHH_DEBUG_CSR (0x44) +/* MIDLE modes */ +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1) + +/* SIDLE modes */ +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1) + /* Values of UHH_REVISION - Note: these are not given in the TRM */ #define OMAP_USBHS_REV10x0010 /* OMAP3 */ #define OMAP_USBHS_REV20x50700100 /* OMAP4 */ @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct usbhs_hcd_omap *omap, return reg; } I'm digging in the code but as I understand this should be done by omap_hwmod and i660 avoid reset of the ehci module. This is done by ocp_softreset? It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod data [1]. Question is do we do it in the driver of leave it to hwmod? The other concern about i660 is in this comment [1] I don't find any description of this errata for omap4. Is this errata valid? I can't say for sure. You might have to try it out without those flags and see if it works reliably. My change was to remove the NO_INIT and add 2uS as you have done The 2uS delay that I added was my mistake and I don't think it is required. Just removing HWMOD_INIT_NO_RESET should work. cheers, -roger /* * During system oot; If the hwmod framework resets the module * the module will have smart idle settings; which can lead to deadlock * (above Errata Id:i660); so, dont reset the module during boot; * Use HWMOD_INIT_NO_RESET. */ But if you look at the errata document [2], Advisory 1.108, it doesn't say that we can't be in smart-idle, but only that we should put the module in force-idle, before cutting the module's functional clock. It also states that the only way to recover from a lockup condition is to soft reset the module. So I'm not sure if the
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 02:01 PM, Sebastian Andrzej Siewior wrote: - sta...@vger.kernel.org since they probably don't care about this unless the patch is merged. On 12/02/2013 10:41 AM, Roger Quadros wrote: Michael, On 11/29/2013 05:32 PM, Michael Trimarchi wrote: Hi Roger On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote: With u-boot 2013.10, USB devices are sometimes not detected on OMAP4 Panda. To make us independent of what bootloader does with the USB Host module, we must RESET it to get it to a known good state. This patch Soft RESETs the USB Host module. Do you think that we need something similar of usb musb? I have seen the OTG_SYSCONFIG is touched in uboot and only readed in omap2430.c. I'm not sure about musb. Maybe Sebastian/Felipe have better idea. In general I believe that all modules must be reset by the kernel. based on the code at the bottom it touches the first few register(s) sysconfig. Isn't hwmod actually doing this idle stuff and resting the device during boot? You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET flag, so hwmod should reset it during boot. Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host hwmod data, then we don't need to change this driver at all. Benoit, Tony any comments? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Fix the name of supplies for smsc911x shared by OMAP
drivers/net/ethernet/smsc/smsc911x.c is expecting supplies named vdd33a and vddvario. Currently the shared DTS file provides vmmc and vmmc_aux, and the supply lookup will fail: smsc911x 2c00.ethernet: Looking up vdd33a-supply from device tree smsc911x 2c00.ethernet: Looking up vdd33a-supply property in node /ocp/gpmc@6e00/ethernet@gpmc failed smsc911x 2c00.ethernet: Looking up vddvario-supply from device tree smsc911x 2c00.ethernet: Looking up vddvario-supply property in node /ocp/gpmc@6e00/ethernet@gpmc failed Fix it! Tested on OMAP3 Overo platform. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi index 9c18adf..f577b7d 100644 --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi @@ -44,8 +44,8 @@ gpmc,wr-access-ns = 186; gpmc,cycle2cycle-samecsen; gpmc,cycle2cycle-diffcsen; - vmmc-supply = vddvario; - vmmc_aux-supply = vdd33a; + vddvario-supply = vddvario; + vdd33a-supply = vdd33a; reg-io-width = 4; smsc,save-mac-address; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 01:12 PM, Roger Quadros wrote: You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET flag, so hwmod should reset it during boot. Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host hwmod data, then we don't need to change this driver at all. Benoit, Tony any comments? Almost two years ago in commit de231388 (ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3) the don't reset flag has been added by Keshava. It refers to Errata Id:i660 why it is required. Once you figured what why it has been added you could have an idea if it is okay to remove it and if the reset you do here might lead to it (I dunno). cheers, -roger Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
Since add_children() never called in not-dt boot, this patch does not
change current
OMAP4 boot behavior and devices initialization.
Also as far as I see all these twl603x regulators (apart from CLK32KG)
and TWL usb
module now have dt-bindings support. Device tree support for CLK32KG
have been removed
since it should not be registered as regulator at all.
So this patch can merged safely.
On Mon, Dec 2, 2013 at 1:08 PM, Lee Jones lee.jo...@linaro.org wrote:
Since currently nobody uses TWL603x platform data and all new
Hmm... when you say nobody, how did you come to this conclusion?
Without digging into it and probably not that relevant, it
appears there is some references to it in platform data still:
$ git grep twl603 -- arch/ | grep -v dts
arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers);
arch/arm/mach-omap2/omap4-common.c:static int
omap4_twl6030_hsmmc_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: irq =
twl6030_mmc_card_detect_config();
arch/arm/mach-omap2/omap4-common.c:
pdata-slots[0].card_detect = twl6030_mmc_card_detect;
arch/arm/mach-omap2/omap4-common.c:static __init void
omap4_twl6030_hsmmc_set_late_init(struct device *dev)
arch/arm/mach-omap2/omap4-common.c: pdata-init =
omap4_twl6030_hsmmc_late_init;
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap4-common.c:
omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
arch/arm/mach-omap2/omap4-common.c:int __init
omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
arch/arm/mach-omap2/omap_twl.c:static unsigned long
twl6030_vsel_to_uv(const u8 vsel)
arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned
long
uv)
arch/arm/mach-omap2/omap_twl.c: if (uv twl6030_vsel_to_uv(0x39)) {
arch/arm/mach-omap2/omap_twl.c: __func__, uv,
twl6030_vsel_to_uv(0x39));
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv =
twl6030_vsel_to_uv,
arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel =
twl6030_uv_to_vsel,
Looks like some misunderstanding is here. This patch *only* removes
platform data for TWL603x
which were used to create TWL sub-devices like regulators, adc's,
watchdogs, etc.
Previously it was set up in twl_common.c by omap4_pmic_init(), which was
called from board files
with specific pmic config.
Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
OMAP4 board files
have been removed omap4_pmic_init() is never called and all TWL603x
sub-devices are created
from device tree data.
I'm not overly familiar with this driver (it looks like a big
historical mess to me), or the current state of the OMAP4 platform, so
I would like a second opinion on this.
Tony would you be kind enough to oblige?
We've moved omap4 to boot based on device tree only, so that legacy
platform data is no longer being used. It might be worth checking if
we do have bindings in place for all of that, or if some of it may
still be needed to be passed as auxdata while we wait for the bindings.
Ruslan, do you know the answer to these concerns?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
Ruslan Ruslichenko | Software Engineer
GlobalLogic
www.globallogic.com
http://www.globallogic.com/email_disclaimer.txt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling
On Thu, 21 Nov 2013, Ruslan Ruslichenko wrote: Since currently nobody uses TWL603x platform data and all new users will supply it through device tree, handling of these data within twl-core will never be used, so remove it. Signed-off-by: Ruslan Ruslichenko ruslan.rusliche...@globallogic.com --- Tested on TI SDP/Tablet OMAP4460 board Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git commit 5e01dc7 Linux 3.12 drivers/mfd/twl-core.c | 198 - 1 file changed, 198 deletions(-) Okay, I'm suitably happy with yours and Tony's responses. Patch applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 03:04 PM, Sebastian Andrzej Siewior wrote: On 12/02/2013 01:12 PM, Roger Quadros wrote: You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET flag, so hwmod should reset it during boot. Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host hwmod data, then we don't need to change this driver at all. Benoit, Tony any comments? Almost two years ago in commit de231388 (ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3) the don't reset flag has been added by Keshava. It refers to Errata Id:i660 why it is required. Once you figured what why it has been added you could have an idea if it is okay to remove it and if the reset you do here might lead to it (I dunno). Keshava no longer works @TI. I have no other means to check why it was added other than doing dome tests and making sure nothing breaks if we remove it. So far, things are going fine for about 50 or so boots divided between OMAP3 and 4 platforms. If more people can test and give feedback it'd be great. For the present situation, omap4 panda USB host doesn't work without the reset with u-boot v2013.10. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 02:35 PM, Roger Quadros wrote: It refers to Errata Id:i660 why it is required. Once you figured what why it has been added you could have an idea if it is okay to remove it and if the reset you do here might lead to it (I dunno). Keshava no longer works @TI. I have no other means to check why it was added other than doing dome tests and making sure nothing breaks if we remove it. So far, things are going fine for about 50 or so boots divided between OMAP3 and 4 platforms. If more people can test and give feedback it'd be great. Hmm. Can't you lookup the errata he revers to? cheers, -roger Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 03:39 PM, Sebastian Andrzej Siewior wrote: On 12/02/2013 02:35 PM, Roger Quadros wrote: It refers to Errata Id:i660 why it is required. Once you figured what why it has been added you could have an idea if it is okay to remove it and if the reset you do here might lead to it (I dunno). Keshava no longer works @TI. I have no other means to check why it was added other than doing dome tests and making sure nothing breaks if we remove it. So far, things are going fine for about 50 or so boots divided between OMAP3 and 4 platforms. If more people can test and give feedback it'd be great. Hmm. Can't you lookup the errata he revers to? Sure, but it was not making sense why RESET was avoided. It doesn't say anything about not using RESET. In fact it says that RESET _is_ the recovery procedure. Pasting the errata description below for easy reference. Errata id: i660 DESCRIPTION In the following configuration : • USBHOST module is set to smart-idle mode • PRCM asserts idle_req to the USBHOST module. (This typically happens when the system is going to a low power mode : all ports have been suspended, the master part of the USBHOST module has entered the standby state, and SW has cut the functional clocks.) • an USBHOST interrupt occurs before the module is able to answer idle_ack, typically a remote wakeup IRQ. Then the USB HOST module will enter a deadlock situation where it is no more accessible nor functional. The only way to recover will be to perform a software reset of the module. WORKAROUND The best workaround consists in switching the module to force idle mode right before cutting the module's FCLK. • the bus has reached the suspend state. • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has been taken into account in case of posted writes. • cut the FCLK • Idle_req will be asserted and idle_ack answered within one L3 clock cycle. Upon resume or remote wakeup, switch back the module to smart-idle. This workaround reduces the failure window to only one L3 clock cycle. The probability for an interrupt to fire at this exact time is considered extremely low, and the case has never been hit on board. Based on this, I don't see anything wrong in Resetting the module at probe or at boot. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 02:44 PM, Roger Quadros wrote: Errata id: i660 DESCRIPTION In the following configuration : • USBHOST module is set to smart-idle mode • PRCM asserts idle_req to the USBHOST module. (This typically happens when the system is going to a low power mode : all ports have been suspended, the master part of the USBHOST module has entered the standby state, and SW has cut the functional clocks.) • an USBHOST interrupt occurs before the module is able to answer idle_ack, typically a remote wakeup IRQ. Then the USB HOST module will enter a deadlock situation where it is no more accessible nor functional. The only way to recover will be to perform a software reset of the module. WORKAROUND The best workaround consists in switching the module to force idle mode right before cutting the module's FCLK. • the bus has reached the suspend state. • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has been taken into account in case of posted writes. • cut the FCLK • Idle_req will be asserted and idle_ack answered within one L3 clock cycle. Upon resume or remote wakeup, switch back the module to smart-idle. This workaround reduces the failure window to only one L3 clock cycle. The probability for an interrupt to fire at this exact time is considered extremely low, and the case has never been hit on board. Based on this, I don't see anything wrong in Resetting the module at probe or at boot. If u-boot configured USB into something not smart-idle and the reset would bring it back then the reset should remain. If you could tell hwmod not use smart-idle nor smart-standby and you make sure that the suspend code manually puts the device into suspend via forceidle then I think could get rid of the do-not-reset-thingy. cheers, -roger Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi, CCing Pekon Gupta pe...@ti.com 2013/12/2 Thomas Petazzoni thomas.petazz...@free-electrons.com: Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 525e6d9..9043e97 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -59,7 +59,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; Tested this with 3.13-rc1, and it somewhat works, but causes some ECC error messages: # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 10.423736] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 10.444671] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 10.472290] jffs2: mtd-read(0x100 bytes from 0x4) returned ECC error [ 10.480743] jffs2: mtd-read(0x100 bytes from 0x6) returned ECC error [ 10.489013] jffs2: mtd-read(0x100 bytes from 0x8) returned ECC error [ 10.497283] jffs2: mtd-read(0x100 bytes from 0xa) returned ECC error [ 10.505126] jffs2: mtd-read(0x100 bytes from 0xc) returned ECC error [ 10.513458] jffs2: mtd-read(0x100 bytes from 0xe) returned ECC error [ 10.521667] jffs2: mtd-read(0x100 bytes from 0x10) returned ECC error [ 10.529968] jffs2: mtd-read(0x100 bytes from 0x12) returned ECC error [ 10.538269] jffs2: mtd-read(0x100 bytes from 0x14) returned ECC error [ 10.546295] jffs2: mtd-read(0x100 bytes from 0x16) returned ECC error [ 10.554534] jffs2: mtd-read(0x100 bytes from 0x18) returned ECC error [ 10.563323] jffs2: mtd-read(0x100 bytes from 0x1a) returned ECC error [ 10.571685] jffs2: mtd-read(0x100 bytes from 0x1c) returned ECC error [ 10.579986] jffs2: mtd-read(0x100 bytes from 0x1e) returned ECC error [ 10.588287] jffs2: mtd-read(0x100 bytes from 0x20) returned ECC error [ 10.596313] jffs2: mtd-read(0x100 bytes from 0x22) returned ECC error [ 10.604522] jffs2: mtd-read(0x100 bytes from 0x24) returned ECC error [ 10.613037] jffs2: mtd-read(0x100 bytes from 0x26) returned ECC error [ 10.621307] jffs2: mtd-read(0x100 bytes from 0x28) returned ECC error [ 10.629608] jffs2: mtd-read(0x100 bytes from 0x2a) returned ECC error [ 10.637908] jffs2: mtd-read(0x100 bytes from 0x2c) returned ECC error [ 10.645843] jffs2: mtd-read(0x100 bytes from 0x2e) returned ECC error [ 10.654113] jffs2: notice: (851) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # # # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK This is with a JFFS2 image flashed after doing nandecc sw in U-Boot. Just a note that this binding property got renamed for v3.13 on commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc Author: Pekon Gupta pe...@ti.com Date: Thu Oct 24 18:20:18 2013 +0530 mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes so users using current v3.12 kernel or older should use ti,nand-ecc-opt = sw; instead. However, this works perfectly fine, with the same JFFS2 image, flashed in the same way in U-Boot: Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? # mount -t jffs2 /dev/mtdblock3 /mnt/ [ 19.789306] jffs2: CLEANMARKER node found at 0x has totlen 0xc != normal 0x0 [ 19.810455] jffs2: CLEANMARKER node found at 0x0002 has totlen 0xc != normal 0x0 [ 19.850860] jffs2: notice: (802) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # cd /mnt/ # ls MD5SUMS foo10foo3 foo5 foo7 foo9 foo1 foo2 foo4 foo6 foo8 # md5sum -c MD5SUMS foo1: OK foo10: OK foo2: OK foo3: OK foo4: OK foo5: OK foo6: OK foo7: OK foo8: OK foo9: OK Best regards, Thomas -- Thomas Petazzoni, CTO, Free
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi, From: Enric Balletbo Serra [mailto:eballe...@gmail.com] CCing Pekon Gupta pe...@ti.com 2013/12/2 Thomas Petazzoni thomas.petazz...@free-electrons.com: Dear Javier Martinez Canillas, On Sun, 1 Dec 2013 13:27:25 +0100, Javier Martinez Canillas wrote: diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index d5cc792..4229e94 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -116,7 +116,7 @@ linux,mtd-name= micron,mt29c4g96maz; reg = 0 0 0; nand-bus-width = 16; - ti,nand-ecc-opt = bch8; + ti,nand-ecc-opt = ham1; A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). [...] Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? In addition, please use HAM1 ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel ham1 and u-boot ham1 should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. with regards, pekon
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On Mon, 2 Dec 2013, Roger Quadros wrote: It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod data [1]. Question is do we do it in the driver of leave it to hwmod? It should be done by hwmod (or more broadly, some OMAP bus code). That way the device can be brought to a known state even if there's no driver present (e.g., if the driver was built as a module). The other concern about i660 is in this comment [1] /* * During system boot; If the hwmod framework resets the module * the module will have smart idle settings; which can lead to deadlock * (above Errata Id:i660); so, dont reset the module during boot; * Use HWMOD_INIT_NO_RESET. */ But if you look at the errata document [2], Advisory 1.108, it doesn't say that we can't be in smart-idle, but only that we should put the module in force-idle, before cutting the module's functional clock. Yes, that looks to be correct. There shouldn't be any problem with the module being in smart-idle mode if the PRCM doesn't try to put it into a low-power mode. It already has the HWMOD_SWSUP_SIDLE flag set, so seems to me it should work fine without HWMOD_INIT_NO_RESET, if i660 is the only issue. Most of the IP blocks that are marked with HWMOD_INIT_NO_RESET are only that way due to laziness, or lack of time, etc., and should be closely reviewed. - 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: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. The current result is that booting a mainline kernel with DT on existing bootloaders simply breaks existing configurations. Pekon, the old ti,nand-ecc-opt = sw should be replaced by ti,nand-ecc-opt = ham1 ? Should be the same ? In that case, why this different behavior ? In addition, please use HAM1 ecc-scheme on mainline u-boot also to flash. (following patches were accepted by domain maintainer 'Scott Woods'). http://lists.denx.de/pipermail/u-boot/2013-November/167548.html So, Kernel ham1 and u-boot ham1 should be in sync.. Once above is clean, you may like to pull another set of patches below (these are kernel equivalent of driver optimization for u-boot driver) http://lists.denx.de/pipermail/u-boot/2013-November/167445.html Also, for JFFS2, please erase the flash using -j option. '-j' option adds a clean marker to erased blocks. As said, I'm erasing/flashing from U-Boot, so flash_eraseall options are not really useful here :) Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On 12/02/2013 04:03 PM, Sebastian Andrzej Siewior wrote: On 12/02/2013 02:44 PM, Roger Quadros wrote: Errata id: i660 DESCRIPTION In the following configuration : • USBHOST module is set to smart-idle mode • PRCM asserts idle_req to the USBHOST module. (This typically happens when the system is going to a low power mode : all ports have been suspended, the master part of the USBHOST module has entered the standby state, and SW has cut the functional clocks.) • an USBHOST interrupt occurs before the module is able to answer idle_ack, typically a remote wakeup IRQ. Then the USB HOST module will enter a deadlock situation where it is no more accessible nor functional. The only way to recover will be to perform a software reset of the module. WORKAROUND The best workaround consists in switching the module to force idle mode right before cutting the module's FCLK. • the bus has reached the suspend state. • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has been taken into account in case of posted writes. • cut the FCLK • Idle_req will be asserted and idle_ack answered within one L3 clock cycle. Upon resume or remote wakeup, switch back the module to smart-idle. This workaround reduces the failure window to only one L3 clock cycle. The probability for an interrupt to fire at this exact time is considered extremely low, and the case has never been hit on board. Based on this, I don't see anything wrong in Resetting the module at probe or at boot. If u-boot configured USB into something not smart-idle and the reset would bring it back then the reset should remain. If you could tell hwmod not use smart-idle nor smart-standby and you make sure that the suspend code manually puts the device into suspend via forceidle then I think could get rid of the do-not-reset-thingy. We are already telling hwmod to not use smart-idle or smart-standby. So the device is always put in no-idle,no-standby during resume and force-idle,force-standby during suspend. I'll send a new patch to remove do-not-reset flag from hwmod data and then we don't need this patch. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. Yes, there is a way to change ecc-scheme in u-boot.. Also, you can modify to any ecc-scheme in u-boot using CONFIG_NAND_OMAP_ECCSCHEME as documented in doc/README.nand Also your board should boot seamlessly from mainline u-boot in sync with mainline kernel. As per my knowledge following patch is already in mainline u-boot. And touches your board as well. (omap3_igep00x0.h) http://lists.denx.de/pipermail/u-boot/2013-November/167550.html AFAIK these patches should be in u-boot mainline. Though I have taken at-most care that no existing board should break. But, I'm sorry if there is something broken in between the u-boot and Kernel builds. Let me know if I can help in fixing that somehow. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi all, 2013/12/2 Gupta, Pekon pe...@ti.com: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 14:56:09 +, Gupta, Pekon wrote: A query Why are you going backward from BCH8 to HAM1 ? HAM1 is just kept for legacy reasons, it's not at all recommended for new development. As some field results have shown that devices with HAM1 become un-usable very soon and start reporting uncorrectable errors because HAM1 can only handle single bit-flip, which is inadequate in field conditions and large page device wears-n-tears. (especially considering your device density is of order of 4Gb - mt29c4g96maz). Also, just to inform that BCH8_SW ecc-scheme is implemented in such a way that *only* error correction is handled using s/w library (lib/bch.c). Rest all ECC calculation is handled using GPMC hardware. So, the CPU penalty will be seen only when there are bit-flips found during Read access, which are of rare conditions, occurring only few times in multi-megabit transfers. Also, On top of that ecc-schemes implementations have been optimized. And the patch-series is under review on mainline kernel. http://lists.infradead.org/pipermail/linux-mtd/2013-November/thread.html (Apologies for long suggestion, but in summary please don't use HAM1 for any new development. And with BCH8_SW you should see better bit-flip handling (longer device life) with no hit in performance). The crucial point here is that the interaction between the bootloader and the kernel. The use case I have is that I'm flashing a filesystem image from the bootloader, and mounting it from the kernel. Using a mainline 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in legacy mode (no Device Tree) works fine. Using the same 2013.10 U-Boot for IGEPv2 + the mainline kernel booted in DT no longer works, because the kernel disagrees with the bootloader on the ECC scheme to use. So I'm not saying that Hamming is better than BCH, certainly not. I'm just saying that changing ECC scheme in the kernel without looking at the more global picture of what support the bootloaders are offering is not nice. At least, the bootloader should provide a command, or option, to be able to use an ECC scheme that is compatible with what the kernel expects. Yes, there is a way to change ecc-scheme in u-boot.. Also, you can modify to any ecc-scheme in u-boot using CONFIG_NAND_OMAP_ECCSCHEME as documented in doc/README.nand Also your board should boot seamlessly from mainline u-boot in sync with mainline kernel. As per my knowledge following patch is already in mainline u-boot. And touches your board as well. (omap3_igep00x0.h) http://lists.denx.de/pipermail/u-boot/2013-November/167550.html AFAIK these patches should be in u-boot mainline. Though I have taken at-most care that no existing board should break. But, I'm sorry if there is something broken in between the u-boot and Kernel builds. Let me know if I can help in fixing that somehow. with regards, pekon Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. Best regards, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Enric Balletbo Serra, On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote: Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 10:51 AM, Thomas Petazzoni wrote: Dear Enric Balletbo Serra, On Mon, 2 Dec 2013 16:39:09 +0100, Enric Balletbo Serra wrote: Thanks for the explanations to all. Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Tom Rini, On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Of course, ideally, we should also be able to tell the kernel about the ECC scheme on a per-partition basis. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:13 AM, Gupta, Pekon wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. Right, on OMAP3 (and related) we have the issue of ROM only doing 1bit ECC, but being used with parts that require more, so what I said above is important. OMAP4/am335x/later ship with ROM that groks at least BCH16. With my U-Boot hat on, I really don't want to encourage people to come up with designs that require on the fly switching because.. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Exactly. The kernel hasn't, and I get the feeling won't, support this case of needing different ECC schemes for different areas of the NAND, so we'll continue to be in the position of the Linux for flashing everything but bootloader or custom hacks to the kernel. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? By the way, a couple of years ago we wrote a small user-space utility to write the SPL from Linux when a different ECC scheme than the 1-bit hamming understand by the Boot ROM is used. The writeloader [0] utility access the NAND mtd partition as raw and manually writes the ECC in the OOB using the MTD_MODE_RAW and MEMWRITEOOB ioctls. So with minor hacks, you should be able to bring-back 'nandecc'. But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. with regards, pekon Best regards, Javier [0]: http://git.isee.biz/?p=pub/scm/writeloader.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. -- Tom -- To unsubscribe from this list: send the line unsubscribe 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] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
From: Roger Quadros [mailto:rog...@ti.com]
On 11/29/2013 03:17 PM, David Laight wrote:
...
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
+ OMAP_UHH_SYSSTATUS_RESETDONE)) {
+ cpu_relax();
You mean use msleep(1) here instead of cpu_relax()?
Shouldn't be a problem IMO, but can you please tell me why that is better
as the reset seems to complete usually in the first iteration.
If it doesn't finish in the first iteration you don't want to
spin the cpu for 100ms.
If it hasn't finished in the first millisecond, you probably expect
it to actually time out - so you might as well look (say) every 10ms.
David
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini tr...@ti.com wrote: On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. I see, so.. what's the solution then :-) We can push Enric's patch and change to HAM1 in the kernel so Thomas (and others) can write everything from U-boot (SPL, rootfs, etc) but I think is safer to use BCH8 since the NAND requires at least a 4-bit ECC. But doing that we can no longer write the SPL from neither U-Boot nor the kernel. Yes, this can be made from user-space using ISEE's writeloader utility and afair there is one from TI too written in C# but this is not very convenient for users. I believe Thomas is right and the correct approach is to change the OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme but we need a temporal solution until someone implements this. -- Tom Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 109
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 97 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8be5c9f..c197028 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -131,6 +131,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -215,6 +216,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -495,27 +499,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1078,8 +1095,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1591,6 +1612,37 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 irq_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ irq_mask = OMAP_HSMMC_READ(host-base, ISE);
+ if (enable) {
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask |= CIRQ_EN;
+ } else {
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask = ~CIRQ_EN;
+ }
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+
+ /*
+* if enable, piggy back detection on current request
+* but always disable immediately
+*/
+ if (!host-req_in_progress || !enable)
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* flush posted write */
+ OMAP_HSMMC_READ(host-base, IE);
+
+ spin_unlock_irqrestore(host-irq_lock, flags);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1643,7 +1695,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
[PATCH v4 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 605dbd3..2f10843 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1789,14 +1790,25 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
+
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK)
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
mmc-index, host-context_loss);
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
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 v4 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 ++
drivers/mmc/host/omap_hsmmc.c | 180 ++--
2 files changed, 219 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..6365695 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the compatible
+section, 2) the named pinctrl states default, active and
+idle and 3) the gpio detecting sdio irq in suspend, see
+example below. The MMC driver will then then toggle between
+active and idle during the runtime. If configuration is
+incomplete, log message is emitted falling back to polling.
+Mind not every application needs SDIO irq, e.g. MMC cards
+Affected chips are am335x, probably others
+
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ ...
+ pinctrl-names = default, active, idle
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ...
+ };
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c197028..605dbd3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -206,6 +208,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int gpio_sdio_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -218,11 +221,32 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(host-gpio_sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -476,6
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 11:46 AM, Javier Martinez Canillas wrote: On Mon, Dec 2, 2013 at 5:24 PM, Tom Rini tr...@ti.com wrote: On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote: Hi Pekon, On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote: Although the new ECC schema breaks the compatibility between the board files and new DT based kernel, I think we should use BCH8 scheme. Sorry, because I had not realized that this was configurable in u-boot, so I think, if Thomas is also agree, the better fix in that case is change CONFIG_NAND_OMAP_ECCSCHEME to OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can discard this patch. I theoretically don't have anything against that, but if I do this change in U-Boot, and then use U-Boot to reflash to NAND the SPL and U-Boot itself, will the OMAP ROM code still be able to read the SPL from NAND ? I'm not sure which ECC scheme does the OMAP ROM code support, and how it detects (or not) which ECC scheme to use to read the SPL. Yes, this brings us back to one of the old and long-standing problems. The ROM on these devices will generally speak one format and that means using NAND chips that say for the first block (or N blocks or whatever) you only need 1bit ECC but for the rest 4/8/16/whatever. And then informing the kernel (and anything else) that partitions N need this format and the rest need that. As long as U-Boot provides separate commands, or a nandecc command that allows to switch between ECC scheme, and select the ECC scheme expected by the ROM code when flashing the SPL, and then the ECC scheme expected by the SPL and the kernel to flash U-Boot itself, the kernel image, and the various filesystem images, then it's all fine, we can leave with different ECC schemes used for different things on the NAND flash. Yes, we used nandecc to write data on different mtd partitions for SPL (nandecc hw) and the rootfs (nandecc hw bch8). Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() Why nandecc is being deprecated from u-boot? How are you supposed to use a different ECC scheme then? We (I) had killed off all of the mainline users of the nandecc command, once everyone was using the same 1bit scheme layout. None of the people that had mixed HAM1/BCH4 at the time wanted to work upstream on it. I see, so.. what's the solution then :-) We can push Enric's patch and change to HAM1 in the kernel so Thomas (and others) can write everything from U-boot (SPL, rootfs, etc) but I think is safer to use BCH8 since the NAND requires at least a 4-bit ECC. We _need_ to bring this back in U-Boot (so please just link to this thread somewhere in the patch that brings the command back), for omap3/etc at least. But doing that we can no longer write the SPL from neither U-Boot nor the kernel. Yes, this can be made from user-space using ISEE's writeloader utility and afair there is one from TI too written in C# but this is not very convenient for users. I believe Thomas is right and the correct approach is to change the OMAP NAND and GPMC drivers to support a per MTD partition ECC scheme but we need a temporal solution until someone implements this. I would argue that yes, Linux should also support on the fly ECC schemes per partition (with some sort of default too, so you can say everything is BCH_X except ..). But I'm not one of the people that needs to be convinced of this, and I assume there was a thread about this problem from before, so someone should dig it up and avoid / address the problems from before, or at least try and re-start the discussion and see if people have changed there mind as the problem is here again, and if we ignore it again will show up again in 5 years when we need BCH16 on the bootloader part, but BCH64 on the rest of the block. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
Ignore this set, I busted it. 2013/12/2 Andreas Fenkart afenk...@gmail.com: v4: - switch to interrupts-extended format - drop ti,swakeup-missing flag convert to comaptible section v3: - removed gpio_irq from platform_data v2: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 drivers/mmc/host/omap_hsmmc.c | 298 ++-- include/linux/platform_data/mmc-omap.h |1 + 3 files changed, 326 insertions(+), 23 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. [...] But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. No, I don't think that kernel needs to ever dynamically switch ecc-schemes. This feature should be limited only to u-boot (or bootloaders) because: (1) Adding support for dynamic switching of ecc-schemes will require all code to be compiled in driver which increases the kernel driver footprint. (example adding BCH8_SW means you need to compile in lib/bch.c) (2) Also selection of ecc-scheme mainly depends on NAND device parameter (like density, page-size, oobsize) which remain constant for a device (all NAND partitions). Thus all partitions should use *same* ecc-scheme preferable highest possible available with NAND device kernel. (3) Kernel uses same driver instance to handle all MTD partitions, so if one partition uses HAM1 while other uses BCH8, and both are simultaneously mounted, then it would be difficult for driver to switch ecc-schemes while doing interleaved Read/Write between the partitions. (though it can be added in framework, but then it's too much over-head). In my opinion, kernel driver should be free from all over-heads, And should be *as lite as possible, while continuing to be strong in catching bit-flips.* Because there are lot of file-system layers over it, to handle more severe failures. Example: even if you use HAM1 and report un-correctable errors, still UBIFS has too much redundancy of critical metadata, that it can still recover your volume. Therefore, I preferred having ecc-scheme selectable via DT (static) for kernel. However these are purely my opinions based on my assessments. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. This constrain of changing ecc-scheme has come because ROM code ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders) is used to between bridge gaps between ROM code and kernel. - This could have been avoided, if u-boot still supported 'nandecc' OR - ROM code had mechanism to change its ecc-scheme based on some Boot-mode setting (sysboot pins on board). So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] mmc: omap_hsmmc: Enable SDIO IRQ.
v4: - switch to interrupts-extended format - drop ti,swakeup-missing flag convert to comaptible section v3: - removed gpio_irq from platform_data v2: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 drivers/mmc/host/omap_hsmmc.c | 298 ++-- include/linux/platform_data/mmc-omap.h |1 + 3 files changed, 326 insertions(+), 23 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Hi Pekon On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon pe...@ti.com wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. [...] But for all these, images need to be flashed from u-boot. As kernel cannot switch ecc-schemes on-the-fly. Which as I was saying, is a bit of shame. There is technically nothing that makes the ECC scheme something that needs to be applied globally on the entire flash. No, I don't think that kernel needs to ever dynamically switch ecc-schemes. This feature should be limited only to u-boot (or bootloaders) because: I don't think so. There are cpu that can be boot only using some ecc scheme but for a lot of reason you should require to have for the filesystem a different ecc scheme (1) Adding support for dynamic switching of ecc-schemes will require all code to be compiled in driver which increases the kernel driver footprint. (example adding BCH8_SW means you need to compile in lib/bch.c) It depends on the system that you are using and sometime increase the kernel size is less important that guarantee system consistency (2) Also selection of ecc-scheme mainly depends on NAND device parameter (like density, page-size, oobsize) which remain constant for a device (all NAND partitions). Thus all partitions should use *same* ecc-scheme preferable highest possible available with NAND device kernel. same as above. It can be a limitation on the bootrom (3) Kernel uses same driver instance to handle all MTD partitions, so if one partition uses HAM1 while other uses BCH8, and both are simultaneously mounted, then it would be difficult for driver to switch ecc-schemes while doing interleaved Read/Write between the partitions. (though it can be added in framework, but then it's too much over-head). agree Michael In my opinion, kernel driver should be free from all over-heads, And should be *as lite as possible, while continuing to be strong in catching bit-flips.* Because there are lot of file-system layers over it, to handle more severe failures. Example: even if you use HAM1 and report un-correctable errors, still UBIFS has too much redundancy of critical metadata, that it can still recover your volume. Therefore, I preferred having ecc-scheme selectable via DT (static) for kernel. However these are purely my opinions based on my assessments. And we see real practical cases where being able to specify a different ECC scheme per partition would make sense: when the ROM code uses a weaker ECC scheme than the one used for most other partitions. This constrain of changing ecc-scheme has come because ROM code ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders) is used to between bridge gaps between ROM code and kernel. - This could have been avoided, if u-boot still supported 'nandecc' OR - ROM code had mechanism to change its ecc-scheme based on some Boot-mode setting (sysboot pins on board). So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 12:05 PM, Gupta, Pekon wrote: From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] Dear Gupta, Pekon, On Mon, 2 Dec 2013 16:13:56 +, Gupta, Pekon wrote: Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. The infrastructure is still in place, however the command 'nandecc' is deprecated in newer versions. References in mainline u-boot: arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() So with minor hacks, you should be able to bring-back 'nandecc'. So in short, what it means is that indeed the fact of switching to BCH8 on the kernel side is really breaking things, because U-Boot users now have the choice between: * Configuring U-Boot to use Hamming ECC, and be able to reflash their SPL, but not their filesystem images. * Configuring U-Boot to use BCH8, and be able to reflash their filesystem images, but not their SPL. Seems a little bit annoying for users, no? Yes, agree .. But this is only because we have mis-match in ecc-scheme between ROM-code (while reading SPL) v/s rest of system. However, if you continue using 'HAM1' for *both* u-boot and kernel you should not face any issue. And with latest patch on u-boot your board file should also remain unchanged. I'm sorry, this is wrong. When the hardware says you MUST use BCH8 or more for a given chip using HAM1 you will have issues. And chips that say you must use BCH4/8/16 are why we get into this issue. -- Tom -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. Forgot to mention, one more way of updating boot-loaders with different ecc-scheme via kernel. This can be helpful when: - you want to remotely upgrade your u-boot, but your kernel is statically build with different ecc-scheme. - In production environment, where you boot multiple devices in parallel (using say NFS boot), and then flash multiple devices without bothering about ecc-schemes.. *Method* (1) Flash the u-boot image on one *sample* device selecting appropriate ecc-scheme which ROM code understands. (2) Dump the complete image along with OOB appended (as a binary) (3) Use this binary image (with OOB included) to flash other devices from kernel as *raw* data (that means kernel will not append ECC while writing data, it will blindly write the image as-it-is on the partition). This way the ECC with which u-boot image was built in (1) will get programmed, irrespective of what kernel supports.. - I have seen at-least one customer going into production this way. - And I have been using this often too, though with older mtd-utils. Hope this helps .. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
On 12/02/2013 12:46 PM, Gupta, Pekon wrote: So coming back to the specific problem here. I think we need 'nandecc' back in u-boot till atleast all systems have migrated to BCH16 or whatever highest ecc-scheme which can be supported on OMAP devices. Forgot to mention, one more way of updating boot-loaders with different ecc-scheme via kernel. This can be helpful when: - you want to remotely upgrade your u-boot, but your kernel is statically build with different ecc-scheme. - In production environment, where you boot multiple devices in parallel (using say NFS boot), and then flash multiple devices without bothering about ecc-schemes.. *Method* (1) Flash the u-boot image on one *sample* device selecting appropriate ecc-scheme which ROM code understands. (2) Dump the complete image along with OOB appended (as a binary) (3) Use this binary image (with OOB included) to flash other devices from kernel as *raw* data (that means kernel will not append ECC while writing data, it will blindly write the image as-it-is on the partition). This way the ECC with which u-boot image was built in (1) will get programmed, irrespective of what kernel supports.. - I have seen at-least one customer going into production this way. - And I have been using this often too, though with older mtd-utils. There are many ways to in essentially work around this problem, given the ability to raw write (including OOB) from the kernel and from u-boot. This doesn't change the general problem of we have cases where we need part of the NAND with one scheme, another part of it with a different one. -- Tom -- To unsubscribe from this list: send the line unsubscribe 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: mmc: omap: Fix DMA configuration to not rely on device id
* Dan Carpenter dan.carpen...@oracle.com [131202 00:07]:
Hello Tony Lindgren,
This is a semi-automatic email about new static checker warnings.
The patch 31ee9181eb92: mmc: omap: Fix DMA configuration to not rely
on device id from Nov 26, 2013, leads to the following Smatch
complaint:
drivers/mmc/host/omap.c:1468 mmc_omap_probe()
error: we previously assumed 'res' could be null (see line 1410)
drivers/mmc/host/omap.c
1409res = platform_get_resource_byname(pdev,
IORESOURCE_DMA, rx);
1410if (res)
^^^
Patch introduces a check.
1411sig = res-start;
1412host-dma_rx = dma_request_slave_channel_compat(mask,
1413omap_dma_filter_fn, sig,
pdev-dev, rx);
1414if (!host-dma_rx)
1415dev_warn(host-dev, unable to obtain RX DMA
engine channel %u\n,
1416sig);
1417
1418ret = request_irq(host-irq, mmc_omap_irq, 0,
DRIVER_NAME, host);
1419if (ret)
1420goto err_free_dma;
1421
1422if (pdata-init != NULL) {
1423ret = pdata-init(pdev-dev);
1424if (ret 0)
1425goto err_free_irq;
1426}
1427
1428host-nr_slots = pdata-nr_slots;
1429host-reg_shift = (mmc_omap7xx() ? 1 : 2);
1430
1431host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
1432if (!host-mmc_omap_wq)
1433goto err_plat_cleanup;
1434
1435for (i = 0; i pdata-nr_slots; i++) {
1436ret = mmc_omap_new_slot(host, i);
1437if (ret 0) {
1438while (--i = 0)
1439
mmc_omap_remove_slot(host-slots[i]);
1440
1441goto err_destroy_wq;
1442}
1443}
1444
1445return 0;
1446
1447err_destroy_wq:
1448destroy_workqueue(host-mmc_omap_wq);
1449err_plat_cleanup:
1450if (pdata-cleanup)
1451pdata-cleanup(pdev-dev);
1452err_free_irq:
1453free_irq(host-irq, host);
1454err_free_dma:
1455if (host-dma_tx)
1456dma_release_channel(host-dma_tx);
1457if (host-dma_rx)
1458dma_release_channel(host-dma_rx);
1459clk_put(host-fclk);
1460err_free_iclk:
1461clk_disable(host-iclk);
1462clk_put(host-iclk);
1463err_free_mmc_host:
1464iounmap(host-virt_base);
1465err_ioremap:
1466kfree(host);
1467err_free_mem_region:
1468release_mem_region(res-start, resource_size(res));
^^
Existing unchecked dereferences.
1469return ret;
1470}
Oops. Thanks a lot for reporting this, I'll post a fix for it separately.
Looks like the minimal fix is to add what at least omap_hsmmc.c is doing:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res-start, resource_size(res));
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+: Powerdomain: Fix unchecked dereference of arch_pwrdm
* Nishanth Menon n...@ti.com [131127 17:56]: On 11/27/2013 05:57 AM, Rajendra Nayak wrote: Commit 'cd8abed' ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm leads to the following Smatch complaint: arch/arm/mach-omap2/powerdomain.c:131 _pwrdm_register() error: we previously assumed 'arch_pwrdm' could be null (see line 105) So, fix the unchecked dereference of arch_pwrdm. Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/powerdomain.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index e233dfc..93a2a6e 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -128,7 +128,8 @@ skip_voltdm: for (i = 0; i pwrdm-banks; i++) pwrdm-ret_mem_off_counter[i] = 0; - arch_pwrdm-pwrdm_wait_transition(pwrdm); + if (arch_pwrdm arch_pwrdm-pwrdm_wait_transition) + arch_pwrdm-pwrdm_wait_transition(pwrdm); pwrdm-state = pwrdm_read_pwrst(pwrdm); pwrdm-state_counter[pwrdm-state] = 1; Acked-by: Nishanth Menon n...@ti.com I'll queue this into omap-for-v3.13/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] ARM: dts: Fix the name of supplies for smsc911x shared by OMAP
* Florian Vaussard florian.vauss...@epfl.ch [131202 04:54]: drivers/net/ethernet/smsc/smsc911x.c is expecting supplies named vdd33a and vddvario. Currently the shared DTS file provides vmmc and vmmc_aux, and the supply lookup will fail: smsc911x 2c00.ethernet: Looking up vdd33a-supply from device tree smsc911x 2c00.ethernet: Looking up vdd33a-supply property in node /ocp/gpmc@6e00/ethernet@gpmc failed smsc911x 2c00.ethernet: Looking up vddvario-supply from device tree smsc911x 2c00.ethernet: Looking up vddvario-supply property in node /ocp/gpmc@6e00/ethernet@gpmc failed Fix it! Tested on OMAP3 Overo platform. OK, looks like we've had it wrong from the start as I just moved it from the omap3-igep0020.dts file :) Applying into omap-for-v3.14/fixes-take4 Regards, Tony Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi index 9c18adf..f577b7d 100644 --- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi +++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi @@ -44,8 +44,8 @@ gpmc,wr-access-ns = 186; gpmc,cycle2cycle-samecsen; gpmc,cycle2cycle-diffcsen; - vmmc-supply = vddvario; - vmmc_aux-supply = vdd33a; + vddvario-supply = vddvario; + vdd33a-supply = vdd33a; reg-io-width = 4; smsc,save-mac-address; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap: Fix error introduced by fix to release_mem_region() path
Commit 31ee9181eb92: (mmc: omap: Fix DMA configuration to not rely on device id) fixed getting of the DMA resources when booted with device tree. This patch however changed the handling of the free_mem_region() error path by reusing the struct resource *res for the DMA resources. Fix the error the same way omap_hsmmc.c driver handles it, which is to restore the resource before using the values to call release_mem_region(). Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Tony Lindgren t...@atomide.com --- Chris, looks like the patch introducing this error is queued in arm-soc fixes branch.. Care to ack this one too and I'll merge it via arm-soc as well? After that, no need for me to patch this driver for my mach-omap2 device tree conversion I hope :) --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1465,7 +1465,10 @@ err_free_mmc_host: err_ioremap: kfree(host); err_free_mem_region: - release_mem_region(res-start, resource_size(res)); + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (res) + release_mem_region(res-start, resource_size(res)); + return ret; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle: Add omap-twl4030 audio support
* Jarkko Nikula jarkko.nik...@bitmer.com [131128 09:05]: On 11/28/2013 12:02 AM, Tony Lindgren wrote: * Jarkko Nikula jarkko.nik...@bitmer.com [131127 10:48]: This adds typical McBSP2-TWL4030 audio description to the legacy Beagle Board. Nice to see that work almost out of the box :) BTW, I just noticed that sound/soc/omap/Kconfig has depends on OMAP_MUX. The OMAP_MUX option will be dropped for mach-omap2 for v3.14, so you may want to take a look at that too. If there really is a dependency, that should be handled using pinctrl-single for the .dts entries. There is actually dependency but only on N810 which needs to remux 4 pins from EAC to McBSP2. I'll try to keep my eye on it but don't let that block your cleanup work. Thanks, meanwhile I'll queue your beagle audio fix. 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] ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present
commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced missing braces, however, we just set return result if clk_get fail and we populate the error pointer in clk pointer and pass it along to clk_prepare. This is wrong. The intent seems to be retry remaining clocks if they are available and warn the ones we cant find clks for. With the current logic, we see the following crash: omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick Unable to handle kernel NULL pointer dereference at virtual address 0032 pgd = c0004000 [0032] *pgd= Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19 task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000 PC is at __clk_prepare+0x10/0x74 LR is at clk_prepare+0x14/0x24 snip [c044d59c] (__clk_prepare+0x10/0x74) from [c044d9b0] (clk_prepare+0x14/0x24) [c044d9b0] (clk_prepare+0x14/0x24) from [c077d8c4] (_init+0x24c/0x3bc) [c077d8c4] (_init+0x24c/0x3bc) from [c0027328] (omap_hwmod_for_each+0x34/0x5c) [c0027328] (omap_hwmod_for_each+0x34/0x5c) from [c077dfa0] (__omap_hwmod_setup_all+0x24/0x40) [c077dfa0] (__omap_hwmod_setup_all+0x24/0x40) from [c0008928] (do_one_initcall+0x38/0x168) [c0008928] (do_one_initcall+0x38/0x168) from [c0771be8] (kernel_init_freeable+0xfc/0x1cc) [c0771be8] (kernel_init_freeable+0xfc/0x1cc) from [c0521064] (kernel_init+0x8/0x110) [c0521064] (kernel_init+0x8/0x110) from [c000e568] (ret_from_fork+0x14/0x2c) Code: e92d4038 e2504000 01a05004 0a05 (e5943034) So, just warn and continue instead of proceeding and crashing, with missing clock nodes/bad data, we will eventually fail, however we should now have enough information to identify the culprit. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index d0cf926..411e24f 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -787,6 +787,7 @@ static int _init_interface_clks(struct omap_hwmod *oh) pr_warning(omap_hwmod: %s: cannot clk_get interface_clk %s\n, oh-name, os-clk); ret = -EINVAL; + continue; } os-_clk = c; /* @@ -823,6 +824,7 @@ static int _init_opt_clks(struct omap_hwmod *oh) pr_warning(omap_hwmod: %s: cannot clk_get opt_clk %s\n, oh-name, oc-clk); ret = -EINVAL; + continue; } oc-_clk = c; /* -- 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
[GIT PULL] more omap dt fixes against v3.13-rc1
The following changes since commit 9cb238c00ba5c1ddfff2c2ed6aa66c15b962e4c3: mmc: omap: Fix I2C dependency and make driver usable with device tree (2013-11-26 15:51:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/more-dt-regressions for you to fetch changes up to ac46bf3933421bde881399d9ad3d165064862cc3: ARM: dts: Fix the name of supplies for smsc911x shared by OMAP (2013-12-02 11:38:15 -0800) Few more legacy booting vs device tree booting fixes that people have noticed while booting things with device tree for things like omap4 WLAN, smsc911x, and beagle audio. Hopefully this will be it for the legacy booting vs device tree fixes for this -rc cycle. Balaji T K (2): ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx ARM: dts: omap4-sdp: Fix pin muxing for wl12xx Florian Vaussard (1): ARM: dts: Fix the name of supplies for smsc911x shared by OMAP Jarkko Nikula (1): ARM: dts: omap3-beagle: Add omap-twl4030 audio support Rajendra Nayak (1): ARM: OMAP2+: Powerdomain: Fix unchecked dereference of arch_pwrdm arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi | 4 ++-- arch/arm/boot/dts/omap3-beagle.dts| 14 ++ arch/arm/boot/dts/omap4-panda-common.dtsi | 20 ++-- arch/arm/boot/dts/omap4-sdp.dts | 12 ++-- arch/arm/mach-omap2/powerdomain.c | 3 ++- 5 files changed, 34 insertions(+), 19 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers: net: cpsw: fix dt probe for one port ethernet
From: Mugunthan V N mugunthan...@ti.com Date: Mon, 2 Dec 2013 12:53:39 +0530 When only one port of the two port is pinned out, then dt probe is failing because second port phy is not found. fixing this by checking the number of slaves and breaking the loop. Signed-off-by: Mugunthan V N mugunthan...@ti.com Of course, this patch assumes that slaves are pinned out in order. But, no matter, this makes more configurations work than before so it's a good patch. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe 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] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
Sorry for the late reply.
On Fri, Nov 29, 2013 at 11:04 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Adding Kevin's Linaro id, + Nishant,
On Tuesday 26 November 2013 05:46 PM, Chao Xu wrote:
From: Felipe Balbi ba...@ti.com
try to keep gpio block suspended as much as possible.
Tested with pandaboard and a sysfs exported gpio.
Signed-off-by: Felipe Balbi balbi at ti.com
[caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision
check to enable aggressive pm_runtime on OMAP4-only. Because
am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP,
which might cause missed interrupts with this patch. Tested on Pandaboard
rev A2.]
Please format the text and limit it to 80 char rule.
Sorry. It's my first time submitting a patch. I will fix it and resubmit.
Signed-off-by: Chao Xu caesarxuc...@gmail.com
---
According to Mr. Felipe Balbi, the original patch was not accepted because
interrupts would be missed when GPIO was used as IRQ source. But in my tests
with pandaboard, interrupts were not missed. This is because _idle_sysc()
sets the idlemode of gpio module to smart-idle-wakeup, and according to
OMAP4430 TRM, under this idlemode, the gpio can generate an asynchronous
wakeup request to the PRCM. And after GPIO is awake, the wake-up request is
reflected into the interrupt status registers.
A change made on the original patch is only applying the aggressive runtime
pm scheme on OMAP4, because I don’t have HW to test OMAP3 or am33xx devices.
According to the respective TRMs, their GPIO modules also can generate
wake-up request if the idlemode is set to smart-idle or smart-idle-wakeup.
So the patch should work for them, too. But I suspect a potential SW bug may
cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked as capable
of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to AM335x TRM,
_only_ gpio0 is capable of this mode. This may make GPIO stuck in force-idle
mode and unable to generate wakeup request. And thus interrupt will be
missed. Again, I don’t have the HW to verify whether this is a bug or not :(
In general I am not against this idea but patch has many assumptions which
are not entirely correct.
- SMART_WAKEUP will take care of waking IP etc not always true to power
domain getting into idle.
I agree that if the power domain goes to idle, SMART_WAKEUP
won't be effective. But, correct me if i'm wrong, even if we don't call
runtime_put(), the power domain can still go to idle. Because the
modulemode of GPIO is set to HW_AUTO in this case, which won't
prevent the power domain goes to retention. So this patch doesn't
make the situation worse.
- If we want to go on this path then I would like to see we address
omap2_gpio_[prepare/resumne]_for_idle()
I did a quick google search but didn't find the problem with the two
functions. Could you give me a pointer here?
- GPIO though sound simple is one of the most notorious IP block
on PM front so this needs lot of testing. This patch not seems be
tested at all so I would have much liked it to be in RFC/RFT
state.
I tested using a gpio pin as interrupt source after applying the patch.
What are the other tests that I should do? Is there a formal way of
reporting test results here?
drivers/gpio/gpio-omap.c| 103
++-
include/linux/platform_data/gpio-omap.h |1 +
2 files changed, 87 insertions(+), 17 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 89675f8..90661f2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -76,6 +76,7 @@ struct gpio_bank {
int context_loss_count;
int power_mode;
bool workaround_enabled;
+ bool is_aggressive_pm;
void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
int (*get_context_loss_count)(struct device *dev);
@@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank
*bank, unsigned offset)
static int gpio_is_input(struct gpio_bank *bank, int mask)
{
void __iomem *reg = bank-base + bank-regs-direction;
+ u32 val;
- return __raw_readl(reg) mask;
+ if (bank-is_aggressive_pm)
+ pm_runtime_get_sync(bank-dev);
+ val = __raw_readl(reg) mask;
+ if (bank-is_aggressive_pm)
+ pm_runtime_put(bank-dev);
+
Move above in some wrapper instead of sprinkling the
'is_aggressive_pm' check everywhere.
Will do.
@@ -1585,18 +1651,21 @@ static const struct omap_gpio_platform_data
omap2_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = false,
+ .is_aggressive_pm = false,
};
static const struct omap_gpio_platform_data omap3_pdata = {
.regs = omap2_gpio_regs,
.bank_width = 32,
.dbck_flag = true,
+ .is_aggressive_pm = false,
};
static const struct omap_gpio_platform_data omap4_pdata = {
.regs =
[PATCH v5 0/3] mmc: omap_hsmmc: enable SDIO IRQ.
v5: - fix compile error introduced by last minute fix v4: - switch to interrupts-extended format - drop ti,swakeup-missing flag convert to comaptible section v3: - removed gpio_irq from platform_data v2: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (3): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 drivers/mmc/host/omap_hsmmc.c | 305 ++-- include/linux/platform_data/mmc-omap.h |1 + 3 files changed, 332 insertions(+), 24 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 109
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 97 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8be5c9f..c197028 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -131,6 +131,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -215,6 +216,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -495,27 +499,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1078,8 +1095,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1591,6 +1612,37 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 irq_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ irq_mask = OMAP_HSMMC_READ(host-base, ISE);
+ if (enable) {
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask |= CIRQ_EN;
+ } else {
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask = ~CIRQ_EN;
+ }
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+
+ /*
+* if enable, piggy back detection on current request
+* but always disable immediately
+*/
+ if (!host-req_in_progress || !enable)
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* flush posted write */
+ OMAP_HSMMC_READ(host-base, IE);
+
+ spin_unlock_irqrestore(host-irq_lock, flags);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1643,7 +1695,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
[PATCH v5 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 ++
drivers/mmc/host/omap_hsmmc.c | 186 ++--
2 files changed, 224 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..6365695 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the compatible
+section, 2) the named pinctrl states default, active and
+idle and 3) the gpio detecting sdio irq in suspend, see
+example below. The MMC driver will then then toggle between
+active and idle during the runtime. If configuration is
+incomplete, log message is emitted falling back to polling.
+Mind not every application needs SDIO irq, e.g. MMC cards
+Affected chips are am335x, probably others
+
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ ...
+ pinctrl-names = default, active, idle
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ...
+ };
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c197028..2c14171 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -206,6 +208,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int gpio_sdio_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -218,11 +221,32 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(host-gpio_sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -476,6
[PATCH v5 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2c14171..5fe3f24 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1789,14 +1790,25 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
+
+ seq_puts(s, \n);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK)
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
mmc-index, host-context_loss);
pm_runtime_get_sync(host-dev);
-
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
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: [GIT PULL] more omap dt fixes against v3.13-rc1
On Mon, Dec 2, 2013 at 1:40 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit 9cb238c00ba5c1ddfff2c2ed6aa66c15b962e4c3: mmc: omap: Fix I2C dependency and make driver usable with device tree (2013-11-26 15:51:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/more-dt-regressions Pulled, thanks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
we could build that as a driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index ad25bfa..975ff9e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1262,7 +1262,7 @@ fail:
return err;
}
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
@@ -1283,7 +1283,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = menelaus_probe,
- .remove = __exit_p(menelaus_remove),
+ .remove = menelaus_remove,
.id_table = menelaus_id,
};
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 04/15] mfd: menelaus: Remove unnecessary loop
we can let irqs refire and give the scheduler
a chance to choose when we should be scheduled.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 43 +++
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11d7d81..11dc4d3 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,30 +795,25 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
-
- while (1) {
- unsigned isr;
-
- isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-~menelaus-mask2) 8;
- isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-~menelaus-mask1;
- if (!isr)
- break;
-
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
- mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
- if (handler)
- handler(menelaus);
- menelaus_enable_irq(irq);
- mutex_unlock(menelaus-lock);
- }
+ unsigned isr;
+
+ isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
+~menelaus-mask2) 8;
+ isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
+~menelaus-mask1;
+
+ while (isr) {
+ int irq = fls(isr) - 1;
+ isr = ~(1 irq);
+
+ mutex_lock(menelaus-lock);
+ menelaus_disable_irq(irq);
+ menelaus_ack_irq(irq);
+ handler = menelaus-handlers[irq];
+ if (handler)
+ handler(menelaus);
+ menelaus_enable_irq(irq);
+ mutex_unlock(menelaus-lock);
}
return IRQ_HANDLED;
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 06/15] mfd: menelaus: Pass menelaus pointer as argument to enable/disable irq
we want to, eventually, get rid of the global
the_menelaus pointer, so let's start passing
menelaus as argument to some function calls
and slowly phase out the_menelaus global pointer.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9ccbb79..4c51e4b 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -199,35 +199,35 @@ static int menelaus_read_reg(int reg)
return val;
}
-static int menelaus_enable_irq(int irq)
+static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 = ~(1 irq);
+ m-mask2 = ~(1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2);
} else {
- the_menelaus-mask1 = ~(1 irq);
+ m-mask1 = ~(1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1);
}
}
-static int menelaus_disable_irq(int irq)
+static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 |= (1 irq);
+ m-mask2 |= (1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2);
} else {
- the_menelaus-mask1 |= (1 irq);
+ m-mask1 |= (1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1);
}
}
-static int menelaus_ack_irq(int irq)
+static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
{
if (irq 7)
return menelaus_write_reg(MENELAUS_INT_ACK2, 1 (irq - 8));
@@ -243,7 +243,7 @@ static int menelaus_add_irq_work(int irq,
mutex_lock(the_menelaus-lock);
the_menelaus-handlers[irq] = handler;
- ret = menelaus_enable_irq(irq);
+ ret = menelaus_enable_irq(the_menelaus, irq);
mutex_unlock(the_menelaus-lock);
return ret;
@@ -255,7 +255,7 @@ static int menelaus_remove_irq_work(int irq)
int ret = 0;
mutex_lock(the_menelaus-lock);
- ret = menelaus_disable_irq(irq);
+ ret = menelaus_disable_irq(the_menelaus, irq);
the_menelaus-handlers[irq] = NULL;
mutex_unlock(the_menelaus-lock);
@@ -793,25 +793,25 @@ out:
static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
- struct menelaus_chip *menelaus = _menelaus;
- void (*handler)(struct menelaus_chip *menelaus);
+ struct menelaus_chip *m = _menelaus;
+ void (*handler)(struct menelaus_chip *m);
unsigned long isr;
unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-~menelaus-mask2) 8;
+~m-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-~menelaus-mask1;
+~m-mask1;
for_each_set_bit(i, isr, 16) {
- mutex_lock(menelaus-lock);
- menelaus_disable_irq(i);
- menelaus_ack_irq(i);
- handler = menelaus-handlers[i];
+ mutex_lock(m-lock);
+ menelaus_disable_irq(m, i);
+ menelaus_ack_irq(m, i);
+ handler = m-handlers[i];
if (handler)
- handler(menelaus);
- menelaus_enable_irq(i);
- mutex_unlock(menelaus-lock);
+ handler(m);
+ menelaus_enable_irq(m, i);
+ mutex_unlock(m-lock);
}
return IRQ_HANDLED;
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 11/15] mfd: menelaus: Start to use irqdomain
introduce an irq_chip and irq_domain for
menelaus driver. Following patches will
convert uses to traditional request_threaded_irq().
while at that, some better error handling had
to be added, so we could free irq descs we
allocated.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 127 ++---
1 file changed, 120 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index aa3c579..e4f33b7 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -34,6 +34,7 @@
#include linux/module.h
#include linux/i2c.h
#include linux/interrupt.h
+#include linux/irqdomain.h
#include linux/sched.h
#include linux/mutex.h
#include linux/delay.h
@@ -47,6 +48,7 @@
#include asm/gpio.h
#define DRIVER_NAMEmenelaus
+#define MENELAUS_NR_IRQS 16
#define MENELAUS_I2C_ADDRESS 0x72
@@ -168,11 +170,19 @@ struct menelaus_chip {
u8 rtc_control;
unsigneduie:1;
#endif
+ int irq_base;
unsignedvcore_hw_mode:1;
u8 mask1, mask2;
+ u8 ack1, ack2;
+
void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
+
+ unsignedmask1_pending:1;
+ unsignedmask2_pending:1;
+ unsignedack1_pending:1;
+ unsignedack2_pending:1;
};
static struct menelaus_chip *the_menelaus;
@@ -235,6 +245,83 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int
irq)
return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
+static void menelaus_irq_ack(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-ack2 |= BIT(irq);
+ m-ack2_pending = true;
+ } else {
+ m-ack1 |= BIT(irq);
+ m-ack1_pending = true;
+ }
+}
+
+static void menelaus_irq_mask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 |= BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 |= BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_unmask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 = ~BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 = ~BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_bus_lock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ mutex_lock(m-lock);
+}
+
+static void menelaus_irq_bus_sync_unlock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ if (m-ack1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK1, m-ack1);
+
+ if (m-ack2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK2, m-ack2);
+
+ if (m-mask1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK1, m-mask1);
+
+ if (m-mask2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK2, m-mask2);
+
+ mutex_unlock(m-lock);
+}
+
+static struct irq_chip menelaus_irq_chip = {
+ .name = menelaus,
+ .irq_ack= menelaus_irq_ack,
+ .irq_mask = menelaus_irq_mask,
+ .irq_unmask = menelaus_irq_unmask,
+ .irq_bus_lock = menelaus_irq_bus_lock,
+ .irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
+};
+
/* Adds a handler for an interrupt. Does not run in interrupt context */
static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
@@ -1186,8 +1273,11 @@ static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct menelaus_chip*m;
+ struct device_node *node = client-dev.of_node;
int rev = 0, val;
int err = 0;
+ int irq_base;
+ int i;
struct menelaus_platform_data *menelaus_pdata =
dev_get_platdata(client-dev);
@@ -1205,12 +1295,32 @@ static int menelaus_probe(struct i2c_client *client,
the_menelaus = m;
m-client = client;
+ mutex_init(m-lock);
+
+ irq_base = irq_alloc_descs(-1, 0, MENELAUS_NR_IRQS, 0);
+
[PATCH v2 14/15] mfd: menelaus: IRQ is a requirement
this driver needs IRQ to work, if client-irq
isn't set properly, we won't work. Remove
check around request_threaded_irq().
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index c0219b7..bffe978 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1271,14 +1271,12 @@ static int menelaus_probe(struct i2c_client *client,
/* Set output buffer strengths */
menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73);
- if (client-irq 0) {
- err = request_threaded_irq(client-irq, NULL, menelaus_irq,
- IRQF_ONESHOT, DRIVER_NAME, m);
- if (err) {
- dev_dbg(client-dev, can't get IRQ %d, err %d\n,
- client-irq, err);
- goto fail_free_descs;
- }
+ err = request_threaded_irq(client-irq, NULL, menelaus_irq,
+ IRQF_ONESHOT, DRIVER_NAME, m);
+ if (err) {
+ dev_dbg(client-dev, can't get IRQ %d, err %d\n,
+ client-irq, err);
+ goto fail_free_descs;
}
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 13/15] mfd: menelaus: Remove unnecessary definition
menelaus_i2c_driver isn't referenced on probe,
just remove that unnecessary line. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 74eae19..c0219b7 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1206,8 +1206,6 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
/*---*/
-static struct i2c_driver menelaus_i2c_driver;
-
static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 03/15] mfd: menelaus: Convert to threaded irq
we don't need that extra workqueue when we
have generic threaded irq handlers support.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 29 -
1 file changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8bd97ca..11d7d81 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -36,7 +36,6 @@
#include linux/interrupt.h
#include linux/sched.h
#include linux/mutex.h
-#include linux/workqueue.h
#include linux/delay.h
#include linux/rtc.h
#include linux/bcd.h
@@ -161,12 +160,9 @@
#define MCT_PIN_ST_S1_CD_ST(1 0)
#define MCT_PIN_ST_S2_CD_ST(1 1)
-static void menelaus_work(struct work_struct *_menelaus);
-
struct menelaus_chip {
struct mutexlock;
struct i2c_client *client;
- struct work_struct work;
#ifdef CONFIG_RTC_DRV_TWL92330
struct rtc_device *rtc;
u8 rtc_control;
@@ -795,11 +791,9 @@ out:
/*---*/
-/* Handles Menelaus interrupts. Does not run in interrupt context */
-static void menelaus_work(struct work_struct *_menelaus)
+static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
- struct menelaus_chip *menelaus =
- container_of(_menelaus, struct menelaus_chip, work);
+ struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
while (1) {
@@ -826,18 +820,6 @@ static void menelaus_work(struct work_struct *_menelaus)
mutex_unlock(menelaus-lock);
}
}
- enable_irq(menelaus-client-irq);
-}
-
-/*
- * We cannot use I2C in interrupt context, so we just schedule work.
- */
-static irqreturn_t menelaus_irq(int irq, void *_menelaus)
-{
- struct menelaus_chip *menelaus = _menelaus;
-
- disable_irq_nosync(irq);
- (void)schedule_work(menelaus-work);
return IRQ_HANDLED;
}
@@ -1225,8 +1207,8 @@ static int menelaus_probe(struct i2c_client *client,
menelaus_write_reg(MENELAUS_MCT_CTRL1, 0x73);
if (client-irq 0) {
- err = request_irq(client-irq, menelaus_irq, 0,
- DRIVER_NAME, menelaus);
+ err = request_threaded_irq(client-irq, NULL, menelaus_irq,
+ IRQF_ONESHOT, DRIVER_NAME, menelaus);
if (err) {
dev_dbg(client-dev, can't get IRQ %d, err %d\n,
client-irq, err);
@@ -1235,7 +1217,6 @@ static int menelaus_probe(struct i2c_client *client,
}
mutex_init(menelaus-lock);
- INIT_WORK(menelaus-work, menelaus_work);
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
@@ -1258,7 +1239,6 @@ static int menelaus_probe(struct i2c_client *client,
return 0;
fail:
free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
return err;
}
@@ -1267,7 +1247,6 @@ static int menelaus_remove(struct i2c_client *client)
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
the_menelaus = NULL;
return 0;
}
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 07/15] mfd: menelaus: Limit the usage of the_menelaus
pass a menelaus_chip pointer as argument to most
functions so we can minimize the usage of the
global the_menelaus pointer.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 265 ++---
1 file changed, 142 insertions(+), 123 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 4c51e4b..8796e5e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -177,9 +177,9 @@ struct menelaus_chip {
static struct menelaus_chip *the_menelaus;
-static int menelaus_write_reg(int reg, u8 value)
+static int menelaus_write_reg(struct menelaus_chip *m, int reg, u8 value)
{
- int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
+ int val = i2c_smbus_write_byte_data(m-client, reg, value);
if (val 0) {
pr_err(DRIVER_NAME : write error);
@@ -189,9 +189,9 @@ static int menelaus_write_reg(int reg, u8 value)
return 0;
}
-static int menelaus_read_reg(int reg)
+static int menelaus_read_reg(struct menelaus_chip *m, int reg)
{
- int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
+ int val = i2c_smbus_read_byte_data(m-client, reg);
if (val 0)
pr_err(DRIVER_NAME : read error);
@@ -204,11 +204,11 @@ static int menelaus_enable_irq(struct menelaus_chip *m,
int irq)
if (irq 7) {
irq -= 8;
m-mask2 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m-mask2);
} else {
m-mask1 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m-mask1);
}
}
@@ -218,11 +218,11 @@ static int menelaus_disable_irq(struct menelaus_chip *m,
int irq)
if (irq 7) {
irq -= 8;
m-mask2 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m-mask2);
} else {
m-mask1 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m-mask1);
}
}
@@ -230,9 +230,9 @@ static int menelaus_disable_irq(struct menelaus_chip *m,
int irq)
static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
{
if (irq 7)
- return menelaus_write_reg(MENELAUS_INT_ACK2, 1 (irq - 8));
+ return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
else
- return menelaus_write_reg(MENELAUS_INT_ACK1, 1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
/* Adds a handler for an interrupt. Does not run in interrupt context */
@@ -268,12 +268,12 @@ static int menelaus_remove_irq_work(int irq)
* in each slot. In this case the cards are not seen by menelaus.
* FIXME: Add handling for D1 too
*/
-static void menelaus_mmc_cd_work(struct menelaus_chip *menelaus_hw)
+static void menelaus_mmc_cd_work(struct menelaus_chip *m)
{
int reg;
unsigned char card_mask = 0;
- reg = menelaus_read_reg(MENELAUS_MCT_PIN_ST);
+ reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg 0)
return;
@@ -283,8 +283,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip
*menelaus_hw)
if (!(reg 0x2))
card_mask |= MCT_PIN_ST_S2_CD_ST;
- if (menelaus_hw-mmc_callback)
- menelaus_hw-mmc_callback(menelaus_hw-mmc_callback_data,
+ if (m-mmc_callback)
+ m-mmc_callback(m-mmc_callback_data,
card_mask);
}
@@ -293,14 +293,16 @@ static void menelaus_mmc_cd_work(struct menelaus_chip
*menelaus_hw)
*/
int menelaus_set_mmc_opendrain(int slot, int enable)
{
+ struct menelaus_chip *m = the_menelaus;
int ret, val;
if (slot != 1 slot != 2)
return -EINVAL;
- mutex_lock(the_menelaus-lock);
- ret = menelaus_read_reg(MENELAUS_MCT_CTRL1);
+
+ mutex_lock(m-lock);
+ ret = menelaus_read_reg(m, MENELAUS_MCT_CTRL1);
if (ret 0) {
- mutex_unlock(the_menelaus-lock);
+ mutex_unlock(m-lock);
return ret;
}
val = ret;
@@ -315,8 +317,8 @@ int menelaus_set_mmc_opendrain(int slot, int enable)
else
val = ~MCT_CTRL1_S2_CMD_OD;
}
- ret = menelaus_write_reg(MENELAUS_MCT_CTRL1, val);
- mutex_unlock(the_menelaus-lock);
+ ret = menelaus_write_reg(m, MENELAUS_MCT_CTRL1, val);
+ mutex_unlock(m-lock);
return ret;
}
@@ -324,10 +326,12 @@
[PATCH v2 08/15] mfd: menelaus: Pass menelaus_chip pointer to add/remove irq functions
those functions are static and can receive a
menelaus_chip pointer very easily.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 57 ++
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8796e5e..8672d86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -236,28 +236,28 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int
irq)
}
/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(int irq,
+static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- the_menelaus-handlers[irq] = handler;
- ret = menelaus_enable_irq(the_menelaus, irq);
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ m-handlers[irq] = handler;
+ ret = menelaus_enable_irq(m, irq);
+ mutex_unlock(m-lock);
return ret;
}
/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(int irq)
+static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- ret = menelaus_disable_irq(the_menelaus, irq);
- the_menelaus-handlers[irq] = NULL;
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ ret = menelaus_disable_irq(m, irq);
+ m-handlers[irq] = NULL;
+ mutex_unlock(m-lock);
return ret;
}
@@ -412,23 +412,24 @@ EXPORT_SYMBOL(menelaus_set_mmc_slot);
int menelaus_register_mmc_callback(void (*callback)(void *data, u8 card_mask),
void *data)
{
+ struct menelaus_chip *m = the_menelaus;
int ret = 0;
- the_menelaus-mmc_callback_data = data;
- the_menelaus-mmc_callback = callback;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S1CD_IRQ,
+ m-mmc_callback_data = data;
+ m-mmc_callback = callback;
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S2CD_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S1D1_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S2D1_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2D1_IRQ,
menelaus_mmc_cd_work);
return ret;
@@ -437,13 +438,15 @@ EXPORT_SYMBOL(menelaus_register_mmc_callback);
void menelaus_unregister_mmc_callback(void)
{
- menelaus_remove_irq_work(MENELAUS_MMC_S1CD_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S2CD_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S1D1_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S2D1_IRQ);
+ struct menelaus_chip *m = the_menelaus;
+
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S1CD_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S2CD_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S1D1_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S2D1_IRQ);
- the_menelaus-mmc_callback = NULL;
- the_menelaus-mmc_callback_data = NULL;
+ m-mmc_callback = NULL;
+ m-mmc_callback_data = NULL;
}
EXPORT_SYMBOL(menelaus_unregister_mmc_callback);
@@ -1070,8 +1073,8 @@ static int menelaus_ioctl(struct device *dev, unsigned
cmd, unsigned long arg)
case RTC_UIE_ON:
if (m-uie)
return 0;
- status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
- status = menelaus_add_irq_work(MENELAUS_RTCTMR_IRQ,
+ status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
+ status = menelaus_add_irq_work(m, MENELAUS_RTCTMR_IRQ,
menelaus_rtc_update_work);
if (status == 0)
m-uie = 1;
@@ -1079,7 +1082,7 @@ static int menelaus_ioctl(struct device *dev, unsigned
cmd, unsigned long arg)
case RTC_UIE_OFF:
if (!m-uie)
return 0;
- status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
+ status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
if (status == 0)
m-uie = 0;
return status;
@@ -1127,7 +1130,7 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
/* support RTC alarm; it can issue wakeups */
if (alarm) {
-
[PATCH v2 10/15] mfd: menelaus: Pass menelaus_chip argument to menelaus - time helpers
time_to_menelaus() and menelaus_to_time() are
static and can easily receive a struct menelaus_chip
pointer argument.
After this patch, the_menelaus is only used on
exported functions which are currently being
used by board-n8x0.c.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 13d1cb0..aa3c579 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -857,10 +857,9 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
#define RTC_HR_PM (1 7)
-static void menelaus_to_time(char *regs, struct rtc_time *t)
+static void menelaus_to_time(struct menelaus_chip *m,
+ char *regs, struct rtc_time *t)
{
- struct menelaus_chip *m = the_menelaus;
-
t-tm_sec = bcd2bin(regs[0]);
t-tm_min = bcd2bin(regs[1]);
if (m-rtc_control RTC_CTRL_MODE12) {
@@ -874,9 +873,9 @@ static void menelaus_to_time(char *regs, struct rtc_time *t)
t-tm_year = bcd2bin(regs[5]) + 100;
}
-static int time_to_menelaus(struct rtc_time *t, int regnum)
+static int time_to_menelaus(struct menelaus_chip *m,
+ struct rtc_time *t, int regnum)
{
- struct menelaus_chip *m = the_menelaus;
int hour, status;
status = menelaus_write_reg(m, regnum++, bin2bcd(t-tm_sec));
@@ -944,7 +943,7 @@ static int menelaus_read_time(struct device *dev, struct
rtc_time *t)
return -EIO;
}
- menelaus_to_time(regs, t);
+ menelaus_to_time(m, regs, t);
t-tm_wday = bcd2bin(regs[6]);
return 0;
@@ -956,7 +955,7 @@ static int menelaus_set_time(struct device *dev, struct
rtc_time *t)
int status;
/* write date and time registers */
- status = time_to_menelaus(t, MENELAUS_RTC_SEC);
+ status = time_to_menelaus(m, t, MENELAUS_RTC_SEC);
if (status 0)
return status;
status = menelaus_write_reg(m, MENELAUS_RTC_WKDAY, bin2bcd(t-tm_wday));
@@ -1001,7 +1000,7 @@ static int menelaus_read_alarm(struct device *dev, struct
rtc_wkalrm *w)
return -EIO;
}
- menelaus_to_time(regs, w-time);
+ menelaus_to_time(m, regs, w-time);
w-enabled = !!(m-rtc_control RTC_CTRL_AL_EN);
@@ -1029,7 +1028,7 @@ static int menelaus_set_alarm(struct device *dev, struct
rtc_wkalrm *w)
}
/* write alarm registers */
- status = time_to_menelaus(w-time, MENELAUS_RTC_AL_SEC);
+ status = time_to_menelaus(m, w-time, MENELAUS_RTC_AL_SEC);
if (status 0)
return status;
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 15/15] mfd: menelaus: Use devm_request_threaded_irq()
by using devm_request_threaded_irq() we can
drop a few extra lines of code and rely on
device managed resources layer to free our
IRQ for us.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index bffe978..b87c2bd 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1271,8 +1271,8 @@ static int menelaus_probe(struct i2c_client *client,
/* Set output buffer strengths */
menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73);
- err = request_threaded_irq(client-irq, NULL, menelaus_irq,
- IRQF_ONESHOT, DRIVER_NAME, m);
+ err = devm_request_threaded_irq(client-dev, client-irq,
+ NULL, menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m);
if (err) {
dev_dbg(client-dev, can't get IRQ %d, err %d\n,
client-irq, err);
@@ -1283,7 +1283,7 @@ static int menelaus_probe(struct i2c_client *client,
val = menelaus_read_reg(m, MENELAUS_VCORE_CTRL1);
if (val 0)
- goto fail_free_irq;
+ goto fail_free_descs;
if (val (1 7))
m-vcore_hw_mode = 1;
else
@@ -1292,14 +1292,12 @@ static int menelaus_probe(struct i2c_client *client,
if (menelaus_pdata != NULL menelaus_pdata-late_init != NULL) {
err = menelaus_pdata-late_init(client-dev);
if (err 0)
- goto fail_free_irq;
+ goto fail_free_descs;
}
menelaus_rtc_init(m);
return 0;
-fail_free_irq:
- free_irq(client-irq, m);
fail_free_descs:
irq_free_descs(irq_base, MENELAUS_NR_IRQS);
@@ -1311,7 +1309,6 @@ static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*m = i2c_get_clientdata(client);
- free_irq(client-irq, m);
irq_free_descs(m-irq_base, MENELAUS_NR_IRQS);
the_menelaus = NULL;
return 0;
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 09/15] mfd: menelaus: Pass menelaus_chip pointer to get/set voltage
those functions are static and can easily receive
a menelaus_chip pointer argument.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 50 +++---
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8672d86..13d1cb0 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -463,10 +463,9 @@ struct menelaus_vtg_value {
u16 val;
};
-static int menelaus_set_voltage(const struct menelaus_vtg *vtg, int mV,
- int vtg_val, int mode)
+static int menelaus_set_voltage(struct menelaus_chip *m,
+ const struct menelaus_vtg *vtg, int mV, int vtg_val, int mode)
{
- struct menelaus_chip *m = the_menelaus;
struct i2c_client *c = m-client;
int val, ret;
@@ -498,8 +497,8 @@ out:
return ret;
}
-static int menelaus_get_vtg_value(int vtg, const struct menelaus_vtg_value
*tbl,
- int n)
+static int menelaus_get_vtg_value(struct menelaus_chip *m,
+ int vtg, const struct menelaus_vtg_value *tbl, int n)
{
int i;
@@ -546,7 +545,7 @@ int menelaus_set_vcore_sw(unsigned int mV)
struct i2c_client *c = m-client;
int val, ret;
- val = menelaus_get_vtg_value(mV, vcore_values,
+ val = menelaus_get_vtg_value(m, mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (val 0)
return -EINVAL;
@@ -570,11 +569,11 @@ int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned
int floor_mV)
struct i2c_client *c = m-client;
int fval, rval, val, ret;
- rval = menelaus_get_vtg_value(roof_mV, vcore_values,
+ rval = menelaus_get_vtg_value(m, roof_mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (rval 0)
return -EINVAL;
- fval = menelaus_get_vtg_value(floor_mV, vcore_values,
+ fval = menelaus_get_vtg_value(m, floor_mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (fval 0)
return -EINVAL;
@@ -619,15 +618,16 @@ static const struct menelaus_vtg_value vmem_values[] = {
int menelaus_set_vmem(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vmem_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vmem_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vmem_values, ARRAY_SIZE(vmem_values));
+ val = menelaus_get_vtg_value(m, mV, vmem_values,
ARRAY_SIZE(vmem_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vmem_vtg, mV, val, 0x02);
+ return menelaus_set_voltage(m, vmem_vtg, mV, val, 0x02);
}
EXPORT_SYMBOL(menelaus_set_vmem);
@@ -648,15 +648,16 @@ static const struct menelaus_vtg_value vio_values[] = {
int menelaus_set_vio(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vio_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vio_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vio_values, ARRAY_SIZE(vio_values));
+ val = menelaus_get_vtg_value(m, mV, vio_values, ARRAY_SIZE(vio_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vio_vtg, mV, val, 0x02);
+ return menelaus_set_voltage(m, vio_vtg, mV, val, 0x02);
}
EXPORT_SYMBOL(menelaus_set_vio);
@@ -689,6 +690,7 @@ static const struct menelaus_vtg vdcdc3_vtg = {
int menelaus_set_vdcdc(int dcdc, unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
const struct menelaus_vtg *vtg;
int val;
@@ -700,13 +702,13 @@ int menelaus_set_vdcdc(int dcdc, unsigned int mV)
vtg = vdcdc3_vtg;
if (mV == 0)
- return menelaus_set_voltage(vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vdcdc_values,
+ val = menelaus_get_vtg_value(m, mV, vdcdc_values,
ARRAY_SIZE(vdcdc_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vtg, mV, val, 0x03);
+ return menelaus_set_voltage(m, vtg, mV, val, 0x03);
}
static const struct menelaus_vtg_value vmmc_values[] = {
@@ -726,15 +728,16 @@ static const struct menelaus_vtg vmmc_vtg = {
int menelaus_set_vmmc(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vmmc_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vmmc_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vmmc_values, ARRAY_SIZE(vmmc_values));
+ val = menelaus_get_vtg_value(m, mV,
[PATCH v2 02/15] mfd: menelaus: Switch over to module_i2c_driver
just a macro to remove some boilerplate code,
no functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 975ff9e..8bd97ca 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1287,29 +1287,8 @@ static struct i2c_driver menelaus_i2c_driver = {
.id_table = menelaus_id,
};
-static int __init menelaus_init(void)
-{
- int res;
-
- res = i2c_add_driver(menelaus_i2c_driver);
- if (res 0) {
- pr_err(DRIVER_NAME : driver registration failed\n);
- return res;
- }
-
- return 0;
-}
-
-static void __exit menelaus_exit(void)
-{
- i2c_del_driver(menelaus_i2c_driver);
-
- /* FIXME: Shutdown menelaus parts that can be shut down */
-}
+module_i2c_driver(menelaus_i2c_driver);
MODULE_AUTHOR(Texas Instruments, Inc. (and others));
MODULE_DESCRIPTION(I2C interface for Menelaus.);
MODULE_LICENSE(GPL);
-
-module_init(menelaus_init);
-module_exit(menelaus_exit);
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 05/15] mfd: menelaus: Use for_each_set_bit()
that macro just helps removing some extra
line of code and hides ffs() calls.
while at that, also fix a variable shadowing
bug where 'int irq' was being redeclared inside
inner loop while it was also argument to interrupt
handler.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11dc4d3..9ccbb79 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
- unsigned isr;
+ unsigned long isr;
+ unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
~menelaus-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
~menelaus-mask1;
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
+ for_each_set_bit(i, isr, 16) {
mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
+ menelaus_disable_irq(i);
+ menelaus_ack_irq(i);
+ handler = menelaus-handlers[i];
if (handler)
handler(menelaus);
- menelaus_enable_irq(irq);
+ menelaus_enable_irq(i);
mutex_unlock(menelaus-lock);
}
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 12/15] mfd: menelaus: Switch all children to threaded_irq
now that we have our own irq_chip, all children
can use traditional request_threaded_irq().
While at that, also remove so functions which
became unused.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 161 +++--
1 file changed, 50 insertions(+), 111 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index e4f33b7..74eae19 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -175,7 +175,6 @@ struct menelaus_chip {
u8 mask1, mask2;
u8 ack1, ack2;
- void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
@@ -209,42 +208,6 @@ static int menelaus_read_reg(struct menelaus_chip *m, int
reg)
return val;
}
-static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7)
- return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
- else
- return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
-}
-
static void menelaus_irq_ack(struct irq_data *data)
{
struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
@@ -322,47 +285,15 @@ static struct irq_chip menelaus_irq_chip = {
.irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
};
-/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
- void (*handler)(struct menelaus_chip *))
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- m-handlers[irq] = handler;
- ret = menelaus_enable_irq(m, irq);
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- ret = menelaus_disable_irq(m, irq);
- m-handlers[irq] = NULL;
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/*
- * Gets scheduled when a card detect interrupt happens. Note that in some cases
- * this line is wired to card cover switch rather than the card detect switch
- * in each slot. In this case the cards are not seen by menelaus.
- * FIXME: Add handling for D1 too
- */
-static void menelaus_mmc_cd_work(struct menelaus_chip *m)
+static irqreturn_t menelaus_mmc_cd_irq(int irq, void *_m)
{
- int reg;
+ struct menelaus_chip *m = _m;
unsigned char card_mask = 0;
+ int reg;
reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg 0)
- return;
+ return IRQ_NONE;
if (!(reg 0x1))
card_mask |= MCT_PIN_ST_S1_CD_ST;
@@ -373,6 +304,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip *m)
if (m-mmc_callback)
m-mmc_callback(m-mmc_callback_data,
card_mask);
+
+ return IRQ_HANDLED;
}
/*
@@ -504,20 +437,25 @@ int menelaus_register_mmc_callback(void (*callback)(void
*data, u8 card_mask),
m-mmc_callback_data = data;
m-mmc_callback = callback;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
- menelaus_mmc_cd_work);
+
+ ret = request_threaded_irq(MENELAUS_MMC_S1CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s1cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
- menelaus_mmc_cd_work);
+ ret = request_threaded_irq(MENELAUS_MMC_S2CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s2cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
- menelaus_mmc_cd_work);
+ ret =
Re: [PATCH] ARM: dts: omap3-beagle: Fix USB host on beagle boards (for 3.13)
Hi Roger, On Monday 25 November 2013 15:55:45 Roger Quadros wrote: Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply for the USB PHY. As the generic PHY driver can't handle more than one supply at the moment, we configure this supply to be always on. This will cause a very small power impact if the USB host subsystem is not in use, about 76.86 micro-W + LDO power. Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere, so there won't be any functional impact on those boards other than some additional LDO power consumption. Do I need any patch other than this one (on top of v3.13-rc1) to enable the ethernet port on a Beagleboard-xM rev B ? Here's what the kernel reports at boot (with ignore_loglevel set on the command line). [3.388305] ehci-omap 48064800.ehci: EHCI Host Controller [3.394165] ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 2 [3.402252] ehci-omap 48064800.ehci: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [3.411254] ehci-omap 48064800.ehci: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park [3.422027] ehci-omap 48064800.ehci: park 0 [3.426544] ehci-omap 48064800.ehci: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [3.436248] ehci-omap 48064800.ehci: irq 93, io mem 0x48064800 [3.442443] ehci-omap 48064800.ehci: init command 0010005 (park)=0 ithresh=1 period=512 RUN [3.467407] ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00 [3.475494] usb usb2: default language 0x0409 [3.480712] usb usb2: udev 1, busnum 2, minor = 128 [3.485809] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [3.493011] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.500640] usb usb2: Product: EHCI Host Controller [3.505737] usb usb2: Manufacturer: Linux 3.13.0-rc1-00022-g0c6e4db ehci_hcd [3.513183] usb usb2: SerialNumber: 48064800.ehci [3.521270] usb usb2: usb_probe_device [3.525207] usb usb2: configuration #1 chosen from 1 choice [3.531890] usb usb2: adding 2-0:1.0 (config #1, interface 0) [3.539855] hub 2-0:1.0: usb_probe_interface [3.544342] hub 2-0:1.0: usb_probe_interface - got id [3.549835] hub 2-0:1.0: USB hub found [3.554290] hub 2-0:1.0: 3 ports detected [3.558593] hub 2-0:1.0: standalone hub [3.562591] hub 2-0:1.0: individual port power switching [3.568237] hub 2-0:1.0: individual port over-current protection [3.574523] hub 2-0:1.0: power on to power good time: 20ms [3.581085] hub 2-0:1.0: local power source is good [3.587646] hub 2-0:1.0: enabling power on all ports [3.598693] of_get_named_gpiod_flags exited with status 0 [3.607208] input: gpio_keys.6 as /devices/gpio_keys.6/input/input0 [3.617370] twl_rtc rtc.10: setting system clock to 2000-01-01 00:37:16 UTC (946687036) [3.628295] omap_vout:Could not register Video driver [3.633575] sr_init: No PMIC hook to init smartreflex [3.641265] sr_init: platform driver register failed for SR [3.765655] ehci-omap 48064800.ehci: GetStatus port:2 status 001c03 0 ACK POWER sig=? CSC CONNECT [3.775329] hub 2-0:1.0: port 2: status 0501 change 0001 [3.877471] hub 2-0:1.0: state 7 ports 3 chg 0004 evt [3.883758] hub 2-0:1.0: port 2, status 0501, change , 480 Mb/s [3.947357] ehci-omap 48064800.ehci: GetStatus port:2 status 001402 0 ACK POWER sig=k CSC [3.977264] hub 2-0:1.0: state 7 ports 3 chg evt 0004 [3.983062] ehci-omap 48064800.ehci: GetStatus port:2 status 003002 0 ACK POWER OWNER sig=se0 CSC [3.993041] hub 2-0:1.0: port 2, status 0100, change 0001, 12 Mb/s [4.157440] hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 [4.165283] hub 2-0:1.0: hub_suspend [4.169311] usb usb2: bus auto-suspend, wakeup 1 [4.174133] ehci-omap 48064800.ehci: suspend root hub [ 15.878875] ALSA device list: [ 15.881988] No soundcards found. [ 15.888214] omap_uart 4902.serial: no wakeirq for uart2 [ 15.894866] Waiting 10 sec before mounting root device... [ 120.959472] VFS: Unable to mount root fs via NFS, trying floppy. [ 120.968048] VFS: Cannot open root device nfs or unknown-block(2,0): error -6 [ 120.975585] Please append a correct root= boot option; here are the available partitions: [ 120.984558] b300 3941376 mmcblk0 driver: mmcblk [ 120.990203] b301 803249 mmcblk0p1 -01 [ 120.995788] b302 3132675 mmcblk0p2 -02 [ 121.001678] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Reported-by: Nishanth Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap3-beagle-xm.dts | 8 arch/arm/boot/dts/omap3-beagle.dts| 8 2 files changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts index 31a632f..b39918e 100644 ---
Re: [PATCH 1/2] ARM: dts: doc: Document missing binding for omap5-mpu
On Fri, Nov 8, 2013 at 4:38 AM, Sricharan R r.sricha...@ti.com wrote: The binding and support for omap5-mpu which has a cortex-a15 smp core, gic and integrated L2 cache has been existing for sometime. So Documenting the missing binding here. Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Documentation/devicetree/bindings/arm/omap/mpu.txt |8 1 file changed, 8 insertions(+) Applied for 3.13. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] mfd: DT bindings for TPS65218 PMIC
Add DT bindings for TPS65218 PMIC.
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 27
.../devicetree/bindings/regulator/tps65218.txt | 22
2 files changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..87cb7a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,27 @@
+The TPS65218 Integrated Power Management Chips.
+These chips are connected to an i2c bus.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 support several interrupts
+ internally, it is considered as an interrupt controller cascaded to the SoC.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the tps65218.
+ It supports a number of features.
+ The children nodes will thus depend of the capability of the variant.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps@24 {
+compatible = ti,tps65218;
+reg = 0x24;
+interrupt-controller;
+#interrupt-cells = 2;
+interrupt-parent = gic;
+};
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..1ccf170
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,22 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-dcdc5 for DCDC5
+ - ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] mfd: TPS65218: Add support for TPS65218 PMIC
The TPS65218 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Over Temperature warning and Shut down. This patch adds support for TPS65218 mfd device. At this time only the regulator functionality is made available. The patch series is dependent on: http://www.spinics.net/lists/arm-kernel/msg289361.html The series is boot tested on am43x-epos-evm board. Keerthy (4): mfd: DT bindings for TPS65218 PMIC MFD: TPS65218: Add driver for the TPS65218 PMIC Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC ARM: dts: AM437x: Add TPS65218 device tree nodes Documentation/devicetree/bindings/mfd/tps65218.txt | 27 ++ .../devicetree/bindings/regulator/tps65218.txt | 22 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 41 ++ drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile |1 + drivers/mfd/tps65218.c | 281 ++ drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/tps65218-regulator.c | 393 include/linux/mfd/tps65218.h | 288 ++ 10 files changed, 1077 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt create mode 100644 drivers/mfd/tps65218.c create mode 100644 drivers/regulator/tps65218-regulator.c create mode 100644 include/linux/mfd/tps65218.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: AM437x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. This patch is tested on am43x-epos-evm board.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 41 ++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index fbf9c4c..ad7000a 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -156,6 +156,47 @@
reg = 0x50;
};
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of
OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of
OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = ti,tps65218-dcdc3;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+
pixcir_ts@5c {
compatible = pixcir,pixcir_ts;
reg = 0x5c;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
This patch adds support for TPS65218 PMIC regulators.
The regulators set consists of 6 DCDCs and 1 LDO. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/regulator/Kconfig |9 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps65218-regulator.c | 393
3 files changed, 403 insertions(+)
create mode 100644 drivers/regulator/tps65218-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index ce785f4..42f94eb 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -498,6 +498,15 @@ config REGULATOR_TPS65217
voltage regulators. It supports software based voltage control
for different voltage domains
+config REGULATOR_TPS65218
+ tristate TI TPS65218 Power regulators
+ depends on MFD_TPS65218
+ help
+ This driver supports TPS65218 voltage regulator chips. TPS65218
+ provides six step-down converters and one general-purpose LDO
+ voltage regulators. It supports software based voltage control
+ for different voltage domains
+
config REGULATOR_TPS6524X
tristate TI TPS6524X Power regulators
depends on SPI
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 01c597e..dfbfdf9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65090) += tps65090-regulator.o
obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
new file mode 100644
index 000..4989c83
--- /dev/null
+++ b/drivers/regulator/tps65218-regulator.c
@@ -0,0 +1,393 @@
+/*
+ * tps65218-regulator.c
+ *
+ * Regulator driver for TPS65218 PMIC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/of_device.h
+#include linux/regulator/of_regulator.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/mfd/tps65218.h
+
+static unsigned int tps65218_ramp_delay = 4000;
+
+#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, _t) \
+ { \
+ .name = _name,\
+ .id = _id, \
+ .ops= _ops,\
+ .n_voltages = _n, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = _vm, \
+ .enable_reg = _er, \
+ .enable_mask= _em, \
+ .volt_table = _t, \
+ } \
+
+#define TPS65218_INFO(_id, _nm, _min, _max, _f1, _f2) \
+ { \
+ .id = _id, \
+ .name = _nm, \
+ .min_uV = _min, \
+ .max_uV = _max, \
+ .vsel_to_uv = _f1, \
+ .uv_to_vsel = _f2, \
+ }
+
+static int tps65218_ldo1_dcdc3_vsel_to_uv(unsigned int vsel)
+{
+ int uV = 0;
+
+ if (vsel = 26)
+ uV = vsel * 25000 + 90;
+ else
+ uV = (vsel - 26) * 5 + 155;
+
+ return uV;
+}
+
+static int tps65218_ldo1_dcdc3_uv_to_vsel(int uV, unsigned int *vsel)
+{
+ if (uV = 155)
+ *vsel = DIV_ROUND_UP(uV - 90, 25000);
+ else
+ *vsel = 26 + DIV_ROUND_UP(uV - 155, 5);
+
+ return 0;
+}
+
[PATCH 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
The TPS65218 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- Over Temperature warning and Shut down.
This patch adds support for tps65218 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65218.c | 281 +
include/linux/mfd/tps65218.h | 288 ++
4 files changed, 584 insertions(+)
create mode 100644 drivers/mfd/tps65218.c
create mode 100644 include/linux/mfd/tps65218.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 62a60ca..b8f8b30 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -833,6 +833,20 @@ config MFD_TPS65217
This driver can also be built as a module. If so, the module
will be called tps65217.
+config MFD_TPS65218
+ tristate TI TPS65218 Power Management chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65218 series of
+ Power Management chips.
+ These include voltage regulators, gpio and other features
+ that are often used in portable devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called tps65218.
+
config MFD_TPS6586X
bool TI TPS6586x Power Management chips
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8a28dc9..76668da 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_TPS6105X)+= tps6105x.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_TPS6507X) += tps6507x.o
obj-$(CONFIG_MFD_TPS65217) += tps65217.o
+obj-$(CONFIG_MFD_TPS65218) += tps65218.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o
tps65912-objs := tps65912-core.o tps65912-irq.o
obj-$(CONFIG_MFD_TPS65912) += tps65912.o
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
new file mode 100644
index 000..8c61640
--- /dev/null
+++ b/drivers/mfd/tps65218.c
@@ -0,0 +1,281 @@
+/*
+ * TPS65218 chip family multi-function driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/mutex.h
+
+#include linux/mfd/core.h
+#include linux/mfd/tps65218.h
+
+#define TPS65218_PASSWORD_REGS_UNLOCK 0x7D
+
+/**
+ * tps65218_reg_read: Read a single tps65218 register.
+ *
+ * @tps: Device to read from.
+ * @reg: Register to read.
+ * @val: Contians the value
+ */
+int tps65218_reg_read(struct tps65218 *tps, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(tps-regmap, reg, val);
+}
+EXPORT_SYMBOL_GPL(tps65218_reg_read);
+
+/**
+ * tps65218_reg_write: Write a single tps65218 register.
+ *
+ * @tps65218: Device to write to.
+ * @reg: Register to write to.
+ * @val: Value to write.
+ * @level: Password protected level
+ */
+int tps65218_reg_write(struct tps65218 *tps, unsigned int reg,
+ unsigned int val, unsigned int level)
+{
+ int ret;
+ unsigned int xor_reg_val;
+
+ switch (level) {
+ case TPS65218_PROTECT_NONE:
+ return regmap_write(tps-regmap, reg, val);
+ case TPS65218_PROTECT_L1:
+ xor_reg_val = reg ^ TPS65218_PASSWORD_REGS_UNLOCK;
+ ret = regmap_write(tps-regmap, TPS65218_REG_PASSWORD,
+ xor_reg_val);
+ if (ret 0)
+ return ret;
+
+ return regmap_write(tps-regmap, reg, val);
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL_GPL(tps65218_reg_write);
+
+/**
+ * tps65218_update_bits: Modify bits w.r.t mask, val and level.
+ *
+ * @tps65218: Device to write to.
+ * @reg: Register to read-write to.
+ * @mask: Mask.
+ * @val: Value to write.
+ * @level: Password protected level
+ */
+static int tps65218_update_bits(struct
