- Nov 25, 2012
-
-
Ludovic Desroches authored
This patch fixes the following warning: drivers/i2c/busses/i2c-at91.c: In function ‘at91_twi_get_driver_data’: drivers/i2c/busses/i2c-at91.c:411:3: warning: return discards ‘const’ qualifier from pointer target type [enabled by default] Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de>
-
- Nov 23, 2012
-
-
Marek Vasut authored
There is no reason to disable the I2C SMBus quick mode on this IP block. Enable it. This essentially fixes the problem with the "i2c-detect" command for probing the bus. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Marek Vasut authored
Properly terminate the DMA transfer in case the DMA PIO transfer or setup fails for any reason. Signed-off-by:
-
Mark Brown authored
The changes in "i2c-s3c2410: use exponential back off while polling for bus idle" remove the initial busy wait for I2C transfers to complete and replace it with usleep_range() calls which will schedule. Since for older SoCs I2C transfers would usually complete within an extremely small number of CPU cycles there is a win from not having to schedule. This happens because on the older SoCs the cores run at a smaller multiple of the speeds that the I2C bus is operating at; on more modern SoCs the busy wait is less likely to be effective. Fix the issue by restoring the busy wait, reducing the number of spins from 20 to 3 which covers the overwhelming majority of I2C transfers on the SoCs where the busy wait is effective. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Olof Johansson <olof@lixom.net> Reviewed-by:
Daniel Kurtz <djkurtz@chromium.org> Reviewed-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
-
Andreas Larsson authored
This moves the grlib set and get functions into the #ifdef CONFIG_OF block to avoid warnings of unimplemented functions when compiling with -Wunused-function when CONFIG_OF is not defined. Signed-off-by:
Andreas Larsson <andreas@gaisler.com> Acked-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
-
- Nov 19, 2012
-
-
Abhilash Kesavan authored
The I2C driver makes a gpio_request during initialization. This request happens again on resume and fails due to the earlier successful request. Re-factor the code to only initialize the gpios during probe. Errors on resume without this: [ 16.020000] s3c-i2c s3c2440-i2c.0: gpio [42] request failed [ 16.020000] s3c-i2c s3c2440-i2c.1: gpio [44] request failed [ 16.020000] s3c-i2c s3c2440-i2c.2: gpio [6] request failed Signed-off-by:
Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by:
-
Abhilash Kesavan authored
Store the requested gpios so that they can be freed on error/removal. Signed-off-by:
-
Aaro Koskinen authored
Add i2c driver to enable access to devices behind CBUS on Nokia Internet Tablets. The patch also adds CBUS I2C configuration for N8x0 which is one of the users of this driver. Acked-by:
Felipe Balbi <balbi@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
- Nov 17, 2012
-
-
Andreas Larsson authored
i2c: ocores: Add support for the GRLIB port of the controller and use function pointers for getreg and setreg functions The registers in the GRLIB port of the controller are 32-bit and in big endian byte order. The PRELOW and PREHIGH registers are merged into one register. The subsequent registers have their offset decreased accordingly. Hence the register access needs to be handled in a non-standard manner using custom getreg and setreg functions. Add setreg and getreg functions for different register widths and let oc_setreg and oc_getreg use function pointers to call the appropriate functions. A type is added as the data of the of match table entries. A new entry with a different compatible string is added to the table. The type of that entry triggers usage of the custom grlib functions by setting the setreg and getreg function pointers. Signed-off-by:
-
Andreas Larsson authored
Add sparc support by using platform_get_irq instead of platform_get_resource. There are no platform resources of type IORESOURCE_IRQ for sparc, but platform_get_irq works for sparc. In the non-sparc case platform_get_irq internally uses platform_get_resource. Signed-off-by:
-
- Nov 16, 2012
-
-
Shubhrajyoti D authored
Currently we just queue the transfer and release the qos constraints, however we do not wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Acked-by:
Jean Pihet <j-pihet@ti.com> Signed-off-by:
Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by:
-
Maxime Ripard authored
This will allow to add the 3 Nuvoton NAU7802 ADCs and the NXP PCA9555 GPIO expander eventually. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Daniel Kurtz authored
Commit "i2c-s3c2410: Add HDMIPHY quirk for S3C2440" added support for HDMIPHY with some special handling in s3c24xx_i2c_set_master: "due to unknown reason (probably HW bug in HDMIPHY and/or the controller) a transfer fails to finish. The controller hangs after sending the last byte, the workaround for this bug is resetting the controller after each transfer" The "unknown reason" was that the proper sequence for generating a STOP condition wasn't being followed as per the datasheet. Since this is fixed by "PATCH: i2c-s3c2410: do not generate STOP for QUIRK_HDMIPHY buses", remove the special handling. Signed-off-by:
Naveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by:
-
Daniel Kurtz authored
Usually, the i2c controller has finished emitting the i2c STOP before the driver reaches the bus idle polling loop. Optimize for this most common case by reading IICSTAT first and potentially skipping the loop. If the cpu is faster than the hardware, we wait for bus idle in a polling loop. However, since the duration of one iteration of the loop is dependent on cpu freq, and this i2c IP is used on many different systems, use a time based loop timeout (5 ms). We would like very low latencies to detect bus idle for the normal 'fast' case. However, if a device is slow to release the bus for some reason, it could hold off the STOP generation for up to several milliseconds. Rapidly polling for bus idle would seriously load the CPU while waiting for it to release the bus. So, use a partial exponential backoff as a compromise between idle detection latency and cpu load. Signed-off-by:
-
Daniel Kurtz authored
The datasheet says that the STOP sequence should be: 1) I2CSTAT.5 = 0 - Clear BUSY (or 'generate STOP') 2) I2CCON.4 = 0 - Clear IRQPEND 3) Wait until the stop condition takes effect. 4*) I2CSTAT.4 = 0 - Clear TXRXEN Where, step "4*" is only for buses with the "HDMIPHY" quirk. However, after much experimentation, it appears that: a) normal buses automatically clear BUSY and transition from Master->Slave when they complete generating a STOP condition. Therefore, step (3) can be done in doxfer() by polling I2CCON.4 after starting the STOP generation here. b) HDMIPHY bus does neither, so there is no way to do step 3. There is no indication when this bus has finished generating STOP. In fact, we have found that as soon as the IRQPEND bit is cleared in step 2, the HDMIPHY bus generates the STOP condition, and then immediately starts transferring another data byte, even though the bus is supposedly stopped. This is presumably because the bus is still in "Master" mode, and its BUSY bit is still set. To avoid these extra post-STOP transactions on HDMI phy devices, we just disable Serial Output on the bus (I2CSTAT.4 = 0) directly, instead of first generating a proper STOP condition. This should float SDA & SCK terminating the transfer. Subsequent transfers start with a proper START condition, and proceed normally. The HDMIPHY bus is an internal bus that always has exactly two devices, the host as Master and the HDMIPHY device as the slave. Skipping the STOP condition has been tested on this bus and works. Also, since we disable the bus directly from the isr, we can skip the bus idle polling loop at the end of doxfer(). Signed-off-by: -
Daniel Kurtz authored
We probably don't want to change I2C frequency while a transfer is in progress. The current implementation grabs a spinlock, but that only protected the writes to IICCON when starting a message, it didn't protect against clock changes in the middle of a transaction. Note: The i2c-core already grabs the adapter lock before calling s3c24xx_i2c_doxfer(), which ensures that only one caller is issuing a xfer at a time. This means it is not necessary to disable interrupts (spin_lock_irqsave) when changing frequencies, since there won't be any i2c interrupts if there is no on-going xfer. Lastly, i2c_lock_adapter() may cause the cpufreq_transition to sleep if if a xfer is in progress, but this is ok since cpufreq notifiers are called in a kernel thread, and there are already cases where it could sleep, such as when using i2c to update the output of a voltage regulator. Note: the cpufreq part of this change has no functional affect on exynos, where the i2c clock is independent of the cpufreq. But, there is a slight perfomance boost since we no longer need to lock/unlock an additional spinlock. Signed-off-by:
-
Tomasz Figa authored
This patch adds support for pin configuration using pinctrl subsystem to the i2c-s3c2410 driver. Signed-off-by:
Tomasz Figa <t.figa@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Mark Brown authored
A small code saving and less error handling to worry about. Signed-off-by:
-
Mark Brown authored
Use the PM_SLEEP ifdef for system suspend and resume. This is partly in preparation for adding runtime operations and partly because a user may in theory choose to enable runtime suspend but not system suspend. Signed-off-by:
-
Maxime Ripard authored
Allow the i2c-mux-gpio to be used by a device tree enabled device. The bindings are inspired by the one found in the i2c-mux-pinctrl driver. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Peter Korsgaard <peter.korsgaard@barco.com> [wsa: fixed some whitespace] Signed-off-by:
-
Shinya Kuribayashi authored
Ensure that any of preceding register write operations to the I2C hardware block reached the module, and the write data is reflected in the registers, before leaving the interrupt handler. Otherwise, we'll suffer from spurious WAIT interrupts that lead to 'Transfer request timed out' message, and the transaction failed. Reported-by:
Teppei Kamijou <teppei.kamijou.yb@renesas.com> Signed-off-by:
Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> Signed-off-by:
-
Shinya Kuribayashi authored
On newer SH-/R-Mobile SoCs, a clock supply to the I2C hardware block, which is used to generate the SCL clock output, is getting faster than before, while on the other hand, the SCL clock control registers, ICCH and ICCL, stay unchanged in 9-bit-wide (8+1). On such silicons, the internal SCL clock counter gets incremented every 2 clocks of the operating clock. This patch makes it configurable through platform data. Signed-off-by:
-
Shinya Kuribayashi authored
ICCH/ICCL values is supposed to be calculated/optimized to strictly meet the timing specs required by the I2C standard. The resulting I2C bus speed does not matter at all, if it's less than 100 or 400 kHz. With this change, sh_mobile_i2c_icch() is virtually identical to sh_mobile_i2c_iccl(), but they're providing good descriptions of SH-/R-Mobile I2C hardware spec, and I'd leave them as separated. Also fix a typo in the comment, print icch/iccl values at probe, etc. Signed-off-by:
-
Shinya Kuribayashi authored
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:
-
- Nov 15, 2012
-
-
Wolfram Sang authored
Acked-by:
Wolfram Sang <wolfram@the-dreams.de>
-
Shubhrajyoti D authored
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 authored
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:
-
Shubhrajyoti D authored
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:
-
Shubhrajyoti D authored
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:
-
Shubhrajyoti D authored
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:
-
Shubhrajyoti D authored
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 authored
The errata i207 is enabled for 2430 and 3xxx. Use the revision check to enable the erratum instead. Reviewed-by:
-
Shubhrajyoti D authored
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:
-
Sebastien Guiriec authored
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:
-
Felipe Balbi authored
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:
-
- Nov 14, 2012
-
-
Paul Walmsley authored
This reverts commit 3db11fef (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:
-
Ludovic Desroches authored
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:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [wsa: improved the commit message] Signed-off-by:
-
Bo Shen authored
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:
-
- Nov 13, 2012
-
-
Thierry Reding authored
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 authored
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:
-
