aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/i2c/busses/i2c-mv64xxx.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-04-27i2c: mv64xxx: remove CONFIG_HAVE_CLK conditionalsThomas Petazzoni1-19/+6
When clock support was added to the i2c-mv64xxx, not all clk functions had stubs when for !CONFIG_HAVE_CLK configurations. However, nowadays, both "struct clk" and all the clock framework functions have stubs when CONFIG_HAVE_CLK is not enabled, so it no longer makes sense to carry such compile-time conditionals in the driver. This commit was compile tested on both ARM64 (which has both CONFIG_OF=y and CONFIG_HAVE_CLK=y) and PowerPC c2k_defconfig (which has CONFIG_OF=y, CONFIG_HAVE_CLK disabled, and the i2c-mv64xxx driver enabled). The only non-trivial change is in the mv64xxx_of_config() function, which was returning -ENODEV unconditionally if CONFIG_HAVE_CLK was disabled. Simply removing this condition works fine because the first test done by the function is to verify if drv_data->clk points to a valid clock, and if it doesn't, we return -ENODEV. When CONFIG_HAVE_CLK is disabled, devm_clk_get() unconditionally returns NULL, so mv64xxx_of_config() will return -ENODEV when no clock is provided, which is the intended behavior. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-27i2c: mv64xxx: use clk_{prepare_enable,disable_unprepare}Thomas Petazzoni1-12/+6
Instead of separately calling clk_prepare()/clk_enable(), use clk_prepare_enable(), and instead of calling clk_disable()/clk_unprepare(), use clk_disable_unprepare(). Those handy shortcuts have been introduced specifically to simplify the numerous call sites were both functions were called in sequence. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-04-27i2c: mv64xxx: handle probe deferral for the clockThomas Petazzoni1-0/+2
If a clock is registered by a platform driver and not by the OF_CLK_DECLARE() mechanism, it might show up after the first attempt to probe i2c-mv64xxx. In order to solve this, we need to handle -EPROBE_PREFER as a special return value of devm_clk_get(), and return the same error code from probe(). This gives us three situations: - There is no reference to a clock in the DT. In this case, devm_clk_get() returns an error that is not -EPROBE_DEFER (something like -ENODEV), and we continue the probing without enabling the clock. - There is a reference to the clock in the DT, and the clock is ready. devm_clk_get() returns a valid reference to the clock, and we prepare/enable it. - There is a reference to the clock in the DT, but the clock is not ready. devm_clk_get() returns -EPROBE_DEFER, and we exit from probe() with the same error code so that probe() is tried again later. This is needed for Marvell Armada 7K/8K, where the clock driver is a platform driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2015-11-30i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCsHans de Goede1-9/+18
According to the datasheets the n factor for dividing the tclk is 2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is on other mv64xxx implementations. I've contacted Allwinner about this and they have confirmed that the datasheet is correct. This commit fixes the clk-divider calculations for Allwinner SoCs accordingly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Tested-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2015-10-22i2c: mv64xxx: really allow I2C offloadingHezi Shahmoon1-2/+0
Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems") completely reworked the offload support, but left a debugging-related "return false" at the beginning of the mv64xxx_i2c_can_offload() function. This has the unfortunate consequence that offloading is in fact never used, which wasn't really the intention. This commit fixes that problem by removing the bogus "return false". Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems") Signed-off-by: Hezi Shahmoon <hezi@marvell.com> [Thomas: reworked commit log and title.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: <stable@vger.kernel.org>
2014-12-17i2c: mv64xxx: rework offload support to fix several problemsThomas Petazzoni1-120/+186
Originally, the I2C controller supported by the i2c-mv64xxx driver requires a lot of software support: an interrupt is generated at each step of an I2C transaction (after the start bit, after sending the address, etc.) and the driver is in charge of re-programming the I2C controller to do the next step of the I2C transaction. This explains the fairly complex state machine that the driver has. On Marvell Armada XP and later processors (Armada 375, 38x, etc.), the I2C controller was extended with a part called the "I2C Bridge", which allows to offload the I2C transaction completely to the hardware. Initial support for this mechanism was added in commit 930ab3d403a ("i2c: mv64xxx: Add I2C Transaction Generator support"). However, the implementation done in this commit has two related issues, which this commit fixes by completely changing how the offload implementation is done: * SMBus read transfers, where there is one write to select the register immediately followed in the same transaction by one read, were making the processor hang. This was easier visible on the Marvell Armada XP WRT1900AC platform using a driver for an I2C LED controller, or on other Armada XP platforms by using a simple 'i2cget' command to read an I2C EEPROM. * The implementation was based on the fact that the offload engine was re-programmed to transfer each message of an I2C xfer: this meant that each message sent with the offload engine was starting with a normal I2C start sequence. However, the I2C subsystem assumes that all messages belonging to the same xfer will use the so-called "repeated start" so that the entire I2C xfer is seen as one transfer by the I2C devices and cannot be interrupt by other I2C masters on the same bus. In fact, the "I2C Bridge" allows to offload three types of xfer: - xfer of one write message - xfer of one read message - xfer of one write message followed by one read message For all other situations, we have to fallback to not using the "I2C Bridge" in order to get proper I2C semantics. Therefore, this commit reworks the offload implementation to put it not at the message level, but at the xfer level: in the mv64xxx_i2c_xfer() function, we decide if the transaction can be offloaded (in which case it is handled by the mv64xxx_i2c_offload_xfer() function), or otherwise it is handled by the slow path (implemented in the existing mv64xxx_i2c_execute_msg()). This allows to simplify the state machine, which no longer needs to have any state related to the offload implementation: the offload implementation is now completely separated from the slow path (with the exception of the interrupt handler, of course). In summary: - mv64xxx_i2c_can_offload() will analyze an I2C xfer and decided of the "I2C Bridge" can be used to offload it or not. - mv64xxx_i2c_offload_xfer() will actually program the "I2C Bridge" to offload one xfer (of either one or two messages), and block using mv64xxx_i2c_wait_for_completion() until the xfer completes. - The interrupt handler mv64xxx_i2c_intr() is modified to push the offload related code to a separate function, mv64xxx_i2c_intr_offload(). It will take care of reading the received data if needed. This commit was tested on: - Armada XP OpenBlocks AX3-4 (EEPROM on I2C and RTC on I2C) - Armada XP WRT1900AC (LED controller on I2C) - Armada XP GP (EEPROM on I2C) Fixes: 930ab3d403ae ("i2c: mv64xxx: Add I2C Transaction Generator support") Cc: <stable@vger.kernel.org> # v3.12+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [wsa: fixed checkpatch warnings] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-12-17i2c: mv64xxx: use BIT() macro for register value definitionsThomas Petazzoni1-11/+11
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-10-20i2c: busses: drop owner assignment from platform_driversWolfram Sang1-1/+0
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-09-02i2c: mv64xxx: continue probe when clock-frequency is missingChen-Yu Tsai1-2/+1
The "clock-frequency" DT property is listed as optional, However, the current code stores the return value of of_property_read_u32 in the return code of mv64xxx_of_config, but then forgets to clear it after setting the default value of "clock-frequency". It is then passed out to the main probe function, resulting in a probe failure when "clock-frequency" is missing. This patch checks and then throws away the return value of of_property_read_u32, instead of storing it and having to clear it afterwards. This issue was discovered after the property was removed from all sunxi DTs. Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Cc: stable@vger.kernel.org Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-07-16i2c: i2c-mv64xxx: Drop class based scanning to improve bootup timeWolfram Sang1-1/+1
This driver has been flagged to drop class based instantiation. The removal improves boot-up time and is unneeded for embedded controllers. Users have been warned to switch for some time now, so we can actually do the removal. Keep the DEPRECATED flag, so the core can inform users that the behaviour finally changed now. After another transition period, this flag can go, too. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-05-22i2c: mv64xxx: Change i2c compatibles for sunxiMaxime Ripard1-1/+1
The Allwinner A10 compatibles were following a slightly different compatible patterns than the rest of the SoCs for historical reasons. Move to the other pattern for consistency across all Allwinner Socs. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> [wsa: dropped binding OK as per http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/229438.html] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-28i2c: i2c-mv64xxx: deprecate class based instantiationWolfram Sang1-1/+1
Warn users that class based instantiation is going away soon in favour of more robust probing and faster bootup times. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-28i2c: mv64xxx: Fix reset controller handlingMaxime Ripard1-3/+3
The reset framework recently gained optional stubs when CONFIG_RESET_CONTROLLER is not selected. It also introduced a function reset_get_optional, that is also dummy-defined whenever the framework isn't enabled, for drivers that needs an optional reset controller. Switch to this function, since the mv64xxx driver is in this case. This also fixes a compilation breakage whenever the reset framework wasn't selected: drivers/i2c/busses/i2c-mv64xxx.c:771:2: error: implicit declaration of function 'devm_reset_control_get' While we're at it, remove the redundant test on dev.of_node surrounding the calls to reset framework functions, since it will either be a valid pointer, an error pointer in the case where we called reset_get_optional without an of_node pointer or if it failed, or NULL if we're not loaded through DT. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-10i2c: mv64xxx: refactor initialization for new msgsWolfram Sang1-10/+6
We now have a central place to put this code to. Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-10i2c: mv64xxx: directly call send_start when initializing transferWolfram Sang1-7/+1
Calling the state machine with a definite state which is only used in this context is superfluous. Do it directly. Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-10i2c: mv64xxx: refactor send_startWolfram Sang1-14/+13
For start and restart, we are doing the same thing. Let's consolidate that. Tested-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-05i2c: mv64xxx: Add support for the Allwinner A31 I2C driverMaxime Ripard1-0/+11
The Allwinner A31 I2C controller is almost identical to the one used in the other Allwinner SoCs, except for the fact that it needs to clear the interrupt by setting the INT_FLAGS bit in the control register, instead of clearing it. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-03-05i2c: mv64xxx: Add reset deassert callMaxime Ripard1-2/+19
The Allwinner A31 SoC using that IP has a reset controller maintaining it reset unless told otherwise. Add some optional reset support to the driver. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-02-15i2c: mv64xxx: refactor message start to ensure proper initializationWolfram Sang1-19/+14
Because the offload mechanism can fall back to a standard transfer, having two seperate initialization states is unfortunate. Let's just have one state which does things consistently. This fixes a bug where some preparation was missing when the fallback happened. And it makes the code much easier to follow. To implement this, we put the check if offload is possible at the top of the offload setup function. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: stable@vger.kernel.org # v3.12+ Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
2014-01-14i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCsGregory CLEMENT1-0/+5
The first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. The commit introduces a new the compatible string marvell,mv78230-a0-i2c for the i2c controller. When this compatible string is used the driver disables the offload mechanism and the kernel no more hangs on these SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reported-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org # v3.12+: af8d1c63afcb: ARM: mvebu: Add support to get the ID and the revision of a SoC Cc: stable@vger.kernel.org # v3.12+: 85e618a1be2b: ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board Cc: stable@vger.kernel.org # v3.12+ Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-10-03i2c: remove redundant of_match_ptrSachin Kamat1-1/+1
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-09-27i2c: mv64xxx: Do not use writel_relaxed()Thierry Reding1-2/+2
The driver is used on PowerPC which don't provide writel_relaxed(). This breaks the c2k and prpmc2800 default configurations. To fix the build, turn the calls to writel_relaxed() into writel(). The impacts for ARM should be minimal. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-09-27i2c: mv64xxx: Fix some build warningsThierry Reding1-5/+7
Some functions and variables are only used if the configuration selects HAVE_CLK. Protect them with a corresponding #ifdef CONFIG_HAVE_CLK block to avoid compiler warnings. Signed-off-by: Thierry Reding <treding@nvidia.com> [wsa: added marker to #endif] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-23i2c: move OF helpers into the coreWolfram Sang1-3/+0
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-23i2c: mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)Gregory CLEMENT1-2/+13
All the Armada XP (mv78230, mv78260 and mv78460) have a silicon issue in the I2C controller which violate the i2c repeated start timing. The I2C standard requires a minimum of 4.7us for the repeated start condition whereas the I2C controller of the Armada XP this time is 2.9us. So this patch adds a 5us delay for the start case only if the the compatible i2c-mv78230 is set. Based on the initals patches from Zbigniew Bodek Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Zbigniew Bodek <zbb@semihalf.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-23i2c: mv64xxx: Add I2C Transaction Generator supportGregory CLEMENT1-11/+182
The I2C Transaction Generator offloads CPU from managing I2C transfer step by step. This feature is currently only available on Armada XP, so usage of this mechanism is activated through device tree. Based on the work of Piotr Ziecik and rewrote to use the new way of handling multiples i2c messages. Signed-off-by: Piotr Ziecik <kosmo@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-19i2c: use dev_get_platdata()Jingoo Han1-1/+1
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-25i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not providedGregory CLEMENT1-1/+5
This commit adds checking whether clock-frequency property acquisition has succeeded. If not, the frequency is set to 100kHz by default. The Device Tree binding documentation is updated accordingly. Based on the intials patches from Zbigniew Bodek Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Zbigniew Bodek <zbb@semihalf.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-25i2c: mv64xxx: Fix transfer error codeGuenter Roeck1-1/+1
The driver returns -ENODEV as error code if it did not get an ACK from the device. Per Documentation/i2c/fault-codes, it should return -ENXIO. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-15i2c: mv64xxx: Add Allwinner sun4i compatibleMaxime Ripard1-0/+11
Add the compatible string for the Allwinner A10 i2c controller and the associated register layout. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-15i2c: mv64xxx: make the registers offset configurableMaxime Ripard1-39/+62
The Allwinner i2c controller uses the same logic as the Marvell one, but with slightly different register offsets. Introduce a structure that will be passed by either the pdata or associated to the compatible strings, and that holds the various registers that might be needed. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-15i2c: mv64xxx: Add macros to access parts of registersMaxime Ripard1-2/+6
These macros make it more comprehensive to access to useful masked and shifted area of the various registers used. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: fix race between FSM/interrupt and process contextRussell King1-20/+34
Asking for a multi-part message to be handled by this driver is racy; it has been observed that the following sequence is possible with this driver: - send start - send address + write - send data - send (repeated) start - send address + write - send (repeated) start - send address + read - unrecoverable bus hang (except by system reset) The problem is that the interrupt handling sees the next event after the first repeated start is sent - the IFLG bit is set in the register even though INTEN is disabled. Let's fix this by moving all of the message processing into interrupt context, rather than having it partly in IRQ and partly in process context. This allows us to move immediately to the next message in the interrupt handler and get on with the transfer, rather than incuring a couple of scheduling switches to get the next message. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: move mv64xxx_i2c_prepare_for_io()Russell King1-26/+26
Move mv64xxx_i2c_prepare_for_io() higher up in the driver to avoid a future forward declaration for this function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: remove I2C_M_NOSTART codeRussell King1-21/+5
As this driver does not advertise protocol mangling support (I2C_FUNC_PROTOCOL_MANGLING is not set), having code to act on I2C_M_NOSTART is illogical, and in any case isn't supportable on anything but the first message - which makes no sense. Remove the I2C_M_NOSTART code. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: fix error handling for request_irq()Russell King1-5/+5
Propagate the error code from request_irq() rather than ignoring it entirely. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: use devm_kzalloc()Russell King1-14/+10
As we're changing to using devm_* APIs to fix various problems in this driver, lets also do devm_kzalloc() while we're here too. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: use devm_clk_get() to avoid missing clk_put()Russell King1-1/+1
This driver forgets to use clk_put(). Rather than adding clk_put(), lets instead use devm_clk_get() to obtain this clock so that it's automatically handled on cleanup. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: use devm_ioremap_resource()Russell King1-40/+6
Eliminate reg_base_p and reg_size, mv64xxx_i2c_unmap_regs() and an unchecked ioremap() return from this driver by using the devm_* API for requesting and ioremapping resources. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-06-05I2C: mv64xxx: use return value from mv64xxx_i2c_map_regs()Russell King1-3/+2
mv64xxx_i2c_map_regs() already returns an error code, so lets propagate that to mv64xxx_i2c_probe()'s caller. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-17i2c: mv64xxx: work around signals causing I2C transactions to be abortedRussell King1-4/+4
Do not use interruptible waits in an I2C driver; if a process uses signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can cause the I2C driver to abort a transaction in progress by another driver, which can cause that driver to fail. I2C drivers are not expected to abort transactions on signals. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-04-02i2c: Ignore return value of i2c_del_adapter()Lars-Peter Clausen1-3/+2
i2c_del_adapter() always returns 0. So all checks testing whether it will be non zero will always evaluate to false and the conditional code is dead code. This patch updates all callers of i2c_del_mux_adapter() to ignore the return value and assume that it will always succeed (which it will). In a subsequent patch the return type of i2c_del_adapter() will be made void. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Ben Hutchings <bhutchings@solarflare.com> Reviewed-by: Jean Delvare <khali@linux-fr.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2012-12-22i2c: remove __dev* attributes from subsystemBill Pemberton1-9/+9
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <wfp5p@virginia.edu> Acked-by: Peter Korsgaard <peter.korsgaard@barco.com> (for ocores and mux-gpio) Acked-by: Havard Skinnemoen <hskinnemoen@gmail.com> (for i2c-gpio) Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> (for puf3) Acked-by: Barry Song <baohua.song@csr.com> (for sirf) Reviewed-by: Jean Delvare <khali@linux-fr.org> [wsa: Fixed "foo* bar" flaws while we are here] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-07-23I2C: MV64XYZ: Add Device Tree supportAndrew Lunn1-5/+128
Extends the driver to get properties from device tree. Rather than pass the N & M factors in DT, use the more standard clock-frequency property. Calculate N & M at run time. In order to do this, we need to know tclk. So the driver uses clk_get() etc in order to get the clock and clk_get_rate() to determine the tclk rate. Not all platforms however have CLK, so some #ifdefery is needed to ensure the driver still compiles when CLK is not available. Signed-off-by: Andrew Lunn <andrew@lunn.ch> [wsa: converted some ints to u32 to match signedness] Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-07-12i2c-mv64xxxx: allow more than one driver instanceFlorian Fainelli1-1/+1
The driver currently checks the platform device id and rejects platform device id different from 0. This prevents the registration of a second i2c controller on systems where a second one might be available (such as Kirkwood 88F6282). CC: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Florian Fainelli <ffainelli@freebox.fr> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
2012-01-12i2c/busses: Use module_platform_driver()Axel Lin1-14/+1
Convert the drivers in drivers/i2c/busses/* to use the module_platform_driver() macro which makes the code smaller and a bit simpler. Cc: Ben Dooks <ben-linux@fluff.org> Acked-by: Jochen Friedrich <jochen@scram.de> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Manuel Lauss <manuel.lauss@googlemail.com> Cc: Barry Song <21cnbao@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Yong Zhang <yong.zhang0@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2011-01-04i2c-mv64xxx: send repeated START between messages in xferRodolfo Giometti1-7/+38
As stated into file include/linux/i2c.h we must send a repeated START between messages in the same xfer groupset: * Except when I2C "protocol mangling" is used, all I2C adapters implement * the standard rules for I2C transactions. Each transaction begins with a * START. That is followed by the slave address, and a bit encoding read * versus write. Then follow all the data bytes, possibly including a byte * with SMBus PEC. The transfer terminates with a NAK, or when all those * bytes have been transferred and ACKed. If this is the last message in a * group, it is followed by a STOP. Otherwise it is followed by the next * @i2c_msg transaction segment, beginning with a (repeated) START. Signed-off-by: Rodolfo Giometti <giometti@linux.it> Signed-off-by: Mauro Barella <mbarella@vds-it.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
2010-05-21i2c: Use <linux/io.h> instead of <asm/io.h>H Hartley Sweeten1-2/+1
As warned by checkpatch.pl, <linux/io.h> should be used instead of <asm/io.h>. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.hTejun Heo1-0/+1
percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2009-12-06i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDRJean Delvare1-3/+0
I2C bus drivers don't have to support I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed. Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Ben Dooks <ben-linux@fluff.org>