Re: [PATCH] i2c: Kconfig: Allow I2C_MXS to be selected by MX23
On Sat, Nov 17, 2012 at 05:48:54PM -0200, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com With the recent DMA support addition to the i2c-mxs driver, it is now possible to also run it on mx23, so update the Kconfig entry accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Did you test it? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH v2] i2c: s3c2410: Add fix for i2c suspend/resume
The I2C driver makes a gpio_request during initialization. This request
happens again on resume and fails due to the earlier successful request.
Re-factor the code to only initialize the gpios during probe.
Errors on resume without this:
[ 16.02] s3c-i2c s3c2440-i2c.0: gpio [42] request failed
[ 16.02] s3c-i2c s3c2440-i2c.1: gpio [44] request failed
[ 16.02] s3c-i2c s3c2440-i2c.2: gpio [6] request failed
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
Changes from v1:
Refactor code to initialize gpios only during probe
drivers/i2c/busses/i2c-s3c2410.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 081e261..0ca321b 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -856,6 +856,7 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c
*i2c)
dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
goto free_gpio;
}
+ i2c-gpios[idx] = gpio;
ret = gpio_request(gpio, i2c-bus);
if (ret) {
@@ -892,6 +893,18 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
}
#endif
+static int s3c24xx_i2c_cfg_gpio(struct s3c24xx_i2c *i2c)
+{
+ struct s3c2410_platform_i2c *pdata = i2c-pdata;
+
+ if (pdata-cfg_gpio)
+ pdata-cfg_gpio(to_platform_device(i2c-dev));
+ else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c))
+ return -EINVAL;
+
+ return 0;
+}
+
/* s3c24xx_i2c_init
*
* initialise the controller, set the IO lines and frequency
@@ -907,13 +920,6 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
pdata = i2c-pdata;
- /* inititalise the gpio */
-
- if (pdata-cfg_gpio)
- pdata-cfg_gpio(to_platform_device(i2c-dev));
- else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c))
- return -EINVAL;
-
/* write slave address */
writeb(pdata-slave_addr, i2c-regs + S3C2410_IICADD);
@@ -1054,6 +1060,12 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev)
i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
+ /* inititalise the i2c gpio lines */
+
+ ret = s3c24xx_i2c_cfg_gpio(i2c);
+ if (ret != 0)
+ goto err_clk;
+
/* initialise the i2c controller */
ret = s3c24xx_i2c_init(i2c);
--
1.6.6.1
--
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: s3c2410: Add fix for i2c suspend/resume
Hi,
On Mon, Nov 19, 2012 at 02:30:26PM +0530, Abhilash Kesavan wrote:
The I2C driver makes a gpio_request during initialization. This request
happens again on resume and fails due to the earlier successful request.
Re-factor the code to only initialize the gpios during probe.
Errors on resume without this:
[ 16.02] s3c-i2c s3c2440-i2c.0: gpio [42] request failed
[ 16.02] s3c-i2c s3c2440-i2c.1: gpio [44] request failed
[ 16.02] s3c-i2c s3c2440-i2c.2: gpio [6] request failed
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
Changes from v1:
Refactor code to initialize gpios only during probe
drivers/i2c/busses/i2c-s3c2410.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index 081e261..0ca321b 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -856,6 +856,7 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c
*i2c)
dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
goto free_gpio;
}
+ i2c-gpios[idx] = gpio;
Without this line, gpios won't be freed at all, right? This should be a
separate patch then, since it fixes a seperate issue.
ret = gpio_request(gpio, i2c-bus);
if (ret) {
@@ -892,6 +893,18 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
}
#endif
+static int s3c24xx_i2c_cfg_gpio(struct s3c24xx_i2c *i2c)
+{
+ struct s3c2410_platform_i2c *pdata = i2c-pdata;
+
+ if (pdata-cfg_gpio)
+ pdata-cfg_gpio(to_platform_device(i2c-dev));
+ else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c))
+ return -EINVAL;
+
+ return 0;
+}
+
/* s3c24xx_i2c_init
*
* initialise the controller, set the IO lines and frequency
@@ -907,13 +920,6 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
pdata = i2c-pdata;
- /* inititalise the gpio */
-
- if (pdata-cfg_gpio)
- pdata-cfg_gpio(to_platform_device(i2c-dev));
- else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c))
- return -EINVAL;
-
/* write slave address */
writeb(pdata-slave_addr, i2c-regs + S3C2410_IICADD);
@@ -1054,6 +1060,12 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev)
i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
+ /* inititalise the i2c gpio lines */
+
+ ret = s3c24xx_i2c_cfg_gpio(i2c);
+ if (ret != 0)
+ goto err_clk;
+
I don't think the seperate function is needed here, just copy the code block?
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 1/2] i2c: mxs: Handle i2c DMA failure properly
On Sun, Nov 18, 2012 at 06:25:07AM +0100, Marek Vasut wrote: Properly terminate the DMA transfer in case the DMA PIO transfer or setup fails for any reason. Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam feste...@gmail.com Cc: Tim Michals tcmich...@gmail.com Cc: Wolfram Sang w.s...@pengutronix.de I liked the one patch approach better; but mainly still waiting for Tim's response. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: tfp410 and i2c_bus_num
hi, On Mon, Nov 19, 2012 at 08:38:21AM +0200, Tomi Valkeinen wrote: (dropping Tony and stable) On 2012-11-18 13:34, Felipe Balbi wrote: how are you toggling the gpio ? You said tfp410 isn't controlled at all except for the power down gpio. Who provides the gpio ? It's a normal OMAP GPIO, going to TFP410. I use gpio_set_value() to set/unset it. ok, fair enough. Well, it's not that simple. TFP410 manages hot plug detection of the HDMI cable (although not implemented currently), so the we'd need to convey that information to the i2c-edid somehow. Which, of course, is doable, but increases complexity. I'd say it would decrease it since you would have a single copy of i2c-edid.c for DRM or DSS or any other panel/display framework. Well. Reading EDID via i2c is one or two i2c reads. There's nothing else to it. still avoids duplication :-) If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Another thing is that even if in this case the i2c and EDID reading are separate from the actual video path, that may not be the case for other display solutions. We could have a DSI panel which reports its resolution via DSI bus, or we could have an external DSI-to-HDMI chip, which reads the EDID via i2c from the monitor, but reports them back to the SoC via DSI bus. In this last case we would see just the DSI, not the I2C bus, so it's like I2C bus doesn't exist, so in fact we would have two possibilities: a) read EDID via I2C bus (standard HDMI) b) read EDID via DSI. Right. And currently reading edid is done via read_edid call with omapdss, and the caller doesn't care if read_edid uses i2c or DSI, so it should just work. b) doesn't exist today so we need to care about it until something like what you say shows up in the market. Until then, we care for EDID over I2C IMHO. There are chips such as I described, although not supported in the mainline. fair enough. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. way for that case you wanna cope with other methods for reading EDID, then you need a generic layer which doesn't care if it's I2C or DSI. Currently implementation is hardcoded to I2C anyway. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. TFP410 is a parallel RGB to DVI chip. It's not related to DSI. The DSI case would be with some other chip. it doesn't change what I said, however. Another chip will need to be
Re: [PATCH v3] i2c-hid: introduce HID over i2c specification implementation
On Mon, 12 Nov 2012, Benjamin Tissoires wrote: Microsoft published the protocol specification of HID over i2c: http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx This patch introduces an implementation of this protocol. This implementation does not includes the ACPI part of the specification. This will come when ACPI 5.0 devices enumeration will be available. Once the ACPI part is done, OEM will not have to declare HID over I2C devices in their platform specific driver. Signed-off-by: Benjamin Tissoires benjamin.tissoi...@gmail.com --- Hi Guys, here is the v3 of the HID over I2C driver. Changes in v3: * fix i2c_hid_alloc_buffers when allocation failed * fix error messages to be more human * fix i2c_hid_set_report as it didn't followed the protocol * remove i2c_hid_write_out_report (hid-core doesn't present the callback that could use this feature of the protocol) * reject HID_OUTPUT_REPORT in i2c_hid_get_raw_report * fix output report id in i2c_hid_output_raw_report and reject HID_INPUT_REPORT Benjamin, I am now queuing this in for-3.8/i2c-hid branch, so please send any potential followup patches on top of that. Thanks a lot for all your work on this so far. -- Jiri Kosina SUSE Labs -- 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] i2c: s3c2410: Add fix for i2c suspend/resume
The I2C driver makes a gpio_request during initialization. This request
happens again on resume and fails due to the earlier successful request.
Re-factor the code to only initialize the gpios during probe.
Errors on resume without this:
[ 16.02] s3c-i2c s3c2440-i2c.0: gpio [42] request failed
[ 16.02] s3c-i2c s3c2440-i2c.1: gpio [44] request failed
[ 16.02] s3c-i2c s3c2440-i2c.2: gpio [6] request failed
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
Changes from v1:
Refactor code to initialize gpios only during probe
Changes from v2:
Split an unrelated bug fix
Removed the new function added in v1
drivers/i2c/busses/i2c-s3c2410.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 081e261..dea4cb2 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -907,13 +907,6 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
pdata = i2c-pdata;
- /* inititalise the gpio */
-
- if (pdata-cfg_gpio)
- pdata-cfg_gpio(to_platform_device(i2c-dev));
- else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c))
- return -EINVAL;
-
/* write slave address */
writeb(pdata-slave_addr, i2c-regs + S3C2410_IICADD);
@@ -1054,6 +1047,15 @@ static int s3c24xx_i2c_probe(struct platform_device
*pdev)
i2c-pctrl = devm_pinctrl_get_select_default(i2c-dev);
+ /* inititalise the i2c gpio lines */
+
+ if (i2c-pdata-cfg_gpio) {
+ i2c-pdata-cfg_gpio(to_platform_device(i2c-dev));
+ } else if (IS_ERR(i2c-pctrl) s3c24xx_i2c_parse_dt_gpio(i2c)) {
+ ret = -EINVAL;
+ goto err_clk;
+ }
+
/* initialise the i2c controller */
ret = s3c24xx_i2c_init(i2c);
--
1.6.6.1
--
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: s3c2410: Fix code to free gpios
Store the requested gpios so that they can be freed on error/removal.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
---
drivers/i2c/busses/i2c-s3c2410.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index dea4cb2..5d5e9cb 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -856,6 +856,7 @@ static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c
*i2c)
dev_err(i2c-dev, invalid gpio[%d]: %d\n, idx, gpio);
goto free_gpio;
}
+ i2c-gpios[idx] = gpio;
ret = gpio_request(gpio, i2c-bus);
if (ret) {
--
1.6.6.1
--
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-core: Remove definition of i2c_smbus_process_call
i2c_smbus_process_call has no users in the kernel, so this can be
removed. Documentation for the same has been updated accordingly.
Fixes following sparse warning.
drivers/i2c/i2c-core.c:1871:5: warning: symbol 'i2c_smbus_process_call'
was not declared. Should it be static?
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Documentation/i2c/writing-clients |4 ++--
drivers/i2c/i2c-core.c| 23 ---
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/Documentation/i2c/writing-clients
b/Documentation/i2c/writing-clients
index 3a94b0e..51059f7 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -365,8 +365,6 @@ in terms of it. Never use this function directly!
s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
s32 i2c_smbus_write_word_data(struct i2c_client *client,
u8 command, u16 value);
- s32 i2c_smbus_process_call(struct i2c_client *client,
- u8 command, u16 value);
s32 i2c_smbus_read_block_data(struct i2c_client *client,
u8 command, u8 *values);
s32 i2c_smbus_write_block_data(struct i2c_client *client,
@@ -383,6 +381,8 @@ be added back later if needed:
s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length, u8 *values);
+ s32 i2c_smbus_process_call(struct i2c_client *client,
+ u8 command, u16 value);
All these transactions return a negative errno value on failure. The 'write'
transactions return 0 on success; the 'read' transactions return the read
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a7edf98..b4c4028 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1860,29 +1860,6 @@ s32 i2c_smbus_write_word_data(const struct i2c_client
*client, u8 command,
EXPORT_SYMBOL(i2c_smbus_write_word_data);
/**
- * i2c_smbus_process_call - SMBus process call protocol
- * @client: Handle to slave device
- * @command: Byte interpreted by slave
- * @value: 16-bit word being written
- *
- * This executes the SMBus process call protocol, returning negative errno
- * else a 16-bit unsigned word received from the device.
- */
-s32 i2c_smbus_process_call(const struct i2c_client *client, u8 command,
- u16 value)
-{
- union i2c_smbus_data data;
- int status;
- data.word = value;
-
- status = i2c_smbus_xfer(client-adapter, client-addr, client-flags,
- I2C_SMBUS_WRITE, command,
- I2C_SMBUS_PROC_CALL, data);
- return (status 0) ? status : data.word;
-}
-EXPORT_SYMBOL(i2c_smbus_process_call);
-
-/**
* i2c_smbus_read_block_data - SMBus block read protocol
* @client: Handle to slave device
* @command: Byte interpreted by slave
--
1.7.4.1
--
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: tfp410 and i2c_bus_num
On 2012-11-19 11:27, Felipe Balbi wrote: If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. Afaik, v4l2 handles only the pipeline for video. This i2c-edid would not be part of the video pipeline, so I don't see a connection to v4l2. And I'm not saying it's not possible, or that the current way is good or correct. I'm saying it's not easy, and definitely more complex than the current tfp410 implementation. The amount of code related to this feature would multiply. If we had 10 different tfp410 like drivers, then obviously there'd be more pressing reason to clean this up. But currently we have only one place where this code is used. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Yep. Althought the same could be done with a common edid library, without an i2c-edid driver. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. TFP410 doesn't need the EDID for anything, it just provides it as raw data. Parsing the EDID is done in other layers. But as you said, instead of tfp410 fetching the EDID and providing it, tfp410 could get the EDID from the i2c-edid driver and pass it forward. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. If with users you mean, for example, tfp410, then true. But tfp410 doesn't use EDID for anything, it just provides it. For the actual users of the EDID data reading the EDID is encapsulated already. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. Well, yes. TFP410 is a RGB to DVI chip. It knows that the underlying bus is DVI, and that there are i2c lines to read the EDID. There are no other option what the busses could be. So I don't see any problem with knowing the underlying bus. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. TFP410 is a parallel RGB to DVI chip. It's not related to DSI. The DSI case would be with some other chip. it doesn't change what I said, however. Another chip will need to be passed in a DVI handle. I'm sorry, but I don't understand what you're saying above... If we have a DSI-2-DVI chip, then reading the EDID would be done by sending a DSI command to the chip, which would return the EDID data. Which would be passed forward when someone requests it. There would not be anything in common with tfp410 and i2c implementation. We could have a library with the code that does the one or two i2c reads. And while I think it'd be good, we're talking about one or two i2c reads. It wouldn't be a huge improvement. fair enough... it looks like this is going nowhere, so best we come back to this later. No reason to block your patch. Well, the patch is a fix for stable
Re: [PATCH] i2c: Kconfig: Allow I2C_MXS to be selected by MX23
Hi Wolfram, On Mon, Nov 19, 2012 at 6:49 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Sat, Nov 17, 2012 at 05:48:54PM -0200, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com With the recent DMA support addition to the i2c-mxs driver, it is now possible to also run it on mx23, so update the Kconfig entry accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Did you test it? I don't have the I2C connector board for mx23-olinuxino, but I have been helping Fadil Berisha (on Cc) to get I2C to work on mx23. He managed to get I2C working on his mx23 board and posted the results at: https://www.olimex.com/forum/index.php?topic=283.msg1086#msg1086 He has already sent the dts patches to the ARM kernel list. Regards, Fabio Estevam -- 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: i2c-ocores: Move grlib set/get functions into #ifdef CONFIG_OF block
This moves the grlib set and get functions into the #ifdef CONFIG_OF block to
avoid warnings of unimplemented functions when compiling with -Wunused-function
when CONFIG_OF is not defined.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
To be applied to the for-next tree
drivers/i2c/busses/i2c-ocores.c | 68 +++---
1 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 2ef318b..3ea2ee7 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -109,40 +109,6 @@ static inline u8 oc_getreg_32(struct ocores_i2c *i2c, int
reg)
return ioread32(i2c-base + (reg i2c-reg_shift));
}
-/* Read and write functions for the GRLIB port of the controller. Registers are
- * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly.
*/
-static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
-{
- u32 rd;
- int rreg = reg;
- if (reg != OCI2C_PRELOW)
- rreg--;
- rd = ioread32be(i2c-base + (rreg i2c-reg_shift));
- if (reg == OCI2C_PREHIGH)
- return (u8)(rd 8);
- else
- return (u8)rd;
-}
-
-static void oc_setreg_grlib(struct ocores_i2c *i2c, int reg, u8 value)
-{
- u32 curr, wr;
- int rreg = reg;
- if (reg != OCI2C_PRELOW)
- rreg--;
- if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
- curr = ioread32be(i2c-base + (rreg i2c-reg_shift));
- if (reg == OCI2C_PRELOW)
- wr = (curr 0xff00) | value;
- else
- wr = (((u32)value) 8) | (curr 0xff);
- } else {
- wr = value;
- }
- iowrite32be(wr, i2c-base + (rreg i2c-reg_shift));
-}
-
static inline void oc_setreg(struct ocores_i2c *i2c, int reg, u8 value)
{
i2c-setreg(i2c, reg, value);
@@ -303,6 +269,40 @@ static struct of_device_id ocores_i2c_match[] = {
MODULE_DEVICE_TABLE(of, ocores_i2c_match);
#ifdef CONFIG_OF
+/* Read and write functions for the GRLIB port of the controller. Registers are
+ * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
+ * register. The subsequent registers has their offset decreased accordingly.
*/
+static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
+{
+ u32 rd;
+ int rreg = reg;
+ if (reg != OCI2C_PRELOW)
+ rreg--;
+ rd = ioread32be(i2c-base + (rreg i2c-reg_shift));
+ if (reg == OCI2C_PREHIGH)
+ return (u8)(rd 8);
+ else
+ return (u8)rd;
+}
+
+static void oc_setreg_grlib(struct ocores_i2c *i2c, int reg, u8 value)
+{
+ u32 curr, wr;
+ int rreg = reg;
+ if (reg != OCI2C_PRELOW)
+ rreg--;
+ if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
+ curr = ioread32be(i2c-base + (rreg i2c-reg_shift));
+ if (reg == OCI2C_PRELOW)
+ wr = (curr 0xff00) | value;
+ else
+ wr = (((u32)value) 8) | (curr 0xff);
+ } else {
+ wr = value;
+ }
+ iowrite32be(wr, i2c-base + (rreg i2c-reg_shift));
+}
+
static int ocores_i2c_of_probe(struct platform_device *pdev,
struct ocores_i2c *i2c)
{
--
1.7.0.4
--
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: tfp410 and i2c_bus_num
Hi, On Mon, Nov 19, 2012 at 01:09:42PM +0200, Tomi Valkeinen wrote: On 2012-11-19 11:27, Felipe Balbi wrote: If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. Afaik, v4l2 handles only the pipeline for video. This i2c-edid would not be part of the video pipeline, so I don't see a connection to v4l2. hehe, I was using an example of building a pipeline and adding whatever devices you wanted to the pipeline ;-) And I'm not saying it's not possible, or that the current way is good or correct. I'm saying it's not easy, and definitely more complex than the current tfp410 implementation. The amount of code related to this feature would multiply. If we had 10 different tfp410 like drivers, then obviously there'd be more pressing reason to clean this up. But currently we have only one place where this code is used. fair enough, but I'd say there are two places: DSS and DRM. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Yep. Althought the same could be done with a common edid library, without an i2c-edid driver. correct. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. TFP410 doesn't need the EDID for anything, it just provides it as raw data. Parsing the EDID is done in other layers. But as you said, instead of tfp410 fetching the EDID and providing it, tfp410 could get the EDID from the i2c-edid driver and pass it forward. Or whatever layer needs EDID would fetch it directly instead of going through tfp410. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. If with users you mean, for example, tfp410, then true. But tfp410 doesn't use EDID for anything, it just provides it. For the actual users of the EDID data reading the EDID is encapsulated already. fair enough. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. Well, yes. TFP410 is a RGB to DVI chip. It knows that the underlying bus is DVI, and that there are i2c lines to read the EDID. There are no other option what the busses could be. So I don't see any problem with knowing the underlying bus. passing i2c_bus_num should be an indicator that something is wrong with your design. Note that not only TFP410 knows that it has an underlying i2c bus, it needs to know exactly which bus it needs to use. Also keep in mind that i2c bus numbers are assigned by the kernel and could be anything. Any changes to the order of adding i2c buses, might break your i2c_bus_num parameter. Of course this is all hypothetical, but it shows that current design is fragile, IMHO. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read
Re: [PATCH 1/2] i2c: Add possibility for user-defined (i2c-)devices for bus-drivers.
Hello,
after the needed break in the discussion (to calm down), I've decided to make a
last try. I don't want to make a thesis about USB RTCs, nor do I want to write
a whole new driver (and afterwards trying to get such into the kernel, not to
speak about the then necessary explicit device/vendor ID).
On Wed, Nov 14, 2012 at 08:22:34PM +0100, t...@harbaum.org wrote:
i have seen i2c chips going nuts because some probing actually affected the
chips state. So i fully agree with Jean here.
I've now changed the device registration from using i2c_new_probed_device() to
i2c_new_device(),
even if that would register non-existent RTCs.
I2C just isn't meant to be used for hot plugging. And so isn't the
i2c-tiny-usb. It's more a hacking and testing device and is e.g. very
convenient to test i2c client drivers or to test some new i2c hardware. But i
have never had a need for this before user land was available. And once it is
you can really do any magic you want using e.g. udev and sysfs.
As you've written yourself, i2c-tiny-usb is more a hacking and testing device,
so there's hopefully no real argument left against including the few lines to
enable devices through module options or the kernel command line. Someone could
like to test such too with the hacking and testing device.
Regards,
Alexander
From 1aa6bbd0a87ce39f9889f835d12127226ffa9403 Mon Sep 17 00:00:00 2001
From: Alexander Holler hol...@ahsoftware.de
Date: Tue, 13 Nov 2012 16:28:07 +0100
Subject: [PATCH] i2c: i2c-tiny-usb: Add parameter for optional i2c-devices.
Make it possible to define i2c-devices at the kernel command line
or as a module parameter.
Format is devname1@addr1,devname2@addr2,...
Example for the kernel command line:
i2c-tiny-usb.devices=ds1307@0x68,pcf8563@0x51
The definition of up to 8 devices is allowed.
Cc: Till Harbaum t...@harbaum.org
Signed-off-by: Alexander Holler hol...@ahsoftware.de
---
drivers/i2c/busses/i2c-tiny-usb.c | 44 +
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tiny-usb.c
b/drivers/i2c/busses/i2c-tiny-usb.c
index 0510636..a3fc711 100644
--- a/drivers/i2c/busses/i2c-tiny-usb.c
+++ b/drivers/i2c/busses/i2c-tiny-usb.c
@@ -40,6 +40,11 @@ module_param(delay, ushort, 0);
MODULE_PARM_DESC(delay, bit delay in microseconds
(default is 10us for 100kHz max));
+#define MAX_OPTIONAL_I2C_DEVICES 8
+static char *opt_devices[MAX_OPTIONAL_I2C_DEVICES];
+module_param_array_named(devices, opt_devices, charp, NULL, 0);
+MODULE_PARM_DESC(devices, devname1@adr1,devname2@adr2,... (e.g.
ds1307@0x68));
+
static int usb_read(struct i2c_adapter *adapter, int cmd,
int value, int index, void *data, int len);
@@ -184,6 +189,42 @@ static void i2c_tiny_usb_free(struct i2c_tiny_usb *dev)
kfree(dev);
}
+static void i2c_add_optional_devices(struct i2c_adapter *adapter)
+{
+ int i;
+ struct i2c_board_info i2c_info;
+ uint addr;
+ const char *at;
+
+ for (i = 0; opt_devices[i]; ++i) {
+ at = strchr(opt_devices[i], '@');
+ if (at++ == NULL) {
+ dev_warn(adapter-dev,
+ address needed in device definition '%s'\n,
+ opt_devices[i]);
+ continue;
+ }
+ if (kstrtouint(at, 0, addr) || addr = I2C_CLIENT_END) {
+ dev_warn(adapter-dev,
+ wrong address in device definition '%s'\n,
+ opt_devices[i]);
+ continue;
+ }
+ memset(i2c_info, 0, sizeof(struct i2c_board_info));
+ strlcpy(i2c_info.type, opt_devices[i],
+ min(I2C_NAME_SIZE, (int)(at-opt_devices[i])));
+ i2c_info.addr = addr;
+ if (i2c_new_device(adapter, i2c_info) != NULL)
+ dev_info(adapter-dev,
+ device %s at address 0x%02x registered\n,
+ i2c_info.type, addr);
+ else
+ dev_warn(adapter-dev,
+ device %s at address 0x%02x not found\n,
+ i2c_info.type, addr);
+ }
+}
+
static int i2c_tiny_usb_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
@@ -236,6 +277,9 @@ static int i2c_tiny_usb_probe(struct usb_interface
*interface,
/* inform user about successful attachment to i2c layer */
dev_info(dev-adapter.dev, connected i2c-tiny-usb device\n);
+ /* add optional devices */
+ i2c_add_optional_devices(dev-adapter);
+
return 0;
error:
--
1.7.8.6
--
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
Re: [PATCH 1/2] i2c: mxs: Handle i2c DMA failure properly
Dear Wolfram Sang, On Sun, Nov 18, 2012 at 06:25:07AM +0100, Marek Vasut wrote: Properly terminate the DMA transfer in case the DMA PIO transfer or setup fails for any reason. Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam feste...@gmail.com Cc: Tim Michals tcmich...@gmail.com Cc: Wolfram Sang w.s...@pengutronix.de I liked the one patch approach better; but mainly still waiting for Tim's response. Oh well ... you now have both, pick whichever you like ;-) Agreed, we should wait for Tim. I thought he said he'd send the patch on friday, no ? btw. I guess we won't be able to squeeze these into 3.7 anymore, right? Even if I'd say these are fixes. Best regards, Marek Vasut -- 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 2/2] i2c: mxs: Do not disable the I2C SMBus quick mode
Dear Tim Michals, Mr. Marek Vasut, Ugh, I feel so old ;-D [...] diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 286ca19..0670da7 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -287,12 +287,14 @@ read_init_dma_fail: select_init_dma_fail: dma_unmap_sg(i2c-dev, i2c-sg_io[0], 1, DMA_TO_DEVICE); select_init_pio_fail: + dmaengine_terminate_all(i2c-dmach); return -EINVAL; /* Write failpath. */ write_init_dma_fail: dma_unmap_sg(i2c-dev, i2c-sg_io, 2, DMA_TO_DEVICE); write_init_pio_fail: + dmaengine_terminate_all(i2c-dmach); return -EINVAL; } I tested both patches using Linux version 3.7.0-rc4 with the following command: Did you test it on mx28 or on mx23? I tested it on mx28 with i2cdetect -y 0 and it worked. # i2cdetect -r 0 20 30 [...] Attaching my results on MX28 (and note, I also attach dmesg and I re-ran the test to proove it's replicable -- aka. the DMA engine doesn't stall). ~ # /i2cdetect.static -r 0 20 30 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using read byte commands. I will probe address range 0x14-0x1e. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 10: -- -- -- -- -- -- -- -- -- -- -- 20: 30: 40: 50: 60: 70: ~ # dmesg | tail -n 12 [6.96] Freeing init memory: 1348K [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 [ 29.50] mxs-dma 80024000.dma-apbx: mxs_dma_int_handler: error in channel 6 ~ # /i2cdetect.static -r 0 20 30 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using read byte commands. I will probe address range 0x14-0x1e. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 10: -- -- -- -- -- -- -- -- -- -- -- 20: 30: 40: 50: 60: 70: Best regards, Marek Vasut -- 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 2/2] i2c: mxs: Do not disable the I2C SMBus quick mode
Dear Tim Michals, [...] ~ # /i2cdetect.static -r 0 20 30 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using read byte commands. I will probe address range 0x14-0x1e. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 10: -- -- -- -- -- -- -- -- -- -- -- 20: 30: 40: 50: 60: 70: Best regards, Marek Vasut I'm using a imx233, I don't know what would be different or cause this issue. The register layout differs. You might want to check if all the register programing is correct. Make sure the placement of various bits is correct. Also see how the DMA operates with the transfer length on MX23 and MX28 ... there are quite a few differences and I didn't test the driver on MX23 like that. I recall someone testing it on a different MX23 board but only by some standard usage. -- 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 207/493] i2c: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jochen Friedrich joc...@scram.de
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Vitaly Wool vitalyw...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Barry Song baohua.s...@csr.com
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: linux-i2c@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-ali1535.c| 4 ++--
drivers/i2c/busses/i2c-ali1563.c| 4 ++--
drivers/i2c/busses/i2c-ali15x3.c| 4 ++--
drivers/i2c/busses/i2c-amd756.c | 2 +-
drivers/i2c/busses/i2c-amd8111.c| 2 +-
drivers/i2c/busses/i2c-at91.c | 6 +++---
drivers/i2c/busses/i2c-au1550.c | 2 +-
drivers/i2c/busses/i2c-cpm.c| 4 ++--
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-eg20t.c | 2 +-
drivers/i2c/busses/i2c-elektor.c| 4 ++--
drivers/i2c/busses/i2c-gpio.c | 4 ++--
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hydra.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 14 +++---
drivers/i2c/busses/i2c-ibm_iic.c| 4 ++--
drivers/i2c/busses/i2c-intel-mid.c | 2 +-
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-mpc.c| 20 ++--
drivers/i2c/busses/i2c-mv64xxx.c| 12 ++--
drivers/i2c/busses/i2c-mxs.c| 2 +-
drivers/i2c/busses/i2c-nforce2.c| 4 ++--
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-ocores.c | 2 +-
drivers/i2c/busses/i2c-octeon.c | 6 +++---
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-parport-light.c | 2 +-
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-pca-isa.c| 4 ++--
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 10 +-
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-pnx.c| 2 +-
drivers/i2c/busses/i2c-powermac.c | 12 ++--
drivers/i2c/busses/i2c-puv3.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c| 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-s6000.c | 4 ++--
drivers/i2c/busses/i2c-sh7760.c | 4 ++--
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-sis5595.c| 4 ++--
drivers/i2c/busses/i2c-sis630.c | 4 ++--
drivers/i2c/busses/i2c-sis96x.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-via.c| 2 +-
drivers/i2c/busses/i2c-viapro.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlr.c| 2 +-
drivers/i2c/busses/scx200_acb.c | 10 +-
drivers/i2c/muxes/i2c-mux-gpio.c| 4 ++--
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
52 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali1535.c b/drivers/i2c/busses/i2c-ali1535.c
index cb30432..9ee96f0 100644
--- a/drivers/i2c/busses/i2c-ali1535.c
+++ b/drivers/i2c/busses/i2c-ali1535.c
@@ -139,7 +139,7 @@ static unsigned short ali1535_offset;
Note the differences between kernels with the old PCI BIOS interface and
newer kernels with the real PCI interface. In compat.h some things are
defined to make the transition easier. */
-static int __devinit ali1535_setup(struct pci_dev *dev)
+static int ali1535_setup(struct pci_dev *dev)
{
int retval;
unsigned char temp;
@@ -502,7 +502,7 @@ static DEFINE_PCI_DEVICE_TABLE(ali1535_ids) = {
MODULE_DEVICE_TABLE(pci, ali1535_ids);
-static int __devinit ali1535_probe(struct pci_dev *dev, const struct
pci_device_id *id)
+static int ali1535_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
if (ali1535_setup(dev)) {
dev_warn(dev-dev,
diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index 547a96f..55c27b9 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
@@ -326,7 +326,7 @@ static u32 ali1563_func(struct i2c_adapter * a)
}
-static int __devinit ali1563_setup(struct pci_dev * dev)
+static int ali1563_setup(struct pci_dev * dev)
{
u16 ctrl;
@@ -390,7
[PATCH 306/493] i2c: remove use of __devinitdata
CONFIG_HOTPLUG is going away as an option so __devinitdata is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: linux-i2c@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
---
drivers/i2c/busses/i2c-i801.c| 4 ++--
drivers/i2c/busses/i2c-mpc.c | 10 +-
drivers/i2c/busses/i2c-mv64xxx.c | 2 +-
drivers/i2c/busses/i2c-nforce2.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 4 ++--
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index d362004..5971441 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -841,7 +841,7 @@ struct dmi_onboard_device_info {
const char *i2c_type;
};
-static struct dmi_onboard_device_info __devinitdata dmi_devices[] = {
+static struct dmi_onboard_device_info dmi_devices[] = {
{ Syleus, DMI_DEV_TYPE_OTHER, 0x73, fscsyl },
{ Hermes, DMI_DEV_TYPE_OTHER, 0x73, fscher },
{ Hades, DMI_DEV_TYPE_OTHER, 0x73, fschds },
@@ -944,7 +944,7 @@ static struct i801_mux_config i801_mux_config_asus_z8_d18 =
{
.n_gpios = 2,
};
-static struct dmi_system_id __devinitdata mux_dmi_table[] = {
+static struct dmi_system_id mux_dmi_table[] = {
{
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, ASUSTeK Computer INC.),
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index caede3c..c26095d 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -746,24 +746,24 @@ static int mpc_i2c_resume(struct device *dev)
SIMPLE_DEV_PM_OPS(mpc_i2c_pm_ops, mpc_i2c_suspend, mpc_i2c_resume);
#endif
-static const struct mpc_i2c_data mpc_i2c_data_512x __devinitdata = {
+static const struct mpc_i2c_data mpc_i2c_data_512x = {
.setup = mpc_i2c_setup_512x,
};
-static const struct mpc_i2c_data mpc_i2c_data_52xx __devinitdata = {
+static const struct mpc_i2c_data mpc_i2c_data_52xx = {
.setup = mpc_i2c_setup_52xx,
};
-static const struct mpc_i2c_data mpc_i2c_data_8313 __devinitdata = {
+static const struct mpc_i2c_data mpc_i2c_data_8313 = {
.setup = mpc_i2c_setup_8xxx,
};
-static const struct mpc_i2c_data mpc_i2c_data_8543 __devinitdata = {
+static const struct mpc_i2c_data mpc_i2c_data_8543 = {
.setup = mpc_i2c_setup_8xxx,
.prescaler = 2,
};
-static const struct mpc_i2c_data mpc_i2c_data_8544 __devinitdata = {
+static const struct mpc_i2c_data mpc_i2c_data_8544 = {
.setup = mpc_i2c_setup_8xxx,
.prescaler = 3,
};
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 06dd6aa..39a0a78 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -718,7 +718,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
return rc;
}
-static const struct of_device_id mv64xxx_i2c_of_match_table[] __devinitdata = {
+static const struct of_device_id mv64xxx_i2c_of_match_table[] = {
{ .compatible = marvell,mv64xxx-i2c, },
{}
};
diff --git a/drivers/i2c/busses/i2c-nforce2.c b/drivers/i2c/busses/i2c-nforce2.c
index d820a93..1012183 100644
--- a/drivers/i2c/busses/i2c-nforce2.c
+++ b/drivers/i2c/busses/i2c-nforce2.c
@@ -117,7 +117,7 @@ struct nforce2_smbus {
#define MAX_TIMEOUT100
/* We disable the second SMBus channel on these boards */
-static struct dmi_system_id __devinitdata nforce2_dmi_blacklist2[] = {
+static struct dmi_system_id nforce2_dmi_blacklist2[] = {
{
.ident = DFI Lanparty NF4 Expert,
.matches = {
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 891f2b5..1cce916 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -99,7 +99,7 @@ MODULE_PARM_DESC(force_addr,
static int srvrworks_csb5_delay;
static struct pci_driver piix4_driver;
-static struct dmi_system_id __devinitdata piix4_dmi_blacklist[] = {
+static struct dmi_system_id piix4_dmi_blacklist[] = {
{
.ident = Sapphire AM2RD790,
.matches = {
@@ -119,7 +119,7 @@ static struct dmi_system_id __devinitdata
piix4_dmi_blacklist[] = {
/* The IBM entry is in a separate table because we only check it
on Intel-based systems */
-static struct dmi_system_id __devinitdata piix4_dmi_ibm[] = {
+static struct dmi_system_id piix4_dmi_ibm[] = {
{
.ident = IBM,
.matches = { DMI_MATCH(DMI_SYS_VENDOR, IBM), },
--
1.8.0
--
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 404/493] i2c: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jochen Friedrich joc...@scram.de
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Vitaly Wool vitalyw...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Barry Song baohua.s...@csr.com
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: linux-i2c@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-ali1535.c| 2 +-
drivers/i2c/busses/i2c-ali1563.c| 2 +-
drivers/i2c/busses/i2c-ali15x3.c| 2 +-
drivers/i2c/busses/i2c-amd756.c | 2 +-
drivers/i2c/busses/i2c-amd8111.c| 2 +-
drivers/i2c/busses/i2c-at91.c | 2 +-
drivers/i2c/busses/i2c-au1550.c | 2 +-
drivers/i2c/busses/i2c-cpm.c| 2 +-
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-eg20t.c | 2 +-
drivers/i2c/busses/i2c-elektor.c| 2 +-
drivers/i2c/busses/i2c-gpio.c | 2 +-
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hydra.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 4 ++--
drivers/i2c/busses/i2c-ibm_iic.c| 2 +-
drivers/i2c/busses/i2c-intel-mid.c | 2 +-
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-mpc.c| 2 +-
drivers/i2c/busses/i2c-mv64xxx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c| 2 +-
drivers/i2c/busses/i2c-nforce2.c| 2 +-
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-ocores.c | 2 +-
drivers/i2c/busses/i2c-octeon.c | 2 +-
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-parport-light.c | 2 +-
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-pca-isa.c| 2 +-
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 4 ++--
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-pnx.c| 2 +-
drivers/i2c/busses/i2c-powermac.c | 2 +-
drivers/i2c/busses/i2c-puv3.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c| 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-s6000.c | 2 +-
drivers/i2c/busses/i2c-sh7760.c | 2 +-
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-sis630.c | 2 +-
drivers/i2c/busses/i2c-sis96x.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-via.c| 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlr.c| 2 +-
drivers/i2c/busses/scx200_acb.c | 4 ++--
drivers/i2c/muxes/i2c-mux-gpio.c| 2 +-
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
50 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali1535.c b/drivers/i2c/busses/i2c-ali1535.c
index 9ee96f0..3f49181 100644
--- a/drivers/i2c/busses/i2c-ali1535.c
+++ b/drivers/i2c/busses/i2c-ali1535.c
@@ -518,7 +518,7 @@ static int ali1535_probe(struct pci_dev *dev, const struct
pci_device_id *id)
return i2c_add_adapter(ali1535_adapter);
}
-static void __devexit ali1535_remove(struct pci_dev *dev)
+static void ali1535_remove(struct pci_dev *dev)
{
i2c_del_adapter(ali1535_adapter);
release_region(ali1535_smba, ALI1535_SMB_IOSIZE);
diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index 55c27b9..5b17c9f 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
@@ -411,7 +411,7 @@ exit:
return error;
}
-static void __devexit ali1563_remove(struct pci_dev * dev)
+static void ali1563_remove(struct pci_dev * dev)
{
i2c_del_adapter(ali1563_adapter);
ali1563_shutdown(dev);
diff --git a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
index 2d32690..26bcc61 100644
--- a/drivers/i2c/busses/i2c-ali15x3.c
+++ b/drivers/i2c/busses/i2c-ali15x3.c
@@ -500,7 +500,7 @@ static int ali15x3_probe(struct pci_dev *dev, const struct
pci_device_id *id)
return i2c_add_adapter(ali15x3_adapter);
}
-static void __devexit ali15x3_remove(struct pci_dev *dev)
+static void ali15x3_remove(struct pci_dev *dev)
{
i2c_del_adapter(ali15x3_adapter);
release_region(ali15x3_smba, ALI15X3_SMB_IOSIZE);
diff --git a/drivers/i2c/busses/i2c-amd756.c b/drivers/i2c/busses/i2c-amd756.c
[PATCH 413/493] misc: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Eric Piel eric.p...@tremplin-utc.net
Cc: Jiri Slaby jirisl...@gmail.com
Cc: linux-i2c@vger.kernel.org
---
drivers/misc/ad525x_dpot-i2c.c | 2 +-
drivers/misc/ad525x_dpot-spi.c | 2 +-
drivers/misc/apds9802als.c | 2 +-
drivers/misc/apds990x.c| 2 +-
drivers/misc/atmel-ssc.c | 2 +-
drivers/misc/bh1770glc.c | 2 +-
drivers/misc/bh1780gli.c | 2 +-
drivers/misc/cb710/core.c | 2 +-
drivers/misc/eeprom/at24.c | 2 +-
drivers/misc/eeprom/at25.c | 2 +-
drivers/misc/eeprom/eeprom_93xx46.c| 2 +-
drivers/misc/fsa9480.c | 2 +-
drivers/misc/ibmasm/module.c | 2 +-
drivers/misc/ioc4.c| 2 +-
drivers/misc/isl29003.c| 2 +-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 2 +-
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 2 +-
drivers/misc/mei/main.c| 2 +-
drivers/misc/pch_phub.c| 2 +-
drivers/misc/phantom.c | 2 +-
drivers/misc/pti.c | 2 +-
drivers/misc/spear13xx_pcie_gadget.c | 2 +-
drivers/misc/ti_dac7512.c | 2 +-
drivers/misc/tsl2550.c | 2 +-
24 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/misc/ad525x_dpot-i2c.c b/drivers/misc/ad525x_dpot-i2c.c
index c7bc84d..705b881 100644
--- a/drivers/misc/ad525x_dpot-i2c.c
+++ b/drivers/misc/ad525x_dpot-i2c.c
@@ -68,7 +68,7 @@ static int ad_dpot_i2c_probe(struct i2c_client *client,
return ad_dpot_probe(client-dev, bdata, id-driver_data, id-name);
}
-static int __devexit ad_dpot_i2c_remove(struct i2c_client *client)
+static int ad_dpot_i2c_remove(struct i2c_client *client)
{
return ad_dpot_remove(client-dev);
}
diff --git a/drivers/misc/ad525x_dpot-spi.c b/drivers/misc/ad525x_dpot-spi.c
index 240c598..9da04ede 100644
--- a/drivers/misc/ad525x_dpot-spi.c
+++ b/drivers/misc/ad525x_dpot-spi.c
@@ -87,7 +87,7 @@ static int ad_dpot_spi_probe(struct spi_device *spi)
spi_get_device_id(spi)-name);
}
-static int __devexit ad_dpot_spi_remove(struct spi_device *spi)
+static int ad_dpot_spi_remove(struct spi_device *spi)
{
return ad_dpot_remove(spi-dev);
}
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index 77f7cdc..92fca41 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -254,7 +254,7 @@ als_error1:
return res;
}
-static int __devexit apds9802als_remove(struct i2c_client *client)
+static int apds9802als_remove(struct i2c_client *client)
{
struct als_data *data = i2c_get_clientdata(client);
diff --git a/drivers/misc/apds990x.c b/drivers/misc/apds990x.c
index b2aaf3f0..0e67f82 100644
--- a/drivers/misc/apds990x.c
+++ b/drivers/misc/apds990x.c
@@ -1181,7 +1181,7 @@ fail1:
return err;
}
-static int __devexit apds990x_remove(struct i2c_client *client)
+static int apds990x_remove(struct i2c_client *client)
{
struct apds990x_chip *chip = i2c_get_clientdata(client);
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index bce3676..96e6c5f 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -187,7 +187,7 @@ static int ssc_probe(struct platform_device *pdev)
return 0;
}
-static int __devexit ssc_remove(struct platform_device *pdev)
+static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
diff --git a/drivers/misc/bh1770glc.c b/drivers/misc/bh1770glc.c
index 003e8d9..2ed8fc3 100644
--- a/drivers/misc/bh1770glc.c
+++ b/drivers/misc/bh1770glc.c
@@ -1285,7 +1285,7 @@ fail1:
return err;
}
-static int __devexit bh1770_remove(struct i2c_client *client)
+static int bh1770_remove(struct i2c_client *client)
{
struct bh1770_chip *chip = i2c_get_clientdata(client);
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
index 3004904..cf03d0a 100644
--- a/drivers/misc/bh1780gli.c
+++ b/drivers/misc/bh1780gli.c
@@ -185,7 +185,7 @@ err_op_failed:
return ret;
}
-static int __devexit bh1780_remove(struct i2c_client *client)
+static int bh1780_remove(struct i2c_client *client)
{
struct bh1780_data *ddata;
diff --git a/drivers/misc/cb710/core.c b/drivers/misc/cb710/core.c
index 4fc9c37..2e50f81 100644
--- a/drivers/misc/cb710/core.c
+++ b/drivers/misc/cb710/core.c
@@ -305,7 +305,7 @@ unreg_mmc:
return err;
}
-static void __devexit cb710_remove_one(struct pci_dev *pdev)
+static void cb710_remove_one(struct pci_dev *pdev)
{
struct cb710_chip *chip = pci_get_drvdata(pdev);
unsigned long flags;
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
[PATCH 357/493] i2c: remove use of __devinitconst
CONFIG_HOTPLUG is going away as an option so __devinitconst is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Barry Song baohua.s...@csr.com
Cc: linux-i2c@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-mpc.c| 4 ++--
drivers/i2c/busses/i2c-sh_mobile.c | 2 +-
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index c26095d..4327dba 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -175,7 +175,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout,
int writing)
}
#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
-static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] __devinitconst = {
+static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
{28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
{36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
@@ -296,7 +296,7 @@ static void mpc_i2c_setup_512x(struct device_node *node,
#endif /* CONFIG_PPC_MPC512x */
#ifdef CONFIG_FSL_SOC
-static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] __devinitconst = {
+static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
{160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
{288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
{416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c
b/drivers/i2c/busses/i2c-sh_mobile.c
index 8110ca4..0a2a1cd 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -714,7 +714,7 @@ static const struct dev_pm_ops sh_mobile_i2c_dev_pm_ops = {
.runtime_resume = sh_mobile_i2c_runtime_nop,
};
-static const struct of_device_id sh_mobile_i2c_dt_ids[] __devinitconst = {
+static const struct of_device_id sh_mobile_i2c_dt_ids[] = {
{ .compatible = renesas,rmobile-iic, },
{},
};
diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
index 7f81a2c..65de4aa 100644
--- a/drivers/i2c/busses/i2c-sirf.c
+++ b/drivers/i2c/busses/i2c-sirf.c
@@ -433,7 +433,7 @@ static const struct dev_pm_ops i2c_sirfsoc_pm_ops = {
};
#endif
-static const struct of_device_id sirfsoc_i2c_of_match[] __devinitconst = {
+static const struct of_device_id sirfsoc_i2c_of_match[] = {
{ .compatible = sirf,prima2-i2c, },
{},
};
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 577887b..c658daa 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -642,7 +642,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
#if defined(CONFIG_OF)
/* Match table for of_platform binding */
-static const struct of_device_id tegra_i2c_of_match[] __devinitconst = {
+static const struct of_device_id tegra_i2c_of_match[] = {
{ .compatible = nvidia,tegra30-i2c, .data = tegra30_i2c_hw, },
{ .compatible = nvidia,tegra20-i2c, .data = tegra20_i2c_hw, },
{ .compatible = nvidia,tegra20-i2c-dvc, .data = tegra20_i2c_hw, },
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index f4e54a9..bb72d00 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -800,7 +800,7 @@ static int __devexit xiic_i2c_remove(struct
platform_device* pdev)
}
#if defined(CONFIG_OF)
-static const struct of_device_id xiic_of_match[] __devinitconst = {
+static const struct of_device_id xiic_of_match[] = {
{ .compatible = xlnx,xps-iic-2.00.a, },
{},
};
diff --git a/drivers/i2c/muxes/i2c-mux-pinctrl.c
b/drivers/i2c/muxes/i2c-mux-pinctrl.c
index a7a5584..c6b70b5 100644
--- a/drivers/i2c/muxes/i2c-mux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-mux-pinctrl.c
@@ -255,7 +255,7 @@ static int __devexit i2c_mux_pinctrl_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_OF
-static const struct of_device_id i2c_mux_pinctrl_of_match[] __devinitconst = {
+static const struct of_device_id i2c_mux_pinctrl_of_match[] = {
{ .compatible = i2c-mux-pinctrl, },
{},
};
--
1.8.0
--
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 065/493] i2c: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jochen Friedrich joc...@scram.de
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Vitaly Wool vitalyw...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Barry Song baohua.s...@csr.com
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: linux-i2c@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-ali1535.c| 2 +-
drivers/i2c/busses/i2c-ali1563.c| 2 +-
drivers/i2c/busses/i2c-ali15x3.c| 2 +-
drivers/i2c/busses/i2c-amd756.c | 2 +-
drivers/i2c/busses/i2c-amd8111.c| 2 +-
drivers/i2c/busses/i2c-at91.c | 2 +-
drivers/i2c/busses/i2c-au1550.c | 2 +-
drivers/i2c/busses/i2c-cpm.c| 2 +-
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-eg20t.c | 2 +-
drivers/i2c/busses/i2c-elektor.c| 2 +-
drivers/i2c/busses/i2c-gpio.c | 2 +-
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hydra.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 2 +-
drivers/i2c/busses/i2c-ibm_iic.c| 2 +-
drivers/i2c/busses/i2c-intel-mid.c | 2 +-
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-mpc.c| 2 +-
drivers/i2c/busses/i2c-mv64xxx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c| 2 +-
drivers/i2c/busses/i2c-nforce2.c| 2 +-
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-ocores.c | 2 +-
drivers/i2c/busses/i2c-octeon.c | 2 +-
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-parport-light.c | 2 +-
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-pca-isa.c| 2 +-
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 2 +-
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-pnx.c| 2 +-
drivers/i2c/busses/i2c-powermac.c | 2 +-
drivers/i2c/busses/i2c-puv3.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c| 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-s6000.c | 2 +-
drivers/i2c/busses/i2c-sh7760.c | 2 +-
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-sis630.c | 2 +-
drivers/i2c/busses/i2c-sis96x.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-via.c| 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlr.c| 2 +-
drivers/i2c/busses/scx200_acb.c | 2 +-
drivers/i2c/muxes/i2c-mux-gpio.c| 2 +-
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
50 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali1535.c b/drivers/i2c/busses/i2c-ali1535.c
index 125cd8e..cb30432 100644
--- a/drivers/i2c/busses/i2c-ali1535.c
+++ b/drivers/i2c/busses/i2c-ali1535.c
@@ -528,7 +528,7 @@ static struct pci_driver ali1535_driver = {
.name = ali1535_smbus,
.id_table = ali1535_ids,
.probe = ali1535_probe,
- .remove = __devexit_p(ali1535_remove),
+ .remove = ali1535_remove,
};
module_pci_driver(ali1535_driver);
diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index e02d9f8..547a96f 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
@@ -428,7 +428,7 @@ static struct pci_driver ali1563_pci_driver = {
.name = ali1563_smbus,
.id_table = ali1563_id_table,
.probe = ali1563_probe,
- .remove = __devexit_p(ali1563_remove),
+ .remove = ali1563_remove,
};
module_pci_driver(ali1563_pci_driver);
diff --git a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
index ce8d26d..62692ec 100644
--- a/drivers/i2c/busses/i2c-ali15x3.c
+++ b/drivers/i2c/busses/i2c-ali15x3.c
@@ -510,7 +510,7 @@ static struct pci_driver ali15x3_driver = {
.name = ali15x3_smbus,
.id_table = ali15x3_ids,
.probe = ali15x3_probe,
- .remove = __devexit_p(ali15x3_remove),
+ .remove = ali15x3_remove,
};
module_pci_driver(ali15x3_driver);
diff --git a/drivers/i2c/busses/i2c-amd756.c
[PATCH 134/493] drivers/misc: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Eric Piel eric.p...@tremplin-utc.net
Cc: Jiri Slaby jirisl...@gmail.com
Cc: linux-i2c@vger.kernel.org
---
drivers/misc/ad525x_dpot-i2c.c | 2 +-
drivers/misc/ad525x_dpot-spi.c | 2 +-
drivers/misc/apds9802als.c | 2 +-
drivers/misc/apds990x.c| 2 +-
drivers/misc/atmel-ssc.c | 2 +-
drivers/misc/bh1770glc.c | 2 +-
drivers/misc/bh1780gli.c | 2 +-
drivers/misc/bmp085-i2c.c | 2 +-
drivers/misc/bmp085-spi.c | 2 +-
drivers/misc/cb710/core.c | 2 +-
drivers/misc/eeprom/at24.c | 2 +-
drivers/misc/eeprom/at25.c | 2 +-
drivers/misc/eeprom/eeprom_93xx46.c| 2 +-
drivers/misc/fsa9480.c | 2 +-
drivers/misc/hpilo.c | 2 +-
drivers/misc/ibmasm/module.c | 2 +-
drivers/misc/ioc4.c| 2 +-
drivers/misc/isl29003.c| 2 +-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 2 +-
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 2 +-
drivers/misc/pch_phub.c| 2 +-
drivers/misc/phantom.c | 2 +-
drivers/misc/pti.c | 2 +-
drivers/misc/ti_dac7512.c | 2 +-
drivers/misc/tsl2550.c | 2 +-
25 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/misc/ad525x_dpot-i2c.c b/drivers/misc/ad525x_dpot-i2c.c
index 8208262..7254a98 100644
--- a/drivers/misc/ad525x_dpot-i2c.c
+++ b/drivers/misc/ad525x_dpot-i2c.c
@@ -109,7 +109,7 @@ static struct i2c_driver ad_dpot_i2c_driver = {
.owner = THIS_MODULE,
},
.probe = ad_dpot_i2c_probe,
- .remove = __devexit_p(ad_dpot_i2c_remove),
+ .remove = ad_dpot_i2c_remove,
.id_table = ad_dpot_id,
};
diff --git a/drivers/misc/ad525x_dpot-spi.c b/drivers/misc/ad525x_dpot-spi.c
index f623175..67e3073 100644
--- a/drivers/misc/ad525x_dpot-spi.c
+++ b/drivers/misc/ad525x_dpot-spi.c
@@ -131,7 +131,7 @@ static struct spi_driver ad_dpot_spi_driver = {
.owner = THIS_MODULE,
},
.probe = ad_dpot_spi_probe,
- .remove = __devexit_p(ad_dpot_spi_remove),
+ .remove = ad_dpot_spi_remove,
.id_table = ad_dpot_spi_id,
};
diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index 0314773..77f7cdc 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -326,7 +326,7 @@ static struct i2c_driver apds9802als_driver = {
.pm = APDS9802ALS_PM_OPS,
},
.probe = apds9802als_probe,
- .remove = __devexit_p(apds9802als_remove),
+ .remove = apds9802als_remove,
.suspend = apds9802als_suspend,
.resume = apds9802als_resume,
.id_table = apds9802als_id,
diff --git a/drivers/misc/apds990x.c b/drivers/misc/apds990x.c
index ee74244..f955d54 100644
--- a/drivers/misc/apds990x.c
+++ b/drivers/misc/apds990x.c
@@ -1275,7 +1275,7 @@ static struct i2c_driver apds990x_driver = {
.pm = apds990x_pm_ops,
},
.probe= apds990x_probe,
- .remove = __devexit_p(apds990x_remove),
+ .remove = apds990x_remove,
.id_table = apds990x_id,
};
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index a769719..bce3676 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -206,7 +206,7 @@ static struct platform_driver ssc_driver = {
},
.id_table = atmel_ssc_devtypes,
.probe = ssc_probe,
- .remove = __devexit_p(ssc_remove),
+ .remove = ssc_remove,
};
module_platform_driver(ssc_driver);
diff --git a/drivers/misc/bh1770glc.c b/drivers/misc/bh1770glc.c
index 3d56ae7..c4b65e2 100644
--- a/drivers/misc/bh1770glc.c
+++ b/drivers/misc/bh1770glc.c
@@ -1395,7 +1395,7 @@ static struct i2c_driver bh1770_driver = {
.pm = bh1770_pm_ops,
},
.probe= bh1770_probe,
- .remove = __devexit_p(bh1770_remove),
+ .remove = bh1770_remove,
.id_table = bh1770_id,
};
diff --git a/drivers/misc/bh1780gli.c b/drivers/misc/bh1780gli.c
index f1f9877..54f6f39 100644
--- a/drivers/misc/bh1780gli.c
+++ b/drivers/misc/bh1780gli.c
@@ -248,7 +248,7 @@ static const struct i2c_device_id bh1780_id[] = {
static struct i2c_driver bh1780_driver = {
.probe = bh1780_probe,
- .remove = __devexit_p(bh1780_remove),
+ .remove = bh1780_remove,
.id_table = bh1780_id,
.driver = {
.name = bh1780,
diff --git a/drivers/misc/bmp085-i2c.c b/drivers/misc/bmp085-i2c.c
index a4f33c9..08cd795 100644
---
[PATCH 002/493] i2c: remove CONFIG_HOTPLUG ifdefs
Remove conditional code based on CONFIG_HOTPLUG being false. It's
always on now in preparation of it going away as an option.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: linux-i2c@vger.kernel.org
---
drivers/i2c/i2c-core.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a7edf98..9cebac0 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -86,9 +86,6 @@ static int i2c_device_match(struct device *dev, struct
device_driver *drv)
return 0;
}
-#ifdef CONFIG_HOTPLUG
-
-/* uevent helps with hotplug: modprobe -q $(MODALIAS) */
static int i2c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -100,10 +97,6 @@ static int i2c_device_uevent(struct device *dev, struct
kobj_uevent_env *env)
return 0;
}
-#else
-#define i2c_device_uevent NULL
-#endif /* CONFIG_HOTPLUG */
-
static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = i2c_verify_client(dev);
--
1.8.0
--
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] i2c: i2c-ocores: Move grlib set/get functions into #ifdef CONFIG_OF block
Andreas == Andreas Larsson andr...@gaisler.com writes: Andreas This moves the grlib set and get functions into the #ifdef Andreas CONFIG_OF block to avoid warnings of unimplemented functions Andreas when compiling with -Wunused-function when CONFIG_OF is not Andreas defined. Andreas Signed-off-by: Andreas Larsson andr...@gaisler.com Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard -- 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 2/2] i2c: mxs: Do not disable the I2C SMBus quick mode
Dear Tim Michals, [...] The register layout differs. You might want to check if all the register programing is correct. Make sure the placement of various bits is correct. Also see how the DMA operates with the transfer length on MX23 and MX28 ... there are quite a few differences and I didn't test the driver on MX23 like that. I recall someone testing it on a different MX23 board but only by some standard usage. OK, will report back in a couple of weeks due holidays and current assignment load. Ok, it might be better to apply these as they actually fix it on MX28 until you have a proper fix ready. We don't officially support MX23 with this driver anyway. Best regards, Marek Vasut -- 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 3/4] i2c-s3c2410: use exponential back off while polling for bus idle
On Thu, Nov 15, 2012 at 05:43:32PM +0530, Naveen Krishna Chatradhi wrote:
+ iicstat = readl(i2c-regs + S3C2410_IICSTAT);
+ delay = 1;
+ while ((iicstat S3C2410_IICSTAT_START)
+ktime_us_delta(now, start) S3C2410_IDLE_TIMEOUT) {
+ usleep_range(delay, 2 * delay);
+ if (delay S3C2410_IDLE_TIMEOUT / 10)
+ delay = 1;
+ now = ktime_get();
+ iicstat = readl(i2c-regs + S3C2410_IICSTAT);
+ }
- /* first, try busy waiting briefly */
- do {
- cpu_relax();
- iicstat = readl(i2c-regs + S3C2410_IICSTAT);
- } while ((iicstat S3C2410_IICSTAT_START) --spins);
On the hardware I was using when I wrote the original code here we were
hitting 1-2 spins often enough to be interesting - starting off with a
direct busy wait was definitely useful when doing large batches of I/O,
especially compared to sleeps which might cause us to schedule.
- /* if that timed out sleep */
- if (!spins) {
- msleep(1);
- iicstat = readl(i2c-regs + S3C2410_IICSTAT);
- }
It seems like it'd be better to do the exponential backoff bit here
instead of removing the busy wait completely.
--
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: i2c-s3c2410: Remove recently introduced performance overheads
The changes in i2c-s3c2410: use exponential back off while polling for
bus idle remove the initial busy wait for I2C transfers to complete and
replace it with usleep_range() calls which will schedule.
Since for older SoCs I2C transfers would usually complete within an
extremely small number of CPU cycles there is a win from not having to
schedule. This happens because on the older SoCs the cores run at a
smaller multiple of the speeds that the I2C bus is operating at; on more
modern SoCs the busy wait is less likely to be effective.
Fix the issue by restoring the busy wait, reducing the number of spins
from 20 to 3 which covers the overwhelming majority of I2C transfers on
the SoCs where the busy wait is effective.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/i2c/busses/i2c-s3c2410.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 31f802b..9050821 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -530,6 +530,7 @@ static void s3c24xx_i2c_wait_idle(struct s3c24xx_i2c *i2c)
unsigned long iicstat;
ktime_t start, now;
unsigned long delay;
+ int spins;
/* ensure the stop has been through the bus */
@@ -542,12 +543,22 @@ static void s3c24xx_i2c_wait_idle(struct s3c24xx_i2c *i2c)
* end of a transaction. However, really slow i2c devices can stretch
* the clock, delaying STOP generation.
*
-* As a compromise between idle detection latency for the normal, fast
-* case, and system load in the slow device case, use an exponential
-* back off in the polling loop, up to 1/10th of the total timeout,
-* then continue to poll at a constant rate up to the timeout.
+* On slower SoCs this typically happens within a very small number of
+* instructions so busy wait briefly to avoid scheduling overhead.
+*/
+ spins = 3;
+ do {
+ cpu_relax();
+ iicstat = readl(i2c-regs + S3C2410_IICSTAT);
+ } while ((iicstat S3C2410_IICSTAT_START) --spins);
+
+ /*
+* If we do get an appreciable delay as a compromise between idle
+* detection latency for the normal, fast case, and system load in the
+* slow device case, use an exponential back off in the polling loop,
+* up to 1/10th of the total timeout, then continue to poll at a
+* constant rate up to the timeout.
*/
- iicstat = readl(i2c-regs + S3C2410_IICSTAT);
delay = 1;
while ((iicstat S3C2410_IICSTAT_START)
ktime_us_delta(now, start) S3C2410_IDLE_TIMEOUT) {
--
1.7.10.4
--
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 065/493] i2c: remove use of __devexit_p
On Mon, Nov 19, 2012 at 11:50 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Reviewed-by: Shubhrajyoti D shubhrajy...@ti.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
