Re: [PATCH] i2c-eg20t: use i2c_add_numbered_adapter to get a fixed bus number
On 1/12/2012 1:08 PM, Feng Tang wrote:
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 Tangfeng.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;
Reviewd By: Rajeev Kumar rajeev-dlh.ku...@st.com
--
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: [PATCH RFC] OMAP: I2C: Fix the mismatch of pm_runtime enable and disable
On Wed, Jan 11, 2012 at 4:25 PM, Shubhrajyoti shubhrajy...@ti.com wrote: 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? When do you see the warning? kfree(dev) should disable runtime pm, but without waking up the device. -- Felipe Contreras -- 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
[i2c-mpc.c] adding entry for mpc8360
Hello,
I am wondering if it is okay to add .compatible entries for mpc8360 and declare
its data structure
to mpc-i2c.c
something like this:
{.compatible = fsl,mpc8360-i2c, .data = mpc_i2c_data_8360, },
static struct mpc_i2c_data mpc_i2c_data_8360 __devinitdata = {
.setup = mpc_i2c_setup_8xxx,
};
or is the intended approach to match the closest thing to your CPU (in this
case mpc8313) ?
--
Richard Retanubun
--
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
[GIT PULL] i2c updates for Linux 3.3
Hi Linus, Please pull i2c subsystem updates for Linux 3.3 from: git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git i2c-for-linus MAINTAINERS|4 +++ drivers/i2c/busses/i2c-ali1535.c | 38 +++ drivers/i2c/busses/i2c-ali1563.c |2 +- drivers/i2c/busses/i2c-ali15x3.c |2 +- drivers/i2c/busses/i2c-amd756.c|2 +- drivers/i2c/busses/i2c-amd8111.c |2 +- drivers/i2c/busses/i2c-at91.c | 17 +--- drivers/i2c/busses/i2c-au1550.c| 13 +- drivers/i2c/busses/i2c-cpm.c | 13 +- drivers/i2c/busses/i2c-designware-pcidrv.c |2 +- drivers/i2c/busses/i2c-eg20t.c |2 +- drivers/i2c/busses/i2c-highlander.c| 13 +- drivers/i2c/busses/i2c-hydra.c |2 +- drivers/i2c/busses/i2c-i801.c |2 +- drivers/i2c/busses/i2c-ibm_iic.c | 13 +- drivers/i2c/busses/i2c-intel-mid.c |2 +- drivers/i2c/busses/i2c-iop3xx.c| 16 +--- drivers/i2c/busses/i2c-isch.c | 13 +- drivers/i2c/busses/i2c-ixp2000.c | 13 +- drivers/i2c/busses/i2c-mpc.c | 13 +- drivers/i2c/busses/i2c-mv64xxx.c | 15 +-- drivers/i2c/busses/i2c-nforce2.c |4 +- drivers/i2c/busses/i2c-ocores.c| 17 +--- drivers/i2c/busses/i2c-octeon.c| 16 +--- drivers/i2c/busses/i2c-pasemi.c|2 +- drivers/i2c/busses/i2c-pca-platform.c | 14 +- drivers/i2c/busses/i2c-piix4.c |2 +- drivers/i2c/busses/i2c-pmcmsp.c| 17 +--- drivers/i2c/busses/i2c-powermac.c | 19 + drivers/i2c/busses/i2c-pxa-pci.c |2 +- drivers/i2c/busses/i2c-sh7760.c| 13 +- drivers/i2c/busses/i2c-simtec.c| 18 +--- drivers/i2c/busses/i2c-sis5595.c |6 ++-- drivers/i2c/busses/i2c-sis630.c|8 - drivers/i2c/busses/i2c-sis96x.c|2 +- drivers/i2c/busses/i2c-via.c |2 +- drivers/i2c/busses/i2c-viapro.c|9 -- drivers/i2c/busses/i2c-xiic.c | 18 +--- drivers/i2c/busses/scx200_acb.c|2 +- drivers/i2c/i2c-dev.c | 13 +++-- drivers/i2c/muxes/gpio-i2cmux.c| 13 +- 41 files changed, 92 insertions(+), 304 deletions(-) --- Axel Lin (3): i2c: Convert to DEFINE_PCI_DEVICE_TABLE i2c/busses: Use module_platform_driver() i2c/gpio-i2cmux: Convert to use module_platform_driver() Jean Delvare (2): i2c: Fix error value returned by several bus drivers MAINTAINERS: List i2c-omap and i2c-davinci drivers Thomas Meyer (1): i2c-dev: Use memdup_user Wolfram Sang (1): MAINTAINERS: i2c: Add third maintainer corentin.labbe (1): i2c-ali1535: enable SPARC support Thanks, -- Jean Delvare -- 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: SiByte: Convert the driver to make use of interrupts
On Tue, Jan 10, 2012 at 9:38 AM, Jean Delvare kh...@linux-fr.org wrote: On Mon, 31 Oct 2011 10:53:54 +0100, Jean Delvare wrote: On Sat, 3 Sep 2011 10:30:36 +0200, Jean Delvare wrote: Please address my concerns where you agree and send an updated patch. Matt, care to send an updated patch addressing my concerns? Otherwise it will be lost again. It's been 3 more months. Matt (or anyone else who cares and has access to the hardware), please send an updated patch or I'll have to drop it. -- Jean Delvare I'll fix it up and resend the next time I'm working on the related mips stuff. It's hard to prioritize volunteer work for hardware you and two other people have. :) Matt -- 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 Thu, 12 Jan 2012, Cousson, Benoit wrote:
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.
Yes, that's right. In general, cross-device dependencies with no
infrastructural consequences should be handled by EXPORT_SYMBOL() between
driver code.
- 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 2/2] 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.
I acknowledge the contributions and suggestions of Jon and Hemant.
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 typically 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.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
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
---
drivers/i2c/busses/i2c-omap.c | 33 ++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3bfb1ae..fed9488 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)
@@ -360,6 +359,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
dev-westate);
}
}
+ return 0;
}
static int omap_i2c_init(struct omap_i2c_dev *dev)
@@ -512,6 +512,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,
@@ -638,6 +663,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
[PATCHv9 0/2] I2C driver updates
The patch series does the following - Removes the reset from probe and inplements a seperate function. - Removes the reset from init as hwmod does it. - The second patch inplements the recovery from bus busy condition Tested on omap4sdp and omap3430 applies to Kevin's for_3.3/i2c/misc Shubhrajyoti D (1): OMAP : I2C : Remove reset at init Vikram Pandita (1): I2C: OMAP: Recover from bus busy condition drivers/i2c/busses/i2c-omap.c | 53 +--- 1 files changed, 43 insertions(+), 10 deletions(-) -- 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
[PATCHv9 1/2] OMAP : I2C : Remove reset at init
The reset in the driver at init is not needed anymore as the
following patch has removed the HWMOD_INIT_NO_RESET flag.
6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup]
This patch does the following
-removes the reset from the probe and implements a omap_i2c_reset
function to reset.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
omap_i2c_reset is added in those places to effect the reset.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..3bfb1ae 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -310,15 +310,9 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
}
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 1200;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -366,6 +360,16 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev-westate);
}
}
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 1200;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
@@ -590,6 +594,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (r == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
+ omap_i2c_reset(dev);
return -ETIMEDOUT;
}
@@ -600,6 +605,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
omap_i2c_init(dev);
+ omap_i2c_reset(dev);
return -EIO;
}
--
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: [i2c-mpc.c] adding entry for mpc8360
Hello,
I added the devicetree-discuss ml.
On 01/12/2012 04:34 PM, Richard Retanubun wrote:
Hello,
I am wondering if it is okay to add .compatible entries for mpc8360 and
declare its data structure
to mpc-i2c.c
something like this:
{.compatible = fsl,mpc8360-i2c, .data = mpc_i2c_data_8360, },
static struct mpc_i2c_data mpc_i2c_data_8360 __devinitdata = {
.setup = mpc_i2c_setup_8xxx,
};
or is the intended approach to match the closest thing to your CPU (in
this case mpc8313) ?
Yes, it is intended to use the name of the compatible device, see:
http://lxr.linux.no/#linux+v3.2.1/arch/powerpc/boot/dts/kmeter1.dts#L69
Wolfgang
--
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
