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 Coelhocoe...@ti.com 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, Shubhrajyotishubhrajy...@ti.com writes: On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti shubhrajy...@ti.com wrote: On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyotishubhrajy...@ti.com 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 Coussonb-cous...@ti.com
Cc: Balaji T Kbalaj...@ti.com
Cc: Graeme Gregoryg...@slimlogic.co.uk
Cc: Samuel Ortizsa...@linux.intel.com
---
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 b-cous...@ti.com
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 b-cous...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Graeme Gregory g...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Rob Herring rob.herr...@calxeda.com
[grant.lik...@secretlab.ca: Fix IRQ_DOMAIN dependency in kconfig]
Cc: Grant Likely grant.lik...@secretlab.ca
---
.../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
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 Dshubhrajy...@ti.com --- 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 Basakp-bas...@ti.com
Signed-off-by: Vishwanath BSvishwanath...@ti.com
Cc: Rafael J. Wysockir...@sisk.pl
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Ben Dooksben-li...@fluff.org
Cc: Jean Delvarekh...@linux-fr.org
---
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
