[i2c] [PATCH] i2c: inform about deprecated chips-directory
The chips directory under drivers/i2c is deprecated. Spread the word! Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- Maybe this makes Jean's life a bit easier ;) drivers/i2c/chips/Kconfig |3 +++ drivers/i2c/chips/Makefile |3 ++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 1735682..44a6e4c 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -1,6 +1,9 @@ # # Miscellaneous I2C chip drivers configuration # +# +# *** DEPRECATED! Do not add new entries! See Makefile *** +# menu Miscellaneous I2C Chip support diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index ca520fa..23d2a31 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -1,7 +1,8 @@ # # Makefile for miscellaneous I2C chip drivers. # -# Think twice before you add a new driver to this directory. +# Do not add new drivers to this directory! It is DEPRECATED. +# # Device drivers are better grouped according to the functionality they # implement rather than to the bus they are connected to. In particular: # * Hardware monitoring chip drivers go to drivers/hwmon -- 1.5.6.5 ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 4/6]: i2c-pcf: Add a way for bus driver to ask for no smbus quick mode support.
Hi Jean,
On Thu, Oct 16, 2008 at 12:13:15PM +0200, Jean Delvare wrote:
The pcf driver sets the class bit used by FAN and temperature sensors,
so the I2C layer goes poking around all of the standard address
locations each of those drivers list.
By setting this class flag in your driver, you ask for these probes.
What about making this more obvious? Something like this?
All the best,
Wolfram
===
i2c: Make clear what the class field of i2c_adapter is good for
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
include/linux/i2c.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/include/linux/i2c.h
===
--- linux-2.6.orig/include/linux/i2c.h
+++ linux-2.6/include/linux/i2c.h
@@ -345,7 +345,7 @@ struct i2c_algorithm {
struct i2c_adapter {
struct module *owner;
unsigned int id;
- unsigned int class;
+ unsigned int class; /* classes to allow probing for */
const struct i2c_algorithm *algo; /* the algorithm to access the bus */
void *algo_data;
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] [RESEND] i2c-cpm: Suppress autoprobing for devices
Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove automatic probing for this i2c controller. Might need updates to dts files using it. Signed-off-by: Wolfram Sang [EMAIL PROTECTED] Acked-by: Jochen Friedrich [EMAIL PROTECTED] --- Resend with cc to i2c. drivers/i2c/busses/i2c-cpm.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/i2c/busses/i2c-cpm.c === --- linux-2.6.orig/drivers/i2c/busses/i2c-cpm.c +++ linux-2.6/drivers/i2c/busses/i2c-cpm.c @@ -423,7 +423,6 @@ static const struct i2c_adapter cpm_ops .owner = THIS_MODULE, .name = i2c-cpm, .algo = cpm_i2c_algo, - .class = I2C_CLASS_HWMON | I2C_CLASS_SPD, }; static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm) -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 support added to i2c-algo-pca and i2c-pca-isa.c
Hi Marco, On Thu, Oct 02, 2008 at 08:27:05PM -0300, Marco Aurelio da Costa wrote: Glad to hear! I will make the changes as you sugests and submit the patch as soon as possible. I am out of office for some time. Any news on your patch? All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Question about i2c new style modle
Hello Wen, On Sun, Oct 12, 2008 at 02:35:49PM +0800, Wen Wang wrote: Can anyone please help to tell me if I have to upgrade my I2C client driver from legacy binding model to new style binding model in 2.6.27 kernel or not? It is not required yet, but it is always a good idea to move to the new binding (which will be required somewhen, nevertheless). If I have to :(, I don't know which part of code will update the board info about I2C devices or this should be done by the client driver? I am not sure if I understood what you meant with updating the board info. You supply i2c_board_info in your board init code and when the i2c adapter is initialized, it will call the client drivers probe-function. Maybe the guide in Documentation/i2c/upgrading-clients will further help you? All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Question about i2c new style modle
Hello Wen, On Sun, Oct 12, 2008 at 07:52:08PM +0800, Wen Wang wrote: i2c adapter is initialized, but I'm quite sure there won't be a such static i2c_board_info in the board init code. Well, you could add one :) And I'm just wonder if there is a dynamic detect method to go? There is also Documentation/i2c/writing-clients with a chapter about Device creation and Device detection using the standard driver model. For reference examples, just look in drivers/hwmon/. There should be plenty of drivers which use a detect-callback, in case you need this. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Question about vt82c596 SMBus driver (Via I2c Bus driver)
Hello Prakash, On Tue, Oct 07, 2008 at 11:19:46AM -0400, Mortha, Prakash wrote: Hi Jean, Please find attached the patches I have generated using quilt. Hopefully this should meet the requirements. (Please bear with me if this doesn't meet the requirements, as this is my first time to generate a official patch). No problem, we all have started somewhere :) Please do not send patches as attachments. It is considered good style to send them inline. Just use the 'quilt mail' command and you won't have problems with that (and also not with wrapped lines or similar). All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 support added to i2c-algo-pca and i2c-pca-isa.c
Hi Marco,
finally I came around to setup my board with the PCA9564. Here are my
results: The algo detected the PCA9564 and moaned about the old style of
supplying the frequency. I could easily change it to newstyle. In every
case, I could still correctly read out the eeprom. So, everything worked
flawlessly with a PCA9564. So, if the PCA9665 works for you and you just
apply these minor suggestions below, I think the patch is ready for
submission. For that, you should follow the canocical patch format
(Documentation/SubmittingPatches, Chapter 15) when you post that
version.
Reviewed-by: Wolfram Sang [EMAIL PROTECTED]
On Sat, Sep 20, 2008 at 09:10:12AM -0300, Marco Aurelio da Costa wrote:
Hi Wolfram.
On Sat, Sep 20, 2008 at 8:09 AM, Marco Aurelio da Costa [EMAIL PROTECTED]
wrote:
I will send you the corrected patch after your comment on the
auto-detection issue.
Actually, I changed my mind and implemented the auto-detection code.
Here is the new patch.
Regards,
Marco
diff -ur linux-2.6.26.5/drivers/i2c/algos/i2c-algo-pca.c
linux-2.6.26.5-new/drivers/i2c/algos/i2c-algo-pca.c
--- linux-2.6.26.5/drivers/i2c/algos/i2c-algo-pca.c 2008-09-08
14:40:20.0 -0300
+++ linux-2.6.26.5-new/drivers/i2c/algos/i2c-algo-pca.c 2008-09-20
09:07:35.0 -0300
@@ -43,6 +43,14 @@
#define pca_wait(adap) adap-wait_for_completion(adap-data)
#define pca_reset(adap) adap-reset_chip(adap-data)
+static void pca9665_reset(void *pd)
+{
+ struct i2c_algo_pca_data *adap = pd;
+ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_IPRESET);
+ pca_outw(adap, I2C_PCA_IND, 0xA5);
+ pca_outw(adap, I2C_PCA_IND, 0x5A);
+}
+
/*
* Generate a start condition on the i2c bus.
*
@@ -330,26 +338,176 @@
.functionality = pca_func,
};
-static int pca_init(struct i2c_adapter *adap)
+static unsigned int pca_probe_chip(struct i2c_adapter *adap)
{
- static int freqs[] = {330,288,217,146,88,59,44,36};
- int clock;
struct i2c_algo_pca_data *pca_data = adap-algo_data;
-
- if (pca_data-i2c_clock 7) {
- printk(KERN_WARNING %s: Invalid I2C clock speed selected.
Trying default.\n,
+ /* The trick here is to check if there is an indirect register
+ * available. If there is one, we will read the value we first
+ * wrote on I2C_PCA_IADR. Otherwise, we will read the last value
+ * we wrote on I2C_PCA_ADR
+ */
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_IADR);
+ pca_outw(pca_data, I2C_PCA_IND, 0xAA);
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ITO);
+ pca_outw(pca_data, I2C_PCA_IND, 0x00);
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_IADR);
+ if (pca_inw(pca_data, I2C_PCA_IND) == 0xAA) {
+ printk(KERN_INFO
+ %s: PCA9665 detected.,
\n is missing. Also, the whole printk should fit into one line.
adap-name);
- pca_data-i2c_clock = I2C_PCA_CON_59kHz;
+ return I2C_PCA_CHIP_9665;
+ } else {
+ printk(KERN_INFO
+ %s: PCA9564 detected.,
Here, too.
+ adap-name);
+ return I2C_PCA_CHIP_9564;
}
+}
+
+static int pca_init(struct i2c_adapter *adap)
+{
+ struct i2c_algo_pca_data *pca_data = adap-algo_data;
adap-algo = pca_algo;
- pca_reset(pca_data);
+ if (pca_probe_chip(adap) == I2C_PCA_CHIP_9564) {
+ static int freqs[] = {330, 288, 217, 146, 88, 59, 44, 36};
+ int clock;
+
+ if (pca_data-i2c_clock 7) {
+ switch (pca_data-i2c_clock) {
+ case 33:
+ pca_data-i2c_clock = I2C_PCA_CON_330kHz;
+ break;
+ case 288000:
+ pca_data-i2c_clock = I2C_PCA_CON_288kHz;
+ break;
+ case 217000:
+ pca_data-i2c_clock = I2C_PCA_CON_217kHz;
+ break;
+ case 146000:
+ pca_data-i2c_clock = I2C_PCA_CON_146kHz;
+ break;
+ case 88000:
+ pca_data-i2c_clock = I2C_PCA_CON_88kHz;
+ break;
+ case 59000:
+ pca_data-i2c_clock = I2C_PCA_CON_59kHz;
+ break;
+ case 44000:
+ pca_data-i2c_clock = I2C_PCA_CON_44kHz;
+ break;
+ case 36000:
+ pca_data-i2c_clock = I2C_PCA_CON_36kHz;
+ break;
+ default:
+ printk(KERN_WARNING
+ %s: Invalid I2C clock speed selected
Re: [i2c] [PATCH] hwmon: LM96000 support
Hello Herbert, On Wed, Oct 01, 2008 at 08:52:35PM +0200, Herbert Poetzl wrote: this patch adds proper support for LM96000 (at least the version I could test with) and provides some Please use the lm-sensors list for this one. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 support added to i2c-algo-pca and i2c-pca-isa.c
Hi Marco, On Wed, Sep 24, 2008 at 09:45:06AM -0300, Marco Aurelio da Costa wrote: Did you have time to look into the patch I sent? I had a look and found very minor issues only (spaces around operators), still I haven't had the time to actually test it on my pca9564-device. I haven't forgotten, but it is one of those weeks... :( All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 support added to i2c-algo-pca and i2c-pca-isa.c
-8s, Fall 29e-8s */
+ } else {
+ mode = I2C_PCA_MODE_STD;
+ min_tlow = 157;
+ min_thigh = 134;
+ raise_fall_time = 127; /* Raise 29e-8s, Fall 98e-8s */
+ }
+
+ if (clock 648) {
+ tlow = 255;
+ thigh = (100-clock*raise_fall_time)/(3*clock)-tlow;
CodingStyle (no spaces around operators)
The values look a bit magic. I could find min_t*-values in the spec,
still a reference to the section of the spec will be helpful. I think
you could elaborate a bit more on raise_fall_time and clock 648,
though.
+ } else {
+ tlow = ((100-clock*raise_fall_time)*min_tlow);
+ tlow /= (3*clock*(min_thigh+min_tlow));
+ thigh = tlow*min_thigh/min_tlow;
+ }
CodingStyle (no spaces around operators)
+
+ pca_reset(pca_data);
- pca_set_con(pca_data, I2C_PCA_CON_ENSIO | clock);
+ DEB1(KERN_INFO
+ %s: Clock frequency is %dHz\n, adap-name, clock*100);
CodingStyle (no spaces around operators)
+
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_IMODE);
+ pca_outw(pca_data, I2C_PCA_IND, mode);
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLL);
+ pca_outw(pca_data, I2C_PCA_IND, tlow);
+ pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLH);
+ pca_outw(pca_data, I2C_PCA_IND, thigh);
+
+ pca_set_con(pca_data, I2C_PCA_CON_ENSIO);
+ }
udelay(500); /* 500 us for oscilator to stabilise */
return 0;
@@ -384,7 +508,7 @@
MODULE_AUTHOR(Ian Campbell [EMAIL PROTECTED],
Wolfram Sang [EMAIL PROTECTED]);
-MODULE_DESCRIPTION(I2C-Bus PCA9564 algorithm);
+MODULE_DESCRIPTION(I2C-Bus PCA9564/PCA9665 algorithm);
MODULE_LICENSE(GPL);
module_param(i2c_debug, int, 0);
diff -ur linux-2.6.26.5/drivers/i2c/busses/i2c-pca-isa.c
linux-2.6.26.5-new/drivers/i2c/busses/i2c-pca-isa.c
--- linux-2.6.26.5/drivers/i2c/busses/i2c-pca-isa.c 2008-09-08
14:40:20.0 -0300
+++ linux-2.6.26.5-new/drivers/i2c/busses/i2c-pca-isa.c 2008-09-19
12:27:51.0 -0300
@@ -41,7 +41,8 @@
/* Data sheet recommends 59kHz for 100kHz operation due to variation
* in the actual clock rate */
-static int clock = I2C_PCA_CON_59kHz;
+static int clock = 59000;
+static int chip = I2C_PCA_CHIP_9564;
static wait_queue_head_t pca_wait;
@@ -103,7 +104,7 @@
.owner = THIS_MODULE,
.id = I2C_HW_A_ISA,
.algo_data = pca_isa_data,
- .name = PCA9564 ISA Adapter,
+ .name = PCA9564/PCA9665 ISA Adapter,
.timeout= 100,
};
@@ -132,6 +133,7 @@
}
}
+ pca_isa_data.i2c_chip_type = chip;
pca_isa_data.i2c_clock = clock;
if (i2c_pca_add_bus(pca_isa_ops) 0) {
dev_err(dev, Failed to add i2c bus\n);
@@ -182,7 +184,7 @@
}
MODULE_AUTHOR(Ian Campbell [EMAIL PROTECTED]);
-MODULE_DESCRIPTION(ISA base PCA9564 driver);
+MODULE_DESCRIPTION(ISA base PCA9564/PCA9665 driver);
MODULE_LICENSE(GPL);
module_param(base, ulong, 0);
@@ -191,7 +193,15 @@
module_param(irq, int, 0);
MODULE_PARM_DESC(irq, IRQ);
module_param(clock, int, 0);
-MODULE_PARM_DESC(clock, Clock rate as described in table 1 of PCA9564
datasheet);
+MODULE_PARM_DESC(clock, Clock rate in hertz.\n\t\t
+ For PCA9564: 33,288000,217000,146000,
+ 88000,59000,44000,36000\n
+ \t\tFor PCA9665:\tStandard: 60300 - 100099\n
+ \t\t\t\tFast: 100100 - 400099\n
+ \t\t\t\tFast+: 400100 - 1099\n
+ \t\t\t\tTurbo: Up to 1265800);
+module_param(chip, int, 0);
+MODULE_PARM_DESC(chip, Chip type: 0 = PCA9564; 1 - PCA9665);
module_init(pca_isa_init);
module_exit(pca_isa_exit);
diff -ur linux-2.6.26.5/drivers/i2c/busses/i2c-pca-platform.c
linux-2.6.26.5-new/drivers/i2c/busses/i2c-pca-platform.c
--- linux-2.6.26.5/drivers/i2c/busses/i2c-pca-platform.c 2008-09-08
14:40:20.0 -0300
+++ linux-2.6.26.5-new/drivers/i2c/busses/i2c-pca-platform.c 2008-09-19
12:28:36.0 -0300
@@ -172,8 +172,9 @@
i2c-adap.nr = pdev-id = 0 ? pdev-id : 0;
i2c-adap.owner = THIS_MODULE;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), PCA9564 at 0x%08lx,
- (unsigned long) res-start);
+ snprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ PCA9564/PCA9665 at 0x%08lx,
I think we could be precise here as we know the chip-type. I just got
the idea: Do you think it is possible to detect the chip type at
runtime? Perhaps by somehow checking the presence of the indirect
register?
+ (unsigned long) res-start);
i2c-adap.algo_data = i2c-algo_data;
i2c-adap.dev.parent
Re: [i2c] pca9665
Hello Marco, sorry for the late reply, I had to work on other parts first. On Wed, Sep 17, 2008 at 12:30:29PM -0300, Marco Aurelio da Costa wrote: I looked into the code for i2c-algo-pca.c and, if I don't want to implement the buffered mode (I can live without it for a while), But it may be worth to already get a rough idea if the buffered mode will fit into this algorithm at all. only changes I need to do are: 1. Implement the reset via parallel bus. I can't see this point right now. The algorithm expects a reset routine from the driver using the algorithm; this should be flexible enough, no? Or do you mean you also want to share i2c-pca-platform.c among those two chips. Then it's correct to change it there. Otherwise, please enlighten me, it's been some time :) 2. Change the way the i2c clock rate is treated, by passing the frequency directly instead of an index. Yup, this has to be generalized between these two. After this, this module could handle both chips. I need your advice: Should I just duplicate all code and make the changes to this new algo or should I add a chip_type field to i2c_algo_pca_data and handle the chip on the existing algo code? Concerning the algorithm, I'd really go for the latter. It is easier to maintain if there will be bugfixes to the state-machine, for example. And they seem to be similar enough (perhaps modulo the buffered mode, which I didn't look at so far). All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] pca9665
Hi Marco, On Fri, Sep 19, 2008 at 08:37:25AM -0300, Marco Aurelio da Costa wrote: I will have to understand the buffered mode first, but at worse I will have to check which mode is being used and add another logic path. Yes, let's hope it can be worked into the current logic then... My ideas was to share the platform and the isa code. This is easy enough. For the PCA9665, the platform will not define the reset function, and the algorithm will not even try use it. Okay, got it. I agree. I can do that then. We should then pass the frequency. For the 9564, I will just accept the chip defined frequencies. Sounds like the right way to do it. I just wonder if we simply can enforce this change of platform_data or if we should provide some transition feature. Jean, Ben, others, what are your experiences? That is also my view. I will start coding, and will send you the patch for review later. Happy hacking! :D Bye, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 support added to i2c-algo-pca and i2c-pca-isa.c
Here is the patch against 2.6.26.5.
Please tell me if I did something very wrong ;)
I'm just about to leave the office, so just the first notes. Will have a
deeper look later this evening...
+static void pca9665_reset(void *pd)
+{
+ struct i2c_algo_pca_data *adap = pd;
+ pca_outw(adap,I2C_PCA_INDPTR,I2C_PCA_IPRESET);
+ pca_outw(adap,I2C_PCA_IND,0xA5);
+ pca_outw(adap,I2C_PCA_IND,0x5A);
CodingStyle issues (space after comma)...
+ if (pca_data-i2c_chip_type != I2C_PCA_CHIP_9564
pca_data-i2c_chip_type != I2C_PCA_CHIP_9665 ) {
Line is longer than 80 chars. Please be sure to have run checkpatch.pl
before submitting.
+
Trailing whitespaces here (and in some other places).
+ int minTLow, minTHi;
This style of naming is at least unusual in kernel. Maybe min_tlow?
So much for now, more later...
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] PCA9665 controller
Hello Marco, On Tue, Sep 16, 2008 at 11:58:47AM -0300, Marco Aurelio da Costa wrote: Is someone working on a driver for the PCA9665? If not, I will start working on it. You probably already found that yourself, I just want to make sure; there already is a pca-platform-driver and a pca-algorithm. They should be useful for you... All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] LM95241 Driver proposal
On Wed, Aug 27, 2008 at 09:59:13AM +0200, Davide Rizzo wrote: Previous message contained HTML, this should be in plain text. It should also be posted to the lm-sensors-list and not i2c. It would also be more convenient for reviewers if you send patches inline and not as attachments. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Access 16bits address register in a device through I2C
Hi Wen, On Fri, Jul 18, 2008 at 12:13:30AM +0800, Wen Wang wrote: So I'm wondering do I miss something or what can I do? Any ideas? For an example what Ben suggested (2 messages), have a look at the at24-driver, which just went through the merge-window. http://article.gmane.org/gmane.linux.drivers.i2c/1661 Check functions 'at24_eeprom_[read|write]' for details. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] i2c: Documentation: upgrading clients HOWTO
Hi Ben,
(Ben, sorry for double-post, I accidently dropped the CC)
On Tue, Jul 15, 2008 at 09:26:23PM +0100, Ben Dooks wrote:
The two typos I mentioned before are still here.
[...]
+Update the detatch method, by changing the name to _remove and
Typo: detach
+to delete the i2c_detach_client call.
+
+- static int __devexit example_detach(struct i2c_client *client)
++ static int __devexit example_remove(struct i2c_client *client)
+{
+ struct example_state *state = i2c_get_clientdata(client);
+
+-i2c_detach_client(client);
+
+And finally ensure that we have the correct ID table for the i2c-core
+and other utilties:
Typo: utilities
+
++ struct i2c_device_id example_idtable[] = {
++ { example, 0 },
++ { }
++};
++
++MODULE_DEVICE_TABLE(i2c, example_idtable);
+
+static struct i2c_driver example_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = example,
+ },
++.id_table = example_ids,
+
+
+Our driver should now look like this:
+
+struct example_state {
+ struct i2c_client *client;
+
+};
+
+static int example_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct example_state *state;
+ struct device *dev = client-dev;
+ int ret;
ret is unused now. This could be mentioned. If you disagree, please
leave a short comment, so I know it was not overlooked.
+
+ state = kzalloc(sizeof(struct example_state), GFP_KERNEL);
+ if (state == NULL) {
+ dev_err(dev, failed to create our state\n);
+ return -ENOMEM;
+ }
+
+ state-client = client;
+ i2c_set_clientdata(client, state);
+
+ /* rest of the initialisation goes here. */
+
+ dev_info(dev, example client created\n);
+
+ return 0;
+}
+
+static int example_remove(struct i2c_client *client)
__devexit
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 12:23:23PM -0600, Grant Likely wrote: On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote: Firstly kernel warns at set_irq_chip, and then dies completely: Trying to install chip for IRQ-1 diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c index b2ccdcb..95a24de 100644 --- a/drivers/of/of_i2c.c +++ b/drivers/of/of_i2c.c @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap, if (info.irq == NO_IRQ) info.irq = -1; What is the reason that info.irq is set to -1 in the first place? This looks like another bug to me. Does something in the i2c layer depend on the -1 value? You already acked a fix to this :) I wasn't sure if my patch would make it on its own, as Jon Smirl was also working on fixes to of_i2c.c and he seemed to pick up this issue, too. (Original patch is here: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058801.html ) All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH v4] New-style EEPROM driver using device_ids (superseding the old eeprom driver)
Hello Ben On Wed, Jul 02, 2008 at 08:59:29PM +0100, Ben Dooks wrote: Out of interest, why not export via MTD? That was discussed here: http://article.gmane.org/gmane.linux.drivers.i2c/1270 All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
Hi Jean, On Tue, Jul 01, 2008 at 06:14:44PM +0200, Jean Delvare wrote: Applied, after fixing the patch so that it applies, fixing it again so that it is correct in the polling case, and fixing it again to make it pass checkpatch.pl. So, it cannot be applied directly? :( Could you repost the correct version perhaps? I'd like to test it, but can't find it at http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/ (because it is scheduled for 2.6.27?). All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH v4] New-style EEPROM driver using device_ids (superseding the old eeprom driver)
On Wed, Jul 02, 2008 at 04:30:04PM +0200, Jean Delvare wrote:
Great. The code looks very nice now, I think it's ready for merge.
Hooray! \o/
+/*
+ * Specs often allow 5 msec for a page write, sometimes 20 msec;
+ * it's important to recover from write timeouts.
+ */
+static unsigned write_timeout = 25;
+module_param(write_timeout, uint, 0);
No longer changeable at run-time? I don't mind, but I'm curious why you
changed it.
Sorry, forgot to document it. When wearing my paranoia-hat, I wondered
what happened if you start writing to an EEPROM with a sufficent value
and change it to an insufficent one while still writing to it. You will
most probably end up with broken eeprom content. This is why I thought
one should better measuer a good value once, and then keep it. Measuring
can easily be done by reloading the module with a different parameter
(or hacking the source if you want to change it run-time).
+ { 24c02, AT24_DEVICE_MAGIC(2048 / 8, 0) },
+ /* spd is a 24c02 in memory DIMMs */
+ { spd, AT24_DEVICE_MAGIC(2048 / 8,
+ AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
+ /* pcf8570 has SRAM only, write it all */
+ { pcf8570, AT24_DEVICE_MAGIC(2048 / 8, 0) },
Now that you use page-size of 1 in all cases, this comment is a bit
confusing. And I am curious if anyone will use this entry, given that
its the same as 24c02, and anyone who is certain to have a PCF8570
would provide platform data to take benefit of the lack of pages of
this chip.
I would at least remove the second part of the comment, and maybe even
the entry, unless you add a new flag AT2C_FLAG_SRAM which automatically
sets a large page size (if that makes sense) or restore the possibility
to set the page size, just for this entry.
ACK. I'd say, delete this entry for now. I guess the 'page_size'-issue
will arise sooner or later anyhow, maybe then this entry can be
reactivated.
+ if (chip.flags AT24_FLAG_TAKE8ADDR)
+ num_addresses = 8;
+ else
+ num_addresses = DIV_ROUND_UP(chip.byte_len,
+ chip.flags AT24_FLAG_ADDR16 ? 65536 : 256);
Extra parentheses wouldn't hurt... I wouldn't know off the top of my
head, which of and ?: has greater precedence.
Okay. Seems I got used to it that ?: is really low.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH v3] New-style I2C and SMBus EEPROM driver (with device_ids)
Hi Jean, hopefully, I now have the time to finish at24 for good. Do you think it can go through the next merge window? As I said, my thought there is to make it safe for most developers to just say 24c32 (or whatever) and have a sane default ... while making sure that they *always* have a way to set chips up to be readonly, or provide a better page size (if they need better bulk write speeds). I agree on the principle. But the question remains: what is a sane default in this context? Using the smallest page size amongst commonly used EEPROM models? Using the smallest page size amongst known models? Using the smallest possible page size (that would be 1 byte for all EEPROM sizes as I understand it)? This 3rd possibility would probably be no better than defaulting to read-only, as the write performance would be so bad that every developer would specify custom platform data. Hmm, I tend to set all page_sizes to 1. It is a bit awkward to write double check those parameters and then provide values you cannot be absolutely sure of. Still, a minimal write-possibility may come in handy, I think. I agree with Jean here, that it will be so slow, that developers surely will create their own platform_devices. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH v4] New-style EEPROM driver using device_ids (superseding the old eeprom driver)
Add a new-style driver for most I2C EEPROMs, giving sysfs read/write access to their data. Tested with various chips and clock rates. Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- Updates since last version: - fixed everything Jean mentioned in the last review - now platform_data has higher priority than device_ids - page_sizes for default values are always 1 - change code for calculating num_addresses - cleaning up comments Updates since last version: - added device_ids for common eeprom types (parameters encoded in a 'magic' driver_data value) - removed platform_data entry 'i2c_addr_mask' and calculated its value from other parameters - added 24c00-quirk flag (it covers 8 addresses) - added a flag to make eeproms world-readable (used for spd) - rewrote code that adds an i2c-address to an i2c-message - rewrote code which truncates to page_size - removed 'addr'-variable from eeprom-functions; i2c-address is now taken from the corresponding client-structure - write buffer now allocated once in probe - removed some sanity checks for file offsets as they are handled at the sysfs-layer already. - fixed typos and corrected spellings in comments and Kconfig - renamed some functions to be more self-explanatory - added includes - further cleanups and simplifications - added myself as another author Updates since last version: - revisited includes - made write-timeout a module parameter - array of clients is allocated dynamically - removed unnecessary indentation within code - formatted comments - replaced at24_ee_address with a simpler function - at24_ee_write now really waits till timeout - added simple checks of provided eeprom chip data in at24_probe - added comment in at24.h about double-checking custom data - minor fixes Updates in this version: - move chip data out of the driver into a seperate .h-file - prefix defined constants with AT24_ - make bin file readonly if requested by flags - introduce AT24_MAX_CLIENTS - bugfix: check correct retval in at24_ee_write drivers/i2c/chips/Kconfig | 26 ++ drivers/i2c/chips/Makefile |1 drivers/i2c/chips/at24.c | 585 include/linux/i2c/at24.h | 28 ++ 4 files changed, 640 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/at24.c create mode 100644 include/linux/i2c/at24.h diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2da2edf..cb01638 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -14,6 +14,32 @@ config DS1682 This driver can also be built as a module. If so, the module will be called ds1682. +config AT24 + tristate EEPROMs from most vendors + depends on SYSFS EXPERIMENTAL + help + Enable this driver to get read/write support to most I2C EEPROMs, + after you configure the driver to know about each EEPROM on + your target board. Use these generic chip names, instead of + vendor-specific ones like at24c64 or 24lc02: + +24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, +24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024 + + Unless you like data loss puzzles, always be sure that any chip + you configure as a 24c32 (32 kbit) or larger is NOT really a + 24c16 (16 kbit) or smaller, and vice versa. Marking the chip + as read-only won't help recover from this. Also, if your chip + has any software write-protect mechanism you may want to review the + code to make sure this driver won't turn it on by accident. + + If you use this with an SMBus adapter instead of an I2C adapter, + full functionality is not available. Only smaller devices are + supported (24c16 and below, max 4 kByte). + + This driver can also be built as a module. If so, the module + will be called at24. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index e47aca0..39e3e69 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -10,6 +10,7 @@ # obj-$(CONFIG_DS1682) += ds1682.o +obj-$(CONFIG_AT24) += at24.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o diff --git a/drivers/i2c/chips/at24.c b/drivers/i2c/chips/at24.c new file mode 100644 index 000..f346b9e --- /dev/null +++ b/drivers/i2c/chips/at24.c @@ -0,0 +1,585 @@ +/* + * at24.c - handle most I2C EEPROMs + * + * Copyright (C) 2005-2007 David Brownell + * Copyright (C) 2008 Wolfram Sang, Pengutronix + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your
[i2c] [PATCH] Fix bad hint about irqs in i2c.h
i2c.h mentions -1 as a not-issued irq. This false hint was taken by of_i2c and
caused crashes. Don't give any advice as 'no irq' is not consistent across all
architectures yet and it is not needed internally by the i2c-core.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
The crash was caused because of_i2c set .irq to -1 and later used that value
for dispose_mapping. Using 0x here instead of the original NO_IRQ
caused the crash. Patch for of_i2c will go via linux-ppcdev later, if it is
accepted here that the -1 is not required by the i2c-core and NO_IRQ is
equally sufficent.
include/linux/i2c.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index fb9af6a..8dc7301 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -171,7 +171,7 @@ struct i2c_client {
struct i2c_adapter *adapter;/* the adapter we sit on*/
struct i2c_driver *driver; /* and our access routines */
struct device dev; /* the device structure */
- int irq;/* irq issued by device (or -1) */
+ int irq;/* irq issued by device */
struct list_head list; /* DEPRECATED */
struct completion released;
};
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Grouping i2c bus drivers
Hi Jean, On Fri, Jun 27, 2008 at 02:52:36PM +0200, Jean Delvare wrote: Hi all, As was mentioned previously, I have decided to group the i2c bus drivers to make it easier for the users to know what they need (and also for me to know what drivers might be affected by a given problem.) Here is the list I have at the moment. There are still many drivers in the Other category. I suspect that many of these should move to the Embedded category, but I don't know for sure. So I would welcome comments and suggestions for improvements. From my first glimpse: # PC SMBus host controller drivers obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o obj-$(CONFIG_I2C_ALI15X3) += i2c-ali15x3.o obj-$(CONFIG_I2C_AMD756) += i2c-amd756.o obj-$(CONFIG_I2C_AMD756_S4882)+= i2c-amd756-s4882.o obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o obj-$(CONFIG_I2C_I801)+= i2c-i801.o obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o obj-$(CONFIG_I2C_NFORCE2_S4985) += i2c-nforce2-s4985.o obj-$(CONFIG_I2C_PIIX4) += i2c-piix4.o obj-$(CONFIG_I2C_SIS5595) += i2c-sis5595.o obj-$(CONFIG_I2C_SIS630) += i2c-sis630.o obj-$(CONFIG_I2C_SIS96X) += i2c-sis96x.o obj-$(CONFIG_I2C_VIA) += i2c-via.o obj-$(CONFIG_I2C_VIAPRO) += i2c-viapro.o # Mac SMBus host controller drivers obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o # Embebbed system I2C/SMBus host controller drivers obj-$(CONFIG_I2C_AT91)+= i2c-at91.o obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o obj-$(CONFIG_I2C_GPIO)+= i2c-gpio.o obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o obj-$(CONFIG_I2C_OMAP)+= i2c-omap.o obj-$(CONFIG_I2C_PXA) += i2c-pxa.o obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o obj-$(CONFIG_I2C_VERSATILE) += i2c-versatile.o # External I2C/SMBus adapter drivers obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o obj-$(CONFIG_I2C_PARPORT_LIGHT) += i2c-parport-light.o obj-$(CONFIG_I2C_TAOS_EVM)+= i2c-taos-evm.o obj-$(CONFIG_I2C_TINY_USB)+= i2c-tiny-usb.o # Graphics adapter I2C/DDC channel drivers obj-$(CONFIG_I2C_VOODOO3) += i2c-voodoo3.o # Other I2C/SMBus bus drivers obj-$(CONFIG_I2C_ACORN) += i2c-acorn.o obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o obj-$(CONFIG_I2C_BLACKFIN_TWI)+= i2c-bfin-twi.o Embedded. obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o It is not SMBus, but still PC (ISA). obj-$(CONFIG_I2C_CPM) += i2c-cpm.o Embedded. obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o obj-$(CONFIG_I2C_ISCH)+= i2c-isch.o obj-$(CONFIG_I2C_MPC) += i2c-mpc.o Embedded. obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o obj-$(CONFIG_I2C_OCORES) += i2c-ocores.o obj-$(CONFIG_I2C_PASEMI) += i2c-pasemi.o obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o It is not SMBus, but still PC (ISA). obj-$(CONFIG_I2C_PCA_PLATFORM)+= i2c-pca-platform.o External means probably: Connected via some bus? This one is just memory mapped... obj-$(CONFIG_I2C_PMCMSP) += i2c-pmcmsp.o obj-$(CONFIG_I2C_PNX) += i2c-pnx.o obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o Embedded. obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o Embedded. obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o PC? Looking at MODULE_DESCRIPTION. obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o obj-$(CONFIG_I2C_STUB)+= i2c-stub.o obj-$(CONFIG_SCx200_ACB) += scx200_acb.o obj-$(CONFIG_SCx200_I2C) += scx200_i2c.o (Of course, Kconfig has similar groups.) Thanks, -- Jean Delvare ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH] Bugfixes for i2c-cpm.c
Bugfixes to the i2c-cpm driver
- enable correct interrupts (I2CER_TXE instead of I2CER_BUSY)
- replace forgotten iic with i2c
- fix typo (devided)
- prefix debug-output on init with 0x and add frequency
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
Sorry for the resend; the CC to Jochen was dropped, haven't figured out
why, yet.
drivers/i2c/busses/i2c-cpm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: drivers/i2c/busses/i2c-cpm.c
===
--- drivers/i2c/busses/i2c-cpm.c.orig
+++ drivers/i2c/busses/i2c-cpm.c
@@ -241,7 +241,7 @@
eieio();
setbits16(tbdf-cbd_sc, BD_SC_READY);
} else {
- dev_dbg(adap-dev, cpm_iic_write(abyte=0x%x)\n, addr);
+ dev_dbg(adap-dev, cpm_i2c_write(abyte=0x%x)\n, addr);
memcpy(tb+1, pmsg-buf, pmsg-len);
@@ -350,7 +350,7 @@
}
/* Start transfer now */
/* Enable RX/TX/Error interupts */
- out_8(i2c_reg-i2cmr, I2CER_BUSY | I2CER_TXB | I2CER_RXB);
+ out_8(i2c_reg-i2cmr, I2CER_TXE | I2CER_TXB | I2CER_RXB);
out_8(i2c_reg-i2cer, 0xff); /* Clear interrupt status */
/* Chip bug, set enable here */
setbits8(i2c_reg-i2mod, I2MOD_EN);/* Enable */
@@ -553,8 +553,8 @@
cpm_reset_i2c_params(cpm);
- dev_dbg(cpm-ofdev-dev, i2c_ram %p, i2c_addr 0x%04x\n,
- cpm-i2c_ram, cpm-i2c_addr);
+ dev_dbg(cpm-ofdev-dev, i2c_ram 0x%p, i2c_addr 0x%04x, freq %d\n,
+ cpm-i2c_ram, cpm-i2c_addr, cpm-freq);
dev_dbg(cpm-ofdev-dev, tbase 0x%04x, rbase 0x%04x\n,
(u8 __iomem *)cpm-tbase - DPRAM_BASE,
(u8 __iomem *)cpm-rbase - DPRAM_BASE);
@@ -568,7 +568,7 @@
/*
* PDIV is set to 00 in i2mod, so brgclk/32 is used as input to the
-* i2c baud rate generator. This is devided by 2 x (DIV + 3) to get
+* i2c baud rate generator. This is divided by 2 x (DIV + 3) to get
* the actual i2c bus frequency.
*/
brg = get_brgfreq() / (32 * 2 * cpm-freq) - 3;
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Bugfixes for i2c-cpm.c
On Fri, Jun 20, 2008 at 10:41:55AM +0200, Wolfram Sang wrote:
Any new on this one? I think at least the interrupt fix should make it
into 2.6.26. The mistakenly activated interrupt caused a regression
here, which made at24 fail on writes.
Wolfram
Bugfixes to the i2c-cpm driver
- enable correct interrupts (I2CER_TXE instead of I2CER_BUSY)
- replace forgotten iic with i2c
- fix typo (devided)
- prefix debug-output on init with 0x and add frequency
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
Sorry for the resend; the CC to Jochen was dropped, haven't figured out
why, yet.
drivers/i2c/busses/i2c-cpm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: drivers/i2c/busses/i2c-cpm.c
===
--- drivers/i2c/busses/i2c-cpm.c.orig
+++ drivers/i2c/busses/i2c-cpm.c
@@ -241,7 +241,7 @@
eieio();
setbits16(tbdf-cbd_sc, BD_SC_READY);
} else {
- dev_dbg(adap-dev, cpm_iic_write(abyte=0x%x)\n, addr);
+ dev_dbg(adap-dev, cpm_i2c_write(abyte=0x%x)\n, addr);
memcpy(tb+1, pmsg-buf, pmsg-len);
@@ -350,7 +350,7 @@
}
/* Start transfer now */
/* Enable RX/TX/Error interupts */
- out_8(i2c_reg-i2cmr, I2CER_BUSY | I2CER_TXB | I2CER_RXB);
+ out_8(i2c_reg-i2cmr, I2CER_TXE | I2CER_TXB | I2CER_RXB);
out_8(i2c_reg-i2cer, 0xff); /* Clear interrupt status */
/* Chip bug, set enable here */
setbits8(i2c_reg-i2mod, I2MOD_EN);/* Enable */
@@ -553,8 +553,8 @@
cpm_reset_i2c_params(cpm);
- dev_dbg(cpm-ofdev-dev, i2c_ram %p, i2c_addr 0x%04x\n,
- cpm-i2c_ram, cpm-i2c_addr);
+ dev_dbg(cpm-ofdev-dev, i2c_ram 0x%p, i2c_addr 0x%04x, freq %d\n,
+ cpm-i2c_ram, cpm-i2c_addr, cpm-freq);
dev_dbg(cpm-ofdev-dev, tbase 0x%04x, rbase 0x%04x\n,
(u8 __iomem *)cpm-tbase - DPRAM_BASE,
(u8 __iomem *)cpm-rbase - DPRAM_BASE);
@@ -568,7 +568,7 @@
/*
* PDIV is set to 00 in i2mod, so brgclk/32 is used as input to the
- * i2c baud rate generator. This is devided by 2 x (DIV + 3) to get
+ * i2c baud rate generator. This is divided by 2 x (DIV + 3) to get
* the actual i2c bus frequency.
*/
brg = get_brgfreq() / (32 * 2 * cpm-freq) - 3;
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Bugfixes for i2c-cpm.c
On Mon, Jun 23, 2008 at 03:59:09PM +0200, Jean Delvare wrote: I was away for the week-end and am now processing the stacked e-mail and other real-life tasks (takes time.) This was more addressed to Jochen; should have pointed out, that I was waiting for his ACK. I fail to see how there would be a regression here given that the i2c-cpm driver is new and is not in kernel 2.6.26. Ups, sigh, I remembered you added it to your tree and mistook it that you also already pushed it. Point taken, not that urgent. Sorry! Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH] Bugfixes for i2c-cpm.c
Bugfixes to the i2c-cpm driver
- enable correct interrupts (I2CER_TXE instead of I2CER_BUSY)
- replace forgotten iic with i2c
- fix typo (devided)
- prefix debug-output on init with 0x and add frequency
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-cpm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: drivers/i2c/busses/i2c-cpm.c
===
--- drivers/i2c/busses/i2c-cpm.c.orig
+++ drivers/i2c/busses/i2c-cpm.c
@@ -241,7 +241,7 @@
eieio();
setbits16(tbdf-cbd_sc, BD_SC_READY);
} else {
- dev_dbg(adap-dev, cpm_iic_write(abyte=0x%x)\n, addr);
+ dev_dbg(adap-dev, cpm_i2c_write(abyte=0x%x)\n, addr);
memcpy(tb+1, pmsg-buf, pmsg-len);
@@ -350,7 +350,7 @@
}
/* Start transfer now */
/* Enable RX/TX/Error interupts */
- out_8(i2c_reg-i2cmr, I2CER_BUSY | I2CER_TXB | I2CER_RXB);
+ out_8(i2c_reg-i2cmr, I2CER_TXE | I2CER_TXB | I2CER_RXB);
out_8(i2c_reg-i2cer, 0xff); /* Clear interrupt status */
/* Chip bug, set enable here */
setbits8(i2c_reg-i2mod, I2MOD_EN);/* Enable */
@@ -553,8 +553,8 @@
cpm_reset_i2c_params(cpm);
- dev_dbg(cpm-ofdev-dev, i2c_ram %p, i2c_addr 0x%04x\n,
- cpm-i2c_ram, cpm-i2c_addr);
+ dev_dbg(cpm-ofdev-dev, i2c_ram 0x%p, i2c_addr 0x%04x, freq %d\n,
+ cpm-i2c_ram, cpm-i2c_addr, cpm-freq);
dev_dbg(cpm-ofdev-dev, tbase 0x%04x, rbase 0x%04x\n,
(u8 __iomem *)cpm-tbase - DPRAM_BASE,
(u8 __iomem *)cpm-rbase - DPRAM_BASE);
@@ -568,7 +568,7 @@
/*
* PDIV is set to 00 in i2mod, so brgclk/32 is used as input to the
-* i2c baud rate generator. This is devided by 2 x (DIV + 3) to get
+* i2c baud rate generator. This is divided by 2 x (DIV + 3) to get
* the actual i2c bus frequency.
*/
brg = get_brgfreq() / (32 * 2 * cpm-freq) - 3;
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH v3] New-style I2C and SMBus EEPROM driver (with device_ids)
AT24_FLAG_24C00 (doesn't really matter), and AT24C01 needs 128 addresses?? (please, someone, prove me wrong) Why do you think so? My personal guess is that they simply forgot to mention the address in the datasheet. A chip responding to all addresses would prevent any other chip from being connected to the bus, that's impractical enough to be reasonably certain that no manufacturer did this. No I2C-address is mentioned in the whole datasheet; all the timing diagrams put the memory offset to the place where one would expect the I2C-address; the pins usually named A0-A2 are not connected... Maybe it once made the chip one cent cheaper, I dunno, but I wouldn't be that surprised :) Doesn't really matter for at24, luckily. Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Tue, Jun 10, 2008 at 10:40:45PM -0400, Jon Smirl wrote:
Convert i2c-mpc from a platform driver into an of_platform driver.
This patch is much smaller since Jochen already added
of_find_i2c_driver(). Versions of this have been posted before.
Signed-ff-by: Jon Smirl [EMAIL PROTECTED]
Typo: Signed-off... (I'm curious, do such typos enforce resending the
patch?)
Tested-by: Wolfram Sang [EMAIL PROTECTED]
--
drivers/i2c/busses/i2c-mpc.c | 105
+-
1 files changed, 63 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index a076129..76d8091 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -18,6 +18,8 @@
#include linux/sched.h
#include linux/init.h
#include linux/platform_device.h
+#include linux/of_platform.h
+#include linux/of_i2c.h
#include asm/io.h
#include linux/fsl_devices.h
@@ -25,13 +27,13 @@
#include linux/interrupt.h
#include linux/delay.h
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME mpc-i2c
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -315,102 +317,121 @@ static struct i2c_adapter mpc_ops = {
.timeout = 1,
};
-static int fsl_i2c_probe(struct platform_device *pdev)
+static int fsl_i2c_probe(struct of_device *op, const struct
of_device_id *match)
The above two lines have to be concatenated, otherwise the patch will
not apply. Also, __devinit?
{
int result = 0;
struct mpc_i2c *i2c;
- struct fsl_i2c_platform_data *pdata;
- struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- pdata = (struct fsl_i2c_platform_data *) pdev-dev.platform_data;
i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
if (!i2c)
return -ENOMEM;
- i2c-irq = platform_get_irq(pdev, 0);
- if (i2c-irq 0)
- i2c-irq = NO_IRQ; /* Use polling */
+ if (of_get_property(op-node, dfsrr, NULL))
+ i2c-flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
- i2c-flags = pdata-device_flags;
- init_waitqueue_head(i2c-queue);
+ if (of_device_is_compatible(op-node, mpc5200-i2c))
+ i2c-flags |= FSL_I2C_DEV_CLOCK_5200;
- i2c-base = ioremap((phys_addr_t)r-start, MPC_I2C_REGION);
+ init_waitqueue_head(i2c-queue);
+ i2c-base = of_iomap(op-node, 0);
if (!i2c-base) {
printk(KERN_ERR i2c-mpc - failed to map controller\n);
result = -ENOMEM;
goto fail_map;
}
- if (i2c-irq != NO_IRQ)
- if ((result = request_irq(i2c-irq, mpc_i2c_isr,
- IRQF_SHARED, i2c-mpc, i2c)) 0) {
- printk(KERN_ERR
-i2c-mpc - failed to attach interrupt\n);
- goto fail_irq;
- }
+ i2c-irq = irq_of_parse_and_map(op-node, 0);
+ if (i2c-irq == NO_IRQ) {
+ result = -ENXIO;
Minor thing, but I wonder if -EINVAL is more appropriate?
+ goto fail_irq;
+ }
+
+ result = request_irq(i2c-irq, mpc_i2c_isr,
+ IRQF_SHARED, i2c-mpc, i2c);
+ if (result 0) {
+ printk(KERN_ERR i2c-mpc - failed to attach interrupt\n);
+ goto fail_request;
+ }
mpc_i2c_setclock(i2c);
- platform_set_drvdata(pdev, i2c);
+
+ dev_set_drvdata(op-dev, i2c);
i2c-adap = mpc_ops;
- i2c-adap.nr = pdev-id;
i2c_set_adapdata(i2c-adap, i2c);
- i2c-adap.dev.parent = pdev-dev;
- if ((result = i2c_add_numbered_adapter(i2c-adap)) 0) {
+ i2c-adap.dev.parent = op-dev;
+
+ result = i2c_add_adapter(i2c-adap);
+ if (result 0) {
printk(KERN_ERR i2c-mpc - failed to add adapter\n);
goto fail_add;
}
+ of_register_i2c_devices(i2c-adap, op-node);
return result;
- fail_add:
- if (i2c-irq != NO_IRQ)
- free_irq(i2c-irq, i2c);
- fail_irq:
+ fail_add:
+ dev_set_drvdata(op-dev, NULL);
+ free_irq(i2c-irq, i2c);
+ fail_request:
+ irq_dispose_mapping(i2c-irq);
+ fail_irq:
iounmap(i2c-base);
- fail_map:
+ fail_map:
kfree(i2c);
return result;
};
-static int fsl_i2c_remove(struct platform_device *pdev)
+static int fsl_i2c_remove(struct of_device *op)
__devexit?
{
- struct mpc_i2c *i2c = platform_get_drvdata(pdev);
+ struct mpc_i2c *i2c = dev_get_drvdata(op-dev);
i2c_del_adapter(i2c-adap);
- platform_set_drvdata(pdev, NULL);
+ dev_set_drvdata(op-dev, NULL);
if (i2c-irq != NO_IRQ)
free_irq(i2c-irq, i2c);
+ irq_dispose_mapping(i2c-irq);
iounmap(i2c-base);
kfree
Re: [i2c] [PATCH v3] New-style I2C and SMBus EEPROM driver (with device_ids)
Hi Jean,
thanks again for your review!
As said before, I don't think it's needed, but if you and David insist
on picking all addresses of the 24C00, so be it.
A new issue is now that some 24C01 also have this behaviour, so I guess the
flag should be renamed from AT24_FLAG_24C00 to AT24_FLAG_TAKE8ADDR or
something.
+/*-*/
+
+static int at24_probe(struct i2c_client *client, const struct
i2c_device_id *id)
+{
+ struct at24_platform_data *chip;
+ bool writable;
+ bool use_smbus = false;
+ struct at24_data *at24;
+ int err;
+ unsigned i, num_addresses;
+ kernel_ulong_t magic;
+
+ if (id-driver_data) {
+ chip = kmalloc(sizeof(struct at24_platform_data), GFP_KERNEL);
+ if (!chip) {
You allocate this just to copy it to another structure and free it
immediately. Allocating the other structure (struct at24_data) earlier
would save this temporary allocation. Alternatively, just put the struct
at24_platform_data on the stack, it's small enough to do so.
I can't allocate at24_data beforehand, as I need to know num_addresses,
so I can then calculate the actual size of at24_data. Will use the stack.
+ if (!at24-client[i]) {
+ dev_err(client-dev, address 0x%04x unavailable\n,
These are 7-bit addresses, so: 0x%02x.
I was unsure because of the 10-bit-addresses (and %03x looked even more
unusual). Will revert to %02x.
+/*
+ * Chip data. Parameters are byte_len, page_size and flags
+ */
+
+/* 128 bit chip, I2C A0-A2 ignored */
+#define AT24_DATA_24C00 128 / 8, 1, AT24_FLAG_24C00
+
+/* 1 Kbit chip, some have 16 byte pages: 24lc014, ... */
+#define AT24_DATA_24C01 1024 / 8, 8, 0
The Atmel 24C01 datasheet says page size is 4 bytes, and the Microchip
24C01A datasheet says 2 bytes. So defaulting to 8 doesn't look safe.
Will go back to 2 because of Microchip. But 24C01 seems to have lots of
variants, which makes a generic entry difficult. Some would need
AT24_FLAG_24C00 (doesn't really matter), and AT24C01 needs 128
addresses?? (please, someone, prove me wrong)
You're going to quite some extent to obfuscate simple things ;) All
I wanted to make the transition from at24_v2 to at24_v3 easier by
reusing the defines containing chip data. I agree though, that the
benefit is mainly for those who already dared to use this driver (is
there anyone besides David and me?), and not for upstream. Will try to
make it more simple.
In the end, the only things that must go in at24.h are the definition
of struct at24_platform_data and its flags. All the rest is internal to
the driver and should go in at24.c.
I wanted to have the AT24_SIZE_* flags next to the struct, so I won't
forget to change their size if anything inside the struct will change.
Then again, I might work with sizeof here; the result will probably look
a bit nasty, too...
All the best,
Wolfram
--
Dipl.-Ing. Wolfralfum Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [patch 1/1] New-style I2C and SMBus EEPROM driver (with device_ids)
Add a new-style driver for most I2C EEPROMs, giving sysfs read/write access to their data. Tested with various chips and clock rates. Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- Note: I am not in my office this week, so I can't do all the tests I usually do. Please check carefully! David: I hope it is OK with you that I added myself as another author of this module. Updates since last version: - added device_ids for common eeprom types (parameters encoded in a 'magic' driver_data value) - removed platform_data entry 'i2c_addr_mask' and calculated its value from other parameters - added 24c00-quirk flag (it covers 8 addresses) - added a flag to make eeproms world-readable (used for spd) - rewrote code that adds an i2c-address to an i2c-message - rewrote code which truncates to page_size - removed 'addr'-variable from eeprom-functions; i2c-address is now taken from the corresponding client-structure - write buffer now allocated once in probe - removed some sanity checks for file offsets as they are handled at the sysfs-layer already. - fixed typos and corrected spellings in comments and Kconfig - renamed some functions to be more self-explanatory - added includes - further cleanups and simplifications - added myself as another author Updates since last version: - revisited includes - made write-timeout a module parameter - array of clients is allocated dynamically - removed unnecessary indentation within code - formatted comments - replaced at24_ee_address with a simpler function - at24_ee_write now really waits till timeout - added simple checks of provided eeprom chip data in at24_probe - added comment in at24.h about double-checking custom data - minor fixes Updates in this version: - move chip data out of the driver into a seperate .h-file - prefix defined constants with AT24_ - make bin file readonly if requested by flags - introduce AT24_MAX_CLIENTS - bugfix: check correct retval in at24_ee_write drivers/i2c/chips/Kconfig | 26 ++ drivers/i2c/chips/Makefile |1 drivers/i2c/chips/at24.c | 574 + include/linux/i2c/at24.h | 104 4 files changed, 705 insertions(+) create mode 100644 drivers/i2c/chips/at24.c create mode 100644 include/linux/i2c/at24.h Index: linux-2.6.26-rc4/drivers/i2c/chips/Kconfig === --- linux-2.6.26-rc4.orig/drivers/i2c/chips/Kconfig +++ linux-2.6.26-rc4/drivers/i2c/chips/Kconfig @@ -14,6 +14,32 @@ This driver can also be built as a module. If so, the module will be called ds1682. +config I2C_AT24 + tristate EEPROMs from most vendors + depends on SYSFS EXPERIMENTAL + help + Enable this driver to get read/write support to most I2C EEPROMs, + after you configure the driver to know about each EEPROM on + your target board. Use these generic chip names, instead of + vendor-specific ones like at24c64 or 24lc02: + +24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, +24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024 + + Unless you like data loss puzzles, always be sure that any chip + you configure as a 24c32 (32 kbit) or larger is NOT really a + 24c16 (16 kbit) or smaller, and vice versa. Marking the chip + as read-only won't help recover from this. Also, if your chip + has any software write-protect mechanism you may want to review the + code to make sure this driver won't turn it on by accident. + + If you use this with an SMBus adapter instead of an I2C adapter, + full functionality is not availble. Only smaller devices are + supported (24c16 and below, max 4 kByte). + + This driver can also be built as a module. If so, the module + will be called at24. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL Index: linux-2.6.26-rc4/drivers/i2c/chips/Makefile === --- linux-2.6.26-rc4.orig/drivers/i2c/chips/Makefile +++ linux-2.6.26-rc4/drivers/i2c/chips/Makefile @@ -10,6 +10,7 @@ # obj-$(CONFIG_DS1682) += ds1682.o +obj-$(CONFIG_I2C_AT24) += at24.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o Index: linux-2.6.26-rc4/drivers/i2c/chips/at24.c === --- /dev/null +++ linux-2.6.26-rc4/drivers/i2c/chips/at24.c @@ -0,0 +1,574 @@ +/* + * at24.c - handle most I2C EEPROMs + * + * Copyright (C) 2005-2007 David Brownell + * Copyright (C) 2008 Wolfram Sang, Pengutronix + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either
[i2c] [PATCH v3] New-style I2C and SMBus EEPROM driver (with device_ids)
New-style I2C and SMBus EEPROM driver (with device_ids) Add a new-style driver for most I2C EEPROMs, giving sysfs read/write access to their data. Tested with various chips and clock rates. Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- Note: I am not in my office this week, so I can't do all the tests I usually do. Please check carefully! David: I hope it is OK with you that I added myself as another author of this module. Updates since last version: - added device_ids for common eeprom types (parameters encoded in a 'magic' driver_data value) - removed platform_data entry 'i2c_addr_mask' and calculated its value from other parameters - added 24c00-quirk flag (it covers 8 addresses) - added a flag to make eeproms world-readable (used for spd) - rewrote code that adds an i2c-address to an i2c-message - rewrote code which truncates to page_size - removed 'addr'-variable from eeprom-functions; i2c-address is now taken from the corresponding client-structure - write buffer now allocated once in probe - removed some sanity checks for file offsets as they are handled at the sysfs-layer already. - fixed typos and corrected spellings in comments and Kconfig - renamed some functions to be more self-explanatory - added includes - further cleanups and simplifications - added myself as another author Updates since last version: - revisited includes - made write-timeout a module parameter - array of clients is allocated dynamically - removed unnecessary indentation within code - formatted comments - replaced at24_ee_address with a simpler function - at24_ee_write now really waits till timeout - added simple checks of provided eeprom chip data in at24_probe - added comment in at24.h about double-checking custom data - minor fixes Updates in this version: - move chip data out of the driver into a seperate .h-file - prefix defined constants with AT24_ - make bin file readonly if requested by flags - introduce AT24_MAX_CLIENTS - bugfix: check correct retval in at24_ee_write drivers/i2c/chips/Kconfig | 26 ++ drivers/i2c/chips/Makefile |1 drivers/i2c/chips/at24.c | 574 + include/linux/i2c/at24.h | 104 4 files changed, 705 insertions(+) create mode 100644 drivers/i2c/chips/at24.c create mode 100644 include/linux/i2c/at24.h Index: linux-2.6.26-rc4/drivers/i2c/chips/Kconfig === --- linux-2.6.26-rc4.orig/drivers/i2c/chips/Kconfig +++ linux-2.6.26-rc4/drivers/i2c/chips/Kconfig @@ -14,6 +14,32 @@ This driver can also be built as a module. If so, the module will be called ds1682. +config I2C_AT24 + tristate EEPROMs from most vendors + depends on SYSFS EXPERIMENTAL + help + Enable this driver to get read/write support to most I2C EEPROMs, + after you configure the driver to know about each EEPROM on + your target board. Use these generic chip names, instead of + vendor-specific ones like at24c64 or 24lc02: + +24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, +24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024 + + Unless you like data loss puzzles, always be sure that any chip + you configure as a 24c32 (32 kbit) or larger is NOT really a + 24c16 (16 kbit) or smaller, and vice versa. Marking the chip + as read-only won't help recover from this. Also, if your chip + has any software write-protect mechanism you may want to review the + code to make sure this driver won't turn it on by accident. + + If you use this with an SMBus adapter instead of an I2C adapter, + full functionality is not availble. Only smaller devices are + supported (24c16 and below, max 4 kByte). + + This driver can also be built as a module. If so, the module + will be called at24. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL Index: linux-2.6.26-rc4/drivers/i2c/chips/Makefile === --- linux-2.6.26-rc4.orig/drivers/i2c/chips/Makefile +++ linux-2.6.26-rc4/drivers/i2c/chips/Makefile @@ -10,6 +10,7 @@ # obj-$(CONFIG_DS1682) += ds1682.o +obj-$(CONFIG_I2C_AT24) += at24.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o Index: linux-2.6.26-rc4/drivers/i2c/chips/at24.c === --- /dev/null +++ linux-2.6.26-rc4/drivers/i2c/chips/at24.c @@ -0,0 +1,574 @@ +/* + * at24.c - handle most I2C EEPROMs + * + * Copyright (C) 2005-2007 David Brownell + * Copyright (C) 2008 Wolfram Sang, Pengutronix + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
On Tue, Jun 03, 2008 at 11:19:27PM +0200, Jean Delvare wrote: I agree that in theory something wrong could happen in the current state of things if the extra addresses of the 24C00 chip are not protected by the at24 driver, but in practice I very much doubt that it'll happen, and if it does, it would be easy to fix. So I reiterate that the at24 driver doesn't need to handle this. After removing i2c_addr_mask, it turned out that it just needed one if-case and anonther flag to handle the 24c00-quirk. Hoping that this will be the only case needing such treatment ;), I think it is worth the price. Sidenote: I just finished hacking in all points from my to-do-list. Now, I want to validate the implicit casts and give the driver some really good testing as some parts had to be rewritten for v3. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
Hi Jean, thanks for your review! Just a few comments from me, otherwise I'll change the things as suggested by you or David. As we now support device_ids, probably most of the chip data will come back into the driver. This is yet to be done. Tested on two platforms by me and another one by David. Builds also on x86. We have to make a decision about the strategy now, and stick to it. Changing it after the driver is upstream will cause a lot of confusion. ACK. I was thinking about the following way to support the standard eeprom sizes without bloating the driver too much with chip data: In a MODULE_DEVICE_TABLE, we have a kernel_ulong_t available for each entry of a supported device. All parameters of the standard eeprom chips are powers of 2. If we use log2 of these parameters, they will easily fit into a kernel_ulong_t. We'd need one macro to create these magic numbers from the provided chip data (AT24_DATA_*) and just a tiny bit of code to create a proper platform_data struct from it. A general at24 entry will expect the platform data to be provided, of course. + struct i2c_client *client[]; Isn't this supposed to be struct i2c_client *client[0]; IIRC I found both versions in kernel code and chose this because of ANSI-C. + at24-bin.attr.name = eeprom; + at24-bin.attr.mode = S_IRUSR; This makes the data only readable by root, as the comment says. The eeprom driver makes (most of) the data world-readable. I think it would be good to at least have the option to make the data world-readable, for example for SPD or EDID data. Otherwise we will never be able to drop the eeprom driver. I'd go for David's solution here to introduce another flag for this purpose. + u8 i2c_addr_mask; /* for multi-addr chips */ This notion of i2c_addr_mask seems more restrictive and easy to get wrong than it needs to be. What you really have is a number of slave I2C addresses, that's more intuitive IMHO, and using this would save a couple + 1 in the code. As a matter of fact, that's what you described in the comment above. Oh, BTW, can't you compute this value yourself from byte_len and (flags AT24_EE_ADDR2)? I think so... I was about to address this issue in the next version. Still need to think about side-effects and corner-cases in a quiet minute. I guess some more comments will arise while updating the driver... All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
Hi Jean, On Fri, May 30, 2008 at 11:51:31AM +0200, Jean Delvare wrote: I was about to address this issue in the next version. Still need to think about side-effects and corner-cases in a quiet minute. I'd rather see this addressed now rather than later, as struct at24_platform_data is public, changing it later would be non-trivial. I agree. With next version I did not mean next version after it went upstream but next revision after the version I sent lately. I am already on it! Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] Problem Configuring Micron sensor MT9D131 using i2c
Hi, On Fri, May 30, 2008 at 04:36:03PM +0530, Tekkalkot, Seetaram (IE10) wrote: 1.As per the datasheet the i2c read address is 0x91 and write address is 0x90, should I set any of these slave addresses based on whether I am reading or writing? The datasheet seems obscure. An I2C-address is 7-bit and then there is a bit stating if the access shall be r/w. Of course, together they form a byte, but the address is 7 bit _only_ (there is a 10 bit extension, but this exception does not apply here). So, the _address_ is 0x48. 2.I am using 7 bits from 0x91 which 0x48, is this correct? Yes. 3.Why i2cdetect doesn't detect this device and also i2cget can't read from register 0x00? Is there anything detected on that bus? Is there something else connected to that bus? All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 3/3] i2c: add support for i2c bus on Freescale CPM1/CPM2 controllers
Hi Jochen, Thanks for the review. If you want I can resend... Please do. And maybe you could comment on my assumption about the value 32 in the brg-formula? All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] i2c-pca-algo: Fix errorcode
Hi Jean, On Tue, May 20, 2008 at 08:17:55PM +0200, Jean Delvare wrote: EBUSY is a fatal error, while a you should be able to retry the transaction later when the bus is free. So I think that EAGAIN would be more appropriate. Okay, fine with me. (Does somebody know of a guide with references for using errorcodes? EBUSY or EAGAIN? ENODEV or ENXIO? Preferred error value if ioremap fails? It seems a bit messy. The patch that was recently posted, defining possible situations for errorcodes within I2C is really great. I wished I would have something like this for the general kernel-routines.) Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 3/3] i2c: add support for i2c bus on Freescale CPM1/CPM2 controllers
On Wed, May 14, 2008 at 04:14:45PM -0700, [EMAIL PROTECTED] wrote:
I just managed to test the latest version of this driver.
+static int cpm_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
num)
+{
+ struct cpm_i2c *cpm = i2c_get_adapdata(adap);
+ struct i2c_reg __iomem *i2c_reg = cpm-i2c_reg;
+ struct i2c_ram __iomem *i2c_ram = cpm-i2c_ram;
+ struct i2c_msg *pmsg;
+ int ret, i;
+ int tptr;
+ int rptr;
+ cbd_t __iomem *tbdf;
+ cbd_t __iomem *rbdf;
+
+ if (num CPM_MAXBD)
+ return -EINVAL;
+
+ /* Check if we have any oversized READ requests */
+ for (i = 0; i num; i++) {
+ pmsg = msgs[i];
+ if (pmsg-len = CPM_MAX_READ)
+ return -EINVAL;
+ }
+
+ /* Reset to use first buffer */
+ out_be16(i2c_ram-rbptr, in_be16(i2c_ram-rbase));
+ out_be16(i2c_ram-tbptr, in_be16(i2c_ram-tbase));
+
+ tbdf = cpm-tbase;
+ rbdf = cpm-rbase;
+
+ tptr = 0;
+ rptr = 0;
+
+ while (tptr num) {
+ pmsg = msgs[tptr];
+ dev_dbg(adap-dev, R: %d T: %d\n, rptr, tptr);
+
+ cpm_i2c_parse_message(adap, pmsg, num, tptr, rptr);
+ if (pmsg-flags I2C_M_RD)
+ rptr++;
+ tptr++;
+ }
+ /* Start transfer now */
+ /* Enable RX/TX/Error interupts */
+ out_8(i2c_reg-i2cmr, I2CER_BUSY | I2CER_TXB | I2CER_RXB);
+ out_8(i2c_reg-i2cer, 0xff); /* Clear interrupt status */
+ /* Chip bug, set enable here */
+ setbits8(i2c_reg-i2mod, I2MOD_EN);/* Enable */
+ /* Begin transmission */
+ setbits8(i2c_reg-i2com, I2COM_MASTER);
Bummer! This should not be I2COM_MASTER but I2COM_START! Otherwise no
I2C communication will happen.
After applying this change, the driver works fine on an MPC8260 (like
the previous version did).
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH V4] I2C bus driver for IMX
On Thu, May 15, 2008 at 10:55:30AM +0300, Darius wrote:
+ for (i=0; iI2C_IMX_TIME_BUSY; i++) {
spacing in here: for (i = 0; i I2C_IMX_TIME_BUSY; i++)
what is there wrong with spacing?
spacing in here, (temp I2CR_IEN) ? 1 : 0
I really should add dummy spaces...?
Please do. Documentation/CodingStyle recommends it. While personal
opinions on ceratin topics may vary, I think it is indeed helpful,
if all kernel sources look somewhat similar.
yeurk, put these in a seperate header file, or place them near
the driver. The One Big Register File is horrible, and hopefully
seems, everybody has her own opinion. Is there somebody one, who can say
how that should be? Because I have already two times changed that... I'm
only beginner, so ambiguous comments are very unwanted... As I know,
Jean Delvare is responsible for I2C drivers. So, his word is welcome:)
He suggested the same (= no register file) to me in January for the
PCA9564-driver.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH] i2c-pcf8575: check for errors when accessing the chip
Make the driver check and report error cases when reading from or writing to
the chip. It used to assume 'always success' and could even deliver bogus
values.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
The PCF on my system seems broken, it does not respond (and I can't probe as my
master doesn't support smbus_quick). The broken chip went unnoticed as the
driver reported some (= bogus) values. So, I can only test the properly
reported error cases, hopefully someone else can confirm the working case.
(Michael and Bart, sorry for double post)
drivers/i2c/chips/pcf8575.c | 29 +
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/chips/pcf8575.c b/drivers/i2c/chips/pcf8575.c
index 3ea08ac..4a4247d 100644
--- a/drivers/i2c/chips/pcf8575.c
+++ b/drivers/i2c/chips/pcf8575.c
@@ -67,15 +67,22 @@ static ssize_t show_read(struct device *dev, struct
device_attribute *attr,
char *buf)
{
struct i2c_client *client = to_i2c_client(dev);
+ int status, retval = -EIO;
u16 val;
u8 iopin_state[2];
- i2c_master_recv(client, iopin_state, 2);
+ status = i2c_master_recv(client, iopin_state, 2);
- val = iopin_state[0];
- val |= iopin_state[1] 8;
+ if (status == 2) {
+ val = iopin_state[0];
+ val |= iopin_state[1] 8;
+ return sprintf(buf, %u\n, val);
+ }
+
+ if (status 0)
+ retval = status;
- return sprintf(buf, %u\n, val);
+ return retval;
}
static DEVICE_ATTR(read, S_IRUGO, show_read, NULL);
@@ -95,19 +102,25 @@ static ssize_t set_write(struct device *dev, struct
device_attribute *attr,
struct i2c_client *client = to_i2c_client(dev);
struct pcf8575_data *data = i2c_get_clientdata(client);
unsigned long val = simple_strtoul(buf, NULL, 10);
+ int status, retval = -EIO;
u8 iopin_state[2];
if (val 0x)
return -EINVAL;
- data-write = val;
-
iopin_state[0] = val 0xFF;
iopin_state[1] = val 8;
- i2c_master_send(client, iopin_state, 2);
+ status = i2c_master_send(client, iopin_state, 2);
+
+ if (status == 2)
+ retval = count;
+ else if (status 0)
+ retval = status;
+
+ data-write = (status == 2) ? val : retval;
- return count;
+ return retval;
}
static DEVICE_ATTR(write, S_IWUSR | S_IRUGO, show_write, set_write);
--
1.5.5.1
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] i2c-pcf8575: check for errors when accessing the chip
On Thu, May 15, 2008 at 09:21:08PM +0200, Jean Delvare wrote: What will you do when I delete drivers/i2c/chips/pcf8575.c in kernel 2.6.28? Ask the customer for another budget :) Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
Add a new-style driver for most I2C EEPROMs, giving sysfs read/write access to their data. Tested with various chips and clock rates. Updates since last version: - revisited includes - made write-timeout a module parameter - array of clients is allocated dynamically - removed unnecessary indentation within code - formatted comments - replaced at24_ee_address with a simpler function - at24_ee_write now really waits till timeout - added simple checks of provided eeprom chip data in at24_probe - added comment in at24.h about double-checking custom data - minor fixes Updates in this version: - move chip data out of the driver into a seperate .h-file - prefix defined constants with AT24_ - make bin file readonly if requested by flags - introduce AT24_MAX_CLIENTS - bugfix: check correct retval in at24_ee_write Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- As we now support device_ids, probably most of the chip data will come back into the driver. This is yet to be done. Tested on two platforms by me and another one by David. Builds also on x86. drivers/i2c/chips/Kconfig | 26 ++ drivers/i2c/chips/Makefile |1 + drivers/i2c/chips/at24.c | 571 include/linux/i2c/at24.h | 102 4 files changed, 700 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/at24.c create mode 100644 include/linux/i2c/at24.h diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index 2da2edf..ad776e3 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -14,6 +14,32 @@ config DS1682 This driver can also be built as a module. If so, the module will be called ds1682. +config I2C_AT24 + tristate EEPROMs from most vendors + depends on I2C SYSFS EXPERIMENTAL + help + Enable this driver to get read/write support to most I2C EEPROMs, + after you configure the driver to know about each eeprom on on + your target board. Use these generic chip names, instead of + vendor-specific ones like at24c64 or 24lc02: + +24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, +24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024 + + Unless you like data loss puzzles, always be sure that any chip + you configure as a 24c32 (32 Kbits) or larger is NOT really a + 24c16 (16 Kbits) or smaller, and vice versa. (Marking the chip + as readonly won't help recover from this.) Also, if your chip + has any software write-protect mechanism you may want to make + sure this driver won't turn it on by accident. + + If you use this with an SMBus adapter instead of an I2C adapter, + full functionality is not availble. Only smaller devices are + supported (24c16 and below, max 4 KBytes). + + This driver can also be built as a module. If so, the module + will be called at24. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index e47aca0..aa1a88c 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -10,6 +10,7 @@ # obj-$(CONFIG_DS1682) += ds1682.o +obj-$(CONFIG_I2C_AT24) += at24.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o diff --git a/drivers/i2c/chips/at24.c b/drivers/i2c/chips/at24.c new file mode 100644 index 000..35c091c --- /dev/null +++ b/drivers/i2c/chips/at24.c @@ -0,0 +1,571 @@ +/* + * at24.c - handle most I2C EEPROMs + * + * Copyright (C) 2005-2007 David Brownell + * Copyright (C) 2008 Wolfram Sang, Pengutronix + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include linux/kernel.h +#include linux/init.h +#include linux/module.h +#include linux/slab.h +#include linux/delay.h +#include linux/log2.h +#include linux/jiffies.h +#include linux/i2c.h +#include linux/i2c/at24.h + +/* + * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable. + * Differences between different vendor product lines (like Atmel AT24C or + * MicroChip 24LC, etc) won't much matter for typical read/write access. + * There are also I2C RAM chips, likewise interchangeable. One example + * would be the PCF8570, which acts like a 24c02 EEPROM (256 bytes). + * + * However, misconfiguration can lose data. Set 16-bit memory address + * to a part with 8-bit addressing will overwrite data. Writing with too + * big a page size also loses data. And it's not safe to assume that the + * conventional addresses 0x50..0x57 only hold eeproms ... a pcf8563 RTC + * uses 0x51, for just one example
Re: [i2c] new style i2c client problem: probe () is not called
On Tue, May 13, 2008 at 01:20:24PM +0300, Darius wrote: I set up i2c_board_info in board init function. Should I somewhere call i2c_new_device()? Have you called i2c_register_board_info? (If not, check arch/arm/mach-iop32x/em7210.c for an example) All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
-Bus adapter routines for CPM boards); +MODULE_LICENSE(GPL); -- 1.5.4.5 ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c In general, the driver works well for me (just had to disable broadcast responses; eeprom at 00-1f \o/). Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
On Tue, May 06, 2008 at 05:19:39PM +0200, Jochen Friedrich wrote: setbits8() and clrbits8() use a bitmask as second argument. Ouch! Guess my mind wanted to read in_8 and out_8 for some reason... Sorry and thanks for clarifying! Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] platform_data when using of?
On Wed, Apr 23, 2008 at 08:30:12PM +0200, Jean Delvare wrote: Hello Jean, Each i2c driver can support many different devices, which are differentiated simply by their name. So the driver can behave differently for each device type as needed. We exactly threw this out of at24 in the new revision, as name-matching stored quite some data in the driver which was needed only once during initialization. Also, it was not very flexible; what if you want to mark this chip as read-only, your variant has bigger page size and could be faster... The list of device names would grow too fast IMHO, adding a new feature which is selectable by a flag could easily double it. Then again: If Jochen's patches get applied, then I have to use MODULE_DEVICE_TABLE anyhow, or? Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
On Mon, Apr 21, 2008 at 10:20:17AM -0700, Trent Piepho wrote:
If it hasn't been long enough since the last write, the next write
isn't suppose to work. That's the expected operation of the device.
But if it has been long enough, and the write still fails, then it
seems to me that the behavior has changed from normal operation to an
error.
I think you got a point there (unless someone gained experience that
retries do help for some quirky chips or other cases).
Still, if you want to wait at least 25 ms, on a HZ=1000 system you
might wait only 3 ms.
I'm sorry, I fail to see this. If there are more than three retries,
then there is still the time_before-condition which keeps the loop
running until the timeout is reached, no?
Except for the timing problem I pointed out before. The timeout is
checked before the write takes place. So if after the 3rd attempt the
msleep(), or kernel preemption, etc., delays for 22 ms or more, the
next write will never happen.
Got it now, I misunderstood you before. We do wait 25ms in total, it is
just that the last write-try happened at 3ms. This is indeed bad. The
following code should handle it better. (Skipping retries for now)
---
timeout = jiffies + msecs_to_jiffies(write_timeout);
do {
keep_trying = time_before(jiffies, timeout);
transfer();
if (success)
return count;
msleep(1);
} while (keep_trying);
return -ETIMEDOUT;
---
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] platform_data when using of?
Hello, I finally could get the work started with I2C on a MPC8260-based platform. I applied Jochen's series on top of 2.6.25 and it seems I could get the i2c-cpm and the rtc-rs5c372 driver working (except that it doesn't autoload as a module, but I think this is my fault somewhere). I have not checked all yet, but at least some reasonable things do happen. I now wanted to test the latest at24-driver on top of that and stumbled over the fact, that I can't directly add platform_data to the dts-file. (As at24 shall be a generic driver, data about the eeprom type needs to be provided.) If I understood of correctly, I need to create another child node and put all necessary data in there (what also means one cannot use the predefined macros for known chips in at24.h). After that I use of_get_property and collect the data. So, at the end, every driver using platform_data has to cope with two mechanisms to get the desired data? This sounds questionable to me, but maybe I just got something wrong as this is my first contact with of. Kind regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
On Fri, Apr 18, 2008 at 01:07:51AM -0700, Trent Piepho wrote: So the loop tries the write for the first time, fails (which is perfectly acceptable), then sleeps for more than timeout jiffies. The timeout expires and the write is never tried again. Ehrm, the conditions for the while loop are OR-ed not AND-ed. So, even if time_before changes to false, 'retries 3' will keep the loop running. I think this minimum of three tries will also cover the other issues you (correctly) mentioned. Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
drivers, so i2c-eeprom would be confusing. at24 is just fine and I see no reason to change the name. The Linux driver tree is full of vendor-specific names, and this has never been a problem. I just wondered why we should pick one vendor's name altough the driver is designed to work for all vendors. Not the biggest question at the moment, though ;) Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCH] Add a new-style driver for most I2C EEPROMs
Add a new-style driver for most I2C EEPROMs, giving sysfs read/write access to their data. Tested with various chips and clock rates. Updates in this version: - move chip data out of the driver into a seperate .h-file - prefix defined constants with AT24_ - make bin file readonly if requested by flags - introduce AT24_MAX_CLIENTS - bugfix: check correct retval in at24_ee_write Signed-off-by: Wolfram Sang [EMAIL PROTECTED] --- drivers/i2c/chips/Kconfig | 26 ++ drivers/i2c/chips/Makefile |1 + drivers/i2c/chips/at24.c | 553 include/linux/i2c/at24.h | 96 4 files changed, 676 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/at24.c create mode 100644 include/linux/i2c/at24.h diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index b21593f..46a3d1e 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -14,6 +14,32 @@ config DS1682 This driver can also be built as a module. If so, the module will be called ds1682. +config I2C_AT24 + tristate EEPROMs from most vendors + depends on I2C SYSFS EXPERIMENTAL + help + Enable this driver to get read/write support to most I2C EEPROMs, + after you configure the driver to know about each eeprom on on + your target board. Use these generic chip names, instead of + vendor-specific ones like at24c64 or 24lc02: + +24c00, 24c01, 24c02, spd (readonly 24c02), 24c04, 24c08, +24c16, 24c32, 24c64, 24c128, 24c256, 24c512, 24c1024 + + Unless you like data loss puzzles, always be sure that any chip + you configure as a 24c32 (32 Kbits) or larger is NOT really a + 24c16 (16 Kbits) or smaller, and vice versa. (Marking the chip + as readonly won't help recover from this.) Also, if your chip + has any software write-protect mechanism you may want to make + sure this driver won't turn it on by accident. + + If you use this with an SMBus adapter instead of an I2C adapter, + full functionality is not availble. Only smaller devices are + supported (24c16 and below, max 4 KBytes). + + This driver can also be built as a module. If so, the module + will be called at24. + config SENSORS_EEPROM tristate EEPROM reader depends on EXPERIMENTAL diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile index e47aca0..aa1a88c 100644 --- a/drivers/i2c/chips/Makefile +++ b/drivers/i2c/chips/Makefile @@ -10,6 +10,7 @@ # obj-$(CONFIG_DS1682) += ds1682.o +obj-$(CONFIG_I2C_AT24) += at24.o obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o obj-$(CONFIG_SENSORS_MAX6875) += max6875.o obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o diff --git a/drivers/i2c/chips/at24.c b/drivers/i2c/chips/at24.c new file mode 100644 index 000..137f250 --- /dev/null +++ b/drivers/i2c/chips/at24.c @@ -0,0 +1,553 @@ +/* + * at24.c - handle most I2C EEPROMs + * + * Copyright (C) 2005-2007 David Brownell + * Copyright (C) 2008 Wolfram Sang, Pengutronix + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include linux/kernel.h +#include linux/init.h +#include linux/module.h +#include linux/slab.h +#include linux/delay.h +#include linux/i2c.h +#include linux/i2c/at24.h + +/* + * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable. + * Differences between different vendor product lines (like Atmel AT24C or + * MicroChip 24LC, etc) won't much matter for typical read/write access. + * There are also I2C RAM chips, likewise interchangeable. One example + * would be the PCF8570, which acts like a 24c02 EEPROM (256 bytes). + * + * However, misconfiguration can lose data. Set 16-bit memory address + * to a part with 8-bit addressing will overwrite data. Writing with too + * big a page size also loses data. And it's not safe to assume that the + * conventional addresses 0x50..0x57 only hold eeproms ... a pcf8563 RTC + * uses 0x51, for just one example. + * + * Accordingly, explicit board-specific configuration data should be used + * in almost all cases. (One partial exception is an SMBus used to access + * SPD data for DRAM sticks. Those only use 24c02 EEPROMs.) + * + * So this driver uses new style I2C driver binding, expecting to be + * told what devices exist. That may be in arch/X/mach-Y/board-Z.c or + * similar kernel-resident tables; or, configuration data coming from + * a bootloader. Be sure to set the board_info type to identify the + * eeprom type. + * + * Other than binding model, current differences from eeprom driver are + * that this one handles write access and isn't restricted to 24c02 devices. + * It also handles larger
Re: [i2c] [PATCH] I2C driver for IMX
On Fri, Mar 14, 2008 at 09:26:28AM +0200, Darius wrote: thanks for comments. What I should do with corrected patch? Place there again? Just send it again. You could add stuff like [PATCHV2] in the subject or a list of changes since the last revision in the description. Bye, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCHv2 3/3] Add platform driver on top of the new
On Mon, Mar 10, 2008 at 09:02:51AM -0800, David Brownell wrote: You should #include linux/gpio.h now and avoid a lot of this #ifdeffery ... which is something I think you'd be told by running checkpatch.pl on 2.6.25-rc5, as well as most RC4 kernels. Last time I changed my #includes from asm/foo.h to linux/foo.h, it was also wrong :) But now I researched that for irq.h checkpatch.pl had a bug (patch sent), for io.h it is unknown and uncommon to replace it (still recommended according to lkml) and for gpio.h it is probably the right thing to do. Still, using linux/gpio.h does not really avoid the #ifdefs if the priority is to produce less code in the driver. It does avoid them if the priority is simply to remove them (for the price of having an integer and two small blocks of code as unused overhead). May I assume that it getting rid of #ifdefs has priority? + /* Use NO_GPIO when this macro is in mainline */ I hope you mean gpio_is_valid() instead... that's in MM, but not yet mainline (except when linux/gpio.h is all stubs). Will change the comment. I also realized that I should register/deregister the gpio-pin in the driver; used to have this in the boardsetup, sigh. Will send an updated version later today. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [PATCHv2 3/3] Add platform driver on top of the new pca-algorithm
Hello,
I sent this patch to myself a minute ago and could apply it. Dunno what went
wrong the last time. I am very sorry (I know that patch fixing is
annoying).
All the best,
Wolfram
---
Subject: Add platform driver on top of the new pca-algorithm
From: Wolfram Sang [EMAIL PROTECTED]
Changes since last revision:
- use linux/gpio.h and remove #ifdefs CONFIG_GENERIC_GPIO
- correct reference to gpio_is_valid()
- register and setup gpio in the driver
- just print whole lines with printk
- removed warnings
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
Changes since last revision:
- check against CONFIG_GENERIC_GPIO (was GENERIC_GPIO :( )
- don't use platform data anymore, copy all over to own struct
- give info about mem irq when booting (and switch to printk
as device is not yet registered)
- add comment about problems with polling
- added proper __devinit and __devexit
- added owner to module
- removed whitespace alignment in code
- driver now named i2c-pca-platform (as the module)
- fixed typos in Kconfig
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
Tested on a blackfin.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
drivers/i2c/busses/Kconfig| 15 +
drivers/i2c/busses/Makefile |1
drivers/i2c/busses/i2c-pca-platform.c | 298 ++
include/linux/i2c-pca-platform.h | 12 +
4 files changed, 324 insertions(+), 2 deletions(-)
Index: linux-playground/drivers/i2c/busses/i2c-pca-platform.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-playground/drivers/i2c/busses/i2c-pca-platform.c 2008-03-14
14:45:34.0 +0100
@@ -0,0 +1,298 @@
+/*
+ * i2c_pca_platform.c
+ *
+ * Platform driver for the PCA9564 I2C controller.
+ *
+ * Copyright (C) 2008 Pengutronix
+ *
+ * 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 linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/i2c-algo-pca.h
+#include linux/i2c-pca-platform.h
+#include linux/gpio.h
+
+#include asm/irq.h
+#include asm/io.h
+
+#define res_len(r) ((r)-end - (r)-start + 1)
+
+struct i2c_pca_pf_data {
+ void __iomem*reg_base;
+ int irq;/* if 0, use polling */
+ int gpio;
+ wait_queue_head_t wait;
+ struct i2c_adapter adap;
+ struct i2c_algo_pca_dataalgo_data;
+ unsigned long io_base;
+ unsigned long io_size;
+};
+
+/* Read/Write functions for different register alignments */
+
+static int i2c_pca_pf_readbyte8(void *pd, int reg)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ return ioread8(i2c-reg_base + reg);
+}
+
+static int i2c_pca_pf_readbyte16(void *pd, int reg)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ return ioread8(i2c-reg_base + reg * 2);
+}
+
+static int i2c_pca_pf_readbyte32(void *pd, int reg)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ return ioread8(i2c-reg_base + reg * 4);
+}
+
+static void i2c_pca_pf_writebyte8(void *pd, int reg, int val)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ iowrite8(val, i2c-reg_base + reg);
+}
+
+static void i2c_pca_pf_writebyte16(void *pd, int reg, int val)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ iowrite8(val, i2c-reg_base + reg * 2);
+}
+
+static void i2c_pca_pf_writebyte32(void *pd, int reg, int val)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ iowrite8(val, i2c-reg_base + reg * 4);
+}
+
+
+static int i2c_pca_pf_waitforcompletion(void *pd)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ int ret = 0;
+
+ if (i2c-irq) {
+ ret = wait_event_interruptible(i2c-wait,
+ i2c-algo_data.read_byte(i2c, I2C_PCA_CON)
+I2C_PCA_CON_SI);
+ } else {
+ /*
+* Do polling...
+* XXX: Could get stuck in extreme cases!
+* Maybe add timeout, but using irqs is preferred anyhow.
+*/
+ while ((i2c-algo_data.read_byte(i2c, I2C_PCA_CON)
+I2C_PCA_CON_SI) == 0)
+ udelay(100);
+ }
+
+ return ret;
+}
+
+static void i2c_pca_pf_dummyreset(void *pd)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+ printk(KERN_WARNING %s: No reset-pin found. Chip may get stuck!\n,
+ i2c-adap.name);
+}
+
+static void i2c_pca_pf_resetchip(void *pd)
+{
+ struct i2c_pca_pf_data *i2c = pd;
+
+ gpio_set_value(i2c-gpio, 0
Re: [i2c] [PATCH] I2C driver for IMX
On Thu, Mar 13, 2008 at 06:07:45PM +0200, Darius wrote:
Hello,
(I know I am myself quite new here. I don't want to boast, just trying
to be a little bit helpful.)
I found some things concerning the formal side:
+ * History: 2002/2/07 use msgs[]
I have been told here that histories are not wanted as they are achieved
through git.
+static struct platform_driver i2c_imx_driver = {
+ .probe = i2c_imx_probe,
+ .remove = i2c_imx_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+.owner = THIS_MODULE,
Indentation seems wrong here and in some other places...
+struct imx_i2c_struct {
+struct i2c_adapter adapter;
+ struct resource *res;
+ void __iomem *base;
...like here and so on.
+#ifdef CONFIG_I2C_DEBUG_BUS
+printk(I2C: i2c_imx_bus_busy\n);
+#endif
Maybe you can define a debug-printing-macro that only prints when
DEBUG_BUS is set and is simply empty when it is unset? This should make
the code more readable, I think (or use pr_debug).
+ // chech or i2c bus is not busy
CodingStyle suggests not using //.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
Re: [i2c] [patch 6/6] Minor fixes for pxa-driver
Hi Jean.
Jean Delvare wrote:
.driver = {
.name = pxa2xx-i2c,
+ .owner = THIS_DRIVER,
THIS_MODULE? Was it just too obvious to be mentioned or how come it
builds at all? My platform driver complains...
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
___
i2c mailing list
i2c@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
[i2c] [PATCHv2 0/3] PCA9564 platform driver
Hello, this is my second try of a patch series adding a platform driver for the PCA9564. I included most suggestions from last time; if not, I tried to make clear why. One point I should mention again is that I did not use NO_IRQ as I read on lkml, that 0 is the equivalent for NO_IRQ and everything else is more like an unwanted exception. I built this driver on x86 and blackfin. The actual testing was done using the latter. All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry ___ i2c mailing list i2c@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/i2c
