Re: [PATCHv3 8/8] i2c: omap: cleanup the sysc write
On 11/5/2012 3:25 PM, Felipe Balbi wrote: Hi, On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote: On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote: - dev->syscstate); - } not sure if this will work. What about the first time you call reset() ? won't SYSC just contain the reset values ? No actually the hwmod sets the value. ahaaa, ok good. Let's get an Ack from Benoit, then. Well, in fact, I'm a little bit surprised that we still have to hack the SYSC directly without using an omap_device API. I know that we have to do some weird stuff for reseting that IP, but didn't we already exposed something to allow that? Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP: fix build breakage when CONFIG_OF is not set
Hi Luca, On 2/8/2012 12:25 PM, Luciano Coelho wrote: On Wed, 2012-02-08 at 16:42 +0530, Shubhrajyoti Datta wrote: On Wed, Feb 8, 2012 at 4:34 PM, Luciano Coelho wrote: On Wed, 2012-02-08 at 12:59 +0200, Felipe Balbi wrote: On Wed, Feb 08, 2012 at 12:56:52PM +0200, Luciano Coelho wrote: Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building we generally like to see the commit subject here too. And adding the abbreviated commit instead of the full sha1, wouldn't hurt either ;-) Ok, different practices. :) However there was already a discurssion. Anyways thanks for the patch. http://permalink.gmane.org/gmane.linux.ports.arm.omap/69796 I'll send v2. I think there was already a fix for this. http://www.spinics.net/lists/linux-omap/msg63151.html Anyways thanks for the patch. Ah, okay. Thanks for the info, I hadn't seen these. Yeah, it looks like the OMAP fixes missed -rc2, but Tony sent the pull request [1]. Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg63564.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
On 1/11/2012 4:22 PM, Paul Walmsley wrote: On Wed, 11 Jan 2012, Cousson, Benoit wrote: Something that puzzle me on that point is most architecture does not use plateform_device and thus does not have any pdata to hack some custom function pointers here an there. It means that there is probably some better solution to handle that. PCI and USB have their own bus-level device reset functions that are exported from bus code that lives under drivers/. In a similar fashion, we could export omap_device_reset() from our arch/arm/plat-omap code. But that would require that arch/arm/plat-omap and arch/arm/mach-omap2 code to be compiled for any ARM build that includes i2c-omap.c. This would be good to avoid, under the principle that drivers should be buildable for any architecture. (This is also why we wish to remove omap_{read,write}*() and cpu_is_omap() from any drivers which contain those.) The intention a few years ago was to eventually create a a real omap_bus and omap_device, with the bus/device integration code living under drivers. In such a situation, we'd be able to use something like the PCI/USB approach cleanly, since there wouldn't be dependencies to arch/ code. For reset, maybe the custom bus is a better approach, since it is something that is handled by the OMAP core infrastructure. I was referring more to all the other function pointer we have today in driver like MMC, DSS that does not necessarily belong to a OMAP core stuff. AFAIU, the way PPC is handling that is by splitting the driver in a generic part and in a platform specific part. You can then add any OMAP specific hacks in the OMAP specific part while keeping most of generic code in a generic driver. In this case, we just have to implement a small shim that will handle the OMAP specific code for the reset. The generic driver will handle the rest. Maybe I'm missing some important details, but that does seems easily doable for the i2c case. Hmm. How do those drivers call the platform-specific code in a way that allows those drivers to be built for non-PPC platforms? Well, the point is that a lot of that code should not be in the omap arch directory at the first place. For example, the MMC is using extensively function pointers because of the control module dependency. Having a control module driver will allow stacking the drivers without having to get any code in mach-omap directory. Otherwise, there is as well a dedicated drivers/platform directory that can store some platform specific drivers. So far it looks like it is used for x86 board kind of drivers only. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
On 1/11/2012 2:29 PM, Paul Walmsley wrote: On Wed, 11 Jan 2012, Shubhrajyoti wrote: On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote: "Datta, Shubhrajyoti" writes: On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti wrote: On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote: On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote: This patch either needs to be acked by Ben with a note that it's okay for us to merge through the OMAP tree, or needs to be merged by Ben during the 3.4 merge window, after patches 1-3 have reached the mainline tree. I agree. Ben do you have any comments . If there are no further comments can this be merged also ? As Benoit mentioned earlier, the addition of new pdata fields will cause problems with the DT support already queued for v3.3. This series should be reworked on top of the DT support which Ben has now queued for v3.3 (my branch: for_3.3/i2c/misc) Yes will rework it. Depending on what you plan to do, you'll probably need to coordinate this with Tony also. He's already pulled some of the patches from this series into his i2c branch. The real question is how you plan to handle the device reset function, given that the driver should compile on a non-OMAP build (meaning that you can't call omap_device*() functions from the driver directly), nor should the driver touch the SYSCONFIG register directly. Something that puzzle me on that point is most architecture does not use plateform_device and thus does not have any pdata to hack some custom function pointers here an there. It means that there is probably some better solution to handle that. AFAIU, the way PPC is handling that is by splitting the driver in a generic part and in a platform specific part. You can then add any OMAP specific hacks in the OMAP specific part while keeping most of generic code in a generic driver. In this case, we just have to implement a small shim that will handle the OMAP specific code for the reset. The generic driver will handle the rest. Maybe I'm missing some important details, but that does seems easily doable for the i2c case. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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 03/12] mfd: twl-core: Add initial DT support for twl4030/twl6030
On 1/2/2012 10:04 AM, Grant Likely wrote: > On Thu, Dec 22, 2011 at 03:56:37PM +0100, Benoit Cousson wrote: >> Add initial device-tree support for twl familly chips. >> The current version is missing the regulator entries due >> to the lack of DT regulator bindings for the moment. >> Only the simple sub-modules that do not depend on >> platform_data information can be initialized properly. >> >> Add irqdomain support. >> >> Add documentation for the Texas Instruments TWL Integrated Chip. >> >> Signed-off-by: Benoit Cousson >> Cc: Balaji T K >> Cc: Graeme Gregory >> Cc: Samuel Ortiz >> --- >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig >> index f1391c2..f0de088 100644 >> --- a/drivers/mfd/Kconfig >> +++ b/drivers/mfd/Kconfig >> @@ -200,6 +200,7 @@ config MENELAUS >> config TWL4030_CORE >> bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support" >> depends on I2C=y&& GENERIC_HARDIRQS >> +select IRQ_DOMAIN > > As discussed on linux-next, this breaks powerpc. Drivers cannot select > IRQ_DOMAIN, it can only be selected by architectures. Drivers must depend > on it instead. OK, good to know. The previous version was already breaking non-ARM platform because the IRQ_DOMAIN was not defined, hence this update. I was able to check that this patch was fixing at least x86... but did not have any way to check the PPC build. To be honest, I did not fully understand that this flag was there because some arch does not support IRQ domain yet and thus it should be selected at arch level. Samuel, Here is the updated version, and hopefully the last one, including Grant's fix. Thanks, Benoit --- >From c213f7c905a1ec66f6d394db2f6ff4c1cd74b991 Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Mon, 29 Aug 2011 16:20:23 +0200 Subject: [PATCH v5 03/12] mfd: twl-core: Add initial DT support for twl4030/twl6030 Add initial device-tree support for twl familly chips. The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly. Add irqdomain support. Add documentation for the Texas Instruments TWL Integrated Chip. Signed-off-by: Benoit Cousson Cc: Balaji T K Cc: Graeme Gregory Cc: Samuel Ortiz Acked-by: Rob Herring [grant.lik...@secretlab.ca: Fix IRQ_DOMAIN dependency in kconfig] Cc: Grant Likely --- .../devicetree/bindings/mfd/twl-familly.txt| 47 ++ drivers/mfd/Kconfig|2 +- drivers/mfd/twl-core.c | 51 +++- 3 files changed, 98 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt b/Documentation/devicetree/bindings/mfd/twl-familly.txt new file mode 100644 index 000..ff4cacd --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt @@ -0,0 +1,47 @@ +Texas Instruments TWL family + +The TWLs are Integrated Power Management Chips. +Some version might contain much more analog function like +USB transceiver or Audio amplifier. +These chips are connected to an i2c bus. + + +Required properties: +- compatible : Must be "ti,twl4030"; + For Integrated power-management/audio CODEC device used in OMAP3 + based boards +- compatible : Must be "ti,twl6030"; + For Integrated power-management used in OMAP4 based boards +- interrupts : This i2c device has an IRQ line connected to the main SoC +- interrupt-controller : Since the twl support several interrupts internally, + it is considered as an interrupt controller cascaded to the SoC one. +- #interrupt-cells = <1>; +- interrupt-parent : The parent interrupt controller. + +Optional node: +- Child nodes contain in the twl. The twl family is made of several variants + that support a different number of features. + The children nodes will thus depend of the capability of the variant. + + +Example: +/* + * Integrated Power Management Chip + * http://www.ti.com/lit/ds/symlink/twl6030.pdf + */ +twl@48 { +compatible = "ti,twl6030"; +reg = <0x48>; +interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */ +interrupt-controller; +#interrupt-cells = <1>; +interrupt-parent = <&gic>; +#address-cells = <1>; +#size-cells = <0>; + +twl_rtc { +compatible = "ti,twl_rtc"; +interrupts = <11>; +reg = <0>; +}; +}; diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f1391c2..09fea20 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -199,7 +199,7 @@ config MENELAUS config TWL4030_CORE bool "Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support" - depends on I2C=y && GENERIC_HARDIRQS + depends on I2C=y && GENERIC_HARDIRQS && IRQ_DOMAIN help Say yes here if you have TWL4030 / TWL6030 family chip on your board. This core driver prov
Re: [PATCHv8 3/5] OMAP: I2C: Reset support
Hi Shubhro, On 12/13/2011 11:55 AM, Shubhrajyoti D wrote: Under some error conditions the i2c driver may do a reset. Adding a reset field and support in the device-specific code to aid error-recovery. Signed-off-by: Shubhrajyoti D --- arch/arm/plat-omap/i2c.c |2 ++ include/linux/i2c-omap.h |1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index db071bc..6cddde2 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -179,6 +179,8 @@ static inline int omap2_i2c_add_bus(int bus_id) */ if (cpu_is_omap34xx()) pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat; + + pdata->device_reset = omap_device_reset; We should avoid introducing any new pdata function pointers since we are in the process of removing them for DT support. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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] I2C: Fix for suspend/resume issue in i2c-core
Hi Vishwa, I just have a couple of minors comments: On 9/4/2010 10:48 AM, Sripathy, Vishwanath wrote: In current i2c core driver, call to pm_runtime_set_active from i2c_device_pm_resume will unconditionally enable i2c module and increment child count of the parent. Because of this, in CPU Idle path, i2c does not idle, preventing Core to enter retention. Also i2c module will not be suspended upon system suspend as pm_runtime_set_suspended is not called from i2c_device_pm_suspend. This issue is fixed by removing pm_runtime_set_active call from resume path which Unnecessary spaces: -^ and ^ is not necessary. This fix has been tested on OMAP4430. Signed-off-by: Partha Basak Signed-off-by: Vishwanath BS Cc: Rafael J. Wysocki Cc: Kevin Hilman Cc: Ben Dooks Cc: Jean Delvare --- drivers/i2c/i2c-core.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) mode change 100644 => 100755 drivers/i2c/i2c-core.c You should probably not have to change the file mode. Regards, Benoit diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c old mode 100644 new mode 100755 index 6649176..13927d5 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -216,12 +216,6 @@ static int i2c_device_pm_resume(struct device *dev) else ret = i2c_legacy_resume(dev); - if (!ret) { - pm_runtime_disable(dev); - pm_runtime_set_active(dev); - pm_runtime_enable(dev); - } - return ret; } -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html