aboutsummaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)AuthorFilesLines
2012-11-16i2c: i2c-sh_mobile: calculate clock parameters at driver probing timeShinya Kuribayashi1-5/+13
Currently SCL clock parameters (ICCH/ICCL) are calculated in activate_ch(), which gets called every time sh_mobile_i2c_xfer() is processed, while each I2C bus speed is system-defined and in general those parameters do not have to be updated over I2C transactions. The only reason I could see having it transaction-time is to adjust ICCH/ICCL values according to the operating frequency of the I2C hardware block, in the face of DFS (Dynamic Frequency Scaling). However, this won't be necessary. The operating frequency of the I2C hardware block can change _even_ in the middle of I2C transactions. There is no way to prevent it from happening, and I2C hardware block can work with such dynamic frequency change, of course. Another is that ICCH/ICCL clock parameters optimized for the faster operating frequency, can also be applied to the slower operating frequency, as long as slave devices work. However, the converse is not true. It would violate SCL timing specs of the I2C standard. What we can do now is to calculate the ICCH/ICCL clock parameters according to the fastest operating clock of the I2C hardware block. And if that's the case, that calculation should be done just once at driver-module-init time. This patch moves ICCH/ICCL calculating part from activate_ch() into sh_mobile_i2c_init(), and call it from sh_mobile_i2c_probe(). Note that sh_mobile_i2c_init() just prepares clock parameters using the clock rate and platform data provided, but does _not_ make any hardware I/O accesses. We don't have to care about run-time PM maintenance here. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-15bindings: i2c: use consistent naming for i2c binding descriptionsWolfram Sang1-4/+0
Filenames of devictree binding documentation seems to be arbitrary and for me it is unneeded hazzle to find the corresponding documentation for a specific driver. Naming the description the same as the driver is a lot easier and makes sense to me since the driver defines the binding it understands. Also, remove a reference in one source to the binding documentation, since path information easily gets stale. Signed-off-by: Wolfram Sang <wolfram@the-dreams.de> Cc: Rob Herring <robherring2@gmail.com> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2012-11-14i2c: omap: don't save a value only needed for read-clearingWolfram Sang1-2/+1
Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
2012-11-14i2c: omap: cleanup the sysc writeShubhrajyoti D1-15/+5
Currently after the reset the sysc is written with hardcoded values. The patch reads the sysc register and writes back the same value after reset. - Some unnecessary rev checks can be optimised. - Also due to whatever reason the hwmod flags are changed we will not reset the values. - In some of the cases the minor values of the 2430 register is different(0x37) in that case the autoidle setting may be missed. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: Restore i2c context alwaysShubhrajyoti D1-2/+1
Currently the restore is done based on the flag OMAP_I2C_FLAG_RESET_REGS_POSTIDLE. This helps the following - The driver is always capable of restoring regardless of the off mode support being there or not. - While testing omap2430 it is found that in case of certain error paths (timeout) a reset is done. However the restore never happens as it is dependent on the POSTIDLE flag. The other option would be to call a restore in the reset case. As there are only a few registers to be restored the penalty in the idle case should not be much. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: make reset a seperate functionShubhrajyoti D1-15/+24
Implement reset as a separate function. This will enable us to make sure that we don't do the calculation again on every transfer. Also at probe the reset is not added as the hwmod is doing that for us. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: re-factor omap_i2c_init functionShubhrajyoti D1-40/+35
re-factor omap_i2c_init() so that we can re-use it for resume. While at it also remove the bufstate variable as we write it in omap_i2c_resize_fifo for every transfer. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14ARM: i2c: omap: Remove the i207 errata flagShubhrajyoti D1-2/+1
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207] uses the revision id instead of the flag. So the flag can be safely removed. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: remove the dtrevShubhrajyoti D1-7/+5
The dtrev is used only for the comments. Remove the same and use the scheme instead to know if it is version2. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207Shubhrajyoti D1-1/+2
The errata i207 is enabled for 2430 and 3xxx. Use the revision check to enable the erratum instead. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: Fix the revision register readShubhrajyoti D1-13/+48
The revision register on OMAP4 is a 16-bit lo and a 16-bit hi. Currently the driver reads only the lower 8-bits. Fix the same by preventing the truncating of the rev register for OMAP4. Also use the scheme bit ie bit-14 of the hi register to know if it is OMAP_I2C_IP_VERSION_2. On platforms previous to OMAP4 the offset 0x04 is IE register whose bit-14 reset value is 0, the code uses the same to its advantage. Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done to fetch the revision register. The dev->regs is populated after reading the rev_hi. A NULL check has been added in the resume handler to prevent the access before the setting of the regs. Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: adopt pinctrl supportSebastien Guiriec1-0/+13
Some GPIO expanders need some early pin control muxing. Due to legacy boards sometimes the driver uses subsys_initcall instead of module_init. This patch takes advantage of defer probe feature and pin control in order to wait until pin control probing before GPIO driver probing. It has been tested on OMAP5 board with TCA6424 driver. Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com> Acked-by: Shubhrajyoti D <shubhrajyoti@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: ensure writes to dev->buf_len are orderedFelipe Balbi1-1/+3
if we allow compiler reorder our writes, we could fall into a situation where dev->buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev->buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev->buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev->buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev->buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: omap: ensure writes to dev->buf_len are orderedFelipe Balbi1-1/+3
if we allow compiler reorder our writes, we could fall into a situation where dev->buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev->buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev->buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev->buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev->buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"Paul Walmsley1-18/+14
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc (ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints). This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2 http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2 http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2 Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"Paul Walmsley1-18/+14
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc (ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints). This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2 http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2 http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2 Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Jean Pihet <j-pihet@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: at91: fix SMBus quick commandLudovic Desroches1-1/+6
The driver claims to support SMBus quick command but it was not the case. This patch fixes this issue. Without it, i2cdetect finds imaginary devices. And with some IP versions, trying to send 0 byte can cause issue when writing data to an EEPROM. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [wsa: improved the commit message] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: at91: fix SMBus quick commandLudovic Desroches1-1/+6
The driver claims to support SMBus quick command but it was not the case. This patch fixes this issue. Without it, i2cdetect finds imaginary devices. And with some IP versions, trying to send 0 byte can cause issue when writing data to an EEPROM. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [wsa: improved the commit message] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-14i2c: i2c-gpio: fix name issue with multiple i2c gpio nodesBo Shen1-1/+5
When having multiple i2c-gpio nodes, the name for each is same. So add the patch to fix it. The adap->name printing information was added by myself without this patch the log information is as following ---<8--- adap->name = i2c-gpio-1 i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL) adap->name = i2c-gpio-1 i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL) --->8--- with this patch, the log information is as following ---<8--- adap->name = i2c.2 i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL) adap->name = i2c.3 i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL) --->8--- Signed-off-by: Bo Shen <voice.shen@atmel.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> [wsa: minor fixes to the commit mesage] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-13i2c-mux-pinctrl: Fix probe error pathGuenter Roeck1-1/+1
When allocating the memory for i2c busses, the code checked the wrong variable and thus never detected if there was a memory error. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-11-13i2c: ocores: Use devm_request_and_ioremap()Thierry Reding1-12/+3
Replacing the devm_request_mem_region() and devm_ioremap_nocache() calls by a single call to devm_request_and_ioremap() simplifies the code. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-13i2c: rcar: fix section mismatchWolfram Sang1-2/+2
Give the driver struct a name according to the 'standard' to fix: WARNING: vmlinux.o(.data+0x11798): Section mismatch in reference from the variable rcar_i2c_drv to the function .devinit.text:rcar_i2c_probe() ... WARNING: vmlinux.o(.data+0x1179c): Section mismatch in reference from the variable rcar_i2c_drv to the function .devexit.text:rcar_i2c_remove() Reported-by: Simon Horman <horms@verge.net.au> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
2012-11-13Merge branch 'cleanups/dma' into next/cleanupArnd Bergmann8-215/+62
Separate patches from Marek Szyprowski <m.szyprowski@samsung.com>: Commit e9da6e9905e639b0 ("ARM: dma-mapping: remove custom consistent dma region") replaced custom consistent memory handling, so setting consistent dma memory size is not longer required. This patch series cleans sub-architecture platform code to remove all calls to the obsolated init_consistent_dma_size() function and finally removes the init_consistent_dma_size() stub itself. * cleanups/dma: ARM: at91: remove obsoleted init_consistent_dma_size() ARM: u300: remove obsoleted init_consistent_dma_size() ARM: dma-mapping: remove init_consistent_dma_size() stub ARM: shmobile: remove obsoleted init_consistent_dma_size() ARM: davinci: remove obsoleted init_consistent_dma_size() ARM: samsung: remove obsoleted init_consistent_dma_size() Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2012-11-13i2c: rcar: used devm_request_and_ioremap() instead of devm_ioremap()Kuninori Morimoto1-1/+1
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-12i2c: nomadik: Fix the usage of wait_for_completion_timeoutChuansheng Liu1-14/+0
The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-03Merge branch 'i2c-embedded/for-current' of ↵Linus Torvalds3-175/+22
git://git.pengutronix.de/git/wsa/linux Pull i2c embedded fixes from Wolfram Sang: "Two patches are usual stuff. The bigger patch is needed to correct a wrong decision made in this merge window. We hoped to get the PIOQUEUE mode in the mxs driver working with DMA, but it turned out to be too broken (leading to data loss), so we now think it is best to remove it entirely and work only with DMA now. The patch should be in 3.7. IMO, so users never get the chance to use both modes in parallel." * 'i2c-embedded/for-current' of git://git.pengutronix.de/git/wsa/linux: i2c: tegra: set irq name as device name i2c-nomadik: Fixup clock handling i2c: mxs: remove broken PIOQUEUE support
2012-11-02i2c: tegra: set irq name as device nameLaxman Dewangan1-1/+1
When watching the irqs name of tegra i2c, all instances irq name shows as tegra_i2c. Passing the device name properly to have the irq names with instance like tegra-i2c.0, tegra-i2c.1 etc. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-02i2c-nomadik: Fixup clock handlingPhilippe Begnic1-2/+7
Make sure to clk_prepare as well as clk_enable. Signed-off-by: Philippe Begnic <philippe.begnic@stericsson.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-11-02i2c: mxs: remove broken PIOQUEUE supportWolfram Sang1-172/+14
This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally, only PIOQUEUE was supported and it had issues, then DMA support was added this cycle. The original intention was to keep PIOQUEUE since it has less overhead what is nice for small transfers. However, runtime switching between PIOQEUE and DMA depending on the transfer size never worked despite a lot of trying. Since PIOQUEUE mode itself was flaky (polling at places where interrupts failed to work) and the implementation also imposed a size limit for transfers, it is best to remove the support, so users don't fall over its limitations. It also makes the driver a lot cleaner and more robust. If somebody really wants less overhead, plain PIO mode could still be implemented with the addidtional advantage that this mode is also available on MX23, too. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Reviewed-by: Marek Vasut <marex@denx.de>
2012-10-28i2c-i801: Fix commentJean Delvare1-1/+1
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-28i2c-i801: Simplify dependency towards GPIOLIBJean Delvare2-4/+6
Arbitrarily selecting GPIOLIB causes trouble on some architectures, so don't do that. Instead, just make the optional multiplexing code depend on CONFIG_I2C_MUX_GPIO instead of CONFIG_I2C_MUX for now. We can revisit if the i2c-i801 driver ever supports other multiplexing flavors. Also make that optional code depend on DMI, as it won't do anything without that. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Fengguang Wu <fengguang.wu@intel.com>
2012-10-28i2c-stub: Move to drivers/i2cJean Delvare3-35/+33
Move the i2c-stub driver to drivers/i2c, to match the Kconfig entry. This is less confusing that way. I also fixed all checkpatch warnings and errors. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Peter Huewe <peterhuewe@gmx.de>
2012-10-15i2c: imx: remove cpu_is_xxx by using platform_device_idShawn Guo1-5/+35
This is some amount of work left/forgot from device tree conversion. Instead of checking cpu_is_xxx to determine the controller type, the driver should use platform_device_id, which should match the device tree compatible string. The patch changes the driver to use platform_device_id rather than cpu_is_xxx to determine the controller type/version. It also updates the platform code and device tree source accordingly. As the result, mach/hardware.h inclusion gets removed from the driver. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: linux-i2c@vger.kernel.org
2012-10-11Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linuxLinus Torvalds12-490/+1836
Pull i2c-embedded changes from Wolfram Sang: "The changes for i2c-embedded include: - massive rework of the omap driver - massive rework of the at91 driver. In fact, the old driver gets removed; I am okay with this approach since the old driver was depending on BROKEN and its limitations made it practically unusable, so people used bitbanging instead. But even if there are users, there is no platform_data or module parameter which would need to be converted. It is just another driver doing I2C transfers, just way better. Modifications of arch/arm/at91 related files have proper acks from the maintainer. - new driver for R-Car I2C - devicetree and generic_clock conversions and fixes - usual driver fixes and changes. The rework patches have come a long way and lots of people have been involved in creating/testing them. Most patches have been in linux-next at least since 3.6-rc5. A few have been added in the last week, I have to admit. An unexpected (but welcome :)) peak in private life is the cause for that. The "late" patches shouldn't cause any merge conflicts and I will have a special eye on them during the stabilization phase. This is an exception and I want to have the patches in place properly in time again for the next kernels." * 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux: (44 commits) MXS: Implement DMA support into mxs-i2c i2c: add Renesas R-Car I2C driver i2c: s3c2410: use clk_prepare_enable and clk_disable_unprepare ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints i2c: nomadik: Add Device Tree support to the Nomadik I2C driver i2c: algo: pca: Fix chip reset function for PCA9665 i2c: mpc: Wait for STOP to hit the bus i2c: davinci: preparation for switch to common clock framework omap-i2c: fix incorrect log message when using a device tree i2c: omap: sanitize exit path i2c: omap: switch over to autosuspend API i2c: omap: remove unnecessary pm_runtime_suspended check i2c: omap: switch to threaded IRQ support i2c: omap: remove redundant status read i2c: omap: get rid of the "complete" label i2c: omap: resize fifos before each message i2c: omap: simplify IRQ exit path i2c: omap: always return IRQ_HANDLED i2c: omap: simplify errata check i2c: omap: bus: add a receiver flag ...
2012-10-08MXS: Implement DMA support into mxs-i2cMarek Vasut1-22/+247
This patch implements DMA support into mxs-i2c. DMA transfers are now enabled via DT. The DMA operation is enabled by default. Signed-off-by: Marek Vasut <marex@denx.de> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> [wsa: rebased to 3.6-rc7] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-08Merge tag 'v3.6-rc7' into i2c-embedded/for-nextWolfram Sang8-36/+83
Linux 3.6-rc7 Needed to get updates from i2c-embedded/for-current into i2c-embedded/for-next
2012-10-08i2c: add Renesas R-Car I2C driverKuninori Morimoto3-0/+720
R-Car I2C is similar with SH7760 I2C. But the SH7760 I2C driver had many workaround operations, since H/W had bugs. Thus, it was pointless to keep compatible between SH7760 and R-Car I2C drivers. This patch creates new Renesas R-Car I2C driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-08Merge branch 'release' of ↵Linus Torvalds1-13/+1
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux Pul ACPI & Power Management updates from Len Brown: - acpidump utility added - intel_idle driver now supports IVB Xeon - turbostat utility can now count SMIs - ACPI can now bind to USB3 hubs - misc fixes * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (49 commits) ACPI: Add new sysfs interface to export device description ACPI: Harden acpi_table_parse_entries() against BIOS bug tools/power/turbostat: add option to count SMIs, re-name some options tools/power turbostat: add [-d MSR#][-D MSR#] options to print counter deltas intel_idle: enable IVB Xeon support tools/power turbostat: add [-m MSR#] option tools/power turbostat: make -M output pretty tools/power turbostat: print more turbo-limit information tools/power turbostat: delete unused line tools/power turbostat: run on IVB Xeon tools/power/acpi/acpidump: create acpidump(8), local make install targets tools/power/acpi/acpidump: version 20101221 - find dynamic tables in sysfs ACPI: run _OSC after ACPI_FULL_INITIALIZATION tools/power/acpi/acpidump: create acpidump(8), local make install targets tools/power/acpi/acpidump: version 20101221 - find dynamic tables in sysfs tools/power/acpi/acpidump: version 20071116 tools/power/acpi/acpidump: version 20070714 tools/power/acpi/acpidump: version 20060606 tools/power/acpi/acpidump: version 20051111 xo15-ebook: convert to module_acpi_driver() ...
2012-10-06i2c: s3c2410: use clk_prepare_enable and clk_disable_unprepareThomas Abraham1-9/+9
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-06ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraintsJean Pihet1-14/+18
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. The I2C device latency timing is derived from the FIFO size and the clock speed and so is applicable to all OMAP SoCs. Signed-off-by: Jean Pihet <j-pihet@ti.com> Acked-by: Shubhrajyoti D <shubhrajyoti@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-06i2c: nomadik: Add Device Tree support to the Nomadik I2C driverLee Jones1-3/+32
Here we apply the bindings required for successful Device Tree probing of the i2c-nomadik driver. Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-06i2c: algo: pca: Fix chip reset function for PCA9665Thomas Kavanagh1-13/+14
The parameter passed to pca9665_reset is adap->data (which is bus driver specific), not i2c_algp_pca_data *adap. pca9665_reset expects it to be i2c_algp_pca_data *adap. All other wrappers from the algo call back to the bus driver, which knows to handle its custom data. Only pca9665_reset resides inside the algorithm code and does not know how to handle a custom data structure. This can result in a kernel crash. Fix by re-factoring pca_reset() from a macro to a function handling chip specific code, and only call adap->reset_chip() if the chip is not PCA9665. Signed-off-by: Thomas Kavanagh <tkavanagh@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-10-05i2c-piix4: Fix build failureDaniel J Blueman1-0/+1
Fix build failure in Intel PIIX4 I2C driver. Signed-off-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: stable@vger.kernel.org [v3.6]
2012-10-05i2c-i801: Let i2c-mux-gpio find the GPIO chipJean Delvare1-33/+4
Now that i2c-mux-gpio is able to find the GPIO chip by itself, we can delegate this task. The great thing here is that i2c-mux-gpio can defer device probing until the gpio chip is available, so we no longer depend on the module loading order. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-05i2c-mux-gpio: Add support for dynamically allocated GPIO pinsJean Delvare1-6/+32
The code instantiating an i2c-mux-gpio platform device doesn't necessarily know in advance the GPIO pin numbers it wants to use. If pins are on a GPIO device which gets its base GPIO number assigned dynamically at run-time, the values can't be hard-coded. In that case, let the caller tell i2c-mux-gpio the name of the GPIO chip and the (relative) GPIO pin numbers to use. At probe time, the i2c-mux-gpio driver will look for the chip and apply the proper offset to turn relative GPIO pin numbers to absolute GPIO pin numbers. The same could be (and was so far) done on the caller's end, however doing it in i2c-mux-gpio has two benefits: * It avoids duplicating the code on every caller's side (about 30 lines of code.) * It allows for deferred probing for the muxed part of the I2C bus only. If finding the GPIO chip is the caller's responsibility, then deferred probing (if the GPIO chip isn't there yet) will not only affect the mux and the I2C bus segments behind it, but also the I2C bus trunk. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Peter Korsgaard <peter.korsgaard@barco.com>
2012-10-05i2c-mux-gpio: Use devm_kzalloc instead of kzallocMaxime Ripard1-9/+5
Use the devm_kzalloc managed function to stripdown the error and remove code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-05i2c-i801: Support SMBus multiplexing on Asus Z8 seriesJean Delvare2-1/+214
Add support for SMBus multiplexing on Asus Z8 motherboard series. On these boards, the memory slots are behind a GPIO-controlled I2C multiplexer. Models with 6 or 12 memory slots have 2 segments behind the multiplexer, while models with 18 memory slots have 3 such segments. On these boards, only the memory slots are behind the multiplexer, so it is possible to keep the autodetection mechanism. The code is generic enough so it could work on other boards as long as the multiplexer is controlled by GPIO pins. For other forms of multiplexing (for example using an I2C device) additional code will be needed. Thanks to Asus for providing a board to develop and test this feature, as well as all the technical information required. At the moment, the GPIO driver must be loaded before the i2c-i801 driver, but I hope to solve this soon, using deferred probing on the i2c-mux-gpio side. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-05i2c-viapro: Add VIA VX900 device IDJean Delvare2-1/+5
The SMBus controller in the VIA VX900 appears to be compatible with the VIA VX855, so just add the device ID. This closes kernel bug #43096. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-05i2c-parport: i2c_parport_irq can be staticJean Delvare1-1/+1
i2c_parport_irq is only called internally so it can be static. Signed-off-by: Jean Delvare <khali@linux-fr.org>
2012-10-05i2c-designware: i2c_dw_xfer_msg can be staticJean Delvare1-1/+1
i2c_dw_xfer_msg is only called internally so it can be static. It original was, before the driver split. No idea why it was changed at that time. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Powered by cgit, Gruvboxed by Blaster4385.