Re: [PATCH v2 2/2] i2c: pxa: enable high speed mode for i2c bus
> Did I misunderstand something? No, you didn't. As I said the patch is already in my tree and linux-next. Please read Documentation/development-process/* in case you don't know about linux-next yet. Regards, Wolfram signature.asc Description: Digital signature
Re: [PATCH v2 2/2] i2c: pxa: enable high speed mode for i2c bus
Hi Wolfram, Did I misunderstand something? Best regards, Leilei 2013/8/16 James Lebron : > Hi Wolfram, > > Thanks for your quick response! > > Do you mean my initial patch has already been accept and I don't need > to push patch v2? > If yes, do I need to rebase the patch? > > And sorry for don't write changelog. > > Best regards, > Leilei > > 2013/8/15 Wolfram Sang : >> On Thu, Aug 15, 2013 at 06:48:28PM +0800, James Lebron wrote: >>> Hi Guys >>> >>> Any comments? >> >> As I wrote on August, 7th, I accepted the last version already; it is >> also in linux-next since then. So, this series is not needed if the only >> thing changed was the addition of the PXA910 register set. Since you >> didn't write a changelog (please always do) I assume there are no >> further changes. >> -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] i2c-mv64xxx: Add I2C Transaction Generator support
Hi,
here is the review. BTW have you tested with and without the offload
engine?
> +static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data *drv_data)
> +{
> + unsigned long data_reg_hi = 0;
> + unsigned long data_reg_lo = 0;
> + unsigned long ctrl_reg;
> + unsigned int i;
> + struct i2c_msg *msg = drv_data->msgs;
> +
> + drv_data->msg = msg;
> + drv_data->byte_posn = 0;
> + drv_data->bytes_left = msg->len;
> + drv_data->aborting = 0;
> + drv_data->rc = 0;
> + /* Only regular transactions can be offloaded */
> + if ((msg->flags & ~(I2C_M_TEN | I2C_M_RD)) != 0)
> + return 1;
-EINVAL?
> +
> + /* Only 1-8 byte transfers can be offloaded */
> + if (msg->len < 1 || msg->len > 8)
> + return 1;
ditto
> +
> + /* Build transaction */
> + ctrl_reg = MV64XXX_I2C_BRIDGE_CONTROL_ENABLE |
> +(msg->addr << MV64XXX_I2C_BRIDGE_CONTROL_ADDR_SHIFT);
> +
> + if ((msg->flags & I2C_M_TEN) != 0)
> + ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_ADDR_EXT;
> +
> + if ((msg->flags & I2C_M_RD) == 0) {
> + for (i = 0; i < 4 && i < msg->len; i++)
> + data_reg_lo = data_reg_lo |
> + (msg->buf[i] << ((i & 0x3) * 8));
> +
> + for (i = 4; i < 8 && i < msg->len; i++)
> + data_reg_hi = data_reg_hi |
> + (msg->buf[i] << ((i & 0x3) * 8));
What about:
local_buf[8] = { 0 };
memcpy(local_buf, msg->buf, msg->len);
cpu_to_be32(...)
? A lot less lines and be32 macros are likely more efficient. Copy loop
probably, too.
> +
> + ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_WR |
> + (msg->len - 1) << MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT;
> + } else {
> + ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_RD |
> + (msg->len - 1) << MV64XXX_I2C_BRIDGE_CONTROL_RX_SIZE_SHIFT;
> + }
> +
> + /* Execute transaction */
> + writel_relaxed(data_reg_lo,
> + drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_LO);
> + writel_relaxed(data_reg_hi,
> + drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_HI);
Do you need to write the 0 in case of I2C_M_RD?
> + writel(ctrl_reg, drv_data->reg_base + MV64XXX_I2C_REG_BRIDGE_CONTROL);
> +
> + return 0;
> +}
> +
> +static void
> +mv64xxx_i2c_update_offload_data(struct i2c_msg *msg, unsigned long
> data_reg_hi,
> + unsigned long data_reg_lo)
> +{
> + int i;
> +
> + if ((msg->flags & I2C_M_RD) != 0) {
!= 0 is superfluous
> + for (i = 0; i < 4 && i < msg->len; i++) {
> + msg->buf[i] = data_reg_lo & 0xFF;
> + data_reg_lo >>= 8;
> + }
> +
> + for (i = 4; i < 8 && i < msg->len; i++) {
> + msg->buf[i] = data_reg_hi & 0xFF;
> + data_reg_hi >>= 8;
> + }
> + }
Same idea as above?
> @@ -298,21 +420,36 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32
> status)
> static void
> mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
> {
> + unsigned long data_reg_hi = 0;
> + unsigned long data_reg_lo = 0;
> +
> switch(drv_data->action) {
> + case MV64XXX_I2C_ACTION_OFFLOAD_RESTART:
> + data_reg_lo = readl(drv_data->reg_base +
> + MV64XXX_I2C_REG_RX_DATA_LO);
> + data_reg_hi = readl(drv_data->reg_base +
> + MV64XXX_I2C_REG_RX_DATA_HI);
Initializing data_reg_* is the same for both calls to
update_offload_data, so it could be moved into the function.
Probably not needed when using the local_buf idea.
> @@ -326,6 +463,12 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
> drv_data->reg_base + drv_data->reg_offsets.control);
> break;
>
> + case MV64XXX_I2C_ACTION_OFFLOAD_SEND_START:
> + if (mv64xxx_i2c_offload_msg(drv_data) <= 0)
needs to be adjusted when using -EINVAL above. I'd prefer the error case
in the else branch, though. Easier to read.
> + break;
> + else
> + drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
> + /* FALLTHRU */
> case MV64XXX_I2C_ACTION_SEND_START:
> writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_START,
> drv_data->reg_base + drv_data->reg_offsets.control);
> @@ -601,6 +779,13 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
>
> memcpy(&drv_data->reg_offsets, device->data,
> sizeof(drv_data->reg_offsets));
>
> + /*
> + * For controllers embedded in new SoCs activate the
> + * Transaction Generator support.
> + */
> + if (of_device_is_compatible(np, "marvell,mv78230-i2c"))
> + drv_data->offload_enabled = true;
For now OK, if there are more users, someone will need t
Re: passing two interrupts two an I2C driver
On Wed, Aug 21, 2013 at 01:37:04PM +0100, Pawel Moll wrote: > So let me ask such question... If Device Tree didn't exist, how would > you make drive such device? I guess it would require some custom code, It's always done using platform data, same for SPI - if we update one we should probably update both. signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c-designware: make *CNT values configurable
On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote: > Hi, > > On 8/5/13 6:31 PM, Christian Ruppert wrote:> On Wed, Jul 24, 2013 at > 11:31:44PM +0900, Shinya Kuribayashi wrote: > >>As said before, all t_SCL things should go away. Please forget > >>about 100kbps, 400kbps, and so on. Bus/clock speed is totally > >>pointless concept for the I2C bus systems. For example, as long > >>as tr/tf, tHIGH/tLOW, tHD;STA, etc. are met by _all_ devices in a > >>certain I2C bus, it doesn't matter that the resulting clock speed > >>is, say 120 kbps with Standard-mode, or even 800 kbps for Fast-mode. > >>Nobody in the I2C bus doesn't care about actual bus/clock speed. > >> > >>We don't have to care about the resulting bus speed, or rather > >>we should/must not check to see if it's within the proper range. > > > >Actually, the I2C specification clearly defines f_SCL;max (and thus > >implies t_SCL;min), both in the tables and the timing diagrams. Why can > >we ignore this constraint while having to meet all the others? > > If we meet t_r, t_f, t_HIGH, t_LOW (and t_HIGH in this DW case), > f_SCL;max will be met by itself. I'm not sure if I agree with this: Standard mode: t_r;min 0ns t_f;min +0ns t_HIGH;min + 4000ns t_LOW;min + 4700ns 1/f_SCL = 8700ns ==> f_SCL = 115kHz==>violation of f_SCL;max=100kHz Fast mode (let's assume V_DD = 5.5V): t_r;min 20ns t_f;min + 20ns t_HIGH;min + 600ns t_LIW;min + 1300ns 1/f_SCL = 1940ns ==> f_SCL = 515kHz==>violation of f_SCL;max=400kHz In my understanding, f_SCL;max condition is only met a) either if t_HIGH = t_HIGH;min and t_LOW = t_LOW;min then t_r must be t_r;max and t_f must be t_f;max b) or if t_r < t_r;max and t_f < t_f;max then t_HIGH must be > t_HIGH;min and T_LOW must be T_LOW;min Given that we cannot easily influence t_r and t_f we must adjust t_HIGH and t_LOW. What am I missing here? > And again, all I2C master and > slave devices in the bus don't care about f_SCL; what they do care > are t_f, t_r, t_HIGH, t_LOW, and so on. That's why I'm saying > f_SCL is pointless and has no value for HCNT/LCNT calculations. I partially agree: If I2C devices don't care about f_SCL but only about t_r, t_f, t_HIGH and t_LOW there's no need to respect the f_SCL;max constraint. If this is the case, I'm wondering why it is part of the specification, though. > Is that clear? What is the point to make sure whether f_SCL > constraint is met or not? Is there any combination where t_f, > t_r, t_HIGH, t_LOW, t_HD;SATA are met, but f_SCL is out of range? > I don't think there is. See above. > I'd make a compromise proposal; it's fine to make sure whether the > resulting f_SCL is within a supported range, but should not make a > correction of HCNT/LCNT values. Just report warning messages that > some parameters/calculations might be mis-configured an/or wrong. Not sure if this is a good idea: If f_SCL is met by design I'm perfectly happy with dropping the t_HIGH/t_LOW adjustment code, no need to bloat the kernel with confusing warnings. If f_SCL is not automatically met we must either make sure t_HIGH/t_LOW are adjusted or we must take the decision to ignore that constraint and document the reasons behind that decision accordingly. Greetings, Christian -- Christian Ruppert , /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] i2c: move of helpers into the core
On 08/21/2013 03:47 PM, Wolfram Sang wrote: > 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. > > Acked-by: Sylwester Nawrocki > Acked-by: Rob Herring > Reviewed-by: Felipe Balbi > Acked-by: Rafael J. Wysocki > Signed-off-by: Wolfram Sang With this patch there are still couple of of_i2c.h header file inclusions: $ git grep of_i2c.h arch/powerpc/platforms/44x/warp.c:#include drivers/gpu/drm/tilcdc/tilcdc_slave.c:#include drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:#include drivers/gpu/host1x/drm/output.c:#include drivers/media/platform/exynos4-is/fimc-is.c:#include drivers/media/platform/exynos4-is/media-dev.c:#include drivers/staging/imx-drm/imx-tve.c:#include sound/soc/fsl/imx-sgtl5000.c:#include sound/soc/fsl/imx-wm8962.c:#include Please include also this chunk, without it I'm getting build errors. --8<- diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c b/drivers/media/platform/exynos4-is/fimc-is-i2c.c index ca07b48..e38e9dc 100644 --- a/drivers/media/platform/exynos4-is/fimc-is-i2c.c +++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c @@ -11,6 +11,7 @@ */ #include +#include #include #include #include diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c index 6743ae3..63e4f1d 100644 --- a/drivers/media/platform/exynos4-is/fimc-is.c +++ b/drivers/media/platform/exynos4-is/fimc-is.c @@ -21,7 +21,6 @@ #include #include #include -#include #include #include #include diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c index c10dee2..00e5f91 100644 --- a/drivers/media/platform/exynos4-is/media-dev.c +++ b/drivers/media/platform/exynos4-is/media-dev.c @@ -22,7 +22,6 @@ #include #include #include -#include #include #include #include --8<- > --- > > V1 -> V2: * Add #else branch to #if CONFIG_OF > * EXPORT_SYMBOLs got attached to wrong functions > * cosmetic change (of -> OF) > * properly based on 3.11-rc4 > > Documentation/acpi/enumeration.txt |1 - > drivers/i2c/busses/i2c-at91.c |3 - > drivers/i2c/busses/i2c-cpm.c|6 -- > drivers/i2c/busses/i2c-davinci.c|2 - > drivers/i2c/busses/i2c-designware-platdrv.c |2 - > drivers/i2c/busses/i2c-gpio.c |3 - > drivers/i2c/busses/i2c-i801.c |2 - > drivers/i2c/busses/i2c-ibm_iic.c|4 - > drivers/i2c/busses/i2c-imx.c|3 - > drivers/i2c/busses/i2c-mpc.c|2 - > drivers/i2c/busses/i2c-mv64xxx.c|3 - > drivers/i2c/busses/i2c-mxs.c|3 - > drivers/i2c/busses/i2c-nomadik.c|3 - > drivers/i2c/busses/i2c-ocores.c |3 - > drivers/i2c/busses/i2c-octeon.c |3 - > drivers/i2c/busses/i2c-omap.c |3 - > drivers/i2c/busses/i2c-pnx.c|3 - > drivers/i2c/busses/i2c-powermac.c |9 +- > drivers/i2c/busses/i2c-pxa.c|2 - > drivers/i2c/busses/i2c-s3c2410.c|2 - > drivers/i2c/busses/i2c-sh_mobile.c |2 - > drivers/i2c/busses/i2c-sirf.c |3 - > drivers/i2c/busses/i2c-stu300.c |2 - > drivers/i2c/busses/i2c-tegra.c |3 - > drivers/i2c/busses/i2c-versatile.c |2 - > drivers/i2c/busses/i2c-wmt.c|3 - > drivers/i2c/busses/i2c-xiic.c |3 - > drivers/i2c/i2c-core.c | 109 +- > drivers/i2c/i2c-mux.c |3 - > drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - > drivers/i2c/muxes/i2c-mux-gpio.c|1 - > drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - > drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - > drivers/of/Kconfig |6 -- > drivers/of/Makefile |1 - > drivers/of/of_i2c.c | 114 > --- > include/linux/i2c.h | 20 > include/linux/of_i2c.h | 46 - > 38 files changed, 132 insertions(+), 253 deletions(-) > delete mode 100644 drivers/of/of_i2c.c > delete mode 100644 include/linux/of_i2c.h I've tested this patch on Exynos4412 SoC based board, so this covers i2c-s3c2410 and fimc-is-i2c. Compiled with CONFIG_
[PATCH v2] i2c: move ACPI helpers into the core
This follows what has already been done for the DeviceTree helpers. Move
the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update
documentation accordingly.
This also solves a problem reported by Jerry Snitselaar that we can't build
the ACPI I2C helpers as a module.
Signed-off-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
---
This is rebased on top of Wolfram's V2 patch here:
http://marc.info/?l=linux-acpi&m=137709287521491&w=2
Changed to use #if IS_ENABLED(CONFIG_ACPI) as is done in the DeviceTree
version.
Documentation/acpi/enumeration.txt | 15 +---
drivers/acpi/Kconfig| 6 --
drivers/acpi/Makefile | 1 -
drivers/acpi/acpi_i2c.c | 103
drivers/i2c/busses/i2c-designware-platdrv.c | 1 -
drivers/i2c/i2c-core.c | 91
include/linux/i2c.h | 6 --
7 files changed, 94 insertions(+), 129 deletions(-)
delete mode 100644 drivers/acpi/acpi_i2c.c
diff --git a/Documentation/acpi/enumeration.txt
b/Documentation/acpi/enumeration.txt
index 958266e..d98 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -228,18 +228,9 @@ ACPI handle like:
I2C serial bus support
~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
-with the platform and SPI drivers. However the I2C bus controller driver
-needs to call acpi_i2c_register_devices() after it has added the adapter.
-
-An I2C bus (controller) driver does:
-
- ...
- ret = i2c_add_numbered_adapter(adapter);
- if (ret)
- /* handle error */
-
- /* Enumerate the slave devices behind this bus via ACPI */
- acpi_i2c_register_devices(adapter);
+with the platform and SPI drivers. The I2C core automatically enumerates
+any slave devices behind the controller device once the adapter is
+registered.
Below is an example of how to add ACPI support to the existing mpu3050
input driver:
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 100bd72..4e0162f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -180,12 +180,6 @@ config ACPI_DOCK
This driver supports ACPI-controlled docking stations and removable
drive bays such as the IBM Ultrabay and the Dell Module Bay.
-config ACPI_I2C
- def_tristate I2C
- depends on I2C
- help
- ACPI I2C enumeration support.
-
config ACPI_PROCESSOR
tristate "Processor"
select THERMAL
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 81dbeb8..cdaf68b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -73,7 +73,6 @@ obj-$(CONFIG_ACPI_HED)+= hed.o
obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
-obj-$(CONFIG_ACPI_I2C) += acpi_i2c.o
# processor has its own "processor." module_param namespace
processor-y:= processor_driver.o processor_throttling.o
diff --git a/drivers/acpi/acpi_i2c.c b/drivers/acpi/acpi_i2c.c
deleted file mode 100644
index a82c762..000
--- a/drivers/acpi/acpi_i2c.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * ACPI I2C enumeration support
- *
- * Copyright (C) 2012, Intel Corporation
- * Author: Mika Westerberg
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-
-ACPI_MODULE_NAME("i2c");
-
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
-{
- struct i2c_board_info *info = data;
-
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
-
- sb = &ares->data.i2c_serial_bus;
- if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- info->flags |= I2C_CLIENT_TEN;
- }
- } else if (info->irq < 0) {
- struct resource r;
-
- if (acpi_dev_resource_interrupt(ares, 0, &r))
- info->irq = r.start;
- }
-
- /* Tell the ACPI core to skip this resource */
- return 1;
-}
-
-static acpi_status acpi_i2c_add_device(acpi_handle handle, u32 level,
- void *data, void **return_value)
-{
- struct i2c_adapter *adapter = data;
- struct list_head resource_list;
- struct i2c_board_info info;
- struct acpi_device *adev;
- int ret;
-
- if (acpi_bus_get_device(handle, &adev))
- return AE_OK;
- if (acpi_bus_get_status(adev) || !adev
[PATCH V2] i2c: move of helpers into the core
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. Acked-by: Sylwester Nawrocki Acked-by: Rob Herring Reviewed-by: Felipe Balbi Acked-by: Rafael J. Wysocki Signed-off-by: Wolfram Sang --- V1 -> V2: * Add #else branch to #if CONFIG_OF * EXPORT_SYMBOLs got attached to wrong functions * cosmetic change (of -> OF) * properly based on 3.11-rc4 Documentation/acpi/enumeration.txt |1 - drivers/i2c/busses/i2c-at91.c |3 - drivers/i2c/busses/i2c-cpm.c|6 -- drivers/i2c/busses/i2c-davinci.c|2 - drivers/i2c/busses/i2c-designware-platdrv.c |2 - drivers/i2c/busses/i2c-gpio.c |3 - drivers/i2c/busses/i2c-i801.c |2 - drivers/i2c/busses/i2c-ibm_iic.c|4 - drivers/i2c/busses/i2c-imx.c|3 - drivers/i2c/busses/i2c-mpc.c|2 - drivers/i2c/busses/i2c-mv64xxx.c|3 - drivers/i2c/busses/i2c-mxs.c|3 - drivers/i2c/busses/i2c-nomadik.c|3 - drivers/i2c/busses/i2c-ocores.c |3 - drivers/i2c/busses/i2c-octeon.c |3 - drivers/i2c/busses/i2c-omap.c |3 - drivers/i2c/busses/i2c-pnx.c|3 - drivers/i2c/busses/i2c-powermac.c |9 +- drivers/i2c/busses/i2c-pxa.c|2 - drivers/i2c/busses/i2c-s3c2410.c|2 - drivers/i2c/busses/i2c-sh_mobile.c |2 - drivers/i2c/busses/i2c-sirf.c |3 - drivers/i2c/busses/i2c-stu300.c |2 - drivers/i2c/busses/i2c-tegra.c |3 - drivers/i2c/busses/i2c-versatile.c |2 - drivers/i2c/busses/i2c-wmt.c|3 - drivers/i2c/busses/i2c-xiic.c |3 - drivers/i2c/i2c-core.c | 109 +- drivers/i2c/i2c-mux.c |3 - drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - drivers/i2c/muxes/i2c-mux-gpio.c|1 - drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - drivers/of/Kconfig |6 -- drivers/of/Makefile |1 - drivers/of/of_i2c.c | 114 --- include/linux/i2c.h | 20 include/linux/of_i2c.h | 46 - 38 files changed, 132 insertions(+), 253 deletions(-) delete mode 100644 drivers/of/of_i2c.c delete mode 100644 include/linux/of_i2c.h diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index d9be7a9..958266e 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: if (ret) /* handle error */ - of_i2c_register_devices(adapter); /* Enumerate the slave devices behind this bus via ACPI */ acpi_i2c_register_devices(adapter); diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c index 6bb839b..fd05930 100644 --- a/drivers/i2c/busses/i2c-at91.c +++ b/drivers/i2c/busses/i2c-at91.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include #include @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) return rc; } - of_i2c_register_devices(&dev->adapter); - dev_info(dev->dev, "AT91 i2c bus driver.\n"); return 0; } diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 2e1f7eb..b2b8aa9 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -42,7 +42,6 @@ #include #include #include -#include #include #include @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", cpm->adap.name); - /* -* register OF I2C devices -*/ - of_i2c_register_devices(&cpm->adap); - return 0; out_shut: cpm_i2c_shutdown(cpm); diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index fa55605..62be3b3 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -38,7 +38,6 @@ #include #include #include -#include #include #include @@ -728,7 +727,6 @@ static int davinci_i2c_probe(struct platform_device *pdev
Re: [PATCH v5 0/3] i2c-mv64xxx: Fixes and new feature for controlers embedded in Aramda XP
> compatible", do you want that I rebase my patch set on your > i2c/for-current branch, or do you prefer to take care of the merge > conflict yourself? My for-next would be preferred. signature.asc Description: Digital signature
Re: passing two interrupts two an I2C driver
[resending, this time really copying Wolfram and linux-i2c...]
On Wed, 2013-08-21 at 12:53 +0100, Jacek Anaszewski wrote:
> From what I've figured out in order to obtain the interrupt id
> by name the function
>
> platform_get_irq_by_name(struct platform_device *dev, const char *name)
>
> has to be exploited. Unfortunately required platform_device structure
> is not available in the struct i2c_client
Well, platform devices belong to platform bus, nothing to do with I2C.
Platform devices are associated with an array of named resources and the
code creating such devices from the DT nodes (of_device_alloc()) do the
necessary magic.
> that is passed to the
> probe function of an i2c driver. Is there some different way to parse
> the interrupt-names property from the I2C driver?
Interesting. Very interesting indeed. It seems (at least at the first
sight) that I2C framework assumes that only one interrupt can be
generated by a I2C device:
struct i2c_client {
[...]
int irq;/* irq issued by device */
[...]
};
So let me ask such question... If Device Tree didn't exist, how would
you make drive such device? I guess it would require some custom code,
as struct i2c_board_info has single int irq as well... If this is the
case, you could parse the irq properties in a similar way as done in
of_irq_to_resource() in drivers/of/irq.c. Doesn't like the optimal
solution, though...
I've copied Wolfram and the I2C mailing list in hope of them shedding
some light at the matter.
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] i2c-mv64xxx: Fixes and new feature for controlers embedded in Aramda XP
On 20/08/2013 21:07, Wolfram Sang wrote: > >> Jason Cooper drooped the third patch as it conflicted with a patch from >> Maxime Ripard which adds the AllWinner support. Olof also asked a formal >> acked-by from a device tree maintainer >> even if we already answer to Mark Rutland request. >> >> Olof also requested that you take the binding update, so I am going to send >> a new version of this patch set with the last patch split in two parts. > > Yeah, I wondered about the binding already being accepted when the driver > review was not done. As there will be a conflict for the Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt file with the commit "i2c: mv64xxx: Document the newly introduced allwinner compatible", do you want that I rebase my patch set on your i2c/for-current branch, or do you prefer to take care of the merge conflict yourself? > >> As explained earlier today, unless you really want I use be32_to_cpu in the >> mv64xxx_i2c_offload_msg() I won't change anything else. > > I found some more (minor) issues. Expect a review by tomorrow evening. > Ok I will wait for your review to send the new version Thanks, -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1 ] i2c: rcar: modify I2C driver
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
Signed-off-by: Nguyen Viet Dung
---
drivers/i2c/busses/i2c-rcar.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 0fc5858..e08ef28 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -101,6 +101,11 @@ enum {
#define ID_ARBLOST (1 << 3)
#define ID_NACK(1 << 4)
+enum rcar_i2c_type {
+ I2C_RCAR_H1,
+ I2C_RCAR_H2,
+};
+
struct rcar_i2c_priv {
void __iomem *io;
struct i2c_adapter adap;
@@ -113,6 +118,7 @@ struct rcar_i2c_priv {
int irq;
u32 icccr;
u32 flags;
+ enum rcar_i2c_type devtype;
};
#define rcar_i2c_priv_to_dev(p)((p)->adap.dev.parent)
@@ -224,12 +230,23 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
u32 scgd, cdf;
u32 round, ick;
u32 scl;
+ u32 cdf_width;
if (!clkp) {
dev_err(dev, "there is no peripheral_clk\n");
return -EIO;
}
+ switch (priv->devtype) {
+ default:
+ case I2C_RCAR_H1:
+ cdf_width = 2;
+ break;
+ case I2C_RCAR_H2:
+ cdf_width = 3;
+ break;
+ }
+
/*
* calculate SCL clock
* see
@@ -245,7 +262,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
* clkp : peripheral_clk
* F[] : integer up-valuation
*/
- for (cdf = 0; cdf < 4; cdf++) {
+ for (cdf = 0; cdf < (1 << cdf_width); cdf++) {
ick = clk_get_rate(clkp) / (1 + cdf);
if (ick < 2000)
goto ick_find;
@@ -287,7 +304,7 @@ scgd_find:
/*
* keep icccr value
*/
- priv->icccr = (scgd << 2 | cdf);
+ priv->icccr = (scgd << (cdf_width) | cdf);
return 0;
}
@@ -632,6 +649,13 @@ static int rcar_i2c_probe(struct platform_device *pdev)
bus_speed = 10; /* default 100 kHz */
if (pdata && pdata->bus_speed)
bus_speed = pdata->bus_speed;
+
+ if (!pdev->id_entry) {
+ dev_err(&pdev->dev, "no entry\n");
+ return -ENODEV;
+ }
+ priv->devtype = pdev->id_entry->driver_data;
+
ret = rcar_i2c_clock_calculate(priv, bus_speed, dev);
if (ret < 0)
return ret;
@@ -686,6 +710,14 @@ static int rcar_i2c_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id rcar_i2c_id_table[] = {
+ { "i2c-rcar", I2C_RCAR_H1 },
+ { "i2c-rcar_h1",I2C_RCAR_H1 },
+ { "i2c-rcar_h2",I2C_RCAR_H2},
+ {},
+};
+MODULE_DEVICE_TABLE(platform, rcar_i2c_id_table);
+
static struct platform_driver rcar_i2c_driver = {
.driver = {
.name = "i2c-rcar",
@@ -693,6 +725,7 @@ static struct platform_driver rcar_i2c_driver = {
},
.probe = rcar_i2c_probe,
.remove = rcar_i2c_remove,
+ .id_table = rcar_i2c_id_table,
};
module_platform_driver(rcar_i2c_driver);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/1] ARM: shmobile: r8a7790: add I2C support
Hi Wolfram CC Morimoto Please consider the following patch for the r8a7790 Soc. This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2. It was developed base on the renesas-devel-20130722 branch and have tested on the Lager board. V3: Using the ID tables to resolve the difference between H1 and H2. Thanks, Nguyen viet Dung Nguyen Viet Dung (1): i2c: rcar: modify I2C driver drivers/i2c/busses/i2c-rcar.c | 37 +++-- 1 file changed, 35 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: exynos5: add High Speed I2C controller driver
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
Highspeed mode is a minor change in the i2c protocol.
Starts with
1. start condition,
2. 8-bit master ID code (1xxx)
3. followed by a NACK bit
Once the above conditions are met, the bus is now operates in highspeed mode.
The rest of the I2C protocol applies the same.
Driver only supports Device Tree method.
Changes since v1:
1. Added FIFO functionality
2. Added High speed mode functionality
3. Remove SMBUS_QUICK
4. Remove the debugfs functionality
5. Use devm_* functions where ever possible
6. Driver is free from GPIO configs
7. Use OF data string "clock-frequency" to get the bus operating frequencies
8. Split the clock divisor calculation function
9. Add resets for the failed transacton cases
10. Removed retries as core does retries if -EAGAIN is returned
11. Removed mode from device tree info (use speed to distinguish
the mode of operation)
12. Use wait_for_completion_timeout as the interruptible case is not tested well
13. few other bug fixes and cosmetic changes
14. Removed the untested runtime_pm code
15. Removed the retries as core does that
16. Use adap.nr instead of alias
17. Added spinlocks around the irq code
18. Use i2c_add_numbered_adapter() instead of using aliases
Signed-off-by: Taekgyun Ko
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Simon Glass
Tested-by: Andrew Bresticker
Signed-off-by: Yuvaraj Kumar C D
Signed-off-by: Andrew Bresticker
---
Wolfram and Thomas Figa thanks for reviewing the code.
Changes since v10:
1. Remove the incomplete runtime_pm code
2. Correct the error checks as suggested by Thomas
3. Use i2c_add_numbered_adapter() as suggested
4. Modified the irq routine to handle the specific interrupts
5. Added spinlocks around the irq code
6. Remove the "mode" of operation field from device tree node and use the
clock-frequency to decide the mode.
.../devicetree/bindings/i2c/i2c-exynos5.txt| 44 ++
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-exynos5.c | 799
4 files changed, 851 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
create mode 100644 drivers/i2c/busses/i2c-exynos5.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000..805e018
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,44 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+ - compatible: value should be.
+ -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+ - reg: physical base address of the controller and length of memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+ - #address-cells: always 1 (for i2c addresses)
+ - #size-cells: always 0
+
+ - Pinctrl:
+- pinctrl-0: Pin control group to be used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
+Optional properties:
+ - clock-frequency: Desired operating frequency in Hz of the bus.
+-> If not specified, the default value is 100khz in fast-speed mode and
+ 1Mhz in high-speed mode.
+-> If specified, The bus operates in high-speed mode only if the
+ clock-frequency is >= 1Mhz.
+
+Example:
+
+hsi2c@12ca {
+ compatible = "samsung,exynos5-hsi2c";
+ reg = <0x12ca 0x100>;
+ interrupts = <56>;
+ clock-frequency = <10>;
+
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ s2mps11_pmic@66 {
+ compatible = "samsung,s2mps11-pmic";
+ reg = <0x66>;
+ };
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index fcdd321..69b1848 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -436,6 +436,13 @@ config I2C_EG20T
ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
+config I2C_EXYNOS5
+ tristate "Exynos5 high-speed I2C driver"
+ depends on ARCH_EXYNOS5 && OF
+ help
+ Say Y here to include support for high-speed I2C controller in the
+ Exynos5 based Samsung SoCs.
+
config I2C_GPIO
tristate "GPIO-based bitbanging I2C"
depends on GPIOLIB
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index d00997f..d1ad371 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-p
Re: [PATCH] i2c: move of helpers into the core
On Tue, Aug 20, 2013 at 04:30:43PM +0200, Wolfram Sang wrote: > On Tue, Aug 20, 2013 at 12:28:13PM +0300, Mika Westerberg wrote: > > [Added Jerry as he found out a problem when acpi_i2c is being build as a > > module, this should solve it as well.] > > > > On Tue, Aug 20, 2013 at 01:25:27AM +0200, Rafael J. Wysocki wrote: > > > On Monday, August 19, 2013 04:56:19 PM Stephen Warren wrote: > > > > On 08/19/2013 05:04 PM, Rafael J. Wysocki wrote: > > > > > On Monday, August 19, 2013 03:19:18 PM Wolfram Sang wrote: > > > > >> 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. > > > > > > > > > > Perhaps we should do the analogous for ACPI then? > > > > Here is the ACPI version based on the current patch from Wolfram (there is > > a compile error because of missing dummy implementation of > > of_i2c_register_devices()) > > > > From: Mika Westerberg > > Subject: [PATCH] i2c: move ACPI helpers into the core > > > > This follows what has already been done for the DeviceTree helpers. Move > > the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update > > documentation accordingly. > > > > This also solves a problem reported by Jerry Snitselaar that we can't build > > the ACPI I2C helpers as a module. > > > > Signed-off-by: Mika Westerberg > > Nice, one thing, though: > > > /* create pre-declared device nodes */ > > of_i2c_register_devices(adap); > > + acpi_i2c_register_devices(adap); > > I prefer the if (IS_ENABLED()) solution and will use this in my V2 as > well. For the ACPI part we need to have the dummy stub because CONFIG_ACPI is needed in order to be able to call the ACPI APIs -- there are still functions that are only available when CONFIG_ACPI is enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
