- 27 May, 2021 1 commit
-
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/i2c/busses/i2c-ocores.c:253: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/i2c/busses/i2c-ocores.c:267: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/i2c/busses/i2c-ocores.c:299: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/i2c/busses/i2c-ocores.c:347: warning: expecting prototype for It handles an IRQ(). Prototype was for ocores_process_polling() instead Signed-off-by:
Lee Jones <lee.jones@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
- 03 Dec, 2020 1 commit
-
-
Stefan Lässer authored
Since commit 7723f4c5 ("driver core: platform: Add an error message to platform_get_irq*()"), platform_get_irq() will call dev_err() on an error. In case of i2c ocores this leads to a false-positive error being logged: [ 4.173989] 007: ocores-i2c ocores-i2c: IRQ index 0 not found i2c ocores already handles the case when the IRQ cannot be found and therefore there is no benefit in having this error message being logged. This commit switches to platform_get_irq_optional(), which does not log in case the IRQ cannot be found. Signed-off-by:
Stefan Lässer <stefan.laesser@omicronenergy.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
- 03 Nov, 2020 1 commit
-
-
Sagar Shrikant Kadam authored
The FU540-C000 has a broken IRQ and support was added earlier so that it will operate in polling mode, but seems to work only in case interrupts property is missing from the i2c0 dt-node. This should not be the case and the driver should handle polling mode with the interrupt property present in i2c0 node of the device tree. So check if it's the FU540-C000 soc and enable polling mode master xfers, as the IRQ for this chip is broken. Fixes commit c45d4ba8 ("i2c: ocores: add polling mode workaround for Sifive FU540-C000 SoC") Signed-off-by:
Sagar Shrikant Kadam <sagar.kadam@sifive.com> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
- 15 Jan, 2020 1 commit
-
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 29 Aug, 2019 1 commit
-
-
Federico Vaga authored
The i2c-ocores device is an HDL component that get instantiated in FPGA. The software stack used to drive an FPGA can be very different, and the i2c-ocore ip-core must work in different context. With respect to this patch the IRQ controller behind this device, and its driver, can have different implementations (nested threads). For this reason, it is safer to use `request_any_context_irq()` to avoid errors at probe time. Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 14 Jun, 2019 2 commits
-
-
Sagar Shrikant Kadam authored
The i2c-ocore driver already has a polling mode interface.But it needs a workaround for FU540 Chipset on HiFive unleashed board (RevA00). There is an erratum in FU540 chip that prevents interrupt driven i2c transfers from working, and also the I2C controller's interrupt bit cannot be cleared if set, due to this the existing i2c polling mode interface added in mainline earlier doesn't work, and CPU stall's infinitely, when-ever i2c transfer is initiated. Ref: commit dd7dbf0e ("i2c: ocores: refactor setup for polling") The workaround / fix under OCORES_FLAG_BROKEN_IRQ is particularly for FU540-COOO SoC. The polling function identifies a SiFive device based on the device node and enables the workaround. Signed-off-by:
Sagar Shrikant Kadam <sagar.kadam@sifive.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Sagar Shrikant Kadam authored
Update device id table for Opencore's I2C master based re-implementation used in FU540-c000 chipset on HiFive Unleashed platform. Device ID's include Sifive, soc-specific device for chip specific tweaks and sifive IP block specific device for generic programming model. Signed-off-by:
Sagar Shrikant Kadam <sagar.kadam@sifive.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 16 Apr, 2019 2 commits
-
-
Wolfram Sang authored
The driver already has the routine in place, tie it to the new callback. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
By properly setting up the algorithm at probe time, we can skip the check at every transfer. This allows us to get rid of the flags completely. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: Andrew Lunn <andrew@lunn.ch> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 24 Feb, 2019 1 commit
-
-
Wolfram Sang authored
gcc complains, rightfully so, I think: drivers/i2c/busses/i2c-ocores.c:32: warning: Cannot understand * @process_lock: protect I2C transfer process. on line 32 - I thought it was a doc line Make it a simple comment. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 14 Feb, 2019 7 commits
-
-
Andrew Lunn authored
Add the I2C bus clock speed to the platform data structure. If not set, default to 100KHz as before. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Andrew Lunn authored
Some implementations of the OCORES i2c bus master use IO mapped registers. Add support for getting the IO registers from the platform data, and register accessor functions. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
Miscellaneous style fixes from checkpatch Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
It adds the SPDX tag and it removes the old text about the GPLv2. Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
This driver assumes that an interrupt line is always available for the I2C master. This is not always the case and this patch adds support for a polling version. Report from Andrew Lunn: I did some timing tests for this. On my box, we request a udelay of 80uS. The kernel actually delays for about 79uS. We then spin in ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations. There are actually 9 bits on the wire, not 8, since there is an ACK/NACK bit after the actual data transfer. So i changed the delay to (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly not looping at all. But for reading an 4K AT24 EEPROM, it increased the read time by 10ms, from 424ms to 434ms. So we should probably keep with 8. Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
If the Interrupt Flag (IF) is not set, we should not handle the IRQ: - the line can be shared with other devices - it can be a spurious interrupt To avoid reading twice the status register, the ocores_process() function expects it to be read by the caller. Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
Detecting a timeout is ok, but we also need to assert a STOP command on the bus in order to prevent it from generating interrupts when there are no on going transfers. Example: very long transmission. 1. ocores_xfer: START a transfer 2. ocores_isr : handle byte by byte the transfer 3. ocores_xfer: goes in timeout [[bugfix here]] 4. ocores_xfer: return to I2C subsystem and to the I2C driver 5. I2C driver : it may clean up the i2c_msg memory 6. ocores_isr : receives another interrupt (pending bytes to be transferred) but the i2c_msg memory is invalid now So, since the transfer was too long, we have to detect the timeout and STOP the transfer. Another point is that we have a critical region here. When handling the timeout condition we may have a running IRQ handler. For this reason I introduce a spinlock. In order to make easier to understan locking I have: - added a new function to handle timeout - modified the current ocores_process() function in order to be protected by the new spinlock Like this it is obvious at first sight that this locking serializes the execution of ocores_process() and ocores_process_timeout() Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 24 Aug, 2018 1 commit
-
-
Peter Korsgaard authored
The old @sunsite.dk address is no longer active, so update the references. Signed-off-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 29 May, 2018 2 commits
-
-
Peter Rosin authored
Because it looks neater. For diolan, this allows factoring out some code that is now common between if and else. For eg20t, pch_i2c_writebytes is always called with a write in msgs->flags, and pch_i2c_readbytes with a read. For imx, i2c_imx_dma_write and i2c_imx_write are always called with a write in msgs->flags, and i2c_imx_read with a read. For qup, qup_i2c_write_tx_fifo_v1 is always called with a write in qup->msg->flags. For stu300, also restructure debug output for resends, since that code as a result is only handling debug output. Reviewed-by: Guenter Roeck <linux@roeck-us.net> [diolan] Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [efm32 and imx] Acked-by: Linus Walleij <linus.walleij@linaro.org> [stu300] Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Federico Vaga authored
The URL is broken. This patch fixes it. Signed-off-by:
Federico Vaga <federico.vaga@vaga.pv.it> [wsa: shortened the URL a bit] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 17 May, 2018 1 commit
-
-
Wolfram Sang authored
This header only contains platform_data. Move it to the proper directory. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Lee Jones <lee.jones@linaro.org>
-
- 29 Aug, 2017 1 commit
-
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 22 Aug, 2016 1 commit
-
-
Wolfram Sang authored
The core will do this for us now. Signed-off-by:
Wolfram Sang <wsa-dev@sang-engineering.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Ray Jui <ray.jui@broadcom.com> Acked-by:
Vladimir Zapolskiy <vz@mleia.com> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 14 Aug, 2016 1 commit
-
-
Alexey Khoroshilov authored
clk_disable_unprepare() is missed on failure paths in ocores_i2c_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 11 Apr, 2016 1 commit
-
-
Wolfram Sang authored
Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 20 Oct, 2015 1 commit
-
-
Max Filippov authored
This allows using OpenCores I2C controller attached to its host in native-endian mode with bi-endian CPUs. Example of such system is Xtensa XTFPGA platform. Acked-by:
Peter Korsgaard <peter@korsgaard.com> Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 20 Feb, 2015 1 commit
-
-
Wolfram Sang authored
For, !HAVE_CLK the clk API returns a NULL cookie. Rework the initialization code to handle that. If clk_get_rate() delivers 0, we use the fallback mechanisms. The patch is pretty easy when ignoring white space issues (git diff -b). Suggested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Tested-by:
Max Filippov <jcmvbkbc@gmail.com>
-
- 05 Feb, 2015 2 commits
-
-
Max Filippov authored
Allow bus clock specification as a common clock handle. This makes this controller easier to use in a setup based on common clock framework. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Max Filippov authored
clock-frequency property is meant to control the bus frequency for i2c bus drivers, but it was incorrectly used to specify i2c controller input clock frequency. Introduce new attribute, opencores,ip-clock-frequency, that specifies i2c controller clock frequency and make clock-frequency attribute compatible with other i2c drivers. Maintain backwards compatibility in case opencores,ip-clock-frequency attribute is missing. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 20 Oct, 2014 1 commit
-
-
Wolfram Sang authored
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>
-
- 16 Jul, 2014 1 commit
-
-
Wolfram Sang authored
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. While we are here, remove the indentation for the array setup because such things always break after some time. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Peter Korsgaard <peter@korsgaard.com>
-
- 02 Jun, 2014 1 commit
-
-
Jingoo Han authored
Make of_device_id array const, because all OF functions handle it as const. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Acked-by:
Peter Korsgaard <peter@korsgaard.com> Acked-by:
Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 05 Mar, 2014 1 commit
-
-
Wolfram Sang authored
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> Acked-by:
Peter Korsgaard <jacmet@sunsite.dk>
-
- 24 Jan, 2014 1 commit
-
-
Paul Gortmaker authored
None of these files are actually using any __init type directives and hence don't need to include <linux/init.h>. Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 23 Aug, 2013 1 commit
-
-
Wolfram Sang authored
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>
-
- 19 Aug, 2013 1 commit
-
-
Jingoo Han authored
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>
-
- 15 Aug, 2013 2 commits
-
-
Julia Lawall authored
Remove unneeded error handling on the result of a call to platform_get_resource when the value is passed to devm_ioremap_resource. Move the call to platform_get_resource adjacent to the call to devm_ioremap_resource to make the connection between them more clear. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/ ) // <smpl> @@ expression pdev,res,n,e,e1; expression ret != 0; identifier l; @@ - res = platform_get_resource(pdev, IORESOURCE_MEM, n); ... when != res - if (res == NULL) { ... \(goto l;\|return ret;\) } ... when != res + res = platform_get_resource(pdev, IORESOURCE_MEM, n); e = devm_ioremap_resource(e1, res); // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
Jingoo Han authored
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_suspend' defined but not used [-Wunused-function] drivers/i2c/busses/i2c-ocores.c:471:12: warning: 'ocores_i2c_resume' defined but not used [-Wunused-function] Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- 21 Feb, 2013 2 commits
-
-
Doug Anderson authored
There is simply no reason to be manually setting the private driver data to NULL in the remove/fail to probe cases. This is just extra cruft code that can be removed. A few notes: * Nothing relies on drvdata being set to NULL. * The __device_release_driver() function eventually calls dev_set_drvdata(dev, NULL) anyway, so there's no need to do it twice. * I verified that there were no cases where xxx_get_drvdata() was being called in these drivers and checking for / relying on the NULL return value. This could be cleaned up kernel-wide but for now just take the baby step and remove from the i2c subsystem. Reported-by:
Wolfram Sang <wsa@the-dreams.de> Reported-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
Doug Anderson <dianders@chromium.org> Reviewed-by:
Jean Delvare <khali@linux-fr.org> Acked-by:
Peter Korsgaard <jacmet@sunsite.dk> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Wolfram Sang <wolfram@the-dreams.de>
-
Jayachandran C authored
After commit a000b8c1 [i2c: ocores: Add support for the GRLIB port of the controller and use function pointers for getreg and setreg function], compiling i2c-ocores.c for 64-bit gives the following warning: drivers/i2c/busses/i2c-ocores.c: In function 'ocores_i2c_of_probe': drivers/i2c/busses/i2c-ocores.c:334:15: warning: cast from pointer to integer of different size Fix it by casting the pointer to long. Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Acked-by:
Peter Korsgaard <jacmet@sunsite.dk> Acked-by:
Andreas Larsson <andreas@gaisler.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-