- 15 Jan, 2018 12 commits
-
-
Arseny Solokha authored
Remove the facility for setting the prescaler value at compile time entirely. It was only used for two SoCs, duplicating the actual value for one of them and setting sometimes bogus value for another. Make all MPC8xxx SoCs obtain their actual I2C clock prescaler from a single place in the code. Changes from v2: - left Device Tree compatibles in place Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Arseny Solokha authored
According to the reference manuals for the corresponding SoCs, SEC frequency ratio configuration is indicated by bit 26 of the POR Device Status Register 2. Consequently, SEC_CFG bit should be tested by mask 0x20, not 0x80. Testing the wrong bit leads to selection of wrong I2C clock prescaler on those SoCs. Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Arseny Solokha authored
Commit 8ce795cb ("i2c: mpc: assign the correct prescaler from SVR") introduced the common helper function for obtaining the actual clock prescaler value for MPC85xx. However, getting the prescaler for MPC8544 which depends on the SEC frequency ratio on this platform, has been always performed separately based on the corresponding Device Tree configuration. Move special handling of MPC8544 into that common helper. Make it dependent on the SoC version and not on Device Tree compatible node, as is the case with all other SoCs. Handle MPC8533 the same way which is similar to MPC8544 in this regard, according to AN2919 "Determining the I2C Frequency Divider Ratio for SCL". Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Arseny Solokha authored
Obtaining the actual I2C clock prescaler value in mpc_i2c_setup_8xxx() only happens when the clock parameter is set to something other than MPC_I2C_CLOCK_LEGACY. When the clock parameter is exactly MPC_I2C_CLOCK_LEGACY, the prescaler parameter is used in arithmetic division as provided by the caller, resulting in a division by zero for the majority of processors supported by the module. Avoid division by zero by obtaining the actual I2C clock prescaler in mpc_i2c_setup_8xxx() unconditionally regardless of the passed clock value. Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Radu Rendec authored
This patch dumps general and master registers at the end of transactions when debugging is enabled. Previously, registers were only dumped before submitting new descriptors (at the beginning of transactions). This helps debugging if some registers change as result of a failed transaction (e.g. bits are set in the ERRSTS general register). Signed-off-by: Radu Rendec <radu.rendec@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Make use of the new formula for more precise bus frequencies. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
The formula to generate the desired bus speeds has changed a little over time. Implement the new formula and allow drivers to opt-in by changing to this new config set. Ensure in probe that we don't divide by zero. The returned values on a R-Car H2 (r8a7790/Lager board) match the suggested values in the datasheet. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Because we will add a second formula soon, put the sanity checks for the computed results into a separate function. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Start RuntimePM a bit earlier, so we can use it to enable the clock during probe for frequency calculations. Make sure it is enabled before calling setup(). Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Require the setup callback and move the frequency calculation into it. This is in preparation for supporting multiple formulas. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
The setup callback will be more generic and, thus, need to be able to return error codes. Change the return type to 'int' for that. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
For refactoring reasons, we will need this information before the setup callback. Also, simplify the comment to a oneliner. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
- 04 Jan, 2018 1 commit
-
-
Jan Kundrát authored
"Slow" GPIOs (usually those connected over an SPI or an I2C bus) are, well, slow in their operation. It is generally a good idea to avoid using them for time-critical operation, but sometimes the hardware just sucks, and the software has to cope. In addition to that, the I2C bus itself does not actually define any strict timing limits; the bus is free to go all the way down to DC. The timeouts (and therefore the slowest acceptable frequency) are present only in SMBus. The `can_sleep` is IMHO a wrong concept to use here. My SPI-to-quad-UART chip (MAX14830) is connected via a 26MHz SPI bus, and it happily drives SCL at 200kHz (5µs pulses) during my benchmarks. That's faster than the maximal allowed speed of the traditional I2C. The previous version of this code did not really block operation over slow GPIO pins, anyway. Instead, it just resorted to printing a warning with a backtrace each time a GPIO pin was accessed, thereby slowing things down even more. Finally, it's not just me. A similar patch was originally submitted in 2015 [1]. [1] https://patchwork.ozlabs.org/patch/450956/Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
- 03 Jan, 2018 4 commits
-
-
Jun Gao authored
Make sure i2c module clock has been enabled before i2c registers access. Signed-off-by: Jun Gao <jun.gao@mediatek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Jun Gao authored
Add i2c compatible for MT2712. Compare to MT8173 i2c controller, internal divider of i2c source clock need to be configured for MT2712 i2c speed calculation. Signed-off-by: Jun Gao <jun.gao@mediatek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Jun Gao authored
Add MT2712 i2c binding to binding file. Compare to MT8173 i2c controller, MT2712 has timing adjust registers which can adjust the internal divider of i2c source clock, SCL duty cycle, SCL compare point, start(repeated start) and stop time, SDA change time. Signed-off-by: Jun Gao <jun.gao@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Merge tag 'at24-4.16-updates-for-wolfram' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-4.16 "AT24 updates for 4.16 merge window The driver has been converted to using regmap instead of raw i2c and smbus calls which shrank the code significantly. Device tree binding document has been cleaned up. Device tree support in the driver has been improved and we now support all at24 models as well as two new DT properties (no-read-rollover and wp-gpios). We no longer user unreadable magic values for driver data as the way it was implemented caused problems for some EEPROM models - we switched to regular structs. Aside from that, there's a bunch of coding style fixes and minor improvements all over the place."
-
- 02 Jan, 2018 4 commits
-
-
Bartosz Golaszewski authored
Add all supported at24 variants to the of_match table. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
-
Bartosz Golaszewski authored
Add other variants of at24 EEPROMs we support in the driver to the list of allowed compatible fallbacks. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
Bartosz Golaszewski authored
Make formatting and style consistent for the entire document. This patch doesn't change the content of the binding. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
Bartosz Golaszewski authored
Current description of the compatible property for at24 is quite vague. State explicitly that any "<manufacturer>,<model>" pair is accepted as long as a correct fallback is used for non-atmel chips. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Rob Herring <robh@kernel.org>
-
- 01 Jan, 2018 19 commits
-
-
Bartosz Golaszewski authored
Replace spaces with tabs in the definition of AT24_FLAG_NO_RDROL. Fixes: 9d404411091c ("eeprom: at24: support eeproms that do not auto-rollover reads") Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Bartosz Golaszewski authored
AT24 EEPROMs have a write-protect pin, which - when pulled high - inhibits writes to the upper quadrant of memory (although it has been observed that on some chips it disables writing to the entire memory range). On some boards, this pin is connected to a GPIO and pulled high by default, which forces the user to manually change its state before writing. On linux this means that we either need to hog the line all the time, or set the GPIO value before writing from outside of the at24 driver. Make the driver check if the write-protect GPIO was defined in the device tree and pull it low whenever writing to the EEPROM. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
-
Bartosz Golaszewski authored
AT24 EEPROMs have a write-protect pin, which - when pulled high - inhibits writes to the upper quadrant of memory (although it has been observed that on some chips it disables writing to the entire memory range). On some boards, this pin is connected to a GPIO and pulled high by default, which forces the user to manually change its state before writing. On linux this means that we either need to hog the line all the time, or set the GPIO value before writing from outside of the at24 driver. Add a new optional property to the device tree binding document, which allows to specify the GPIO line to which the write-protect pin is connected. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org>
-
Sven Van Asbroeck authored
The chip size passed via devicetree, i2c, or acpi device ids is now no longer limited to a power of two. So the temporary fix can be removed. Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Sven Van Asbroeck authored
Fundamental properties such as capacity and page size differ among at24-type chips. But these chips do not have an id register, so this can't be discovered at runtime. Traditionally, at24-type eeprom properties were determined in two ways: - by passing a 'struct at24_platform_data' via platform_data, or - by naming the chip type in the devicetree, which passes a 'magic number' to probe(), which is then converted to a 'struct at24_platform_data'. Recently a bug was discovered because the magic number rounds down all chip sizes to the lowest power of two. This was addressed by a work-around commit 5478e478 ("eeprom: at24: correctly set the size for at24mac402"), with the wish that magic numbers should over time be converted to structs. This patch replaces the magic numbers with 'struct at24_chip_data'. Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Bartosz Golaszewski authored
A regmap_config struct is pretty big and declaring two of them statically just to tweak the reg_bits value adds unnecessary bloat. Declare the regmap config locally in at24_probe() instead. Bloat-o-meter output for ARM: add/remove: 0/2 grow/shrink: 1/0 up/down: 4/-272 (-268) Function old new delta at24_probe 1560 1564 +4 regmap_config_8 136 - -136 regmap_config_16 136 - -136 Total: Before=7012, After=6744, chg -3.82% Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Bartosz Golaszewski authored
There are a couple symbols defined in the driver source file which are missing the at24_ prefix. This patch fixes that. For module params: use module_param_named() in order to not break userspace. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Bartosz Golaszewski authored
Fix issues reported by checkpatch for at24.c. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Bartosz Golaszewski authored
Add the link to my git tree to the at24 section. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Sven Van Asbroeck authored
Some multi-address eeproms in the at24 family may not automatically roll-over reads to the next slave address. On those eeproms, reads that straddle slave boundaries will not work correctly. Solution: Mark such eeproms with a flag that prevents reads straddling slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom entry in the device_id table, or add 'no-read-rollover' to the eeprom devicetree entry. Note that I have not personally enountered an at24 chip that does not support read rollovers. They may or may not exist. However, my hardware requires this functionality because of a quirk. Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Sven Van Asbroeck authored
Adds an optional property for at24 eeproms. This parameterless property indicates that the multi-address eeprom does not automatically roll over reads to the next slave address. Signed-off-by: Sven Van Asbroeck <svendev@arcx.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Wolfram Sang authored
The driver gained DT support recently, so we should add the binding docs in the MAINTAINERS file. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Wolfram Sang authored
This binding documentation is for the at24 driver, so the filename should reflect it. This avoids confusion because we also have an "eeprom" driver in Linux but it doesn't support DT even. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Remove remaining now unneeded code dealing with SMBUS details. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Remove the old and now unused read functions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Add regmap-based read function and instead of using three different read functions (standard, mac, serial) use just one and factor out the read offset adjustment for mac and serial to at24_adjust_read_offset. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Remove the old and now unused write functions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Add a regmap-based write function. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-
Heiner Kallweit authored
Change return type of at24_translate_offset to *at24_client to make member regmap accessible for subsequent patches of this series. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-