summaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)Author
2020-04-21Merge tag 'for-v2020.07' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2cTom Rini
i2c changes for 2020.07 - add new i2c driver for Broadcom iproc-based socs - fix cmd: eeprom: Staticize eeprom_i2c_bus - i2c: muxes: pca954x: add PCA9546 variant
2020-04-20drivers: i2c: add brcm iproc I2C driver supportRayagonda Kokatanur
Add I2C driver support for Broadcom iproc-based socs. Signed-off-by: Arjun Jyothi <arjun.jyothi@broadcom.com> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Sheetal Tigadoli <sheetal.tigadoli@broadcom.com> Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-04-20i2c: muxes: pca954x: add PCA9546 variantChris Packham
This adds the PCA9546 4-channel i2c bus switch. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-04-17doc: fix references to driver-modelHeinrich Schuchardt
Fix some errors pointed out by 'make refcheckdocs'. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-03-24i2c: stm32f7_i2c: allows for any bus frequencyAlain Volmat
Do not limit to 3 (100KHz, 400KHz, 1MHz) bus frequencies, but instead allow for any frequency. Depending on the requested frequency (via the clock-frequency DT entry), use the spec data from either Standard, Fast or Fast Plus mode. In order to do so, the driver do not use anymore spec identifier by directly handle the requested frequency and from it retrieve the corresponding spec data to be used for the computation of the timing register. Signed-off-by: Alain Volmat <alain.volmat@st.com> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Patrice Chotard <patrice.chotard@st.com>
2020-03-16i2c: designware_i2c: add 'hs_hcnt' and 'hs_lcnt' for high speedJun Chen
Add support for high speed if scl_sda_cfg exist. Signed-off-by: Jun Chen <ptchentw@gmail.com> Signed-off-by: Jun Chen <jun.chen@vatics.com>
2020-03-16i2c: designware_i2c: remove 'has_high_speed'Jun Chen
Remove 'has_high_speed' config since we can check high speed support from IC_COMP_PARAM_1 register. Signed-off-by: Jun Chen <ptchentw@gmail.com> Signed-off-by: Jun Chen <jun.chen@vatics.com>
2020-03-16i2c: designware_i2c: check is high speed possible supportJun Chen
To read IC_COMP_PARAM_1[3:2] to check is high speed possible, and fall back to fast mode if not. Signed-off-by: Jun Chen <ptchentw@gmail.com> Signed-off-by: Jun Chen <jun.chen@vatics.com>
2020-03-16i2c: designware_i2c: Fix IC_CON register setting for high speed modeJun Chen
IC_CON[2:1] should be 3 for high speed mode Signed-off-by: Jun Chen <ptchentw@gmail.com> Signed-off-by: Jun Chen <jun.chen@vatics.com>
2020-03-16dm: i2c-gpio: add support for clock stretchingHeiko Schocher
This adds support for clock stretching to the i2c-gpio driver. This is accomplished by switching the GPIO used for the SCL line to an input when it should be driven high, and polling on the SCL line value until it goes high (indicating that the I2C slave is no longer pulling it low). This is enabled by default; for gpios which cannot be configured as inputs, the i2c-gpio,scl-output-only property can be used to fall back to the previous behavior. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Cc: Heiko Schocher <hs@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-16dm: i2c-gpio: rework gpio get/set functionsMichael Auchter
This patch reworks i2c-gpio to make it easier to switch out the implementation of the sda/scl get/set functions. This is in preparation for a patch to conditionally implement clock stretching support. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Cc: Heiko Schocher <hs@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-16i2c: gpio: Run deblock sequence on probeMarek Vasut
Add deblock dequence for the I2C bus, needed on some devices. This sequence is issued once, when probing the driver, and is controlled by DT property, "i2c-gpio,deblock". Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-16i2c: Add option to send start condition after deblockingMarek Vasut
Add option to send start condition after deblocking SDA. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-16i2c: Export i2c_deblock_gpio_loop()Marek Vasut
Export the i2c_deblock_gpio_loop() so it can be used in other places in U-Boot. In particular, this is useful in the GPIO I2C driver, which claims the SDA/SCL GPIOs and thus prevents the i2c_deblock() implementation from claiming the pins as GPIOs again. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-16i2c: Make deblock delay and SCL clock configurableMarek Vasut
Make the delay between SCL line changes and the number of SCL clock changes configurable as a parameter of the deblock function. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-02-18i2c: designware_i2c: Correct the selection of speed modeSimon Glass
Unfortunately a recent change adjusted the order of the checks here such that 400MHz now shows up as fast-plus speed (1Mbps). Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: d96440d1e3 ("i2c: designware_i2c: Add support for fast-plus speed")
2020-02-11Merge tag 'dm-pull-6feb20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dmTom Rini
sandbox conversion to SDL2 TPM TEE driver Various minor sandbox video enhancements New driver model core utility functions
2020-02-07tegra: i2c: Change driver to use helper functionSimon Glass
Now that we have uclass_first_device_drvdata(), use it from the I2C driver to reduce code duplication. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-02-05dm: core: Create a new header file for 'compat' featuresSimon Glass
At present dm/device.h includes the linux-compatible features. This requires including linux/compat.h which in turn includes a lot of headers. One of these is malloc.h which we thus end up including in every file in U-Boot. Apart from the inefficiency of this, it is problematic for sandbox which needs to use the system malloc() in some files. Move the compatibility features into a separate header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-02-05dm: core: Require users of devres to include the headerSimon Glass
At present devres.h is included in all files that include dm.h but few make use of it. Also this pulls in linux/compat which adds several more headers. Drop the automatic inclusion and require files to include devres themselves. This provides a good indication of which files use devres. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2020-02-04i2c: mxc_i2c: add DM_FLAG_PRE_RELOC flagBiwen Li
This adds DM_FLAG_PRE_RELOC flag to probe i2c driver before relocation Signed-off-by: Biwen Li <biwen.li@nxp.com> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2020-01-27i2c: designware_i2c: Do more in the probe() methodSimon Glass
Move some of the code currently in the ofdata_to_platdata() method to probe() so that it is not executed when generating ACPI tables. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27i2c: designware_i2c: Separate out the speed calculationSimon Glass
We want to be able to calculate the speed separately from actually setting the speed, so we can generate the required ACPI tables. Split out the calculation into its own function. Drop the double underscore on __dw_i2c_set_bus_speed while we are here. That is reserved for compiler internals. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27i2c: designware_i2c: Move dw_i2c_speed_config to headerSimon Glass
This is used to store the speed information for a bus. We want to provide this to ACPI so that it can tell the kernel. Move this struct to the header file so it can be accessed by the ACPI i2c implementation being added later. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27i2c: designware_i2c: Add support for fast-plus speedSimon Glass
Fast-plus runs at 1MHz and is used by some devices. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27i2c: Update drivers to use enum for speedSimon Glass
Convert the obvious uses of i2c bus speeds to use the enum. Use livetree access for code changes. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: stm32: Update to use standard enums for speedSimon Glass
Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com> Tested-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: omap: Update to use standard enums for speedSimon Glass
Update this driver to use the new standard enums for speed. Note: This driver needs to move to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: kona_i2c: Update to use standard enums for speedSimon Glass
Update this driver to use the new standard enums for speed. Note: This driver needs to move to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Update to use standard enums for speedSimon Glass
Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: ast_i2c: Update to use standard enums for speedSimon Glass
Update this driver to use the new standard enums for speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Add spike supressionSimon Glass
Some versions of this peripheral include a spike-suppression phase of the bus. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Rewrite timing calculationSimon Glass
At present the driver can end up with timing parameters which are slightly faster than those expected. It is possible to optimise the parameters to get the best possible result. Create a new function to handle the timing calculation. This uses a table of defaults for each speed mode rather than writing it in code. The function works by calculating the 'period' of each bit on the bus in terms of the input clock to the controller (IC_CLK). It makes sure that the constraints are met and that the different components of that period add up correctly. This code was taken from coreboot which has ended up with this same driver, but now in a much-different form. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Put hold config in a structSimon Glass
Create a struct to hold the three timing parameters. This will make it easier to move these calculations into a separate function in a later patch. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Drop scl_sda_cfg parameterSimon Glass
Instead of passing this parameter into __dw_i2c_set_bus_speed(), pass in the driver's private data, from which the function can obtain that information. This allows the function to have access to the full state of the driver. Signed-off-by: Sicomp_param1mon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-27i2c: designware_i2c: Read device-tree propertiesSimon Glass
The i2c controller defines a few timing properties. Read these in and store them for use by the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Use an accurate bus clock instead of MHzSimon Glass
At present the driver uses an approximation for the bus clock, e.g. 166MHz instead of 166 2/3 MHz. This can result in small errors in the resulting I2C speed, perhaps 0.5% or so. Adjust the existing code to start from the accurate figure, even if later rounding reduces this accuracy. Update the bus speed code to work in KHz instead of MHz, which removes most of the error. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Use an enum for selected speed modeSimon Glass
Group these #defines into an enum to make it easier to understand the relationship between them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Rename 'max' speed to 'high' speedSimon Glass
Some SoCs support a higher speed than what is currently called 'max' in this driver. Rename it to 'high' speed, which is the official name of the 3.4MHz speed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Include clk.h in the header fileSimon Glass
We use struct clk here so really should include this header file to avoid build errors. Also switch the order of clk.h in the C file to match the required code style. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Don't allow changing IC_CLKSimon Glass
If a different input clock is required then the correct way to do this is with a clock driver. Don't allow boards to override IC_CLK. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Add more registersSimon Glass
Some versions of this peripherals provide more control of the bus behaviour. Add definitions for these registers. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-12-18Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-x86 ↵Tom Rini
into next - Various x86 common codes updated for TPL/SPL - I2C designware driver updated for PCI - ICH SPI driver updated to support Apollo Lake - Add Intel FSP2 base support - Intel Apollo Lake platform specific drivers support - Add a new board Google Chromebook Coral
2019-12-17i2c: add support for offset overflow in to addressRobert Beckett
Some devices (2 wire eeproms for example) use some bits from the chip address to represent the high bits of the offset instead of or as well as using multiple bytes for the offset, effectively stealing chip addresses on the bus. Add a chip offset mask that can be set for any i2c chip which gets filled with the offset overflow during offset setup. Signed-off-by: Robert Beckett <bob.beckett@collabora.com> Signed-off-by: Ian Ray <ian.ray@ge.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-12-15i2c: designware: Add Apollo Lake supportSimon Glass
For Apollo Lake we need to take the I2C bus controller out of reset before using this. Add this functionality to the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Support use in SPLSimon Glass
Allow this driver to set up an IO address in SPL using an 'early-regs' property. This allows SPL to use the I2C driver without having to enable the full PCI stack. Also split out ofdata_to_platdata in designware driver since this is more correct, and more convenient for the new logic. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Avoid using static dataSimon Glass
Drivers are not allowed to use static data since they may be used in SPL where BSS is not available. It is possible that driver model may provide support for numbering devices in the future. But for now, move this to global_data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Tidy up PCI supportSimon Glass
This is hacked into the driver at present. It seems better to have it as a separate driver that uses the base driver. Create a new file and put the X86 code into it. Actually the Baytrail settings should really come from the device tree. Note that 'has_max_speed' is added as well. This is currently always false but since only Baytrail provides the config, it does not affect operation for other devices. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15dm: gpio: Allow control of GPIO uclass in SPLSimon Glass
At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass is included in SPL/TPL without any control for boards. Some boards may want to disable this to reduce code size where GPIOs are not needed in SPL or TPL. Add a new Kconfig option to permit this. Default it to 'y' so that existing boards work correctly. Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to preserve the current behaviour. Also update the 74x164 GPIO driver since it cannot build with SPL. This allows us to remove the hacks in config_uncmd_spl.h and Makefile.uncmd_spl (eventually those files should be removed). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-11i2c: i2c_cdns: fix write timeout on fifo boundaryMichael Auchter
This fixes an issue that would cause I2C writes to timeout when the number of bytes is a multiple of the FIFO depth (i.e. 16 bytes). Within the transfer loop, after writing the data register with a new byte to transfer, if the transfer size equals the FIFO depth, the loop pauses until the INTERRUPT_COMP bit asserts to indicate data has been sent. This same check is performed after the loop as well to ensure data has been transferred prior to returning. In the case where the amount of data to be written is a multiple of the FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to assert after writing the final byte, and then wait for this bit to assert once more. However, since the transfer has finished at this point, no new data has been written to the data register, and hence INTERRUPT_COMP will never assert. Fix this by only waiting for INTERRUPT_COMP in the transfer loop if there's still data to be written. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>