Re: [PATCH 0/1] Group and resource assignments for TWL4030
On Fri, Feb 13, 2009 at 09:55:21PM +0100, ext David Brownell wrote: On Tuesday 10 February 2009, Peter 'p2' De Schrijver wrote: This patch introduces support for board specific group assignments of TWL4030 resources. The resource type and type2 fields can also be specified. Do we have any real examples yet of needing to assign resources to anything other than P1 (processor)? Yes. On our custom hardware we use it to assign CLKEN to P3. Cheers, Peter. -- goa is a state of mind -- 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
Re: [PATCH 1/1] Allow I2C_OMAP to compile as a module.
On Fri, 13 Feb 2009 14:21:00 -0800 Tony Lindgren t...@atomide.com wrote: Subject needs a ARM: OMAP: prefix, otherwise ok from me. Acked-by: Jarkko Nikula jarkko.nik...@nokia.com Sounds like a fix, except I posted a shorter version of the patch that should do the trick (untested). Attached here too for reference. Tony's version does not fix the issue since obj-$(CONFIG_I2C_OMAP) below still tries to compile arch/arm/plat-omap/i2c.c as a module. -obj-$(CONFIG_I2C_OMAP) += i2c.o + +ifneq ($(CONFIG_I2C_OMAP),) + obj-$(CONFIG_I2C_OMAP) += i2c.o +endif Problem was that drivers/i2c/busses/i2c-omap.c can be module but arch/arm/plat-omap/i2c.c cannot since it is for early board initialization code. -- Jarkko -- 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
Re: [PATCH 1/1] Allow I2C_OMAP to compile as a module.
On Sun, 15 Feb 2009 21:35:59 +0200 Jarkko Nikula jhnik...@gmail.com wrote: Tony's version does not fix the issue since obj-$(CONFIG_I2C_OMAP) below still tries to compile arch/arm/plat-omap/i2c.c as a module. -obj-$(CONFIG_I2C_OMAP) += i2c.o + +ifneq ($(CONFIG_I2C_OMAP),) + obj-$(CONFIG_I2C_OMAP) += i2c.o +endif And build works if obj-y rule is used instead -obj-$(CONFIG_I2C_OMAP) += i2c.o + +ifneq ($(CONFIG_I2C_OMAP),) + obj-y += i2c.o +endif Good. Patch can be made to touch only single file and add only three new lines. -- Jarkko -- 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
Re: [PATCH 1/1] Allow I2C_OMAP to compile as a mo dule.
Hi, On Sun, 15 Feb 2009 21:35:59 +0200, Jarkko Nikula jhnik...@gmail.com wrote: On Fri, 13 Feb 2009 14:21:00 -0800 Tony Lindgren t...@atomide.com wrote: Subject needs a ARM: OMAP: prefix, otherwise ok from me. Acked-by: Jarkko Nikula jarkko.nik...@nokia.com Sounds like a fix, except I posted a shorter version of the patch that should do the trick (untested). Attached here too for reference. Tony's version does not fix the issue since obj-$(CONFIG_I2C_OMAP) below still tries to compile arch/arm/plat-omap/i2c.c as a module. -obj-$(CONFIG_I2C_OMAP) += i2c.o + +ifneq ($(CONFIG_I2C_OMAP),) + obj-$(CONFIG_I2C_OMAP) += i2c.o +endif Problem was that drivers/i2c/busses/i2c-omap.c can be module but arch/arm/plat-omap/i2c.c cannot since it is for early board initialization code. why don't you: -obj-$(CONFIG_I2C_OMAP) += i2c.o +obj-y += i2c.o It's quite possible that we will need i2c anyways in most boards. And for the ones who won't need, it's just a few extra bytes to kernel image. I guess it should be ok to always build i2c utilities. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com m...@felipebalbi.com -- 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
RE: [pacth] I2C bug fixes for L-O and L-Z
Could you please also address the question of the load on the SCL line? In my understanding, many boards are using the experimental values from TRM for SCLL, SCLH, HSSCLL and HSSCLH. I have notices that those default values fail to provide a standard I2C clock for, at least, boards that I have tested. Should those values be board specific and taken off from the I2C driver? Or should a note be added there saying These values are board specific and they depend on the load on the SCL line. Please measure and validate correct values for your board. -- 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
