Re: [PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
Ben Dooks ben-...@fluff.org writes: On Tue, Jul 05, 2011 at 12:00:56PM -0700, Kevin Hilman wrote: Hi Ben, On Mon, 2011-06-27 at 15:15 -0700, Kevin Hilman wrote: On Mon, 2011-06-27 at 15:12 -0700, Kevin Hilman wrote: Ping. I don't see this in linux-next yet. Are you planning to queue this for v3.1? Oops, pushed send too soon on this... As this series touches various data files in arch/arm/mach-omap2/* and we have a handful of other changes to that data for this merge window, I think it would be better for conflict avoidance if this series is merged via Tony's linux-omap tree. With your Ack, we'll merge it via OMAP. I see that the same day I sent this, you merged it into your next-i2c branch. Guess I was too late with my request. As I mentioned above, we will have several conflicts with the arch/arm/mach-omap2 changes in this series, so we would prefer to merge them via the OMAP tree if at all possible so we can properly handle the conflicts. Do you mind dropping it from your next-i2c so we can merge it via linux-omap (with your Ack.) Yes, and if you could indicate all the other omap i2c patches and I'll add my ack to yours. Acked-by: Ben Dooks ben-li...@fluff.org Thanks, I will refresh/repost any remaining OMAP I2C patches today and let you know. 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 v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Tue, Jul 05, 2011 at 12:00:56PM -0700, Kevin Hilman wrote: Hi Ben, On Mon, 2011-06-27 at 15:15 -0700, Kevin Hilman wrote: On Mon, 2011-06-27 at 15:12 -0700, Kevin Hilman wrote: Ping. I don't see this in linux-next yet. Are you planning to queue this for v3.1? Oops, pushed send too soon on this... As this series touches various data files in arch/arm/mach-omap2/* and we have a handful of other changes to that data for this merge window, I think it would be better for conflict avoidance if this series is merged via Tony's linux-omap tree. With your Ack, we'll merge it via OMAP. I see that the same day I sent this, you merged it into your next-i2c branch. Guess I was too late with my request. As I mentioned above, we will have several conflicts with the arch/arm/mach-omap2 changes in this series, so we would prefer to merge them via the OMAP tree if at all possible so we can properly handle the conflicts. Do you mind dropping it from your next-i2c so we can merge it via linux-omap (with your Ack.) Yes, and if you could indicate all the other omap i2c patches and I'll add my ack to yours. Acked-by: Ben Dooks ben-li...@fluff.org Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- 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 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Mon, 2011-06-27 at 15:12 -0700, Kevin Hilman wrote: Ping. I don't see this in linux-next yet. Are you planning to queue this for v3.1? Oops, pushed send too soon on this... As this series touches various data files in arch/arm/mach-omap2/* and we have a handful of other changes to that data for this merge window, I think it would be better for conflict avoidance if this series is merged via Tony's linux-omap tree. With your Ack, we'll merge it via OMAP. 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 v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, 2011-06-15 at 16:33 -0700, Kevin Hilman wrote: Hi Ben, Ben Dooks ben-...@fluff.org writes: On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. Correct, this is a rework of functionality, not a set of fixes. This series is targeted for the next release (v3.1), not for fixes (v3.0-rc). I was requesting for it to be included in your queue for -next and for the next merge window. Tony has already been merging this in his omap-testing branch so it is has been getting lots of testing on OMAP platforms already. Ping. I don't see this in linux-next yet. Are you planning to queue this for v3.1? 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 v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. It's also available here for pulling: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.1/i2c-andy Original cover letter from Andy below: The following series removes cpu_...() usage completely from the omap-i2c driver by having decisions about functional implementation choices in the SoC held in cpu-specific hwmod tables that are already established, or for OMAP1 where there is no hwmod, set at OMAP1-specific i2c bus addition time. Along the way it solves two issues with the existing implementation, that only 16-bit accesses are documented to be allowed to the I2C peripheral unit, and that due to a confusion in the existing driver about whether it is faced with a newer IP version on OMAP3530, currently it writes to a random non-existent I2C register at times on that platform. As noted above there's rather lot of functionality change to go in with fixing bugs. Is there a possibility of just fixing as many problems without making a pile of changes? The patch series is quite extended from the first try thanks to comments from Benoit Cousson. This 3rd try is based on 2.6.38-rc8 as requested. Andy Green (18): I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c I2C: OMAP2+: Name registers in I2C IP V2 only accordingly I2C: OMAP2+: Introduce I2C IP versioning constants I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision I2C: OMAP: add rev to omap i2c platform data I2C: OMAP1: set IP revision in platform data I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added I2C: OMAP2+: use platform_data ip revision to select register map I2C: OMAP2+: Solve array bounds overflow error on i2c idle I2C: OMAP2+: address confused probed version naming I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data I2C: OMAP2+: Pass flags up to omap i2c platform_data as well I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr I2C: OMAP1: set i2c unit feature implementation flags in platform data I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info arch/arm/mach-omap2/omap_hwmod_2420_data.c |8 ++- arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 - arch/arm/plat-omap/i2c.c | 27 arch/arm/plat-omap/include/plat/i2c.h |3 +- drivers/i2c/busses/i2c-omap.c | 100 +++- include/linux/i2c-omap.h | 29 8 files changed, 153 insertions(+), 51 deletions(-) -- 1.7.4 -- 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 -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- 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 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, 15 Jun 2011, Ben Dooks wrote: On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. What do you mean, exactly? The merge window, as opposed to the -rc period, is good for functionality changes, no? Those patches have been out for quite a while, and they got quite extensive testing in the OMAP tree, and in the kernel included with the Linaro 11.05 release as well. Nicolas -- 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 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
Hi Ben, Ben Dooks ben-...@fluff.org writes: On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. Correct, this is a rework of functionality, not a set of fixes. This series is targeted for the next release (v3.1), not for fixes (v3.0-rc). I was requesting for it to be included in your queue for -next and for the next merge window. Tony has already been merging this in his omap-testing branch so it is has been getting lots of testing on OMAP platforms already. 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 v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. I'll have a look through this set as soon as possible. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. It's also available here for pulling: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.1/i2c-andy Original cover letter from Andy below: The following series removes cpu_...() usage completely from the omap-i2c driver by having decisions about functional implementation choices in the SoC held in cpu-specific hwmod tables that are already established, or for OMAP1 where there is no hwmod, set at OMAP1-specific i2c bus addition time. Along the way it solves two issues with the existing implementation, that only 16-bit accesses are documented to be allowed to the I2C peripheral unit, and that due to a confusion in the existing driver about whether it is faced with a newer IP version on OMAP3530, currently it writes to a random non-existent I2C register at times on that platform. The patch series is quite extended from the first try thanks to comments from Benoit Cousson. This 3rd try is based on 2.6.38-rc8 as requested. Andy Green (18): I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c I2C: OMAP2+: Name registers in I2C IP V2 only accordingly I2C: OMAP2+: Introduce I2C IP versioning constants I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision I2C: OMAP: add rev to omap i2c platform data I2C: OMAP1: set IP revision in platform data I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added I2C: OMAP2+: use platform_data ip revision to select register map I2C: OMAP2+: Solve array bounds overflow error on i2c idle I2C: OMAP2+: address confused probed version naming I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data I2C: OMAP2+: Pass flags up to omap i2c platform_data as well I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each cpu_... test I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attr I2C: OMAP1: set i2c unit feature implementation flags in platform data I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info arch/arm/mach-omap2/omap_hwmod_2420_data.c |8 ++- arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 - arch/arm/plat-omap/i2c.c | 27 arch/arm/plat-omap/include/plat/i2c.h |3 +- drivers/i2c/busses/i2c-omap.c | 100 +++- include/linux/i2c-omap.h | 29 8 files changed, 153 insertions(+), 51 deletions(-) -- 1.7.4 -- 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 -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- 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
