Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Mon, Mar 19, 2012 at 4:39 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 19-03-2012 14:06, Felipe Balbi wrote:
+ ver = usbtll_read(base, OMAP_USBTLL_REVISION);
+ if (ver == OMAP_USBTLL_REV1)
+ count = OMAP_TLL_CHANNEL_COUNT;
+ else if (ver == OMAP_USBTLL_REV2)
+ count = OMAP_REV2_TLL_CHANNEL_COUNT;
+ else {
+ dev_err(dev, TLL version failed\n);
+ ret = -ENODEV;
+ goto err_ioremap;
+ }
wrong coding style.
And *switch* seems more fitting here.
WBR, Sergei
Thanks , I will do this,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Mon, Mar 19, 2012 at 3:11 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Hi Keshava,
Some doubts / comments .
On Monday 19 March 2012 12:18 PM, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h | 8 +
drivers/mfd/Kconfig | 2 +-
drivers/mfd/Makefile | 2 +-
drivers/mfd/omap-usb-tll.c | 463
+
4 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..eb1e47d 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int
on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
+
#endif
extern void am35x_musb_reset(void);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f147395..5f75ad4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -772,7 +772,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..4b3a8e0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855) += vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..3da468a
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,463 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
Nitpick : 2012
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#define OMAP_USBTLL_REVISION (0x00)
+#define OMAP_USBTLL_SYSCONFIG (0x10)
+#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#define OMAP_USBTLL_SYSCONFIG_AUTOIDLE
Re: [PATCH v2 7/7] ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
On Mon, 2012-03-19 at 11:09 -0700, Tony Lindgren wrote: I've updated your patch a bit for the comments a bit and marked omap4_hdmi_mux_pads as __init, will apply to fixes. Updated patch below. Hmm, is there something funny with these init changes now... Initially the situation was that there were no __inits in display.c's mux functions. Then Mark omap_hsmmc_init... patch added __inits to all of them. My patch removed the __inits from dsi functions, but left them to hdmi functions. But now you modified my patch to add the __inits to hdmi functions. Which should already have them from the Mark omap_hsmmc_init... patch. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Mon, Mar 19, 2012 at 12:18 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h | 8 +
drivers/mfd/Kconfig | 2 +-
drivers/mfd/Makefile | 2 +-
drivers/mfd/omap-usb-tll.c | 463
+
4 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..eb1e47d 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int
on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
+
#endif
extern void am35x_musb_reset(void);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f147395..5f75ad4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -772,7 +772,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..4b3a8e0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855) += vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..3da468a
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,463 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#define OMAP_USBTLL_REVISION (0x00)
+#define OMAP_USBTLL_SYSCONFIG (0x10)
+#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#define OMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+
+#define OMAP_USBTLL_SYSSTATUS (0x14)
Re: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulator for first instance
On Monday 19 March 2012, Tony Lindgren wrote: Let's just keep bb60424af. There are more patches needed to make multiple smsc91x instances work, but we need to hear from people with such boards first. Then those can be tagged for stable. Ok, I'm just putting that into the fixes branch for 3.4 then. Thanks, Arnd -- 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
Troubleshooting DSPLINK example
Hi, I am trying to have a working dsplink on a DM3730 based board. DVSDK is 4.03 Kernel is the kernel provided by the DVSDK What happens is the __second__ test I run, if different from the first, fails with a MMU fault. The faulting adress vary, and is never a valid address, where valid means somewhere in the DSPLINK memory map. I checked the DSPLink Troubleshooting page [1], and everything seems ok to me. I did not change the memory map, but checked the tci file mentioned in [2], and my mem command line arg is mem==55M which should be ok. What is strange is the first app run fine. For example in the following test runs (dsp is powered off between each run) : -- test # 1 -- ./loopgpp ./loop.out 100 1000 ./messagegpp ./message.out 2000 -- faulting app -- test #2 -- ./messagegpp ./message.out 2000 ./loopgpp ./loop.out 100 1000 -- faulting app -- test #3 -- ./messagegpp ./message.out 2000 ./messagegpp ./message.out 4000 ./loopgpp ./loop.out 100 1000 -- faulting app DSP MMU Error Fault! MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xbebebeb8]. I think what leads to the MMU fault is the DSP is executing garbage with something like this going on : - DSP does not stop running, and when new code is loaded, at some point old and new code is mixed, leading to fault - Code loading works Ok, but there is a cache or cache flush problem, leading to old and new code being mixed. Thank you for reading this, any hint on what to test next is welcome. Jean-Philippe François [1] http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues [2] http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map -- 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 0/4] ARM: OMAP: boards: changes to support dynamic irq alloc
On 3/20/2012 12:39 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120319 16:00]: Hi Tony, On 3/19/2012 8:17 PM, Tony Lindgren wrote: * Tarun Kanti DebBarmatarun.ka...@ti.com [120319 05:09]: These two patches incorporate changes to OMAP1 and OMAP2 platforms board files whereby older references to OMAP_GPIO_IRQ macro are now replaced with gpio_to_irq(), thereby getting rid of static irq references. Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt Commit: 9a0cee711448335ec43eae83272495e9334c0098 Can you please tell the exact two commits causing this breakage? Well, this is the GPIO DT + SPARSE_IRQ series I have done. It appears that the boards I have were already using properly gpio_to_irq() and thus were working fine with this series. But this is unfortunately not the case of most OMAP2 and 3 legacy boards that were still using an old OMAP way of converting GPIO to IRQ and were never modified to take advantage of the gpiolib stuff. So if these patches are apply before the GPIO DT + SPARSE_IRQ series, there will be no breakage at all. All the cleanup we have never done before will hurt us at some point when we will start using more extensively newer fmwk (DT, sparse_irq, dmaengine...). It was not done on purpose, but this GPIO series highlighted this remaining static broken mapping inside OMAP boards. Yes I understand. But still, which patch(s) cause the issue so we can put that in the changelog for the fixes? OK, here they are: 25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ 384ebe1 gpio/omap: Add DT support to GPIO driver Tarun, You should indeed add the references in your cover letter. I'm baffled how despite all the effort for previnting issues like this this still happen. These all seem valid fixes and clean up things, but how come this was not seen earlier? Maybe because there are much more boards inside mach-omap2 directory than inside my cubicle... :-( Well somehow we need to make sure that patches get properly tested on a reasonable selection of boards. This pretty much breaks things for 21 boards out of the 51 board-*.c files :( What is too bad is that one broken board was enough to figured out the issue and fix all the other ones. I just did not have that one :-( Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
Hi Keshava,
On Tuesday 20 March 2012 12:58 PM, Munegowda, Keshava wrote:Snip
+}
+
+static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
+ .runtime_suspend= usbtll_runtime_suspend,
+ .runtime_resume = usbtll_runtime_resume,
+};
+
Also how about using runtime_pm_ops ?
Sorry I din't get this? what exact alternative are you suggesting here?
SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
usbtll_runtime_resume, NULL)
I should have been clearer.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Tue, Mar 20, 2012 at 2:22 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Hi Keshava,
On Tuesday 20 March 2012 12:58 PM, Munegowda, Keshava wrote:Snip
+}
+
+static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
+ .runtime_suspend = usbtll_runtime_suspend,
+ .runtime_resume = usbtll_runtime_resume,
+};
+
Also how about using runtime_pm_ops ?
Sorry I din't get this? what exact alternative are you suggesting here?
SET_RUNTIME_PM_OPS(usbtll_runtime_suspend,
usbtll_runtime_resume, NULL)
I should have been clearer.
Thanks, I will do this , I think Felipe has already pointed out this.
regards
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] arm: omap3: pm34xx.c: Fix omap3_pm_init() error out paths
+ Kevin On Mon, 19 Mar 2012, Tero Kristo wrote: On Sat, 2012-03-17 at 18:22 -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com It appears that the error paths were overlooked when the omap3_pm_init() routine had the prcm chain handler code added. Fix this by adding a goto target and reordering the error handling code. Also fix how the irq argument for free_irq() is determined. You are right, it looks like the error handling part was accidentally dropped from version 7 of the prcm patch set. Acked-by: Tero Kristo t-kri...@ti.com Paul, you going to grab this? Kevin is the pm34xx.c maintainer, so unless he wants me to queue it, it's probably best for him to take it. - 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 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Mon, Mar 19, 2012 at 3:36 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Mar 19, 2012 at 12:18:31PM +0530, Keshava Munegowda wrote:
+ ver = usbtll_read(base, OMAP_USBTLL_REVISION);
+ if (ver == OMAP_USBTLL_REV1)
+ count = OMAP_TLL_CHANNEL_COUNT;
+ else if (ver == OMAP_USBTLL_REV2)
+ count = OMAP_REV2_TLL_CHANNEL_COUNT;
+ else {
+ dev_err(dev, TLL version failed\n);
+ ret = -ENODEV;
+ goto err_ioremap;
+ }
wrong coding style.
+static const struct dev_pm_ops usbtllomap_dev_pm_ops = {
+ .runtime_suspend = usbtll_runtime_suspend,
+ .runtime_resume = usbtll_runtime_resume,
use SET_RUNTIME_PM_OPS()
+static struct platform_driver usbtll_omap_driver = {
+ .driver = {
+ .name = (char *)usbtll_driver_name,
+ .owner = THIS_MODULE,
+ .pm = usbtllomap_dev_pm_ops,
+ },
+ .remove = __exit_p(usbtll_omap_remove),
__devexit_p()
+};
+
+int omap_tll_enable(void)
+{
+ if (!tll_pdev) {
+ dev_dbg(tll_pdev-dev, missing platform_data\n);
+ return -ENODEV;
+ }
+ return pm_runtime_get_sync(tll_pdev-dev);
+}
+EXPORT_SYMBOL_GPL(omap_tll_enable);
why ?
the usb hs core driver uses omap_tll_enable and omap_tll_disable
apis based on the port selection in ./drivers/mfd/omap-usb-host.c file.
+
+int omap_tll_disable(void)
+{
+ if (!tll_pdev) {
+ dev_dbg(tll_pdev-dev, missing platform_data\n);
+ return -ENODEV;
+ }
+ return pm_runtime_put_sync(tll_pdev-dev);
+}
+EXPORT_SYMBOL_GPL(omap_tll_disable);
why ?
+MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
+MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI controllers);
+
+static int __init omap_usbtll_drvinit(void)
+{
+ return platform_driver_probe(usbtll_omap_driver, usbtll_omap_probe);
please don't. Make sure you use platform_driver_register, instead.
Here , omap_usbtll_drvinit is registered through fs_initcall call;
this is required because, the TLL driver is required to initialized
before the UHH ( usb host core) driver.
regards
keshava
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
Hi,
On Tue, Mar 20, 2012 at 03:00:50PM +0530, Munegowda, Keshava wrote:
+MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
+MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI
controllers);
+
+static int __init omap_usbtll_drvinit(void)
+{
+ return platform_driver_probe(usbtll_omap_driver, usbtll_omap_probe);
please don't. Make sure you use platform_driver_register, instead.
Here , omap_usbtll_drvinit is registered through fs_initcall call;
this is required because, the TLL driver is required to initialized
before the UHH ( usb host core) driver.
no issues with fs_initcall. The issue is with platform_driver_probe()
only.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Tue, Mar 20, 2012 at 01:02:58PM +0530, Munegowda, Keshava wrote:
On Mon, Mar 19, 2012 at 12:18 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h | 8 +
drivers/mfd/Kconfig | 2 +-
drivers/mfd/Makefile | 2 +-
drivers/mfd/omap-usb-tll.c | 463
+
4 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..eb1e47d 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode
port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev,
int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
+
#endif
extern void am35x_musb_reset(void);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f147395..5f75ad4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -772,7 +772,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..4b3a8e0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855) += vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..3da468a
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,463 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#define OMAP_USBTLL_REVISION (0x00)
+#define OMAP_USBTLL_SYSCONFIG (0x10)
+#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#define
[PATCH v2 1/2] of: Add generic device tree DMA helpers
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.
One simple xlate function is provided for the single number type of
request binding.
This implementation is independent from dmaengine so it can also be used
by legacy drivers.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
---
Hi all,
v2: - remove of_dma_to_resource API
- make property #dma-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function
This patch is just for the record as it seems that those helpers will not cover
every people expectations. So I let interested people build on top of this or
redo the whole stuff from the gound up.
Bye,
Documentation/devicetree/bindings/dma/dma.txt | 45 +
drivers/of/Makefile |2 +-
drivers/of/dma.c | 215 +
include/linux/of_dma.h| 60 +++
4 files changed, 321 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..c49e98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,45 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Number of cells for each DMA line.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+ #dma-cells = 1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..338c2ee 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,4 +1,4 @@
-obj-y = base.o
+obj-y = base.o dma.o
obj-$(CONFIG_OF_FLATTREE) += fdt.o
obj-$(CONFIG_OF_PROMTREE) += pdt.o
obj-$(CONFIG_OF_ADDRESS) += address.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..e58a0dd
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,215 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 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.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_dma.h
+
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node *of_node;
+ int of_dma_n_cells;
+ int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
+};
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+ struct of_dma *ofdma;
+
+ list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+ if (ofdma-of_node == np)
+ return ofdma;
+ }
+
+ return NULL;
+}
+
+/**
+ * of_dma_controller_register() - Register a DMA controller to DT DMA helpers
+ * @np:
[PATCH 2/2] of: selftest/dma: Add selftest for new DT DMA request helpers
Those selftests are covering the new DT DMA helpers. They will test both
error and normal cases.
A custom .xlate() function is also provided to show the use of this API in case
of a different need than the single cell argument.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
---
arch/arm/boot/dts/at91sam9m10g45ek.dts |2 +
arch/arm/boot/dts/testcases/tests-dma.dtsi | 24 +++
arch/arm/boot/dts/testcases/tests.dtsi |1 +
drivers/of/selftest.c | 100
4 files changed, 127 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/testcases/tests-dma.dtsi
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index a387e77..18a8f3c 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -38,3 +38,5 @@
};
};
};
+
+/include/ testcases/tests.dtsi
diff --git a/arch/arm/boot/dts/testcases/tests-dma.dtsi
b/arch/arm/boot/dts/testcases/tests-dma.dtsi
new file mode 100644
index 000..5f0ba93
--- /dev/null
+++ b/arch/arm/boot/dts/testcases/tests-dma.dtsi
@@ -0,0 +1,24 @@
+
+/ {
+ testcase-data {
+ dma-tests {
+ testdmac0: test-dma-controller0 {
+ #dma-cells = 1;
+ };
+
+ testdmac1: test-dma-controller1 {
+ #dma-cells = 2;
+ };
+
+ dma-slave-a {
+ dma-request = testdmac0 42;
+ };
+ dma-slave-b {
+ dma-request = testdmac1 24; /* wrong number
of values */
+ };
+ dma-slave-c {
+ dma-request = testdmac1 24 25;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/testcases/tests.dtsi
b/arch/arm/boot/dts/testcases/tests.dtsi
index a7c5067..e3afb2b 100644
--- a/arch/arm/boot/dts/testcases/tests.dtsi
+++ b/arch/arm/boot/dts/testcases/tests.dtsi
@@ -1 +1,2 @@
/include/ tests-phandle.dtsi
+/include/ tests-dma.dtsi
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index f24ffd7..3281bfd 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -9,6 +9,7 @@
#include linux/errno.h
#include linux/module.h
#include linux/of.h
+#include linux/of_dma.h
#include linux/list.h
#include linux/mutex.h
#include linux/slab.h
@@ -148,6 +149,104 @@ static void __init of_selftest_property_match_string(void)
selftest(rc == -EILSEQ, unterminated string; rc=%i, rc);
}
+struct two_cells {
+ int cell1;
+ int cell2;
+};
+
+static int of_dma_xlate_twonumbercell(struct of_phandle_args *dma_spec, void
*cells)
+{
+ struct two_cells *tc;
+
+ if (!dma_spec)
+ return -EINVAL;
+ if (!cells)
+ return -ENOBUFS;
+ if (WARN_ON(dma_spec-args_count != 2))
+ return -EINVAL;
+
+ tc = (struct two_cells *)cells;
+
+ tc-cell1 = dma_spec-args[0];
+ tc-cell2 = dma_spec-args[1];
+ return 0;
+}
+
+static void __init of_selftest_dma(void)
+{
+ struct device_node *dma_controller0_np;
+ struct device_node *dma_controller1_np;
+ struct device_node *dma_slave_np;
+ int rc;
+ int dma_req;
+ struct two_cells tc;
+
+ pr_info(start\n);
+ dma_controller0_np =
of_find_node_by_path(/testcase-data/dma-tests/test-dma-controller0);
+ dma_slave_np =
of_find_node_by_path(/testcase-data/dma-tests/dma-slave-a);
+ if (!dma_controller0_np || !dma_slave_np) {
+ pr_err(No testcase data in device tree\n);
+ return;
+ }
+
+ /* wrong usage: DMA controller not registered yet! */
+ rc = of_get_dma_request(dma_slave_np, 0, dma_req);
+ selftest(rc == -ENODEV, selftest DMA slave request expected:-ENODEV
got:%i\n, rc);
+
+ /* test DMA controller registration */
+ rc = of_dma_controller_register(dma_controller0_np,
of_dma_xlate_onenumbercell);
+ selftest(rc == 0, selftest DMA controller not found: got:%i\n, rc);
+
+ /* wrong usage and error code tests */
+ rc = of_get_dma_request(dma_slave_np, 1, dma_req);
+ selftest(rc == -EINVAL, selftest DMA slave request expected:-EINVAL
got:%i\n, rc);
+
+ rc = of_get_dma_request(dma_slave_np, 0, NULL);
+ selftest(rc == -ENOBUFS, selftest DMA slave request expected:-ENOBUFS
got:%i\n, rc);
+
+ /* proper use of the API */
+ rc = of_get_dma_request(dma_slave_np, 0, dma_req);
+ selftest(rc == 0, selftest DMA slave request error:
[PATCH] of: dma/fixup
---
include/linux/of_dma.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 2865480..da95e37 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -18,7 +18,7 @@
struct device_node;
-#ifdef CONFIG_OF_DMA
+#ifdef CONFIG_OF
extern int of_dma_controller_register(struct device_node *np,
int (*of_dma_xlate)(struct of_phandle_args *, void *));
@@ -29,7 +29,7 @@ extern unsigned int of_dma_count(struct device_node *np);
extern int of_dma_xlate_onenumbercell(struct of_phandle_args *dma_spec,
void *dma_req);
-#else /* CONFIG_OF_DMA */
+#else /* CONFIG_OF */
static int of_dma_controller_register(struct device_node *np,
int (*of_dma_xlate)(struct of_phandle_args *, void *))
@@ -55,6 +55,6 @@ static int of_dma_xlate_onenumbercell(struct of_phandle_args
*dma_spec,
{
return -ENOSYS;
}
-#endif /* CONFIG_OF_DMA */
+#endif /* CONFIG_OF */
#endif /* __LINUX_OF_DMA_H */
--
1.7.9
--
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/3] SPI updates
The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi Felipe Balbi (2): spi: omap2-mcspi: make it behave as a module spi: omap2-mcspi: convert to module_platform_driver Shubhrajyoti D (1): spi: omap2-mcspi: use devm_* functions drivers/spi/spi-omap2-mcspi.c | 46 - 1 files changed, 9 insertions(+), 37 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
[PATCH 2/3] spi: omap2-mcspi: convert to module_platform_driver
From: Felipe Balbi ba...@ti.com
this will delete a few lines of code, no functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5f4419e..7745f91 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1291,18 +1291,5 @@ static struct platform_driver omap2_mcspi_driver = {
.remove = __devexit_p(omap2_mcspi_remove),
};
-
-static int __init omap2_mcspi_init(void)
-{
- return platform_driver_register(omap2_mcspi_driver);
-}
-subsys_initcall(omap2_mcspi_init);
-
-static void __exit omap2_mcspi_exit(void)
-{
- platform_driver_unregister(omap2_mcspi_driver);
-
-}
-module_exit(omap2_mcspi_exit);
-
+module_platform_driver(omap2_mcspi_driver);
MODULE_LICENSE(GPL);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] spi: omap2-mcspi: use devm_* functions
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_request_and_ioremap
to request memory in probe function. Since the freeing is not
needed the calls are deleted from remove function.Also use
use devm_kzalloc for the cs memory allocation.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 7745f91..cb2c0e3 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -789,7 +789,7 @@ static int omap2_mcspi_setup(struct spi_device *spi)
mcspi_dma = mcspi-dma_channels[spi-chip_select];
if (!cs) {
- cs = kzalloc(sizeof *cs, GFP_KERNEL);
+ cs = devm_kzalloc(spi-dev , sizeof *cs, GFP_KERNEL);
if (!cs)
return -ENOMEM;
cs-base = mcspi-base + spi-chip_select * 0x14;
@@ -831,7 +831,6 @@ static void omap2_mcspi_cleanup(struct spi_device *spi)
cs = spi-controller_state;
list_del(cs-node);
- kfree(spi-controller_state);
}
if (spi-chip_select spi-master-num_chipselect) {
@@ -1127,17 +1126,12 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
r-start += pdata-regs_offset;
r-end += pdata-regs_offset;
mcspi-phys = r-start;
- if (!request_mem_region(r-start, resource_size(r),
- dev_name(pdev-dev))) {
- status = -EBUSY;
- goto free_master;
- }
- mcspi-base = ioremap(r-start, resource_size(r));
+ mcspi-base = devm_request_and_ioremap(pdev-dev, r);
if (!mcspi-base) {
dev_dbg(pdev-dev, can't ioremap MCSPI\n);
status = -ENOMEM;
- goto release_region;
+ goto free_master;
}
mcspi-dev = pdev-dev;
@@ -1152,7 +1146,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (mcspi-dma_channels == NULL)
- goto unmap_io;
+ goto free_master;
for (i = 0; i master-num_chipselect; i++) {
char dma_ch_name[14];
@@ -1202,10 +1196,6 @@ disable_pm:
pm_runtime_disable(pdev-dev);
dma_chnl_free:
kfree(mcspi-dma_channels);
-unmap_io:
- iounmap(mcspi-base);
-release_region:
- release_mem_region(r-start, resource_size(r));
free_master:
kfree(master);
platform_set_drvdata(pdev, NULL);
@@ -1217,8 +1207,6 @@ static int __devexit omap2_mcspi_remove(struct
platform_device *pdev)
struct spi_master *master;
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *dma_channels;
- struct resource *r;
- void __iomem *base;
master = dev_get_drvdata(pdev-dev);
mcspi = spi_master_get_devdata(master);
@@ -1226,12 +1214,8 @@ static int __devexit omap2_mcspi_remove(struct
platform_device *pdev)
omap2_mcspi_disable_clocks(mcspi);
pm_runtime_disable(pdev-dev);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(r-start, resource_size(r));
- base = mcspi-base;
spi_unregister_master(master);
- iounmap(base);
kfree(dma_channels);
destroy_workqueue(mcspi-wq);
platform_set_drvdata(pdev, NULL);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] spi: omap2-mcspi: make it behave as a module
From: Felipe Balbi ba...@ti.com
move probe away from __init section and use
platform_driver_register() instead of
platform_driver_probe().
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 0b0dfb7..5f4419e 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1080,7 +1080,7 @@ static int omap_mcspi_runtime_resume(struct device *dev)
}
-static int __init omap2_mcspi_probe(struct platform_device *pdev)
+static int __devinit omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
struct omap2_mcspi_platform_config *pdata = pdev-dev.platform_data;
@@ -1212,7 +1212,7 @@ free_master:
return status;
}
-static int __exit omap2_mcspi_remove(struct platform_device *pdev)
+static int __devexit omap2_mcspi_remove(struct platform_device *pdev)
{
struct spi_master *master;
struct omap2_mcspi *mcspi;
@@ -1287,13 +1287,14 @@ static struct platform_driver omap2_mcspi_driver = {
.owner =THIS_MODULE,
.pm = omap2_mcspi_pm_ops
},
- .remove = __exit_p(omap2_mcspi_remove),
+ .probe =omap2_mcspi_probe,
+ .remove = __devexit_p(omap2_mcspi_remove),
};
static int __init omap2_mcspi_init(void)
{
- return platform_driver_probe(omap2_mcspi_driver, omap2_mcspi_probe);
+ return platform_driver_register(omap2_mcspi_driver);
}
subsys_initcall(omap2_mcspi_init);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Tue, Mar 20, 2012 at 3:29 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Mar 20, 2012 at 03:00:50PM +0530, Munegowda, Keshava wrote:
+MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
+MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI
controllers);
+
+static int __init omap_usbtll_drvinit(void)
+{
+ return platform_driver_probe(usbtll_omap_driver,
usbtll_omap_probe);
please don't. Make sure you use platform_driver_register, instead.
Here , omap_usbtll_drvinit is registered through fs_initcall call;
this is required because, the TLL driver is required to initialized
before the UHH ( usb host core) driver.
no issues with fs_initcall. The issue is with platform_driver_probe()
only.
--
balbi
Thanks , I got it.
I will take the same comment make the same change in usbhs driver too;
regards
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 4/7] gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8901d57..bbe9648 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -120,10 +120,13 @@ static void _set_gpio_dataout_reg(struct gpio_bank *bank,
int gpio, int enable)
void __iomem *reg = bank-base;
u32 l = GPIO_BIT(bank, gpio);
- if (enable)
+ if (enable) {
reg += bank-regs-set_dataout;
- else
+ bank-context.dataout |= l;
+ } else {
reg += bank-regs-clr_dataout;
+ bank-context.dataout = ~l;
+ }
__raw_writel(l, reg);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs-irqenable
instead of overwriting it with gpio_mask.
The overwriting makes sense only in the second case where irqenable
is explicitly read and updated with new gpio_mask before writing it
back. However, for consistency reading regs-irqenable into the
bank-context.irqenable1 takes care of both the scenarios.
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
if (bank-regs-irqenable_inv)
l = ~gpio_mask;
else
l |= gpio_mask;
}
Make the same change for _disable_gpio_irqbank().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index bcb1061..6c17e58 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -451,6 +451,7 @@ static void _enable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
if (bank-regs-set_irqenable) {
reg += bank-regs-set_irqenable;
l = gpio_mask;
+ bank-context.irqenable1 |= gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
@@ -458,10 +459,10 @@ static void _enable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
l = ~gpio_mask;
else
l |= gpio_mask;
+ bank-context.irqenable1 = l;
}
__raw_writel(l, reg);
- bank-context.irqenable1 = l;
}
static void _disable_gpio_irqbank(struct gpio_bank *bank, int gpio_mask)
@@ -472,6 +473,7 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
if (bank-regs-clr_irqenable) {
reg += bank-regs-clr_irqenable;
l = gpio_mask;
+ bank-context.irqenable1 = ~gpio_mask;
} else {
reg += bank-regs-irqenable;
l = __raw_readl(reg);
@@ -479,10 +481,10 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
l |= gpio_mask;
else
l = ~gpio_mask;
+ bank-context.irqenable1 = l;
}
__raw_writel(l, reg);
- bank-context.irqenable1 = l;
}
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 1/7] gpio/omap: fix wakeup_en register update in _set_gpio_wakeup()
There are two ways through which wakeup_en register can be programmed using gpiolib APIs as shown below. It is seen that in the second case in _set_gpio_wakeup(), even though bank-suspend_wakeup is updated correctly, its value is not programmed in wakeup_en register. Fix this. irq_set_type()-gpio_irq_type()-_set_gpio_triggering()-set_gpio_trigger() irq_set_wake()-gpio_wake_enable()-_set_gpio_wakeup() Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 7cbad85..1a144ac 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -511,6 +511,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable) else bank-suspend_wakeup = ~gpio_bit; + __raw_writel(bank-suspend_wakeup, bank-base + bank-regs-wkup_en); spin_unlock_irqrestore(bank-lock, flags); return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 3/7] gpio/omap: fix _set_gpio_irqenable implementation
This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 2042857..8901d57 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -484,7 +484,10 @@ static void _disable_gpio_irqbank(struct gpio_bank *bank,
int gpio_mask)
static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int
enable)
{
- _enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ if (enable)
+ _enable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
+ else
+ _disable_gpio_irqbank(bank, GPIO_BIT(bank, gpio));
}
/*
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 2/7] gpio/omap: fix trigger type to unsigned
The GPIO trigger parameter is of type unsigned.
enum {
IRQ_TYPE_NONE = 0x,
IRQ_TYPE_EDGE_RISING= 0x0001,
IRQ_TYPE_EDGE_FALLING = 0x0002,
IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_EDGE_RISING),
IRQ_TYPE_LEVEL_HIGH = 0x0004,
IRQ_TYPE_LEVEL_LOW = 0x0008,
IRQ_TYPE_LEVEL_MASK = (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH),
IRQ_TYPE_SENSE_MASK = 0x000f,
IRQ_TYPE_PROBE = 0x0010,
...
};
Even though gpio_irq_type(struct irq_data *d, unsigned type) has the right type
of parameter, the subsequent called functions set_gpio_triggering() and
set_gpio_trigger() wrongly makes it signed integer. Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/gpio/gpio-omap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 1a144ac..2042857 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -245,7 +245,7 @@ static void _set_gpio_debounce(struct gpio_bank *bank,
unsigned gpio,
}
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
- int trigger)
+ unsigned trigger)
{
void __iomem *base = bank-base;
u32 gpio_bit = 1 gpio;
@@ -327,7 +327,8 @@ static void _toggle_gpio_edge_triggering(struct gpio_bank
*bank, int gpio)
static void _toggle_gpio_edge_triggering(struct gpio_bank *bank, int gpio) {}
#endif
-static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, int trigger)
+static int _set_gpio_triggering(struct gpio_bank *bank, int gpio,
+ unsigned trigger)
{
void __iomem *reg = bank-base;
void __iomem *base = bank-base;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 5/7] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_*
In omap_gpio_runtime_suspend/resume() the context save/restore should
be independent of bank-enabled_non_wakeup_gpios. This was preventing
context restore of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index bbe9648..bcb1061 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1247,9 +1247,6 @@ static int omap_gpio_runtime_suspend(struct device *dev)
* non-wakeup GPIOs. Otherwise spurious IRQs will be
* generated. See OMAP2420 Errata item 1.101.
*/
- if (!(bank-enabled_non_wakeup_gpios))
- goto update_gpio_context_count;
-
bank-saved_datain = __raw_readl(bank-base +
bank-regs-datain);
l1 = __raw_readl(bank-base + bank-regs-fallingdetect);
@@ -1298,7 +1295,7 @@ static int omap_gpio_runtime_resume(struct device *dev)
__raw_writel(bank-context.risingdetect,
bank-base + bank-regs-risingdetect);
- if (!bank-enabled_non_wakeup_gpios || !bank-workaround_enabled) {
+ if (!bank-workaround_enabled) {
spin_unlock_irqrestore(bank-lock, flags);
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 RESEND 0/7] gpio/omap: Some more driver fixes
This series excludes the cleanup patches as suggested by Kevin from the previously posted series. The fixes include correction of _set_gpio_irqenable() implementation, missing wakeup_en register update in set_gpio_wakeup(), type mismatch of gpio trigger parameter in set_gpio_trigger(), incorrect dataout register update in set_gpio_dataout_() and few corrections in context save logic. It is baselined on top of: git://git.secretlab.ca/git/linux-2.6.git gpio/next Commit: 81b279d80a63628e580c71a31d30a8c3b3047ad4 Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Power Test: Off-mode and Retention on OMAP3430 (Suspend and Idle paths). Also confirmed that dataout register content preserved over off-mode. Functional Test: OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430, OMAP4-BLAZE v4: a) Implemented all comments on v3 which are mostly related to avoiding unnecessary register read while updating the context. b) Folded: gpio/omap: fix dataout register overwrite in _set_gpio_dataout into: gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg v3: - Added 4 more additional patches to the previous series which are all bug fixes. v2: - Added a new patch to update wakeup_en register in _set_gpio_wakeup() in addition to updating bank-context.wake_en. - Added a new patch to remove redundant decoding of gpio offset in gpio_get(), _get_gpio_datain() and _get_gpio_dataout(). - Added a new patch to remove suspend/resume callbacks because the operations performed with the callbacks are redundant. Tarun Kanti DebBarma (7): gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() gpio/omap: fix trigger type to unsigned gpio/omap: fix _set_gpio_irqenable implementation gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_* gpio/omap: fix incorrect update to context.irqenable1 gpio/omap: fix redundant decoding of gpio offset drivers/gpio/gpio-omap.c | 47 - 1 files changed, 25 insertions(+), 22 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 v2 0/4] ARM: OMAP: boards: changes to support dynamic irq alloc
On Tue, Mar 20, 2012 at 2:30 PM, Cousson, Benoit b-cous...@ti.com wrote: On 3/20/2012 12:39 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120319 16:00]: Hi Tony, On 3/19/2012 8:17 PM, Tony Lindgren wrote: * Tarun Kanti DebBarmatarun.ka...@ti.com [120319 05:09]: These two patches incorporate changes to OMAP1 and OMAP2 platforms board files whereby older references to OMAP_GPIO_IRQ macro are now replaced with gpio_to_irq(), thereby getting rid of static irq references. Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt Commit: 9a0cee711448335ec43eae83272495e9334c0098 Can you please tell the exact two commits causing this breakage? Well, this is the GPIO DT + SPARSE_IRQ series I have done. It appears that the boards I have were already using properly gpio_to_irq() and thus were working fine with this series. But this is unfortunately not the case of most OMAP2 and 3 legacy boards that were still using an old OMAP way of converting GPIO to IRQ and were never modified to take advantage of the gpiolib stuff. So if these patches are apply before the GPIO DT + SPARSE_IRQ series, there will be no breakage at all. All the cleanup we have never done before will hurt us at some point when we will start using more extensively newer fmwk (DT, sparse_irq, dmaengine...). It was not done on purpose, but this GPIO series highlighted this remaining static broken mapping inside OMAP boards. Yes I understand. But still, which patch(s) cause the issue so we can put that in the changelog for the fixes? OK, here they are: 25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ 384ebe1 gpio/omap: Add DT support to GPIO driver Tarun, You should indeed add the references in your cover letter. Yes, I will specify them in the cover letter. -- Tarun I'm baffled how despite all the effort for previnting issues like this this still happen. These all seem valid fixes and clean up things, but how come this was not seen earlier? Maybe because there are much more boards inside mach-omap2 directory than inside my cubicle... :-( Well somehow we need to make sure that patches get properly tested on a reasonable selection of boards. This pretty much breaks things for 21 boards out of the 51 board-*.c files :( What is too bad is that one broken board was enough to figured out the issue and fix all the other ones. I just did not have that one :-( Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 RESEND] ARM: OMAP: USB: HOST TLL platform driver
On Tue, Mar 20, 2012 at 04:21:18PM +0530, Munegowda, Keshava wrote:
On Tue, Mar 20, 2012 at 3:29 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Mar 20, 2012 at 03:00:50PM +0530, Munegowda, Keshava wrote:
+MODULE_AUTHOR(Keshava Munegowda keshava_mgo...@ti.com);
+MODULE_ALIAS(platform: USBHS_DRIVER_NAME);
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(usb tll driver for TI OMAP EHCI and OHCI
controllers);
+
+static int __init omap_usbtll_drvinit(void)
+{
+ return platform_driver_probe(usbtll_omap_driver,
usbtll_omap_probe);
please don't. Make sure you use platform_driver_register, instead.
Here , omap_usbtll_drvinit is registered through fs_initcall call;
this is required because, the TLL driver is required to initialized
before the UHH ( usb host core) driver.
no issues with fs_initcall. The issue is with platform_driver_probe()
only.
--
balbi
Thanks , I got it.
I will take the same comment make the same change in usbhs driver too;
cool, thanks
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/3] OMAPDSS: HDMI: Interrupt and PHY state handling support
From: Mythri P K mythr...@ti.com Add support for handling the DSS_HDMI interrupt in HDMI, A line that serves to notify HDMI of status change in PHY, PLL and CORE based on the registration. Also logic to support enabling of the PHY in TX_ON state only when a PHY_CONNECT which would make sure that TMDS lines are high before putting it in TX_ON state. Mythri P K (3): OMAPDSS: HDMI: support for interrupt enabling OMAPDSS: HDMI: Add support for DSS_HDMI Interrupt OMAPDSS: HDMI: wait for TMDS to be high before putting phy in TX_ON drivers/video/omap2/dss/dss_features.c|1 + drivers/video/omap2/dss/hdmi.c| 21 + drivers/video/omap2/dss/ti_hdmi.h | 20 + drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 117 +++- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |3 + 5 files changed, 157 insertions(+), 5 deletions(-) -- 1.7.5.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 3/3] OMAPDSS: HDMI: wait for TMDS to be high before putting
From: Mythri P K mythr...@ti.com
Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
It just ensures that the TV is connected but does not guarantee
that TMDS data lines and clock lines are up and ready for transmission.
Which although is very rare scenario has a potential to damage the HDMI
port.
Thus this patch adds the support based on PHY interrupts.
On getting a HPD it registers for PHY connect/disconnect interrupt,
On recieving those it is made sure TMDS lines are UP before changing
the PHY state from LDO_ON to TX_ON.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |1 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 61 ++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +
3 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 5e7e0da..5051df6 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -186,6 +186,7 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
int hpd_gpio;
bool phy_tx_enabled;
+ bool phy_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 31d9927..a54c811 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -273,7 +273,8 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
{
unsigned long flags;
bool hpd;
- int r;
+ int r = 0;
+ struct hdmi_irq_vector irq_enable;
/* this should be in ti_hdmi_4xxx_ip private data */
static DEFINE_SPINLOCK(phy_tx_lock);
@@ -286,11 +287,21 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
return 0;
}
- if (hpd)
- r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ hdmi_wp_clr_irq(ip_data);
+ hdmi_wp_irq_init(irq_enable);
+ if (hpd) {
+ if (ip_data-phy_enabled) {
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
+ } else {
+ irq_enable.phy_connect = 1;
+ irq_enable.phy_disconnect = 0;
+ }
+ } else {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
-
+ irq_enable.phy_connect = 0;
+ irq_enable.phy_disconnect = 0;
+ ip_data-phy_enabled = false;
+ }
if (r) {
DSSERR(Failed to %s PHY TX power\n,
hpd ? enable : disable);
@@ -300,6 +311,7 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
ip_data-phy_tx_enabled = hpd;
err:
spin_unlock_irqrestore(phy_tx_lock, flags);
+ hdmi_wp_irq_enable(ip_data, irq_enable);
return r;
}
@@ -312,17 +324,54 @@ static irqreturn_t hpd_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+int hdmi_ti_4xxx_rxdet(struct hdmi_ip_data *ip_data)
+{
+ int tmds_lines =0;
+
+ tmds_lines = hdmi_read_reg(hdmi_phy_base(ip_data),
+ HDMI_TXPHY_PAD_CFG_CTRL);
+
+ return (tmds_lines 0x7F80);
+}
/* Interrupt handler */
void ti_hdmi_4xxx_intr_handler(struct hdmi_ip_data *ip_data)
{
- u32 val;
+ u32 val, r = 0;
+ struct hdmi_irq_vector irq_enable;
val = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS);
+
+ hdmi_wp_clr_irq(ip_data);
+ hdmi_wp_irq_init(irq_enable);
+
+ if (val HDMI_WP_IRQSTATUS_PHYCONNECT) {
+ if (ip_data-phy_tx_enabled hdmi_ti_4xxx_rxdet(ip_data)) {
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
+ irq_enable.phy_connect = 0;
+ irq_enable.phy_disconnect = 1;
+ ip_data-phy_enabled = true;
+ }
+ }
+
+ /* We can get connect / disconnect simultaneously due to glitch */
+ if (val HDMI_WP_IRQSTATUS_PHYDISCONNECT) {
+ if (ip_data-phy_tx_enabled !hdmi_ti_4xxx_rxdet(ip_data)) {
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ irq_enable.phy_connect = 1;
+ irq_enable.phy_disconnect = 0;
+ ip_data-phy_enabled = false;
+ }
+ }
+
+ if (r)
+ DSSERR(Failed to set PHY TX power\n);
+
/* Ack other interrupts if any */
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS, val);
/* flush posted write */
hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS);
+ hdmi_wp_irq_enable(ip_data, irq_enable);
}
int
[PATCH 1/3] OMAPDSS: HDMI: support for interrupt enabling
From: Mythri P K mythr...@ti.com
Add function to enable or clear interrupts in the HDMI wrapper.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 16 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 45 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |1 +
3 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 1f58b84..6d65b3b 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -80,6 +80,22 @@ struct hdmi_pll_info {
enum hdmi_clk_refsel refsel;
};
+struct hdmi_irq_vector {
+ u8 pll_recal;
+ u8 pll_unlock;
+ u8 pll_lock;
+ u8 phy_disconnect;
+ u8 phy_connect;
+ u8 phy_short_5v;
+ u8 video_end_fr;
+ u8 video_vsync;
+ u8 fifo_sample_req;
+ u8 fifo_overflow;
+ u8 fifo_underflow;
+ u8 ocp_timeout;
+ u8 core;
+};
+
struct ti_hdmi_ip_ops {
void (*video_configure)(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bfe6fe6..5272f49 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -224,6 +224,51 @@ void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data)
hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
}
+static void hdmi_wp_irq_init(struct hdmi_irq_vector *irq_enable)
+{
+ irq_enable-pll_recal = 0;
+ irq_enable-pll_unlock = 0;
+ irq_enable-pll_lock = 0;
+ irq_enable-phy_disconnect = 0;
+ irq_enable-phy_connect = 0;
+ irq_enable-phy_short_5v = 0;
+ irq_enable-video_end_fr = 0;
+ irq_enable-video_vsync = 0;
+ irq_enable-fifo_sample_req = 0;
+ irq_enable-fifo_overflow = 0;
+ irq_enable-fifo_underflow = 0;
+ irq_enable-ocp_timeout = 0;
+ irq_enable-core = 0;
+}
+
+static void hdmi_wp_clr_irq(struct hdmi_ip_data *ip_data)
+{
+ hdmi_write_reg(hdmi_wp_base(ip_data),
+ HDMI_WP_IRQENABLE_CLR, 0X);
+}
+
+static void hdmi_wp_irq_enable(struct hdmi_ip_data *ip_data,
+ struct hdmi_irq_vector *irq_enable)
+{
+ u32 r = 0;
+
+ r = ((irq_enable-pll_recal 31) |
+ (irq_enable-pll_unlock 30) |
+ (irq_enable-pll_lock 29) |
+ (irq_enable-phy_disconnect 26) |
+ (irq_enable-phy_connect 25) |
+ (irq_enable-phy_short_5v 24) |
+ (irq_enable-video_end_fr 17) |
+ (irq_enable-video_vsync 16) |
+ (irq_enable-fifo_sample_req 10) |
+ (irq_enable-fifo_overflow 9) |
+ (irq_enable-fifo_underflow 8) |
+ (irq_enable-ocp_timeout 4) |
+ (irq_enable-core 0));
+
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQENABLE_SET, r);
+}
+
static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
{
unsigned long flags;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a14d1a0..3090e81 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -38,6 +38,7 @@
#define HDMI_WP_IRQSTATUS 0x28
#define HDMI_WP_PWR_CTRL 0x40
#define HDMI_WP_IRQENABLE_SET 0x2C
+#define HDMI_WP_IRQENABLE_CLR 0x30
#define HDMI_WP_VIDEO_CFG 0x50
#define HDMI_WP_VIDEO_SIZE 0x60
#define HDMI_WP_VIDEO_TIMING_H 0x68
--
1.7.5.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 2/3] OMAPDSS: HDMI: Add support for DSS_HDMI Interrupt
From: Mythri P K mythr...@ti.com
Add support for DSS_HDMI interrupt handling in HDMI driver
by registering for the same. This is the path for many necessary HDMI
interrupts such as PLL lock/unlock, PHY connect/disconnet, video frame
done etc.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss_features.c|1 +
drivers/video/omap2/dss/hdmi.c| 21 +
drivers/video/omap2/dss/ti_hdmi.h |3 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 13 +
4 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index ce14aa6..29c5548 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -566,6 +566,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
+ .irq_handle = ti_hdmi_4xxx_intr_handler,
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
.audio_enable = ti_hdmi_4xxx_wp_audio_enable,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c4b4f69..14e90b5 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -67,6 +67,8 @@ static struct {
struct platform_device *pdev;
struct hdmi_ip_data ip_data;
+ int irq;
+ spinlock_t irq_lock;
struct clk *sys_clk;
} hdmi;
@@ -790,6 +792,19 @@ static void hdmi_put_clocks(void)
clk_put(hdmi.sys_clk);
}
+static irqreturn_t hdmi_irq_handler(int irq, void *arg)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(hdmi.irq_lock, flags);
+
+ hdmi.ip_data.ops-irq_handle(hdmi.ip_data);
+
+ spin_unlock_irqrestore(hdmi.irq_lock, flags);
+
+ return IRQ_HANDLED;
+}
+
/* HDMI HW IP initialisation */
static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
@@ -823,6 +838,10 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
pm_runtime_enable(pdev-dev);
+ hdmi.irq = platform_get_irq(pdev, 0);
+ r = request_threaded_irq(hdmi.irq, NULL, hdmi_irq_handler, 0,
+ OMAP HDMI, (void *)0);
+
hdmi.ip_data.core_sys_offset = HDMI_CORE_SYS;
hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
@@ -853,6 +872,8 @@ static int omapdss_hdmihw_remove(struct platform_device
*pdev)
snd_soc_unregister_codec(pdev-dev);
#endif
+ free_irq(hdmi.irq, NULL);
+
pm_runtime_disable(pdev-dev);
hdmi_put_clocks();
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 6d65b3b..5e7e0da 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -122,6 +122,8 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
+ void (*irq_handle)(struct hdmi_ip_data *ip_data);
+
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
@@ -197,6 +199,7 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+void ti_hdmi_4xxx_intr_handler(struct hdmi_ip_data *ip_data);
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 5272f49..31d9927 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -312,6 +312,19 @@ static irqreturn_t hpd_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+/* Interrupt handler */
+void ti_hdmi_4xxx_intr_handler(struct hdmi_ip_data *ip_data)
+{
+ u32 val;
+
+ val = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS);
+ /* Ack other interrupts if any */
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS, val);
+ /* flush posted write */
+ hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_IRQSTATUS);
+
+}
+
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
--
1.7.5.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
Re: [PATCH] of: Add generic device tree DMA helpers
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote: On 3/15/2012 9:41 PM, Arnd Bergmann wrote: The numbers definitely need to become local to each of the controllers, but that is the case pretty much automatically using the proposed binding, because each dma request identifier starts with the phandle of the controller. Indeed, and in the case of the OMAP SDMA controller, it can handle up to 127 DMA request lines numbered from 0 to 126... So a local number seems to be a good representation... especially for a number. I'm not sure to understand the issue with this binding. And AFAIK, there is the only one general purpose DMA controller in OMAP so far. The other ones are private to some IPs like MMC or USB, so they do not need necessarily need any DT representation. AM335x has an EDMA controller instead of SDMA. This is the same EDMA found on mach-davinci/ parts. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] arm: omap3: pm34xx.c: Fix omap3_pm_init() error out paths
Paul Walmsley p...@pwsan.com writes: + Kevin On Mon, 19 Mar 2012, Tero Kristo wrote: On Sat, 2012-03-17 at 18:22 -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com It appears that the error paths were overlooked when the omap3_pm_init() routine had the prcm chain handler code added. Fix this by adding a goto target and reordering the error handling code. Also fix how the irq argument for free_irq() is determined. You are right, it looks like the error handling part was accidentally dropped from version 7 of the prcm patch set. Acked-by: Tero Kristo t-kri...@ti.com Paul, you going to grab this? Kevin is the pm34xx.c maintainer, so unless he wants me to queue it, it's probably best for him to take it. Yeah, I've already queued these for v3.4. (branch: for_3.4/fixes/pm) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] of: selftest/dma: Add selftest for new DT DMA request helpers
On Tue, 20 Mar 2012 11:13:32 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
Those selftests are covering the new DT DMA helpers. They will test both
error and normal cases.
A custom .xlate() function is also provided to show the use of this API in
case
of a different need than the single cell argument.
I'm very happy to see test case code. Thanks.
However, since we both understand that this series doesn't address my
major concerns, I'm not spending any time reviewing this version.
g.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
---
arch/arm/boot/dts/at91sam9m10g45ek.dts |2 +
arch/arm/boot/dts/testcases/tests-dma.dtsi | 24 +++
arch/arm/boot/dts/testcases/tests.dtsi |1 +
drivers/of/selftest.c | 100
4 files changed, 127 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/testcases/tests-dma.dtsi
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index a387e77..18a8f3c 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -38,3 +38,5 @@
};
};
};
+
+/include/ testcases/tests.dtsi
diff --git a/arch/arm/boot/dts/testcases/tests-dma.dtsi
b/arch/arm/boot/dts/testcases/tests-dma.dtsi
new file mode 100644
index 000..5f0ba93
--- /dev/null
+++ b/arch/arm/boot/dts/testcases/tests-dma.dtsi
@@ -0,0 +1,24 @@
+
+/ {
+ testcase-data {
+ dma-tests {
+ testdmac0: test-dma-controller0 {
+ #dma-cells = 1;
+ };
+
+ testdmac1: test-dma-controller1 {
+ #dma-cells = 2;
+ };
+
+ dma-slave-a {
+ dma-request = testdmac0 42;
+ };
+ dma-slave-b {
+ dma-request = testdmac1 24; /* wrong number
of values */
+ };
+ dma-slave-c {
+ dma-request = testdmac1 24 25;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/testcases/tests.dtsi
b/arch/arm/boot/dts/testcases/tests.dtsi
index a7c5067..e3afb2b 100644
--- a/arch/arm/boot/dts/testcases/tests.dtsi
+++ b/arch/arm/boot/dts/testcases/tests.dtsi
@@ -1 +1,2 @@
/include/ tests-phandle.dtsi
+/include/ tests-dma.dtsi
diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
index f24ffd7..3281bfd 100644
--- a/drivers/of/selftest.c
+++ b/drivers/of/selftest.c
@@ -9,6 +9,7 @@
#include linux/errno.h
#include linux/module.h
#include linux/of.h
+#include linux/of_dma.h
#include linux/list.h
#include linux/mutex.h
#include linux/slab.h
@@ -148,6 +149,104 @@ static void __init
of_selftest_property_match_string(void)
selftest(rc == -EILSEQ, unterminated string; rc=%i, rc);
}
+struct two_cells {
+ int cell1;
+ int cell2;
+};
+
+static int of_dma_xlate_twonumbercell(struct of_phandle_args *dma_spec, void
*cells)
+{
+ struct two_cells *tc;
+
+ if (!dma_spec)
+ return -EINVAL;
+ if (!cells)
+ return -ENOBUFS;
+ if (WARN_ON(dma_spec-args_count != 2))
+ return -EINVAL;
+
+ tc = (struct two_cells *)cells;
+
+ tc-cell1 = dma_spec-args[0];
+ tc-cell2 = dma_spec-args[1];
+ return 0;
+}
+
+static void __init of_selftest_dma(void)
+{
+ struct device_node *dma_controller0_np;
+ struct device_node *dma_controller1_np;
+ struct device_node *dma_slave_np;
+ int rc;
+ int dma_req;
+ struct two_cells tc;
+
+ pr_info(start\n);
+ dma_controller0_np =
of_find_node_by_path(/testcase-data/dma-tests/test-dma-controller0);
+ dma_slave_np =
of_find_node_by_path(/testcase-data/dma-tests/dma-slave-a);
+ if (!dma_controller0_np || !dma_slave_np) {
+ pr_err(No testcase data in device tree\n);
+ return;
+ }
+
+ /* wrong usage: DMA controller not registered yet! */
+ rc = of_get_dma_request(dma_slave_np, 0, dma_req);
+ selftest(rc == -ENODEV, selftest DMA slave request expected:-ENODEV
got:%i\n, rc);
+
+ /* test DMA controller registration */
+ rc = of_dma_controller_register(dma_controller0_np,
of_dma_xlate_onenumbercell);
+ selftest(rc == 0, selftest DMA controller not found: got:%i\n, rc);
+
+ /* wrong usage and error code tests */
+ rc = of_get_dma_request(dma_slave_np, 1, dma_req);
+ selftest(rc == -EINVAL, selftest DMA slave request expected:-EINVAL
got:%i\n, rc);
+
+
Re: smsc911x on Gumstix Overo/Tobi doesn't work
Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. However, I noticed another problem while testing the patch (not sure if it occurs with the previous version, I can check if that helps): A NULL pointer dereference occurs when unloading the module, see attached log. Yes please do check, that needs to be fixed. The NULL pointer dereference occurs with the unpatched kernel as well. I've attached the log, although I don't see a major difference to the one from the patched kernel. Note that this only happens when the driver works properly (that is, eth0 is usable). I can unload the driver without problems if it is not working as described above. Regards, Thomas [ 286.276245] Unable to handle kernel NULL pointer dereference at virtual address 073c [ 286.285308] pgd = ce744000 [ 286.288818] [073c] *pgd= [ 286.293151] Internal error: Oops: 5 [#1] [ 286.297271] Modules linked in: ipt_MASQUERADE xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables snd_soc_twl4030 ath9k_htc ath9k_common ath9k_hw carl9170 ath ohci_hcd smsc libertas_sdio libertas snd_soc_core regmap_spi regmap_i2c snd_pcm snd_timer smsc911x(-) ehci_hcd snd soundcore snd_page_alloc twl4030_usb [ 286.330047] CPU: 0Tainted: GW (3.3.0-rc7-11899-gb8fe178 #102) [ 286.337554] PC is at regulator_bulk_disable+0x18/0x90 [ 286.342895] LR is at smsc911x_drv_remove+0xd4/0xf4 [smsc911x] [ 286.348907] pc : [c02395fc]lr : [bf03c9cc]psr: 8013 [ 286.348907] sp : ce6c7ed8 ip : 0002 fp : becdfdb4 [ 286.360961] r10: 0738 r9 : ce6c6000 r8 : 0002 [ 286.366424] r7 : cec85408 r6 : 0738 r5 : cec85400 r4 : [ 286.373260] r3 : ce628bc0 r2 : r1 : 0738 r0 : 0002 [ 286.380096] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 286.387603] Control: 10c5387d Table: 8e744019 DAC: 0015 [ 286.393615] Process modprobe (pid: 2393, stack limit = 0xce6c62f0) [ 286.400085] Stack: (0xce6c7ed8 to 0xce6c8000) [ 286.404663] 7ec0: ce628bc0 ce615800 [ 286.413238] 7ee0: cec85400 cec85408 c000d484 bf03c9cc bf03c8f8 cec85408 [ 286.421813] 7f00: bf03e6dc cec8543c 0081 c02618d0 c02618bc c026041c cec85408 bf03e6dc [ 286.430389] 7f20: cec8543c c02609f0 bf03e6dc c0664b08 c02602f8 bf03e718 [ 286.438995] 7f40: b6f581b0 c0064db0 ce484488 63736d73 78313139 c00a3b00 ce628bc0 0001 [ 286.447570] 7f60: ce628bc0 0001 c000d3d4 0081 6010 b6f58208 becdfdc0 [ 286.456146] 7f80:
Re: [PATCH v4 RESEND 0/7] gpio/omap: Some more driver fixes
On Tue, 20 Mar 2012 16:23:12 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This series excludes the cleanup patches as suggested by Kevin from the previously posted series. The fixes include correction of _set_gpio_irqenable() implementation, missing wakeup_en register update in set_gpio_wakeup(), type mismatch of gpio trigger parameter in set_gpio_trigger(), incorrect dataout register update in set_gpio_dataout_() and few corrections in context save logic. It is baselined on top of: git://git.secretlab.ca/git/linux-2.6.git gpio/next Commit: 81b279d80a63628e580c71a31d30a8c3b3047ad4 Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Merged; thanks g. Power Test: Off-mode and Retention on OMAP3430 (Suspend and Idle paths). Also confirmed that dataout register content preserved over off-mode. Functional Test: OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430, OMAP4-BLAZE v4: a) Implemented all comments on v3 which are mostly related to avoiding unnecessary register read while updating the context. b) Folded: gpio/omap: fix dataout register overwrite in _set_gpio_dataout into: gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg v3: - Added 4 more additional patches to the previous series which are all bug fixes. v2: - Added a new patch to update wakeup_en register in _set_gpio_wakeup() in addition to updating bank-context.wake_en. - Added a new patch to remove redundant decoding of gpio offset in gpio_get(), _get_gpio_datain() and _get_gpio_dataout(). - Added a new patch to remove suspend/resume callbacks because the operations performed with the callbacks are redundant. Tarun Kanti DebBarma (7): gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() gpio/omap: fix trigger type to unsigned gpio/omap: fix _set_gpio_irqenable implementation gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_* gpio/omap: fix incorrect update to context.irqenable1 gpio/omap: fix redundant decoding of gpio offset drivers/gpio/gpio-omap.c | 47 - 1 files changed, 25 insertions(+), 22 deletions(-) -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies,Ltd. -- 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] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states
Hey Kevin, I would like to try out this patch in my platform see the benefits that you are reporting. But there is one issue in this patch. You have not initialized hrtimer_timeout variable. This will always be 0 right ?. Thanks, -M On Wed, Nov 9, 2011 at 11:36 PM, Chalhoub, Nicole n-chalh...@ti.com wrote: Hi Deepthi, Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com] Sent: Wednesday, November 09, 2011 12:13 PM To: Hilman, Kevin Cc: linux-ker...@vger.kernel.org; Arjan van de Ven; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; linux- p...@lists.linux-foundation.org; Chalhoub, Nicole Subject: Re: [PATCH] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states [...] By setting timers when we enter non-deepest C-state possible, such that when it fires we can re-evaluate and try moving into deeper and deeper C-states enhancing the power savings is a good feature to have. Looking at the current implementation, is it possible to have it as configurable option where one can enable/disable this functionality through the backhand driver ? The timeout values of the c state timers are set in the backhand driver. By setting the timeout to 0 the timers will not fire so you'll not have this functionality enabled Also I am thinking, instead of having them in governor wouldnt it be a good idea to have it implemented in the backhand driver itself ? --Deepthi In fact each C-state had its own configurable timer, so it is a parameter characterizing a C-state as it is for the exit_latency and target_residency parameters. And we wanted the timer to fire only when we do not go in deep Cstate due to a high load. This decision is made in the CPU idle governor. So the functionality should be seen from the governor.. Thanks and Regards Nicole -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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] of: Add generic device tree DMA helpers
On 03/19/2012 03:45 PM, Grant Likely :
On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
On 03/17/2012 10:40 AM, Grant Likely :
On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node *of_node;
+ int of_dma_n_cells;
+ int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
+};
This _xlate is nearly useless as a generic API. It solves the problem for
the specific case where the driver is hard-coded to know which DMA engine
to talk to, but since the returned data doesn't provide any context, it
isn't useful if there are multiple DMA controllers to choose from.
You mean, if there is no DMA controller phandle specified in the
property?
No; I'm assuming that dma-channel properties will alwasy have a
phandle to the dma controller node.
I think that it is not the purpose of this API to choose a DMA
controller, Nor to provide a channel. The only purpose of this API is to
give a HW request to be used by a DMA slave driver. This slave should
already have a channel to use and a controller to talk to.
Then where is the function that finds the reference to the DMA
controller? I don't understand why it would be useful to decode that
separately.
The void *data pointer must be replaced with a typed structure so that
context can be returned.
I am not sure to follow you entirely... How do I address the fact that
several types of request value can be returned then?
BTW, can we imagine a phandle property with a sting as a argument?
should it be written this way?
dma-request = testdmac1, slave-rx, slave-tx;
No, I'm not suggesting that. Mixing phandles and strings in a single
property is possible but ugly. The phandle-args pattern which uses
zero or more cells as arguments should be used.
If yes, the of_parse_phandle_with_args() is not working on this type...
Right; of_parse_phandle_with_args() should do the job.
(I realize that there seems to be no way out for a generic API: maybe we
should move to one or two cases to address and concentrate on them).
The way I read this patch, the xlate function returns a single
integer representing the DMA request number, but it doesn't provide
any data about *which* dma controller is associated with that channel.
The result of xlate needs to be something like a dma_chan reference
that identifies both the DMA engine and the channel/request on that
dma engine.
[...]
+/**
+ * of_dma_xlate_onenumbercell() - Generic DMA xlate for direct one cell
bindings
+ *
+ * Device Tree DMA translation function which works with one cell bindings
+ * where the cell values map directly to the hardware request number
understood
+ * by the DMA controller.
+ */
+int of_dma_xlate_onenumbercell(struct of_phandle_args *dma_spec, void
*dma_req)
+{
+ if (!dma_spec)
+ return -EINVAL;
+ if (WARN_ON(dma_spec-args_count != 1))
+ return -EINVAL;
+ *(int *)dma_req = dma_spec-args[0];
Following on from comment above; the void *dma_req parameter is dangerous.
How
does this function know that it has been passed an int* pointer?
Well, that is a drawback that comes from having to address generic
cases.
Not if you do it right. If a specific data structure is returned,
then there can be context attached as to what the data means and which
dma controller knows how to parse it.
But anyway, if the DMA controller decide to register a .xlate()
function that returns an integer, the slave driver that will ask a
request line to this DMA controller will be aware that an integer has
to be passed to of_get_dma_request().
The problem still remains; I don't see how the dma slave can figure
out *which* dma controller it needs to talk to.
Is not it what the phandle to the dma controller is made for?
Bye,
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] of: Add generic device tree DMA helpers
On 03/20/2012 04:13 AM, Nicolas Ferre wrote: Add some basic helpers to retrieve a DMA controller device_node and the DMA request specifications. By making DMA controllers register a generic translation function, we allow the management of any type of DMA requests specification. The void * output of an of_dma_xlate() function that will be implemented by the DMA controller can carry any type of dma-request argument. The DMA client will search its associated DMA controller in the list and call the registered of_dam_xlate() function to retrieve the request values. One simple xlate function is provided for the single number type of request binding. This implementation is independent from dmaengine so it can also be used by legacy drivers. +++ b/Documentation/devicetree/bindings/dma/dma.txt +* DMA client + +Client drivers should specify the DMA request property using a phandle to +the controller. If needed, the DMA request identity on that controller is then +added followed by optional request specifications. + +Required property: +- dma-request: List of phandle + dma-request + request specifications, + one group per request line. Should the property name be plural, i.e. dma-requests? For PWM I believe we settled on pwms not pwm, and that was for consistency with other bindings like interrupts and GPIOs. -- 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Tue, Mar 20, 2012 at 04:53:53PM +0100, Samuel Ortiz wrote: Hi Keshava, On Mon, Mar 19, 2012 at 12:12:47PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Felipe, are you ok with that patch ? I'll most likely queue it after this merge window is closed though. my bad, here's my Ack: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] of: Add generic device tree DMA helpers
On Tuesday 20 March 2012, Nicolas Ferre wrote: Add some basic helpers to retrieve a DMA controller device_node and the DMA request specifications. By making DMA controllers register a generic translation function, we allow the management of any type of DMA requests specification. The void * output of an of_dma_xlate() function that will be implemented by the DMA controller can carry any type of dma-request argument. The DMA client will search its associated DMA controller in the list and call the registered of_dam_xlate() function to retrieve the request values. One simple xlate function is provided for the single number type of request binding. This implementation is independent from dmaengine so it can also be used by legacy drivers. Thanks a lot of posting this updated version, I think it will be very useful as we proceed. I still hope that in the end we find that the differences are not all that big and we can do it all with bindings very much like what you have here. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] SPI updates
On Tue, 20 Mar 2012 15:59:46 +0530, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi Felipe Balbi (2): spi: omap2-mcspi: make it behave as a module spi: omap2-mcspi: convert to module_platform_driver Shubhrajyoti D (1): spi: omap2-mcspi: use devm_* functions drivers/spi/spi-omap2-mcspi.c | 46 - 1 files changed, 9 insertions(+), 37 deletions(-) Merged for v3.5 (it's too late for v3.4) g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] SPI updates
On Tuesday 20 March 2012 09:50 PM, Grant Likely wrote: On Tue, 20 Mar 2012 15:59:46 +0530, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi Felipe Balbi (2): spi: omap2-mcspi: make it behave as a module spi: omap2-mcspi: convert to module_platform_driver Shubhrajyoti D (1): spi: omap2-mcspi: use devm_* functions drivers/spi/spi-omap2-mcspi.c | 46 - 1 files changed, 9 insertions(+), 37 deletions(-) Merged for v3.5 (it's too late for v3.4) g. Thanks Grant. -- 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 0/4] ARM: OMAP: boards: changes to support dynamic irq alloc
* DebBarma, Tarun Kanti tarun.ka...@ti.com [120320 04:02]: On Tue, Mar 20, 2012 at 2:30 PM, Cousson, Benoit b-cous...@ti.com wrote: On 3/20/2012 12:39 AM, Tony Lindgren wrote: Yes I understand. But still, which patch(s) cause the issue so we can put that in the changelog for the fixes? OK, here they are: 25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ 384ebe1 gpio/omap: Add DT support to GPIO driver Thanks, I'll update the comments for the first two patches for this and apply them. If I get an ack from Dmitry for patch 3/4, I'll apply them too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: Add TWL4030 PWM driver
This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
PWM has been used as mode, but the PWM registers are different.
The driver can be used and has been tested in conjunction with
pwm-backlight to control a backlight LED of a LCD touch screen.
Signed-off-by: Bernhard Walle wa...@corscience.de
---
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/twl4030-pwm.c | 235 +
3 files changed, 245 insertions(+)
create mode 100644 drivers/mfd/twl4030-pwm.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f147395..4a7bee8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -235,6 +235,15 @@ config TWL4030_POWER
and load scripts controlling which resources are switched off/on
or reset when a sleep, wakeup or warm reset event occurs.
+config TWL4030_PWM
+ tristate TWL4030 PWM (Pulse Width Modulator) Support
+ depends on TWL4030_CORE
+ select HAVE_PWM
+ default n
+ help
+ Say yes here if you want support for TWL4030 PWM. This PWM
+ can be used to control the brightness of an LCD backlight.
+
config MFD_TWL4030_AUDIO
bool
depends on TWL4030_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..7b824eb 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_MENELAUS)+= menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
+obj-$(CONFIG_TWL4030_PWM) += twl4030-pwm.o
obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
obj-$(CONFIG_TWL6040_CORE) += twl6040-core.o twl6040-irq.o
diff --git a/drivers/mfd/twl4030-pwm.c b/drivers/mfd/twl4030-pwm.c
new file mode 100644
index 000..06a5dbf
--- /dev/null
+++ b/drivers/mfd/twl4030-pwm.c
@@ -0,0 +1,235 @@
+/*
+ * twl4030-pwm.c
+ * Copyright (C) 2012 Corscience GmbH Co. KG
+ * Bernhard Walle bernh...@bwalle.de
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/i2c/twl.h
+#include linux/slab.h
+
+#define TWL_INTBR_PMBR10xD
+#define TWL_INTBR_GPBR10xC
+#define TWL_LED_PWMON 0x0
+#define TWL_LED_PWMOFF 0x1
+
+/* GPBR1 */
+#define GPBR1_PWM1_ENABLE (13)
+#define GPBR1_PWM0_ENABLE (12)
+#define GPBR1_PWM1_CLK_ENABLE (11)
+#define GPBR1_PWM0_CLK_ENABLE (10)
+
+/* PMBR1 */
+#define PMBR1_GPIO7_MASK ((15)|(14))
+#define PMBR1_GPIO7_GPIO (0x04)
+#define PMBR1_GPIO7_VIBRASYNC (0x14)
+#define PMBR1_GPIO7_NOACTION (0x24)
+#define PMBR1_GPIO7_PWM1 (0x34)
+
+#define PMBR1_GPIO6_MASK ((13)|(12))
+#define PMBR1_GPIO6_GPIO (0x02)
+#define PMBR1_GPIO6_PWM0 (0x12)
+#define PMBR1_GPIO6_MUTE (0x22)
+
+/* TWL_LED_PWMON and TWL_LED_PWMOFF must be between 0 and PWM_COUNT_MAX. */
+#define PWM_COUNT_MAX 128
+
+/* Opaque data structure */
+struct pwm_device {
+ const char *label;
+ unsigned int pwm_id;
+};
+
+/*
+ * Converts the pwm_id to the I2C register of the TWL that is used to
+ * set the PWM on and off cycle.
+ */
+static const u8 twl_module_register[] = {
+ [0] = TWL4030_MODULE_PWM0,
+ [1] = TWL4030_MODULE_PWM1
+};
+
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ u8 duty_cycle, addr;
+ int ret;
+
+ if (pwm == NULL || period_ns == 0 || duty_ns period_ns)
+ return -EINVAL;
+
+ duty_cycle = (duty_ns * PWM_COUNT_MAX) / period_ns;
+ addr = twl_module_register[pwm-pwm_id];
+
+ ret = twl_i2c_write_u8(addr, 0, TWL_LED_PWMON);
+ if (ret) {
+ pr_err(%s: Failed to configure PWM, Error %d\n,
+ pwm-label, ret);
+ return ret;
+ }
+
+ ret = twl_i2c_write_u8(addr, duty_cycle, TWL_LED_PWMOFF);
+ if (ret 0) {
+ pr_err(%s: Failed to configure PWM, Error %d\n,
+ pwm-label, ret);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(pwm_config);
+
+int pwm_enable(struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR,
Re: [PATCH v2 3/4] drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in ams_delta_serio_exit()
Hi Dmitry,
* Tarun Kanti DebBarma tarun.ka...@ti.com [120319 05:09]:
Even though ams-delta-serio input driver uses gpio_to_irq() in all
relevent places to get irq number, the ams_delta_serio_exit() still
uses OMAP_GPIO_IRQ macro. Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Care to ack this one? I'd like to apply all four as fixes
at the end of the merge window so we can drop the old and
now broken OMAP_GPIO_IRQ macro.
Regards,
Tony
---
drivers/input/serio/ams_delta_serio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..dbe1ae8 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -170,7 +170,7 @@ module_init(ams_delta_serio_init);
static void __exit ams_delta_serio_exit(void)
{
serio_unregister_port(ams_delta_serio);
- free_irq(OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
+ free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in ams_delta_serio_exit()
On Tue, Mar 20, 2012 at 09:52:46AM -0700, Tony Lindgren wrote: Hi Dmitry, * Tarun Kanti DebBarma tarun.ka...@ti.com [120319 05:09]: Even though ams-delta-serio input driver uses gpio_to_irq() in all relevent places to get irq number, the ams_delta_serio_exit() still uses OMAP_GPIO_IRQ macro. Fix this. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Care to ack this one? I'd like to apply all four as fixes at the end of the merge window so we can drop the old and now broken OMAP_GPIO_IRQ macro. Sure. Acked-by: Dmitry Torokhov d...@mail.ru Thanks. -- Dmitry -- 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 RESEND 0/7] gpio/omap: Some more driver fixes
Hi Grant, Grant Likely grant.lik...@secretlab.ca writes: On Tue, 20 Mar 2012 16:23:12 +0530, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: This series excludes the cleanup patches as suggested by Kevin from the previously posted series. The fixes include correction of _set_gpio_irqenable() implementation, missing wakeup_en register update in set_gpio_wakeup(), type mismatch of gpio trigger parameter in set_gpio_trigger(), incorrect dataout register update in set_gpio_dataout_() and few corrections in context save logic. It is baselined on top of: git://git.secretlab.ca/git/linux-2.6.git gpio/next Commit: 81b279d80a63628e580c71a31d30a8c3b3047ad4 Series is available here for reference: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes Merged; thanks Can you hold off slightly before merging this. I haven't been through v4 yet or tested the fixes alone now that they're separated from the other cleanups. Expect a pull request from me when ready. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states
melwyn lobo linux.mel...@gmail.com writes: Hey Kevin, I would like to try out this patch in my platform see the benefits that you are reporting. But there is one issue in this patch. You have not initialized hrtimer_timeout variable. This will always be 0 right ?. Correct. The generic code defaults to zero so that the default behavior with this patch is unchanged from previous behavior. In order to use this feature, your platform-specific code which creates your C-states sets the per-C-state timer values. Kevin Thanks, -M On Wed, Nov 9, 2011 at 11:36 PM, Chalhoub, Nicole n-chalh...@ti.com wrote: Hi Deepthi, Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com] Sent: Wednesday, November 09, 2011 12:13 PM To: Hilman, Kevin Cc: linux-ker...@vger.kernel.org; Arjan van de Ven; linux-arm- ker...@lists.infradead.org; linux-omap@vger.kernel.org; linux- p...@lists.linux-foundation.org; Chalhoub, Nicole Subject: Re: [PATCH] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states [...] By setting timers when we enter non-deepest C-state possible, such that when it fires we can re-evaluate and try moving into deeper and deeper C-states enhancing the power savings is a good feature to have. Looking at the current implementation, is it possible to have it as configurable option where one can enable/disable this functionality through the backhand driver ? The timeout values of the c state timers are set in the backhand driver. By setting the timeout to 0 the timers will not fire so you'll not have this functionality enabled Also I am thinking, instead of having them in governor wouldnt it be a good idea to have it implemented in the backhand driver itself ? --Deepthi In fact each C-state had its own configurable timer, so it is a parameter characterizing a C-state as it is for the exit_latency and target_residency parameters. And we wanted the timer to fire only when we do not go in deep Cstate due to a high load. This decision is made in the CPU idle governor. So the functionality should be seen from the governor.. Thanks and Regards Nicole -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
Tarun Kanti DebBarma tarun.ka...@ti.com writes: In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid, gpio_mask can be directly set by writing to set_irqenable register without overwriting current value. In order to ensure the same is stored in context.irqenable1, we must read from regs-irqenable instead of overwriting it with gpio_mask. The overwriting makes sense only in the second case where irqenable is explicitly read and updated with new gpio_mask before writing it back. However, for consistency reading regs-irqenable into the bank-context.irqenable1 takes care of both the scenarios. ...except that the code doesn't do this anymore. I like the newer version (I hope so, since I suggested it :), but please update the changlog to describe what the code is actually doing. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: smsc911x on Gumstix Overo/Tobi doesn't work
On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. Hi Thomas, I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode. The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful. I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset. The commit is: commit 6386994e03ebbe60338ded3d586308a41e81c0dc Author: Javier Martinez Canillas jav...@dowhile0.org Date: Tue Jan 3 13:36:19 2012 + net/smsc911x: Check if PHY is in operational mode before software reset When I fix the issue I only guarded against generation 4 chips (i.e: pdata-generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets). Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode. Hope it helps, 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 v8 1/8] cpuidle: Add common time keeping and irq enabling
Make necessary changes to implement time keeping and irq enabling
in the core cpuidle code. This will allow the removal of these
functionalities from various platform cpuidle implementations whose
timekeeping and irq enabling follows the form in this common code.
Signed-off-by: Robert Lee rob@linaro.org
Tested-by: Jean Pihetj-pi...@ti.com
Tested-by: Amit Danielamit.kach...@linaro.org
Tested-by: Robert Leerob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Reviewed-by: Deepthi Dharwardeep...@linux.vnet.ibm.com
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/include/asm/cpuidle.h | 30 ++
arch/arm/kernel/Makefile |2 +-
arch/arm/kernel/cpuidle.c | 21 +
drivers/cpuidle/cpuidle.c | 66 +++-
include/linux/cpuidle.h| 13 +++-
5 files changed, 123 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/include/asm/cpuidle.h
create mode 100644 arch/arm/kernel/cpuidle.c
diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
new file mode 100644
index 000..9322f444
--- /dev/null
+++ b/arch/arm/include/asm/cpuidle.h
@@ -0,0 +1,30 @@
+#ifndef __ASM_ARM_CPUIDLE_H
+#define __ASM_ARM_CPUIDLE_H
+
+#ifdef CONFIG_CPU_IDLE
+extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index);
+#else
+static inline int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index) { return -ENODEV; }
+#endif
+
+/* Common ARM WFI state */
+#define ARM_CPUIDLE_WFI_STATE_PWR(p) {\
+ .enter = arm_cpuidle_simple_enter,\
+ .exit_latency = 1,\
+ .target_residency = 1,\
+ .power_usage= p,\
+ .flags = CPUIDLE_FLAG_TIME_VALID,\
+ .name = WFI,\
+ .desc = ARM WFI,\
+}
+
+/*
+ * in case power_specified == 1, give a default WFI power value needed
+ * by some governors
+ */
+#define ARM_CPUIDLE_WFI_STATE ARM_CPUIDLE_WFI_STATE_PWR(UINT_MAX)
+
+#endif
+
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 43b740d..940c27f 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_DEPRECATED_PARAM_STRUCT) += compat.o
obj-$(CONFIG_LEDS) += leds.o
obj-$(CONFIG_OC_ETM) += etm.o
-
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_ISA_DMA_API) += dma.o
obj-$(CONFIG_ARCH_ACORN) += ecard.o
obj-$(CONFIG_FIQ) += fiq.o fiqasm.o
diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
new file mode 100644
index 000..89545f6
--- /dev/null
+++ b/arch/arm/kernel/cpuidle.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2012 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/cpuidle.h
+#include asm/proc-fns.h
+
+int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ cpu_do_idle();
+
+ return index;
+}
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 59f4261..4869b55 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -53,6 +53,24 @@ static void cpuidle_kick_cpus(void) {}
static int __cpuidle_register_device(struct cpuidle_device *dev);
+static inline int cpuidle_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ struct cpuidle_state *target_state = drv-states[index];
+ return target_state-enter(dev, drv, index);
+}
+
+static inline int cpuidle_enter_tk(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ return cpuidle_wrap_enter(dev, drv, index, cpuidle_enter);
+}
+
+typedef int (*cpuidle_enter_t)(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index);
+
+static cpuidle_enter_t cpuidle_enter_ops;
+
/**
* cpuidle_idle_call - the main idle loop
*
@@ -63,7 +81,6 @@ int cpuidle_idle_call(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
struct cpuidle_driver *drv = cpuidle_get_driver();
- struct cpuidle_state *target_state;
int next_state, entered_state;
if (off)
@@ -92,12 +109,10 @@ int cpuidle_idle_call(void)
return 0;
}
- target_state = drv-states[next_state];
-
trace_power_start(POWER_CSTATE, next_state, dev-cpu);
trace_cpu_idle(next_state, dev-cpu);
- entered_state = target_state-enter(dev, drv, next_state);
+
[PATCH v8 2/8] ARM: at91: Consolidate time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-at91/cpuidle.c | 67 +++---
1 file changed, 24 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index a851e6c..d40b3f3 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -17,9 +17,10 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/cpuidle.h
-#include asm/proc-fns.h
#include linux/io.h
#include linux/export.h
+#include asm/proc-fns.h
+#include asm/cpuidle.h
#include pm.h
@@ -27,66 +28,46 @@
static DEFINE_PER_CPU(struct cpuidle_device, at91_cpuidle_device);
-static struct cpuidle_driver at91_idle_driver = {
- .name = at91_idle,
- .owner =THIS_MODULE,
-};
-
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct timeval before, after;
- int idle_time;
u32 saved_lpr;
- local_irq_disable();
- do_gettimeofday(before);
- if (index == 0)
- /* Wait for interrupt state */
- cpu_do_idle();
- else if (index == 1) {
- asm(b 1f; .align 5; 1:);
- asm(mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
- saved_lpr = sdram_selfrefresh_enable();
- cpu_do_idle();
- sdram_selfrefresh_disable(saved_lpr);
- }
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
+ __asm__(b 1f; .align 5; 1:\n
+ mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
+
+ saved_lpr = sdram_selfrefresh_enable();
+ cpu_do_idle();
+ sdram_selfrefresh_disable(saved_lpr);
- dev-last_residency = idle_time;
return index;
}
+static struct cpuidle_driver at91_idle_driver = {
+ .name = at91_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = at91_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = RAM_SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = AT91_MAX_STATES,
+};
+
/* Initialize CPU idle by registering the idle states */
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
- struct cpuidle_driver *driver = at91_idle_driver;
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
- driver-state_count = AT91_MAX_STATES;
-
- /* Wait for interrupt state */
- driver-states[0].enter = at91_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and RAM self refresh state */
- driver-states[1].enter = at91_enter_idle;
- driver-states[1].exit_latency = 10;
- driver-states[1].target_residency = 1;
- driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[1].name, RAM_SR);
- strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
cpuidle_register_driver(at91_idle_driver);
--
1.7.9.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 v8 6/8] ARM: omap: Consolidate OMAP4 time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 21 +++--
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 72e018b..f386cbe 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -62,15 +62,9 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
{
struct omap4_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
- struct timespec ts_preidle, ts_postidle, ts_idle;
u32 cpu1_state;
- int idle_time;
int cpu_id = smp_processor_id();
- /* Used to keep track of the total time in idle */
- getnstimeofday(ts_preidle);
-
- local_irq_disable();
local_fiq_disable();
/*
@@ -128,26 +122,17 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (index 0)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
- getnstimeofday(ts_postidle);
- ts_idle = timespec_sub(ts_postidle, ts_preidle);
-
- local_irq_enable();
local_fiq_enable();
- idle_time = ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * \
- USEC_PER_SEC;
-
- /* Update cpuidle counters */
- dev-last_residency = idle_time;
-
return index;
}
DEFINE_PER_CPU(struct cpuidle_device, omap4_idle_dev);
struct cpuidle_driver omap4_idle_driver = {
- .name = omap4_idle,
- .owner =THIS_MODULE,
+ .name = omap4_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
};
static inline void _fill_cstate(struct cpuidle_driver *drv,
--
1.7.9.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 v8 8/8] SH: shmobile: Consolidate time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/sh/kernel/cpu/shmobile/cpuidle.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/sh/kernel/cpu/shmobile/cpuidle.c
b/arch/sh/kernel/cpu/shmobile/cpuidle.c
index 6d62eb4..1ddc876 100644
--- a/arch/sh/kernel/cpu/shmobile/cpuidle.c
+++ b/arch/sh/kernel/cpu/shmobile/cpuidle.c
@@ -29,7 +29,6 @@ static int cpuidle_sleep_enter(struct cpuidle_device *dev,
int index)
{
unsigned long allowed_mode = SUSP_SH_SLEEP;
- ktime_t before, after;
int requested_state = index;
int allowed_state;
int k;
@@ -47,19 +46,16 @@ static int cpuidle_sleep_enter(struct cpuidle_device *dev,
*/
k = min_t(int, allowed_state, requested_state);
- before = ktime_get();
sh_mobile_call_standby(cpuidle_mode[k]);
- after = ktime_get();
-
- dev-last_residency = (int)ktime_to_ns(ktime_sub(after, before)) 10;
return k;
}
static struct cpuidle_device cpuidle_dev;
static struct cpuidle_driver cpuidle_driver = {
- .name = sh_idle,
- .owner =THIS_MODULE,
+ .name = sh_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
};
void sh_mobile_setup_cpuidle(void)
--
1.7.9.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 v8 7/8] ARM: shmobile: Consolidate time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-shmobile/cpuidle.c | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-shmobile/cpuidle.c b/arch/arm/mach-shmobile/cpuidle.c
index 1b23342..ca23b20 100644
--- a/arch/arm/mach-shmobile/cpuidle.c
+++ b/arch/arm/mach-shmobile/cpuidle.c
@@ -14,6 +14,7 @@
#include linux/module.h
#include linux/err.h
#include asm/system.h
+#include asm/cpuidle.h
#include asm/io.h
static void shmobile_enter_wfi(void)
@@ -29,37 +30,19 @@ static int shmobile_cpuidle_enter(struct cpuidle_device
*dev,
struct cpuidle_driver *drv,
int index)
{
- ktime_t before, after;
-
- before = ktime_get();
-
- local_irq_disable();
- local_fiq_disable();
-
shmobile_cpuidle_modes[index]();
- local_irq_enable();
- local_fiq_enable();
-
- after = ktime_get();
- dev-last_residency = ktime_to_ns(ktime_sub(after, before)) 10;
-
return index;
}
static struct cpuidle_device shmobile_cpuidle_dev;
static struct cpuidle_driver shmobile_cpuidle_driver = {
- .name = shmobile_cpuidle,
- .owner =THIS_MODULE,
- .states[0] = {
- .name = C1,
- .desc = WFI,
- .exit_latency = 1,
- .target_residency = 1 * 2,
- .flags = CPUIDLE_FLAG_TIME_VALID,
- },
- .safe_state_index = 0, /* C1 */
- .state_count = 1,
+ .name = shmobile_cpuidle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .safe_state_index = 0, /* C1 */
+ .state_count= 1,
};
void (*shmobile_cpuidle_setup)(struct cpuidle_driver *drv);
--
1.7.9.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 v8 0/8] Consolidate cpuidle functionality
This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? Acked-by: Jean Pihetj-pi...@ti.com (v6) Tested-by: Jean Pihetj-pi...@ti.com (v6, omap3) Tested-by: Amit Danielamit.kach...@linaro.org (v6, Exynos4) Tested-by: Robert Leerob@linaro.org (imx51, imx6q) Reviewed-by: Kevin Hilman khil...@ti.com Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org Reviewed-by: Deepthi Dharwardeep...@linux.vnet.ibm.com (core cpuidle only) v8 changes: * v7 testing in linux-next revealed a bug reported by Hugh Dickins on x86 platforms. Investigated and fixed by Daniel Lezcano. * Made a slight change to the defaut ARM WFI state macro as Daniel Lezcano suggested the previous interface was prone to mis-use by platforms that set power_specified to 1. * updated to kernel v3.3 These v8 fixes have been applied to the pull tree being used by linux-next: git://git.linaro.org/people/rob_lee/linux.git cpuidle_consol_pull v7 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg162290.html v7 changes: * Made some struct whitespace alignment changes. * Fixed a coding style violation (thanks Jean Pihet) * Fixed a bug in davinci cpuidle (thanks Jean Pihet) * Corrected the common ARM cpuidle WFI state description to be ARM platform agnostic (thanks Kevin Hilman) * Fixed the problem causing x86 and PPC builds to fail (thanks Deepthi) * Re-added a line of code that was mistakenly removed (thanks Deepthi) v6 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg162018.html v6 changes: * Fixed mindless bug in CONFIG_ARCH_HAS_RELAX code in drivers/cpuidle/cpuidle.c * Removed inline from wrapper function (thanks Mike Turquette and Rob Herring) * Add zeroing out of last_residency if error value is returned (thanks Mike) * Made drivers/cpuidle/cpuidle.c more intelligently handle en_core_tk_irqen flag allowing removal of the if (en_core_tk_irqen) in cpuidle_idle_call (thanks Daniel Lezcano) * Moved CPUIDLE_ARM_WFI_STATE macro to arch/arm/include/asm/cpuidle.h (thanks Jean Pihet) * Cleaned up some comments and a stray change (thanks Jean) v5 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg161596.html v5 changes: * Added common cpu_do_idle function to core cpuidle * Added time keep irq en wrapper to core cpuidle * Removed pre/post enter * Re-added platforms that can use new common code. v4 submission can be found here: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/082742.html v4 changes: * Removed drivers/cpuidle/common.c ** Removed the initialization helper functions ** Removed the wrapper used to consolidate time keeping and irq enable/disable * Add time keeping and local_irq_disable handling in cpuidle_call_idle(). * Made necessary modifications to a few platforms that required the most changes ** Note on omap3: changed structure of omap3_idle_drvdata and added per_next_state and per_saved_state vars to accomodate new framework. v3 submission can be found here: http://www.spinics.net/lists/arm-kernel/msg156751.html v3 changes: * Made various code organization and style changes as suggested in v2 review. (thanks Mark Brown, Rob Herring, Mike Turquette, Kevin Hillman, Daniel Lezcano) * Removed at91 use of common code. A separate effort is underway to clean at91 code and the author has offered to convert to common interface as part of those changes (if this common interface is accepted in time). * Made platform cpuidle_driver objects __initdata and dynamically added one persistent instance of this object in common code. * Removed imx5 pm usage of gpc_dvfs clock as it is no longer needed after being enabled during clock initialization. * Re-organized patches. v2 submission can be found here: http://comments.gmane.org/gmane.linux.ports.arm.kernel/144199 v2 changes: * Common interface moved to drivers/cpuidle and made non arch-specific. * Made various fixes and suggested additions to the common cpuidle code from v1 review. (Thanks Rob Herring and Mark Brown) * Added callback for filling in driver_data field as needed. * Modified the various platforms with these changes. v1 submission can be found here: http://comments.gmane.org/gmane.linux.ports.arm.kernel/142791 Robert Lee (8): cpuidle: Add common time keeping and irq enabling ARM: at91: Consolidate time keeping and irq enable ARM: kirkwood: Consolidate time keeping and irq enable ARM: davinci: Consolidate time keeping and irq enable ARM: omap: Consolidate OMAP3 time keeping and irq enable ARM: omap: Consolidate OMAP4 time keeping and irq enable ARM: shmobile: Consolidate time keeping and irq enable SH: shmobile: Consolidate time keeping and irq enable
[PATCH v8 3/8] ARM: kirkwood: Consolidate time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-kirkwood/cpuidle.c | 72 +++---
1 file changed, 21 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-kirkwood/cpuidle.c
index 7088180..0f17109 100644
--- a/arch/arm/mach-kirkwood/cpuidle.c
+++ b/arch/arm/mach-kirkwood/cpuidle.c
@@ -20,77 +20,47 @@
#include linux/io.h
#include linux/export.h
#include asm/proc-fns.h
+#include asm/cpuidle.h
#include mach/kirkwood.h
#define KIRKWOOD_MAX_STATES2
-static struct cpuidle_driver kirkwood_idle_driver = {
- .name = kirkwood_idle,
- .owner =THIS_MODULE,
-};
-
-static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
-
/* Actual code that puts the SoC in different idle states */
static int kirkwood_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
- if (index == 0)
- /* Wait for interrupt state */
- cpu_do_idle();
- else if (index == 1) {
- /*
-* Following write will put DDR in self refresh.
-* Note that we have 256 cycles before DDR puts it
-* self in self-refresh, so the wait-for-interrupt
-* call afterwards won't get the DDR from self refresh
-* mode.
-*/
- writel(0x7, DDR_OPERATION_BASE);
- cpu_do_idle();
- }
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- /* Update last residency */
- dev-last_residency = idle_time;
+ writel(0x7, DDR_OPERATION_BASE);
+ cpu_do_idle();
return index;
}
+static struct cpuidle_driver kirkwood_idle_driver = {
+ .name = kirkwood_idle,
+ .owner = THIS_MODULE,
+ .en_core_tk_irqen = 1,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = kirkwood_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = DDR SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = KIRKWOOD_MAX_STATES,
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, kirkwood_cpuidle_device);
+
/* Initialize CPU idle by registering the idle states */
static int kirkwood_init_cpuidle(void)
{
struct cpuidle_device *device;
- struct cpuidle_driver *driver = kirkwood_idle_driver;
device = per_cpu(kirkwood_cpuidle_device, smp_processor_id());
device-state_count = KIRKWOOD_MAX_STATES;
- driver-state_count = KIRKWOOD_MAX_STATES;
-
- /* Wait for interrupt state */
- driver-states[0].enter = kirkwood_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and DDR self refresh state */
- driver-states[1].enter = kirkwood_enter_idle;
- driver-states[1].exit_latency = 10;
- driver-states[1].target_residency = 1;
- driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[1].name, DDR SR);
- strcpy(driver-states[1].desc, WFI and DDR Self Refresh);
cpuidle_register_driver(kirkwood_idle_driver);
if (cpuidle_register_device(device)) {
--
1.7.9.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 v8 5/8] ARM: omap: Consolidate OMAP3 time keeping and irq enable
Use core cpuidle timekeeping and irqen wrapper and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Tested-by: Jean Pihetj-pi...@ti.com
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 42 +++--
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 464cffd..5358664 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -87,29 +87,14 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm,
return 0;
}
-/**
- * omap3_enter_idle - Programs OMAP3 to enter the specified state
- * @dev: cpuidle device
- * @drv: cpuidle driver
- * @index: the index of state to be entered
- *
- * Called from the CPUidle framework to program the device to the
- * specified target state selected by the governor.
- */
-static int omap3_enter_idle(struct cpuidle_device *dev,
+static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
struct omap3_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
- struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
- int idle_time;
-
- /* Used to keep track of the total time in idle */
- getnstimeofday(ts_preidle);
- local_irq_disable();
local_fiq_disable();
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
@@ -148,22 +133,29 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
}
return_sleep_time:
- getnstimeofday(ts_postidle);
- ts_idle = timespec_sub(ts_postidle, ts_preidle);
- local_irq_enable();
local_fiq_enable();
- idle_time = ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * \
- USEC_PER_SEC;
-
- /* Update cpuidle counters */
- dev-last_residency = idle_time;
-
return index;
}
/**
+ * omap3_enter_idle - Programs OMAP3 to enter the specified state
+ * @dev: cpuidle device
+ * @drv: cpuidle driver
+ * @index: the index of state to be entered
+ *
+ * Called from the CPUidle framework to program the device to the
+ * specified target state selected by the governor.
+ */
+static inline int omap3_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ return cpuidle_wrap_enter(dev, drv, index, __omap3_enter_idle);
+}
+
+/**
* next_valid_state - Find next valid C-state
* @dev: cpuidle device
* @drv: cpuidle driver
--
1.7.9.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 v8 4/8] ARM: davinci: Consolidate time keeping and irq enable
Enable core cpuidle timekeeping and irq enabling and remove that
handling from this code.
Signed-off-by: Robert Lee rob@linaro.org
Reviewed-by: Kevin Hilman khil...@ti.com
Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-davinci/cpuidle.c | 82 ---
1 file changed, 33 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index a30c7c5..93ae096 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -18,6 +18,7 @@
#include linux/io.h
#include linux/export.h
#include asm/proc-fns.h
+#include asm/cpuidle.h
#include mach/cpuidle.h
#include mach/ddr2.h
@@ -30,12 +31,42 @@ struct davinci_ops {
u32 flags;
};
+/* Actual code that puts the SoC in different idle states */
+static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
+
+ if (ops ops-enter)
+ ops-enter(ops-flags);
+
+ index = cpuidle_wrap_enter(dev, drv, index,
+ arm_cpuidle_simple_enter);
+
+ if (ops ops-exit)
+ ops-exit(ops-flags);
+
+ return index;
+}
+
/* fields in davinci_ops.flags */
#define DAVINCI_CPUIDLE_FLAGS_DDR2_PWDNBIT(0)
static struct cpuidle_driver davinci_idle_driver = {
- .name = cpuidle-davinci,
- .owner = THIS_MODULE,
+ .name = cpuidle-davinci,
+ .owner = THIS_MODULE,
+ .states[0] = ARM_CPUIDLE_WFI_STATE,
+ .states[1] = {
+ .enter = davinci_enter_idle,
+ .exit_latency = 10,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = DDR SR,
+ .desc = WFI and DDR Self Refresh,
+ },
+ .state_count = DAVINCI_CPUIDLE_MAX_STATES,
};
static DEFINE_PER_CPU(struct cpuidle_device, davinci_cpuidle_device);
@@ -77,41 +108,10 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
},
};
-/* Actual code that puts the SoC in different idle states */
-static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
-{
- struct cpuidle_state_usage *state_usage = dev-states_usage[index];
- struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
- struct timeval before, after;
- int idle_time;
-
- local_irq_disable();
- do_gettimeofday(before);
-
- if (ops ops-enter)
- ops-enter(ops-flags);
- /* Wait for interrupt state */
- cpu_do_idle();
- if (ops ops-exit)
- ops-exit(ops-flags);
-
- do_gettimeofday(after);
- local_irq_enable();
- idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
- (after.tv_usec - before.tv_usec);
-
- dev-last_residency = idle_time;
-
- return index;
-}
-
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
- struct cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device = per_cpu(davinci_cpuidle_device, smp_processor_id());
@@ -123,27 +123,11 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
ddr2_reg_base = pdata-ddr2_ctlr_base;
- /* Wait for interrupt state */
- driver-states[0].enter = davinci_enter_idle;
- driver-states[0].exit_latency = 1;
- driver-states[0].target_residency = 1;
- driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[0].name, WFI);
- strcpy(driver-states[0].desc, Wait for interrupt);
-
- /* Wait for interrupt and DDR self refresh state */
- driver-states[1].enter = davinci_enter_idle;
- driver-states[1].exit_latency = 10;
- driver-states[1].target_residency = 1;
- driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(driver-states[1].name, DDR SR);
- strcpy(driver-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
- driver-state_count = DAVINCI_CPUIDLE_MAX_STATES;
ret = cpuidle_register_driver(davinci_idle_driver);
if (ret) {
--
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tuesday 20 March 2012, Robert Lee wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. Arnd -- 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: Add TWL4030 PWM driver
On Tuesday 20 March 2012, Bernhard Walle wrote: This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030 PWM has been used as mode, but the PWM registers are different. The driver can be used and has been tested in conjunction with pwm-backlight to control a backlight LED of a LCD touch screen. Signed-off-by: Bernhard Walle wa...@corscience.de Since it's too late for v3.4 now and we will get a new pwm subsystem in v3.5, I suggest you change the driver to work register with that subsystem instead of just using the old header file. Note that drivers/mfd is not really the right place anyway, because this is not a multifunction driver but just one device driver that happens to be a slave of an mfd. Arnd -- 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 7/7] ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
* Tomi Valkeinen tomi.valkei...@ti.com [120320 00:41]: On Mon, 2012-03-19 at 11:09 -0700, Tony Lindgren wrote: I've updated your patch a bit for the comments a bit and marked omap4_hdmi_mux_pads as __init, will apply to fixes. Updated patch below. Hmm, is there something funny with these init changes now... Initially the situation was that there were no __inits in display.c's mux functions. Then Mark omap_hsmmc_init... patch added __inits to all of them. My patch removed the __inits from dsi functions, but left them to hdmi functions. But now you modified my patch to add the __inits to hdmi functions. Which should already have them from the Mark omap_hsmmc_init... patch. Looks like the original patch missed making omap4_hdmi_mux_pads __init though. I'm just changing omap4_hdmi_mux_pads to make it __init like it should be. 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 v8 0/8] Consolidate cpuidle functionality
Arnd Bergmann arnd.bergm...@linaro.org writes: On Tuesday 20 March 2012, Robert Lee wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. FWIW, I have not had good luck getting response for proposed core CPUidle changes either: http://lkml.org/lkml/2011/9/19/374 Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tuesday 20 March 2012, Kevin Hilman wrote: Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. Hmm, according to the script, you are the maintainer ;-) $ scripts/get_maintainer.pl -f drivers/cpuidle/cpuidle.c Kevin Hilman khil...@ti.com (commit_signer:8/10=80%) Len Brown len.br...@intel.com (commit_signer:7/10=70%) Trinabh Gupta g.trin...@gmail.com (commit_signer:4/10=40%) Arjan van de Ven ar...@linux.intel.com (commit_signer:4/10=40%) Deepthi Dharwar deep...@linux.vnet.ibm.com (commit_signer:4/10=40%) While I realize that the get_maintainers.pl is not the final word, you could be the acting cpuidle maintainer for this merge window and send the pull request. Arnd -- 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 v8 0/8] Consolidate cpuidle functionality
On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Arnd Bergmann arnd.bergm...@linaro.org writes: On Tuesday 20 March 2012, Robert Lee wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. FWIW, I have not had good luck getting response for proposed core CPUidle changes either: http://lkml.org/lkml/2011/9/19/374 Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. /Amit -- 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 v7 1/3] Documentation: common clk API
Hello Sascha,
On Sat, 17 Mar 2012, Sascha Hauer wrote:
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
No, please don't do this. This effectively marks the architectures using
the generic clock framework experimental. We can mark drivers as 'you
have been warned', but marking an architecture as experimental is the
wrong sign for both its users and people willing to adopt the framework.
Also we get this:
warning: (ARCH_MX1 MACH_MX21 ARCH_MX25 MACH_MX27) selects COMMON_CLK
which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
It sounds as if your objection is with CONFIG_EXPERIMENTAL. If that is
indeed your objection, I personally have no objection to simply marking
the code experimental in the Kconfig text. (Patch at the bottom of this
message.)
We need to indicate in some way that the existing code and API is very
likely to change in ways that could involve quite a bit of work for
adopters.
This is because we know the API is not well-defined, and
that both the API and the underlying mechanics will almost certainly need
to change for non-trivial uses of the rate changing code (e.g., DVFS with
external I/O devices).
Please leave DVFS out of the game. DVFS will use the clock framework for
the F part and the regulator framework for the V part, but the clock
framework should not get extended with DVFS features. The notifiers we
currently have in the clock framework should give enough information
for DVFS implementations.
Sadly, that's not so.
Consider a CPUFreq driver as one common clock framework user. This driver
will attempt to repeatedly change the rate of a clock. Changing that
clock's rate may also involve changing the rate of several other clocks
used by active devices. So drivers for these devices will need to
register rate change notifiers. The notifier callbacks might involve
heavyweight work, such as asserting flow control to an
externally-connected device.
Suppose now that the last registered device in the notifier chain cannot
handle the frequency transition and must abort it. This in turn will
require notifier callbacks to all of the previously-notified devices to
abort the change. And then shortly after that, CPUFreq is likely to
request the same frequency change again: hammering a notifier chain that
can never succeed.
Bad enough. We know at least one way to solve this problem. We can use
something like the clk_{block,allow}_changes() functions that have been
discussed for some time now. But these quickly reveal another problem in
the existing API. By default, when there are multiple enabled users of a
clock, another entity is allowed to change the clock's rate, or the rate
of any parent of that clock (!).
This has several implications. One that is significant is that for any
non-trivial clock tree, any driver that cares about its clock's rate will
need to implement notifier callbacks. This is because the driver has no
way of knowing if or when any other code on the system will attempt to
change that clock's rate or source. Or any parent clock's rate or source
might change. Should we really force all current drivers using the clock
code to implement these callbacks? Or can we restrict the situations in
which the clock's rate or parent can change by placing restrictions on the
API? But then, driver code may need to be rewritten, and behavior
assumptions may change.
Even if they don't and we have to change something here this will have
no influence on the architectures implementing their clock tree with the
common clock framework.
That sounds pretty confident. Are you sure that the semantics are so well
understood?
For example, should we allow clk_set_rate() on disabled clocks? How about
prepared, but disabled clocks? If so, what exactly should the clock
framework do in these circumstances? Should notifier callbacks go out
immediately to registered callbacks? Or should those callbacks be delayed
until the clock is prepared or enabled? How should that work when
clk_enable() cannot block? And are you confident that any other user of
the clock framework will answer these undefined questions in the same way
you would?
The above questions are simply scratching the surface. (Just as
examples, there are still significant questions about locking, reentrancy,
and so on - [1] is just one example)
These questions have reasonable answers that I think can be mostly aligned
on. Thinking through the use-cases, and implications, and answering them,
should have been the first task in working on the common clock code. I am
sorry to say -- and perhaps this is partially my fault -- that it seems as
if most people are not even aware that these questions exist, despite
discussions at several conferences and on the mailing
Re: [PATCH v7 1/3] Documentation: common clk API
Hello Arnd, On Sat, 17 Mar 2012, Arnd Bergmann wrote: I think it's rather pointless, because the option is not going to be user selectable but will get selected by the platform unless I'm mistaken. The platform maintainers that care already know the state of the framework. This is where we have differing views, I think. Clearly, Sascha, Saravana, Rob, and I have at least slightly different opinions on the durability of the existing API and code. So it seems reasonable to assume that others who have not followed the development of the common clock code might mistake the implementation or API as being stable and well-defined. It sounds like the primary objection is to the use of CONFIG_EXPERIMENTAL. So here is a patch to simply note the status of this code in its Kconfig text. - Paul From: Paul Walmsley p...@pwsan.com Date: Tue, 20 Mar 2012 17:19:06 -0600 Subject: [PATCH] clk: note that the common clk code is still subject to significant change Indicate that the common clk code and API is still likely to require significant change. The API is not well-defined and both it and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined. A good time for removing this help text would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@ti.com --- drivers/clk/Kconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..dd2d528 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -21,6 +21,11 @@ menuconfig COMMON_CLK this option for loadable modules requiring the common clock framework. + The API and implementation enabled by this option is still + incomplete. The API and implementation is expected to be + fluid and subject to change at any time, potentially + breaking existing users. + If in doubt, say N. if COMMON_CLK -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Wednesday, March 21, 2012, Amit Kucheria wrote: On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Arnd Bergmann arnd.bergm...@linaro.org writes: On Tuesday 20 March 2012, Robert Lee wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. FWIW, I have not had good luck getting response for proposed core CPUidle changes either: http://lkml.org/lkml/2011/9/19/374 Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. Well, I discussed that before with Arjan and he said he would maintain CPUidle if Len didn't have the time, but it seems he didn't expect that there would be a lot of work on it in the near future. So, I suggest that if neither Len nor Arjan reappear shortly, people can send CPUidle patches to me. Thanks, Rafael -- 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 v8 0/8] Consolidate cpuidle functionality
Arnd Bergmann arnd.bergm...@linaro.org writes: On Tuesday 20 March 2012, Kevin Hilman wrote: Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. Hmm, according to the script, you are the maintainer ;-) doh, I knew I should've kept quiet :/ $ scripts/get_maintainer.pl -f drivers/cpuidle/cpuidle.c Kevin Hilman khil...@ti.com (commit_signer:8/10=80%) Len Brown len.br...@intel.com (commit_signer:7/10=70%) Trinabh Gupta g.trin...@gmail.com (commit_signer:4/10=40%) Arjan van de Ven ar...@linux.intel.com (commit_signer:4/10=40%) Deepthi Dharwar deep...@linux.vnet.ibm.com (commit_signer:4/10=40%) While I realize that the get_maintainers.pl is not the final word, you could be the acting cpuidle maintainer for this merge window and send the pull request. Not exactly the outcome I was hoping for (I have enough stuff to look after at the moment.) However, if you think it would help and won't be seen as a take over attempt (I don't want to maintain CPUidle), I can possibly do it for this merge window. Before doing that though, I'll need give this series a final once over before I'm willing to send a potentially flame-attracting pull request. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
Hi Rob, Robert Lee rob@linaro.org writes: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? Acked-by: Jean Pihetj-pi...@ti.com (v6) Tested-by: Jean Pihetj-pi...@ti.com (v6, omap3) Tested-by: Amit Danielamit.kach...@linaro.org (v6, Exynos4) Tested-by: Robert Leerob@linaro.org (imx51, imx6q) Note that there's a space missing between the name and email in these tags (and for Deepthi's below also.) That seems to exist in all the patches. Reviewed-by: Kevin Hilman khil...@ti.com For my Reviewed-by, it only applies to the core code and the OMAP changes. I haven't reviewed the other platform-specific drivers. I believe the same applies to Jean Pihet who works with me on OMAP. Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org Reviewed-by: Deepthi Dharwardeep...@linux.vnet.ibm.com (core cpuidle only) Looks like you never heard from anyone actively working on at91, shmobile, kirwood or davinci. I'm not sure we should merge those platform-specific changes without an ack from those platform maintainers. For 3.4, maybe we should just merge the core code and the platforms that have been reviewed/ack'd, and for 3.5, spent some time nagging the other platform maintainers to review and test. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tue, 20 Mar 2012, Kevin Hilman wrote: Looks like you never heard from anyone actively working on at91, shmobile, kirwood or davinci. I'm not sure we should merge those platform-specific changes without an ack from those platform maintainers. Depends. There is a limit to how long you may be willing to wait after people. Sometimes the only way to make progress is to merge the thing and hope that someone who cares will test the stuff during the ~2 months -rc period and provide any fix then. And if that doesn't happen during that time then either the code is just right and no one noticed the change, or no one cares anymore. IMHO, Rob posted those patches many times now for quite a while (many months) already. So I'd suggest simply pushing that stuff into mainline as is. Nicolas -- 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 v8 0/8] Consolidate cpuidle functionality
On Wed, 21 Mar 2012, Amit Kucheria wrote: On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. As I advised recently, it is usually a good idea for the person/group who is working the most on a subsystem to simply take the lead and become the new maintainer. Waiting for another maintainer to emerge could be compared to cowardice. Nicolas
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On 03/21/2012 05:31 AM, Rafael J. Wysocki wrote: On Wednesday, March 21, 2012, Amit Kucheria wrote: On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Arnd Bergmann arnd.bergm...@linaro.org writes: On Tuesday 20 March 2012, Robert Lee wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? FWIW, Len seems to be rather inactive on the kernel mailing list right now and generally not very interested in anything outside of x86 and acpi. If he doesn't reply in the next few days and Andrew also isn't interested in handling these patches, I'd suggest you just send the pull request to Linus, with Len on Cc and explain that you tried to send them through him but gave up in the end. FWIW, I have not had good luck getting response for proposed core CPUidle changes either: http://lkml.org/lkml/2011/9/19/374 Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. Well, I discussed that before with Arjan and he said he would maintain CPUidle if Len didn't have the time, but it seems he didn't expect that there would be a lot of work on it in the near future. So, I suggest that if neither Len nor Arjan reappear shortly, people can send CPUidle patches to me. Thanks, Rafael I'll be glad to assist you in this. Cheers, Deepthi -- 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 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
On Tue, Mar 20, 2012 at 11:31 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid, gpio_mask can be directly set by writing to set_irqenable register without overwriting current value. In order to ensure the same is stored in context.irqenable1, we must read from regs-irqenable instead of overwriting it with gpio_mask. The overwriting makes sense only in the second case where irqenable is explicitly read and updated with new gpio_mask before writing it back. However, for consistency reading regs-irqenable into the bank-context.irqenable1 takes care of both the scenarios. ...except that the code doesn't do this anymore. Yes. I like the newer version (I hope so, since I suggested it :), but please update the changlog to describe what the code is actually doing. Sure. -- Tarun Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/3] Documentation: common clk API
On Tue, 20 Mar 2012, Paul Walmsley wrote: We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters. [...] Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly. Paul, While I understand your concern, please don't forget that the perfect is the enemy of the good. This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all. So, until the API is well-defined and does all that it needs to do for its major users, [...] No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever. And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily. Nicolas -- 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 v7 1/3] Documentation: common clk API
On 03/20/2012 08:15 PM, Nicolas Pitre wrote: On Tue, 20 Mar 2012, Paul Walmsley wrote: We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters. [...] Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly. Paul, While I understand your concern, please don't forget that the perfect is the enemy of the good. This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all. So, until the API is well-defined and does all that it needs to do for its major users, [...] No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever. And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily. +1 to the general idea in Nicolas's email. To add a few more thoughts, while I agree with Paul that there is room for improvement in the APIs, I think the difference in opinion comes when we ask the question: When we eventually refine the APIs in the future to be more expressive, do we think that the current APIs can or cannot be made as wrappers around the new more expressive APIs? Absolutes are almost never right, so I can't give an absolute answer. But I'm strongly leaning towards we can as the answer to the question. That combined with the reasons Nicholas mentioned is why I think the APIs should not be marked as experimental in anyway. -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 v8 0/8] Consolidate cpuidle functionality
On Tue, Mar 20, 2012 at 7:10 PM, Kevin Hilman khil...@ti.com wrote: Hi Rob, Robert Lee rob@linaro.org writes: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). These changes have been pulled into linux-next. Len, Andrew, can a request be made for Linus to pull these changes? Acked-by: Jean Pihetj-pi...@ti.com (v6) Tested-by: Jean Pihetj-pi...@ti.com (v6, omap3) Tested-by: Amit Danielamit.kach...@linaro.org (v6, Exynos4) Tested-by: Robert Leerob@linaro.org (imx51, imx6q) Note that there's a space missing between the name and email in these tags (and for Deepthi's below also.) That seems to exist in all the patches. Thanks. This is now fixed in my pull tree. Reviewed-by: Kevin Hilman khil...@ti.com For my Reviewed-by, it only applies to the core code and the OMAP changes. I haven't reviewed the other platform-specific drivers. I believe the same applies to Jean Pihet who works with me on OMAP. Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org Reviewed-by: Deepthi Dharwardeep...@linux.vnet.ibm.com (core cpuidle only) Looks like you never heard from anyone actively working on at91, shmobile, kirwood or davinci. I'm not sure we should merge those platform-specific changes without an ack from those platform maintainers. For 3.4, maybe we should just merge the core code and the platforms that have been reviewed/ack'd, and for 3.5, spent some time nagging the other platform maintainers to review and test. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3+: fix oops triggered in omap_prcm_register_chain_handler
This patch fixes the oos below:
[1.790242] Unable to handle kernel NULL pointer dereference at virtual
address 0004
[1.798632] pgd = c0004000
[1.801638] [0004] *pgd=
[1.805400] Internal error: Oops: 805 [#1] PREEMPT SMP THUMB2
[1.811381] Modules linked in:
[1.814601] CPU: 1Not tainted (3.3.0-next-20120320+ #733)
[1.820683] PC is at irq_setup_generic_chip+0x6a/0x84
[1.825951] LR is at irq_get_irq_data+0x7/0x8
[1.830508] pc : [c006465e]lr : [c0063a03]psr: 2133
[1.830512] sp : ee04ff58 ip : fp :
[1.842461] r10: r9 : r8 : 0800
[1.847905] r7 : c064e260 r6 : 01dc r5 : 0001 r4 : ee0accc0
[1.854687] r3 : 0002 r2 : 0800 r1 : 01dc r0 :
[1.861472] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment
kernel
[1.869234] Control: 50c5387d Table: 8000404a DAC: 0015
[1.875215] Process swapper/0 (pid: 1, stack limit = 0xee04e2f8)
[1.881463] Stack: (0xee04ff58 to 0xee05)
[1.886017] ff40: c061b668 0008
[1.894497] ff60: c0682090 ee0accc0 0003 c001c637
0201
[1.902976] ff80: 0004 c0473820 c0473800 c0459e8d c0680ac0 c000866d
0004 0004
[1.911455] ffa0: ee04ffa8 0004 c047381c 0004 c0473820 c0473800
c0680ac0 0082
[1.919934] ffc0: c0489694 c045265f 0004 0004 c0452135 c000d105
0033
[1.928413] ffe0: c04525b5 c000d111 0033 c000d111
[1.936912] [c006465e] (irq_setup_generic_chip+0x6a/0x84) from
[c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0)
[1.948516] [c001c637] (omap_prcm_register_chain_handler+0x147/0x1a0) from
[c000866d] (do_one_initcall+0x65/0xf4)
[1.959500] [c000866d] (do_one_initcall+0x65/0xf4) from [c045265f]
(kernel_init+0xab/0x138)
[1.968529] [c045265f] (kernel_init+0xab/0x138) from [c000d111]
(kernel_thread_exit+0x1/0x6)
[1.977632] Code: f7ff f9d1 6b23 1af3 (6043) 086d
[1.982684] ---[ end trace 1b75b31a2719ed1c ]---
[1.987526] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap2/prm_common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 873b51d..d28f848 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -290,7 +290,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
goto err;
}
- for (i = 0; i = irq_setup-nr_regs; i++) {
+ for (i = 0; i irq_setup-nr_regs; i++) {
gc = irq_alloc_generic_chip(PRCM, 1,
irq_setup-base_irq + i * 32, prm_base,
handle_level_irq);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
So, I suggest that if neither Len nor Arjan reappear shortly, people can send CPUidle patches to me. /me reappears this series is in my tree now, and I'll be poking at it a bit tomorrow. If everything is happy I'll send it for 3.4. thanks, -Len -- 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 RESEND 6/7] gpio/omap: fix incorrect update to context.irqenable1
On Wed, Mar 21, 2012 at 8:10 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Mar 20, 2012 at 11:31 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: In _enable_gpio_irqbank() when bank-regs-set_irqenable is valid, gpio_mask can be directly set by writing to set_irqenable register without overwriting current value. In order to ensure the same is stored in context.irqenable1, we must read from regs-irqenable instead of overwriting it with gpio_mask. The overwriting makes sense only in the second case where irqenable is explicitly read and updated with new gpio_mask before writing it back. However, for consistency reading regs-irqenable into the bank-context.irqenable1 takes care of both the scenarios. ...except that the code doesn't do this anymore. Yes. I like the newer version (I hope so, since I suggested it :), but please update the changlog to describe what the code is actually doing. Sure. I have updated the change log here: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_more_fixes -- Tarun Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
