[PATCH] media: omap3isp: fix format string warning

2011-05-29 Thread Ohad Ben-Cohen
Trivially fix this: drivers/media/video/omap3isp/isp.c: In function 'isp_isr_dbg': drivers/media/video/omap3isp/isp.c:394: warning: zero-length gnu_printf format string Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/media/video/omap3isp/isp.c |2 +- 1 files changed, 1

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

2011-05-29 Thread Steve Calfee
On Fri, May 27, 2011 at 12:38 PM, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: [...] In general we do not want to reset nor idle an IP that was potentially already properly configured by bootloader or early Linux boot code. Actually, the opposite is true.

[pm_wip/voltdm_nm][PATCH v2 0/4] OMAP4: PM: Voltage cleanups

2011-05-29 Thread Nishanth Menon
The following patches are on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/voltdm_nm Tested on: SDP4430 This is v2 of the series (of which most of the patches were incorporated) Dropped patches:

[pm_wip/voltdm_nm][PATCH v2 1/3] OMAP4: PM: VC: fix channel bit offset for MPU

2011-05-29 Thread Nishanth Menon
Patch OMAP3+: VC: abstract out channel configuration abstracts out VC channel configuration. However, TRM has it's little surprises such as the following for channel_cfg: CFG_CHANNEL_SABIT(0) CFG_CHANNEL_RAV BIT(1) CFG_CHANNEL_RAC BIT(2) CFG_CHANNEL_RACEN BIT(3) CFG_CHANNEL_CMD BIT(4) is

[pm_wip/voltdm_nm][PATCH v2 2/3] OMAP4: PM: VC: introduce concept of default channel

2011-05-29 Thread Nishanth Menon
Due to a TRM bug, the current code assumes that channel0(core) is the default channel. With the additional explanation provided by the hardware team, it is clear that PRM_VC_CFG_CHANNEL register allows for flexibility of configuring for various PMIC configurations. For example, the I2C slave

[pm_wip/voltdm_nm][PATCH v2 3/3] OMAP4: PM: VC: make omap_vc_i2c_init static

2011-05-29 Thread Nishanth Menon
The only user of omap_vc_i2c_init is vc.c itself, makes no reason for us to expose it out. This also fixes the sparse warning: arch/arm/mach-omap2/vc.c:207:13: warning: symbol 'omap_vc_i2c_init' was not declared. Should it be static? Signed-off-by: Nishanth Menon n...@ti.com ---

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

2011-05-29 Thread Paul Walmsley
On Fri, 27 May 2011, Tomi Valkeinen wrote: However, VENC doesn't use the standard syscontrol mechanism, so that cannot be done via omap_device interface anyway. struct omap_hwmod_class has a .reset function pointer for this purpose. It's already been necessary to deal with the I2C IP block:

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

2011-05-29 Thread Paul Walmsley
Hi Tomi, On Fri, 27 May 2011, Tomi Valkeinen wrote: DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program all possible registers to a sane value. Not impossible, of

[pm_wip/voltdm_nm][PATCH] OMAP3+: PM: VC: support configuring PMIC over I2C_SR

2011-05-29 Thread Nishanth Menon
Many simpler PMICs such as TPS65023 as discussed in: http://marc.info/?t=129848405600010r=1w=2 With a single I2C interface do still have configuration registers that may need population. Typical being slew rate, thermal shutdown configuration etc. These devices are typically hooked on Application

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

2011-05-29 Thread Tomi Valkeinen
On Sun, 2011-05-29 at 20:24 -0600, Paul Walmsley wrote: Hi Tomi, On Fri, 27 May 2011, Tomi Valkeinen wrote: DSS driver has been designed so that it resets the HW before it begins programming it. That way we get the HW into known state. Otherwise we need to be extra careful to program