Message ID | 1340896292-12112-1-git-send-email-shubhrajyoti@ti.com |
---|---|
State | New |
Headers | show |
Hi, On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote: > Use INIT_COMPLETION instead of init_completion in transfer. > > Reviewed-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > --- > - Add Felipe's reviewed-by tag > > drivers/i2c/busses/i2c-omap.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index b9915bb..6d05f18 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -490,7 +490,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, > w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; > omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); > > - init_completion(&dev->cmd_complete); > + INIT_COMPLETION(dev->cmd_complete); > dev->cmd_err = 0; > > w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; > @@ -999,6 +999,7 @@ omap_i2c_probe(struct platform_device *pdev) > } > > platform_set_drvdata(pdev, dev); > + init_completion(&dev->cmd_complete); It should be INIT_COMPLETION here too. Thanks Kishon
No, it should be init_completion(&dev->cmd_complete); in probe, we need to initialize the wait queue, which will be used when using "complete(......)" -----Original Message----- From: linux-i2c-owner@vger.kernel.org [mailto:linux-i2c-owner@vger.kernel.org] On Behalf Of ABRAHAM, KISHON VIJAY Sent: Friday, June 29, 2012 12:03 AM To: Shubhrajyoti D Cc: linux-omap@vger.kernel.org; linux-i2c@vger.kernel.org; linux-arm-kernel@lists.infradead.org; ben-linux@fluff.org; tony@atomide.com; w.sang@pengutronix.de Subject: Re: [PATCHv11 3/6] i2c: omap: Do not initialise the completion everytime Hi, On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote: > Use INIT_COMPLETION instead of init_completion in transfer. > > Reviewed-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > --- > - Add Felipe's reviewed-by tag > > drivers/i2c/busses/i2c-omap.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c > b/drivers/i2c/busses/i2c-omap.c index b9915bb..6d05f18 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -490,7 +490,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter > *adap, > w |= OMAP_I2C_BUF_RXFIF_CLR | OMAP_I2C_BUF_TXFIF_CLR; > omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, w); > > - init_completion(&dev->cmd_complete); > + INIT_COMPLETION(dev->cmd_complete); > dev->cmd_err = 0; > > w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT; @@ > -999,6 +999,7 @@ omap_i2c_probe(struct platform_device *pdev) > } > > platform_set_drvdata(pdev, dev); > + init_completion(&dev->cmd_complete); It should be INIT_COMPLETION here too. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote: > This is a minimal cleanup series. If there are no further comments can this series be queued? > > The patch series does the following > > - Bus busy recovery mechanism. > - Make the i2c use SET_RUNTIME_PM_OPS > - Use INIT_COMPLETION instead of init_completion > - the reset patch is dropped will try to rework it as per the > review comments recieved. > > > This applies on Wolfram's i2c-embedded/for-next branch. > > Functional testing on omap4430 , 4460 panda and omap3sdp. > > > The following changes since commit 0f009a914b40be8786fa67b1f4345cacc263b48c: > > i2c: tegra: make all resource allocation through devm_* (2012-06-13 16:01:38 +0200) > > are available in the git repository at: > git://gitorious.org/linus-tree/linus-tree.git for_next/omap/minimal_cleanup > > Jon Hunter (1): > i2c: omap: Correct I2C revision for OMAP3 > > Shubhrajyoti D (4): > i2c: omap: Optimise the remove code > i2c: omap: Use SET_RUNTIME_PM_OPS > i2c: omap: Do not initialise the completion everytime > i2c: omap: Remove the definition of SYSS_RESETDONE_MASK > > Vikram Pandita (1): > i2c: omap: Recover from Bus Busy condition > > drivers/i2c/busses/i2c-omap.c | 60 ++++++++++++++++++++++++++++------------ > 1 files changed, 42 insertions(+), 18 deletions(-) > > -- > 1.7.5.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 28, 2012 at 08:41:27PM +0530, Shubhrajyoti D wrote: > The omap_i2c_remove function may not be needed after > device exit so the memory could be freed. > > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Changed the title from "optimise" to "annotate" and pushed to next.
On Thu, Jun 28, 2012 at 08:41:28PM +0530, Shubhrajyoti D wrote: > Use SET_RUNTIME_PM_OPS macro to set runtime functions. > > Acked-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Applied to next, thanks.
On Thu, Jun 28, 2012 at 08:41:29PM +0530, Shubhrajyoti D wrote: > Use INIT_COMPLETION instead of init_completion in transfer. > > Reviewed-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Applied to next, thanks.
On Thu, Jun 28, 2012 at 08:41:30PM +0530, Shubhrajyoti D wrote: > Remove the definition of SYSS_RESETDONE_MASK and use the > one in omap_hwmod.h. > > Reviewed-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > --- > - Add Felipe's reviewed by tag > > drivers/i2c/busses/i2c-omap.c | 4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 6d05f18..4bbf288 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -43,6 +43,7 @@ > #include <linux/slab.h> > #include <linux/i2c-omap.h> > #include <linux/pm_runtime.h> > +#include <plat/omap_hwmod.h> Hmmm, so far the driver has no plat/mach dependencies and now this gets added. Need to think about it a bit more...
On Thu, Jun 28, 2012 at 08:41:31PM +0530, Shubhrajyoti D wrote: > From: Jon Hunter <jon-hunter@ti.com> > > The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C > revision is the same for 3430 and 3530. However, the OMAP3630 device has the > same I2C revision as OMAP4. Correct the revision definition to reflect this. > > This patch is based on work done by Jon Hunter <jon-hunter@ti.com> > Changes from his patch > - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530 > > Reviewed-by: Felipe Balbi <balbi@ti.com> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Applied to next, thanks.
On Thu, Jun 28, 2012 at 08:41:32PM +0530, Shubhrajyoti D wrote: > From: Vikram Pandita <vikram.pandita@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.pandita@ti.com> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> This has to wait a little bit until I can spend time on the recovery framework (which is still in the queue, sadly :( ). There might be some consolidation.
On Mon, Jul 09, 2012 at 05:17:07PM +0530, Shubhrajyoti Datta wrote: > On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote: > > This is a minimal cleanup series. > > If there are no further comments can this series be queued? I just applied a few of them. BTW I get a build warning when compiling the kernel, maybe someone is interested. It is not related to the patches, though. === WARNING: arch/arm/mach-omap2/built-in.o(.data+0x2b5c0): Section mismatch in reference from the variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown) The variable rx51_si4713_dev references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console === I think this is what I'll pull in for the next merge window. The big OMAP cleanup (latest version from 3. July) would then go in early into -next for 3.7. Is that OK with the omap-people? Also, thanks to Shubhrajyoti Datta for reviewing other patches on the i2c-list, much appreciated. Thanks, Wolfram
On Thursday 12 July 2012 05:52 PM, Wolfram Sang wrote: >> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> >> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> >> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > This has to wait a little bit until I can spend time on the recovery > framework (which is still in the queue, sadly :( ). There might be some > consolidation. OK thanks.
On Thursday 12 July 2012 05:51 PM, Wolfram Sang wrote: >> - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530 >> > >> > Reviewed-by: Felipe Balbi <balbi@ti.com> >> > Signed-off-by: Jon Hunter <jon-hunter@ti.com> >> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > Applied to next, thanks. Thanks.
On Thursday 12 July 2012 05:50 PM, Wolfram Sang wrote: >> +#include <plat/omap_hwmod.h> > Hmmm, so far the driver has no plat/mach dependencies and now this gets > added. Need to think about it a bit more... OK .
On Thursday 12 July 2012 05:49 PM, Wolfram Sang wrote: >> Reviewed-by: Felipe Balbi <balbi@ti.com> >> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > Applied to next, thanks. Thanks
On Thursday 12 July 2012 05:48 PM, Wolfram Sang wrote: > On Thu, Jun 28, 2012 at 08:41:27PM +0530, Shubhrajyoti D wrote: >> The omap_i2c_remove function may not be needed after >> device exit so the memory could be freed. >> >> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > Changed the title from "optimise" to "annotate" and pushed to next. Thanks for fixing that. >
On Thursday 12 July 2012 06:22 PM, Wolfram Sang wrote: > On Mon, Jul 09, 2012 at 05:17:07PM +0530, Shubhrajyoti Datta wrote: >> On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote: >>> This is a minimal cleanup series. >> If there are no further comments can this series be queued? > I just applied a few of them. BTW I get a build warning when compiling the > kernel, maybe someone is interested. It is not related to the patches, though. OK could check that. > > === > > WARNING: arch/arm/mach-omap2/built-in.o(.data+0x2b5c0): Section mismatch in reference from the variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown) > The variable rx51_si4713_dev references > the (unknown reference) __initdata (unknown) > If the reference is valid then annotate the > variable with __init* or __refdata (see linux/init.h) or name the variable: > *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console > > === > > I think this is what I'll pull in for the next merge window. The big OMAP > cleanup (latest version from 3. July) would then go in early into -next for > 3.7. Is that OK with the omap-people? > > Also, thanks to Shubhrajyoti Datta for reviewing other patches on the > i2c-list, much appreciated. Thanks, > Thanks, > > Wolfram >