[PATCH 1/2] i2c: omap: convert to module_platform_driver()
The OMAP I2C driver has a relation to pinctrl-single driver. As result,
its probe will be deferred during system boot until late init time,
because the pinctrl-single is initizalized as moudle/device init time.
This, in turn, will delay initialization of all I2C devices (like mfd,
I2C regulators and etc.) and cause boot delay (more over, it can broken
initialization of drivers which are not ready to use deferred probe
mechanism yet, for example DSS).
There are no sense to keep OMAP I2C initialization on subsys init layer
any more, hence shift it to module/device layer where the i2c --
pinctrl-single dependency is resolved in drivers/Makefile now.
Cc: Wolfram Sang w...@the-dreams.de
Cc: Ben Dooks (embedded platforms) ben-li...@fluff.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: linux-o...@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4cc2f05..70d3fed 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1342,19 +1342,7 @@ static struct platform_driver omap_i2c_driver = {
},
};
-/* I2C may be needed to bring up other drivers */
-static int __init
-omap_i2c_init_driver(void)
-{
- return platform_driver_register(omap_i2c_driver);
-}
-subsys_initcall(omap_i2c_init_driver);
-
-static void __exit omap_i2c_exit_driver(void)
-{
- platform_driver_unregister(omap_i2c_driver);
-}
-module_exit(omap_i2c_exit_driver);
+module_platform_driver(omap_i2c_driver);
MODULE_AUTHOR(MontaVista Software, Inc. (and others));
MODULE_DESCRIPTION(TI OMAP I2C bus adapter);
--
1.7.9.5
--
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: Re: Re: [PATCH] I2C: Change the value of octeon i2c adapter timeout value
Hi, what mail client do you use? It seems to break message threading on my side :( Have you been writing to EEPROMS? Their erase/write cycle might be longer. But I am not forcing you to change the value, just giving some suggestions. My board has i2c mux, temp sensor, eeprom. And I added some debugging code for measuring i2c response time as below and run i2c operation for each device. The maximum respeonse time was 500usec(under 1msec). So 20 msec is enough for adapter timeout. Well, OK, I don't mind. We can increase it later if needed. Applied to for-next, thanks! Please have a look later how I changed your commit messages to see the preferred style. -- 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-designware: fix RX FIFO overrun
On Mon, Apr 22, 2013 at 03:08:59PM +0100, Josef Ahmad wrote: From a969728248c3b439dc97a69e7dac133b5efa34e7 Mon Sep 17 00:00:00 2001 From: Josef Ahmad josef.ah...@linux.intel.com Date: Fri, 19 Apr 2013 17:28:10 +0100 Subject: [PATCH] i2c-designware: fix RX FIFO overrun i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive to/from the bus into the TX FIFO. For master-rx transactions, the maximum amount of data that can be received is calculated depending solely on TX and RX FIFO load. This is racy - TX FIFO may contain master-rx data yet to be processed, which will eventually land into the RX FIFO. This data is not taken into account and the function may request more data than the controller is actually capable of storing. This patch ensures the driver takes into account the outstanding master-rx data in TX FIFO to prevent RX FIFO overrun. Signed-off-by: Josef Ahmad josef.ah...@linux.intel.com Acked-by: Mika Westerberg mika.westerb...@linux.intel.com This driver had a major cleanup meanwhile. Could you rebase your patch on top of my for-next branch? I guess this version should make it into stable? -- 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-xiic.c must always write 16-bit words to TX_FIFO
On Mon, Apr 22, 2013 at 03:34:39PM -0400, Steven A. Falco wrote: The TX_FIFO register is 10 bits wide. The lower 8 bits are the data to be written, while the upper two bits are flags to indicate stop/start. The driver apparently attempted to optimize write access, by only writing a byte in those cases where the stop/start bits are zero. However, we have seen cases where the lower byte is duplicated onto the upper byte by the hardware, which causes inadvertent stop/starts. This patch changes the write access to the transmit FIFO to always be 16 bits wide. Signed off by: Steven A. Falco sfa...@harris.com Applied to for-next, and added stable, thanks! -- 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 0/2] OMAP: fix boot sequence
* Grygorii Strashko grygorii.stras...@ti.com [130423 06:25]: Hi There are two public discussions now related to OMAP boot and drivers initialization issues: Multiple issues with omap4 panda es in linux next http://www.spinics.net/lists/linux-omap/msg90241.html [BUG] omap: mfd/regulator: twl/core: init order http://www.spinics.net/lists/linux-omap/msg89980.html In both cases there are pinctrl-single/I2C/MFD/Regulators initailization issue: - regulators are not initialized because of twl, - twl is not initialized because of I2C, - I2C is not initialized because of pinctrl-single, - pinctrl-single is initialized at mudule/device init time. So, most everything will be shifted at late_initcall time. This may cause boot delay (more over, it can broken initialization of drivers which are not ready to use deferred probe mechanism yet, for example DSS). Introduced pathes shift I2C and TWL iniialization to module/device init layer instead of subsys init layer where initialization dependencies resolved indirectly in drivers/Makefile now. Grygorii Strashko (2): i2c: omap: convert to module_platform_driver() mfd: twl-core: convert to module_i2c_driver() drivers/i2c/busses/i2c-omap.c | 14 +- drivers/mfd/twl-core.c| 12 +--- 2 files changed, 2 insertions(+), 24 deletions(-) Thanks, I have few questions: 1. It seems that the real fix to the issues we're seeing is to make the broken drivers to support -EPROBE_DEFER? 2. If so, can these be merged later on as clean-up? 3. Can these two patches be merged separately without breaking things? Regards, Tony -- 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 0/2] OMAP: fix boot sequence
On 04/23/2013 08:34 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [130423 06:25]: Hi There are two public discussions now related to OMAP boot and drivers initialization issues: Multiple issues with omap4 panda es in linux next http://www.spinics.net/lists/linux-omap/msg90241.html [BUG] omap: mfd/regulator: twl/core: init order http://www.spinics.net/lists/linux-omap/msg89980.html In both cases there are pinctrl-single/I2C/MFD/Regulators initailization issue: - regulators are not initialized because of twl, - twl is not initialized because of I2C, - I2C is not initialized because of pinctrl-single, - pinctrl-single is initialized at mudule/device init time. So, most everything will be shifted at late_initcall time. This may cause boot delay (more over, it can broken initialization of drivers which are not ready to use deferred probe mechanism yet, for example DSS). Introduced pathes shift I2C and TWL iniialization to module/device init layer instead of subsys init layer where initialization dependencies resolved indirectly in drivers/Makefile now. Grygorii Strashko (2): i2c: omap: convert to module_platform_driver() mfd: twl-core: convert to module_i2c_driver() drivers/i2c/busses/i2c-omap.c | 14 +- drivers/mfd/twl-core.c| 12 +--- 2 files changed, 2 insertions(+), 24 deletions(-) Thanks, I have few questions: 1. It seems that the real fix to the issues we're seeing is to make the broken drivers to support -EPROBE_DEFER? yes. 2. If so, can these be merged later on as clean-up? if i understand Tomi correctly, he has problems with DSS updating to use -EPROBE_DEFER, so this is rather fix than clean-up. But need confirmation that it's true from him. 3. Can these two patches be merged separately without breaking things? I think, yes. Regards, Tony -- 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: Re: Re: Re: [PATCH] I2C: Change the value of octeon i2c adapter timeout value
Sender : Wolfram Sangw...@the-dreams.de Date : 2013-04-24 01:27 (GMT+09:00) Title : Re: Re: Re: [PATCH] I2C: Change the value of octeon i2c adapter timeout value Well, OK, I don't mind. We can increase it later if needed. Applied to for-next, thanks! Please have a look later how I changed your commit messages to see the preferred style. Yes, i will check your commit message and use for reference for the next-time. Thanks.
