[PATCH 2/2] i2c: ocores: add CONFIG_PM_SLEEP to suspend/resume functions

2013-03-21 Thread Jingoo Han
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/i2c/busses/i2c-ocores.c:460:12: warning: 'ocores_i2c_s

[PATCH 1/2] i2c: designware: add CONFIG_PM_SLEEP to suspend/resume functions

2013-03-21 Thread Jingoo Han
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/i2c/busses/i2c-designware-platdrv.c:253:12: warning: '

[PATCH 1/2] i2c: designware: add CONFIG_PM_SLEEP to suspend/resume functions

2013-03-21 Thread Jingoo Han
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following build warning when CONFIG_PM_SLEEP is not selected. This is because sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled. drivers/i2c/busses/i2c-designware-platdrv.c:253:12: warning: '

Re: i2c_i801: status of use hardware semaphore patch?

2013-03-21 Thread Martin Mokrejs
Jason Baron wrote: > Hi, > > I've also hit the i2c_i801 driver conflicts with ACPI region: > > kernel: [73904.044722] i801_smbus :00:1f.3: PCI INT C -> GSI 18 > (level, low) -> IRQ 18 > kernel: [73904.045573] ACPI: resource :00:1f.3 [io 0xf000-0xf01f] > conflicts with ACPI region SMBI [i

i2c_i801: status of use hardware semaphore patch?

2013-03-21 Thread Jason Baron
Hi, I've also hit the i2c_i801 driver conflicts with ACPI region: kernel: [73904.044722] i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 kernel: [73904.045573] ACPI: resource :00:1f.3 [io 0xf000-0xf01f] conflicts with ACPI region SMBI [io 0xf000-0xf00f] kernel: [73904.046

[PATCH V2] i2c: tegra: assume CONFIG_OF, remove platform data

2013-03-21 Thread Stephen Warren
From: Stephen Warren Tegra only supports, and always enables, device tree. Remove all ifdefs and runtime checks for DT support from the driver. Platform data is therefore no longer required. Delete the header that defines it. Signed-off-by: Stephen Warren --- V2: Rebased onto v3.9-rc1; hopefull

[PATCH v2 2/2] i2c: s3c2410: fixup the styling of the newly moved register definitions

2013-03-21 Thread Heiko Stübner
Make them conform more to established standards. Signed-off-by: Heiko Stuebner --- changes since v1: none drivers/i2c/busses/i2c-s3c2410.c | 50 ++--- 1 files changed, 24 insertions(+), 26 deletions(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2

[PATCH v2 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver

2013-03-21 Thread Heiko Stübner
The register definitions are only used in the driver itself. This also removes the last dependency on plat/ includes from the i2c driver. Signed-off-by: Heiko Stuebner Acked-by: Kukjin Kim --- changes since v1: rebased against 3.9-rc3 arch/arm/mach-s3c24xx/mach-rx1950.c |1 - arc

[PATCH 1/7] i2c-designware: move to managed functions (devm_*)

2013-03-21 Thread Mika Westerberg
From: Andy Shevchenko This makes the error handling much more simpler than open-coding everything and in addition makes the probe function smaller and tidier. Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg --- drivers/i2c/busses/i2c-designware-platdrv.c | 73 -

[PATCH 6/7] i2c-designware: use usleep_range() in the busy-loop

2013-03-21 Thread Mika Westerberg
This is not an atomic context so there is no need to use mdelay() but instead use usleep_range(). Signed-off-by: Mika Westerberg --- drivers/i2c/busses/i2c-designware-core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers

[PATCH 7/7] i2c-designware: switch to use runtime PM autosuspend

2013-03-21 Thread Mika Westerberg
Using autosuspend helps to reduce the resume latency in situations where another I2C message is going to be started soon. For example with HID over I2C touch panels we get several messages in a short period of time while the touch panel is in use. Signed-off-by: Mika Westerberg --- drivers/i2c/b

[PATCH 3/7] i2c-designware-pci: use managed functions pcim_* and devm_*

2013-03-21 Thread Mika Westerberg
From: Andy Shevchenko This makes the error handling much more simpler than open-coding everything and in addition makes the probe function smaller an tidier. Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg --- drivers/i2c/busses/i2c-designware-pcidrv.c | 68 +++

[PATCH 5/7] i2c-designware: enable/disable the controller properly

2013-03-21 Thread Mika Westerberg
The correct way to disable or enable the controller is to wait until DW_IC_ENABLE_STATUS register bit matches the bit we program to the DW_IC_ENABLE register. This procedure is described in the DesignWare I2C handbook. By doing this we can be sure that the controller is in correct state once the f

[PATCH 4/7] i2c-designware: use dynamic adapter numbering on Lynxpoint

2013-03-21 Thread Mika Westerberg
It is not good idea to mix static and dynamic I2C adapter numbering. In this particular case on Lynxpoint we had graphics I2C adapter which took the first numbers preventing the designware I2C driver from using the adapter numbers it preferred. Fix this by switching to use dynamic adapter numberin

[PATCH 2/7] i2c-designware-pci: use dev_err() instead of printk()

2013-03-21 Thread Mika Westerberg
From: Andy Shevchenko With dev_err() we can get the device instance printed as well and is pretty much standard to use dev_* macros in drivers anyway. In addition correct indentation of probe() arguments. Signed-off-by: Andy Shevchenko Signed-off-by: Mika Westerberg --- drivers/i2c/busses/i2c

Re: [PATCH v4 2/2] i2c: pxa: Use i2c-core to get bus number now

2013-03-21 Thread Wolfram Sang
On Fri, Mar 01, 2013 at 08:57:32AM -0800, Doug Anderson wrote: > The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if > present" adds support for automatically picking the bus number based > on the alias ID. Remove the now unnecessary code from i2c-pxa that > did the same thing. > > S

Re: [PATCH v2 06/12] i2c: i2c-mxs: move to use generic DMA helper

2013-03-21 Thread Wolfram Sang
On Tue, Mar 05, 2013 at 08:23:58PM +0800, Shawn Guo wrote: > With the generic DMA device tree helper supported by mxs-dma driver, > client devices only need to call dma_request_slave_channel() for > requesting a DMA channel from dmaengine. > > Signed-off-by: Shawn Guo > Cc: Wolfram Sang > Cc: li

Re: [PATCH 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver

2013-03-21 Thread Wolfram Sang
> I'm not sure anymore ... probably some linux-next. I'll redo them on top of > your (i2c) for-next branch. Thanks, but please use 3.9-rc3. -- 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://

Re: [PATCH v3] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error

2013-03-21 Thread Wolfram Sang
On Thu, Feb 14, 2013 at 12:28:18PM +0100, Cong Ding wrote: > If it goes to eclk through line 1107, the variable res would be NULL. It will > cause a null pointer dereference error if we call release_mem_region. The > correct way should be using devm_kzalloc rather than kzalloc to allocate > memory.

Re: [PATCH 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver

2013-03-21 Thread Heiko Stübner
Hi Wolfram, Am Donnerstag, 21. März 2013, 10:57:58 schrieb Wolfram Sang: > On Fri, Feb 08, 2013 at 12:57:00AM +0100, Heiko Stübner wrote: > > The register definitions are only used in the driver itself. > > This also removes the last dependency on plat/ includes from the > > i2c driver. > > > > S

Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration

2013-03-21 Thread Heiko Stübner
Am Donnerstag, 21. März 2013, 11:00:32 schrieb Wolfram Sang: > On Mon, Mar 04, 2013 at 07:12:53PM +0530, Thomas Abraham wrote: > > With device core now able to setup the default pin configuration, > > the call to devm_pinctrl_get_select_default can be removed. And > > the pin configuration code bas

Re: [PATCH V10 1/2] i2c/adapter: Add bus recovery infrastructure

2013-03-21 Thread Shiraz Hashim
On Thu, Mar 21, 2013 at 03:45:29PM +0530, Viresh Kumar wrote: > On 21 March 2013 15:06, Wolfram Sang wrote: > > I applied V11 of the core changes with minor modifications. > > Wow!! Thanks. > > > I do wonder > > about the hook in the designware driver. You apply the recovery on > > transfer time

Re: [PATCH V10 1/2] i2c/adapter: Add bus recovery infrastructure

2013-03-21 Thread Viresh Kumar
On 21 March 2013 15:06, Wolfram Sang wrote: > I applied V11 of the core changes with minor modifications. Wow!! Thanks. > I do wonder > about the hook in the designware driver. You apply the recovery on > transfer timeout. I think this should go into the timeout of > i2c_dw_wait_bus_not_busy()?

Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration

2013-03-21 Thread Wolfram Sang
On Mon, Mar 04, 2013 at 07:12:53PM +0530, Thomas Abraham wrote: > With device core now able to setup the default pin configuration, > the call to devm_pinctrl_get_select_default can be removed. And > the pin configuration code based on the deprecated Samsung specific > gpio bindings is also removed

Re: [PATCH 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver

2013-03-21 Thread Wolfram Sang
On Fri, Feb 08, 2013 at 12:57:00AM +0100, Heiko Stübner wrote: > The register definitions are only used in the driver itself. > This also removes the last dependency on plat/ includes from the > i2c driver. > > Signed-off-by: Heiko Stuebner What tree is this against? I can't apply it on top of v

Re: [PATCH V10 1/2] i2c/adapter: Add bus recovery infrastructure

2013-03-21 Thread Wolfram Sang
Viresh, I applied V11 of the core changes with minor modifications. I do wonder about the hook in the designware driver. You apply the recovery on transfer timeout. I think this should go into the timeout of i2c_dw_wait_bus_not_busy()? Thanks, Wolfram -- To unsubscribe from this list: send th