Re: [PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path
On Wed, 11 Jan 2012, Shubhrajyoti wrote: On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote: Datta, Shubhrajyoti shubhrajy...@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, Shubhrajyoti shubhrajy...@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. - Paul -- 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 Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote: On Wed, 11 Jan 2012, Shubhrajyoti wrote: On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote: Datta, Shubhrajyoti shubhrajy...@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, Shubhrajyoti shubhrajy...@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. Paul I thought through it myself not very clear. - One way is to find some way for the dt to pass function pointer. Or maybe a flag that activates a static function / hwmod func. Will give this a little more thought and get back. I have not any answer right now. - Paul -- 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 RFC] OMAP: I2C: Fix the mismatch of pm_runtime enable and disable
On Wed, Jan 11, 2012 at 3:21 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. I remember seeing Felipe doing the reverse to musb here: http://marc.info/?l=linux-omapm=132432610700952w=2 so I'm confused here. Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 12d402c..abc7b5b 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1070,6 +1070,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1085,6 +1086,7 @@ omap_i2c_remove(struct platform_device *pdev) struct omap_i2c_dev *dev = platform_get_drvdata(pdev); struct resource *mem; + pm_runtime_disable(pdev-dev); platform_set_drvdata(pdev, NULL); free_irq(dev-irq, dev); -- 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 -- Gražvydas -- 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 v7 0/5] AT91: replace broken TWI driver i2c-at91.c
Hi, Carsten Behling wrote on 2011-12-28: I've tested this driver with the pca953x GPIO expander driver with a PCA9554. In the case of 8 GPIO pins (my case) i2c_smbus_read_byte_data(...) [...] I observed that reading out the GPIO status is one read delayed. The first read to a register from the pca953x driver does not result in a RXRDY interrupt and at91_twi_read_next_byte(...) is not called. Only the completion routine is triggered with a TXCOMP interrupt. Which SOC are you using? This is probably a hardware bug since on my at91sam9g45 i2c_smbus_read_byte_data() works reliably without any problems. Please check the errata and see if there is a useable workaround. If not, the driver should be disabled for your SOC. Additionally, I took a look at the status flags just after the control flags are set (in at91_do_twi_transfer(...), AT91_TWI_START|AT91_TWI_STOP for the one byte read). Surprisingly, the AT91_TWI_RXRDY flag is zero before the first register read and one for the following reads. According to the manual this flag should be zero after a read on AT91_TWI_RHR. Reading the AT91_TWI_RHR before the control flags are set to be sure that the AT91_TWI_RXRDY is cleared leads to a never occurring RXRDY interrupt. Again, this behavior does not conform to the datasheet, I suspect documented or undocumented errata... At91rm9200 has at least one erratum for which I imported a workaround from the old driver (which does not use interrupts). Niko -- 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 RFC] OMAP: I2C: Fix the mismatch of pm_runtime enable and disable
On Wednesday 11 January 2012 07:29 PM, Grazvydas Ignotas wrote: On Wed, Jan 11, 2012 at 3:21 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: Currently the i2c driver calls the pm_runtime_enable and never the disable. This may cause a warning when pm_runtime_enable checks for the count match.Attempting to fix the same by calling pm_runtime_disable in the error and the remove path. I remember seeing Felipe doing the reverse to musb here: http://marc.info/?l=linux-omapm=132432610700952w=2 so I'm confused here. Strange however I see many drivers doing the same in the kernel on greping . Besides I expect a warn to come up. Felipe could you explain the issue? Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 12d402c..abc7b5b 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1070,6 +1070,7 @@ err_unuse_clocks: omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); pm_runtime_put(dev-dev); iounmap(dev-base); + pm_runtime_disable(pdev-dev); err_free_mem: platform_set_drvdata(pdev, NULL); kfree(dev); @@ -1085,6 +1086,7 @@ omap_i2c_remove(struct platform_device *pdev) struct omap_i2c_dev *dev = platform_get_drvdata(pdev); struct resource *mem; + pm_runtime_disable(pdev-dev); platform_set_drvdata(pdev, NULL); free_irq(dev-irq, dev); -- 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 -- 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 Wed, 11 Jan 2012, Shubhrajyoti wrote: On Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote: 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. Paul I thought through it myself not very clear. - One way is to find some way for the dt to pass function pointer. Or maybe a flag that activates a static function / hwmod func. Will give this a little more thought and get back. I have not any answer right now. Well, if it makes you feel any better, no one else seems to have thought through it very much either :-( To me this is essentially implementing a bus-level (or really, integration-level) reset of the device. This seems to be a function that many other buses might support. So let's look at some of the other common Linux bus implementations. PCI has pci_reset_function() in drivers/pci/pci.c, which a handful of PCI-specific drivers call. USB has usb_reset_device() in drivers/usb/core/hub.c, also called by a handful of devices. So there's precedent for the use case. Incidentally, this is the kind of thing that ideally should be supported via a common function pointer in struct bus_type or maybe struct device. So rather than the driver calling pci_reset_function() or usb_reset_device(), it seems preferable for the driver to do something like: if (dev-bus-device_reset) dev-bus-device_reset(dev); It seems best to avoid binding a driver tightly to a particular bus whenever possible. ... Now to consider something like this from an OMAP perspective. In a rough approximation of an ideal world, much of the hwmod and omap_device code would live somewhere like drivers/omap_bus/. Our devices would be omap_device based rather than platform_device or of_device based. We could export omap_device_reset() and then the I2C driver could call this directly. We're at least a year away from this (if ever): we need PRM, CM, SCM drivers; we'd need to have a real omap_bus and omap_device that our drivers would use, unlike the faux omap_device we have now. Maybe the latter is never going to happen now due to the DT situation. So any solution that would depend on these steps as prerequisites might easily be delayed for an infinite amount of time. But let's say that a device_reset() function pointer existed inside the common struct bus_type in include/linux/device.h, as discussed above. From an OMAP perspective, we could simply set that to point to omap_device_reset() in the OMAP-specific device creation code or DT notifier callback code. PCI and USB code could set it to point to their own reset functions. Something like the code fragment above would be recommended for all device drivers to do an integration device reset. Anyway, just an idea. - Paul -- 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 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.
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?
- Paul
--
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
[PATCH v2] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for
mainline by Jon Hunter. A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and tpyically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
applies on Kevin's for_3.3/i2c/misc
drivers/i2c/busses/i2c-omap.c | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..6d59bc6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -508,6 +507,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG,
+ (OMAP_I2C_SYSTEST_ST_EN | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -632,6 +656,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.1
--
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
[PATCH v2] I2C: OMAP: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for
mainline by Jon Hunter. A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and tpyically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
applies on Kevin's for_3.3/i2c/misc
drivers/i2c/busses/i2c-omap.c | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..6d59bc6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK(1 0)
@@ -508,6 +507,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG,
+ (OMAP_I2C_SYSTEST_ST_EN | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -632,6 +656,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.1
--
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 RFC] I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
Shubhrajyoti D shubhrajy...@ti.com writes: The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. Make the omap_i2c_unidle/idle also depend on CONFIG_PM_RUNTIME flag. I probably should've done this when I initially cleaned up the callbacks, but since you're doing it... rather than move the functions within the file, just remove the functions and move the code into the runtime callbacks. Kevin -- 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: OMAP: Recover from Bus Busy condition
Shubhrajyoti D shubhrajy...@ti.com writes: From: Vikram Pandita vikram.pand...@ti.com In case a peripheral is driving SDA bus low (ie. a start condition), provide a constant clock output using the test mode of the OMAP I2C controller to try and clear the bus. Soft reset I2C controller after attempting the bus clear to ensure that controller is in a good state. Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for mainline by Jon Hunter. A couple differences from the original patch ... 1. Add a new function for bus clear 2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to output a permanent clock. This bit needs to be set and tpyically it would be set by the unidle function but this is not the case for all OMAP generations. 3. Program the SYSTEST setting only the bits we care about. However, restore SYSTEST registers to there original state as some OMAP generations do not implement perform a soft-reset. 4. Clear the CON register after performing the bus clear, so when we call the init function the controller is disabled and the init function will re-enable later. Cc: Kevin Hilman khil...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- Original patch can be found here: http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1 applies on Kevin's for_3.3/i2c/misc Please also explain how this was tested, and on what platforms. Thanks, Kevin -- 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: OMAP: Recover from Bus Busy condition
On Wednesday 11 January 2012 11:12 PM, Shubhrajyoti D wrote:
From: Vikram Pandita vikram.pand...@ti.com
I am reworking the patch on the latest changes.
Please ignore this.
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus
clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for
mainline by Jon Hunter. A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and tpyically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
applies on Kevin's for_3.3/i2c/misc
drivers/i2c/busses/i2c-omap.c | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..6d59bc6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -147,16 +147,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test
enable */
#define OMAP_I2C_SYSTEST_FREE(1 14) /* Free running
mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK (3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST (2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP (3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line
sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line
drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line
sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line
drive out */
-#endif
/* OCP_SYSSTATUS bit definitions */
#define SYSS_RESETDONE_MASK (1 0)
@@ -508,6 +507,31 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
}
/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+ * Per the I2C specification, if we are stuck in a bus busy state
+ * we can attempt a bus clear to try and recover the bus by sending
+ * at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+ * will output a continuous clock on SCL.
+ */
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG,
+ (OMAP_I2C_SYSTEST_ST_EN | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_reset(dev);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
+
+/*
* Low level master read/write transaction.
*/
static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
@@ -632,6 +656,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
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: OMAP: Recover from Bus Busy condition
On Thursday 12 January 2012 03:58 AM, Kevin Hilman wrote: Shubhrajyoti D shubhrajy...@ti.com writes: From: Vikram Pandita vikram.pand...@ti.com In case a peripheral is driving SDA bus low (ie. a start condition), provide a constant clock output using the test mode of the OMAP I2C controller to try and clear the bus. Soft reset I2C controller after attempting the bus clear to ensure that controller is in a good state. Based upon Vikram Pandita's patch from TI Android 3.0 kernel and modified for mainline by Jon Hunter. A couple differences from the original patch ... 1. Add a new function for bus clear 2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to output a permanent clock. This bit needs to be set and tpyically it would be set by the unidle function but this is not the case for all OMAP generations. 3. Program the SYSTEST setting only the bits we care about. However, restore SYSTEST registers to there original state as some OMAP generations do not implement perform a soft-reset. 4. Clear the CON register after performing the bus clear, so when we call the init function the controller is disabled and the init function will re-enable later. Cc: Kevin Hilman khil...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- Original patch can be found here: http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1 applies on Kevin's for_3.3/i2c/misc Please also explain how this was tested, and on what platforms. Please ignore will resend. Thanks, Kevin -- 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
[PATCH] i2c-eg20t: use i2c_add_numbered_adapter to get a fixed bus number
For EG20T and ML7213 IOH, the i2c controller numbers are fixed, using
fixed bus number will make it much easier for platform code to use
i2c_register_board_info() to register i2c devices.
Signed-off-by: Feng Tang feng.t...@intel.com
---
drivers/i2c/busses/i2c-eg20t.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
index 18936ac..079435b 100644
--- a/drivers/i2c/busses/i2c-eg20t.c
+++ b/drivers/i2c/busses/i2c-eg20t.c
@@ -918,7 +918,9 @@ static int __devinit pch_i2c_probe(struct pci_dev *pdev,
pch_adap-dev.parent = pdev-dev;
pch_i2c_init(adap_info-pch_data[i]);
- ret = i2c_add_adapter(pch_adap);
+
+ pch_adap-nr = i;
+ ret = i2c_add_numbered_adapter(pch_adap);
if (ret) {
pch_pci_err(pdev, i2c_add_adapter[ch:%d] FAILED\n, i);
goto err_add_adapter;
--
1.7.1
--
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
