Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree
* Dmitry Torokhov [150803 13:05]:
> On Mon, Aug 03, 2015 at 03:21:21AM -0700, Tony Lindgren wrote:
> >
> > Hmm why do we need the check for if (device_can_wakeup(&client->dev)))?
>
> Because of the code in device_wakeup_attach_irq():
>
> ws = dev->power.wakeup;
> if (!ws) {
> dev_err(dev, "forgot to call call device_init_wakeup?\n");
> return -EINVAL;
> }
OK :)
> > Also wondering about the dev vs &client->dev usage here.. But I take
> > you have checked that we end up calling the runtime PM calls of the
> > client instead of the i2c bus controller :)
>
> dev *is* clent->dev in this context:
>
> struct i2c_client *client = i2c_verify_client(dev);
OK thanks for confirming that.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree
* Vignesh R [150731 04:00]:
> On 07/31/2015 01:44 AM, Dmitry Torokhov wrote:
> > Instead of having each i2c driver individually parse device tree data in
> > case it or platform supports separate wakeup interrupt, and handle
> > enabling and disabling wakeup interrupts in their power management
> > routines, let's have i2c core do that for us.
Good idea, yes the dedicated wake-up interrupts can be handled
at the bus level to keep device drivers generic.
One question below though..
> > @@ -639,11 +640,13 @@ static int i2c_device_probe(struct device *dev)
> > if (!client->irq) {
> > int irq = -ENOENT;
> >
> > - if (dev->of_node)
> > - irq = of_irq_get(dev->of_node, 0);
> > - else if (ACPI_COMPANION(dev))
> > + if (dev->of_node) {
> > + irq = of_irq_get_byname(dev->of_node, "irq");
> > + if (irq == -EINVAL || irq == -ENODATA)
> > + irq = of_irq_get(dev->of_node, 0);
> > + } else if (ACPI_COMPANION(dev)) {
> > irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > -
> > + }
> > if (irq == -EPROBE_DEFER)
> > return irq;
> > if (irq < 0)
> > @@ -659,20 +662,47 @@ static int i2c_device_probe(struct device *dev)
> > if (!device_can_wakeup(&client->dev))
> > device_init_wakeup(&client->dev,
> > client->flags & I2C_CLIENT_WAKE);
> > +
> > + if (device_can_wakeup(&client->dev)) {
> > + int wakeirq = -ENOENT;
> > +
> > + if (dev->of_node) {
> > + wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> > + if (wakeirq == -EPROBE_DEFER)
> > + return wakeirq;
> > + }
> > +
> > + if (wakeirq > 0 && wakeirq != client->irq)
> > + status = dev_pm_set_dedicated_wake_irq(dev, wakeirq);
> > + else if (client->irq > 0)
> > + status = dev_pm_set_wake_irq(dev, wakeirq);
> > + else
> > + status = 0;
Hmm why do we need the check for if (device_can_wakeup(&client->dev)))?
Also wondering about the dev vs &client->dev usage here.. But I take
you have checked that we end up calling the runtime PM calls of the
client instead of the i2c bus controller :)
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] i2c: omap: new fixes 2
* Alexander Kochetkov [141203 06:36]: > This pacth series intended for fixing problem reported > by Tony Lindgren here[1] > > One of first four patched could fix the problem. > Last patch provide event trace so I could resolve problem. > It could be applied using 'git am' or 'patch -p1 ...' > > Patches are rebased on branch 'i2c/for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > (6e79807443cba7397cd855ed29d6faba51d4c893) > > Tony, could you check, does the series fix the problem reported[1]? > If yes, could you bisect and point commit that solve. > If no, could you provide trace output (with or without the patches > from series). > If no, could you check does i2c-omap.c from commit > ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4. > (the commit before my changes to kernel) work for you? It seems this is not related to your patches. Applying these cause the following though on my 2430sdp: omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: XFER0: STAT=0x; IE=0x601f; CON=0x8000; (omap_i2c_xfer_msg:705) omap_i2c 48072000.i2c: XFER1: STAT=0x0010; IE=0x601f; CON=0x8600; (omap_i2c_xfer_msg:707) omap_i2c 48072000.i2c: THR: STAT=0x1410; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: THR: STAT=0x1000; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: THR DONE: STAT=0x1004; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1168) omap_i2c 48072000.i2c: THR: STAT=0x1004; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: THR: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: THR DONE: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_isr_thread:1168) omap_i2c 48072000.i2c: XFER TIMEOUT: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_xfer_msg:716) omap_i2c 48072000.i2c: controller timed out twl: Write failed (mod 3, reg 0x0e count 1) Regards, Tony > [1] http://www.spinics.net/lists/linux-i2c/msg17811.html > > Alexander Kochetkov (5): > i2c: omap: ack only reported events > i2c: omap: simplify i462 errata handling for NACK and AL cases > i2c: omap: move STP generation logic into ISR thread > i2c: omap: reimpelement STP hack via 2-phases transfer > i2c: omap: add trace > > drivers/i2c/busses/i2c-omap.c | 162 > - > 1 file changed, 95 insertions(+), 67 deletions(-) > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing
* Alexander Kochetkov [141202 03:19]: > > 01 дек. 2014 г., в 22:58, Tony Lindgren написал(а): > > > I think this is a different issue than what I'm seeing. > > Hello, Tony! > > Thank you for testing! > > Could check i2c-omap.c from commit ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4. > As all my changes comes after it[1]. So I can understand was the problem > before my work. The issue I'm seeing on 2430sdp is some earlier regression that has started happening over the past year or so. No idea when though as it sometimes works and sometimes does not. So it does not have anything to do with your patches. > I there was no problems, then try with my first commit: > 27caca9d2e01c92b26d0690f065aad093fea01c7 > > The problems you talk about is this? > [9.675994] omap_i2c 48072000.i2c: controller timed out > [ 10.704010] omap_i2c 48072000.i2c: controller timed out > [ 11.734069] omap_i2c 48072000.i2c: controller timed out > root@omap2430sdp:/# [ 12.823638] omap_i2c 48072000.i2c: controller timed out No, I'm seeing just this: omap_i2c 4807.i2c: bus 0 rev3.3 at 100 kHz omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 And the system just hangs. With i2c-omap debug enabled, the lines around the twl are: omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) And then it hangs. In the working case, the output continues with: omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072
Re: [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing
* Alexander Kochetkov [141129 13:02]:
> commit dd74548ddece4b9d68e5528287a272fa552c81d0 ("i2c: omap:
> resize fifos before each message") dropped check for dev->buf_len.
> As result, data processing loop cause dev->buf overruns for
> devices with 16-bit data register (omap2420).
>
> In the dd74548ddece4b9d68 code, for each loop iteration if the
> flag OMAP_I2C_FLAG_16BIT_DATA_REG is set (omap2420), dev->buf
> is incremented twice, and dev->buf_len decremented twice.
>
> Also buffer overrun could happen (in theory) due to wrong
> ISR handling (bug).
>
> The commit fix data processing for omap2420 and add guard checks
> in the data processing loops do disallow accesses to the buffer,
> when dev->buf_len is zero. Also added warnings to unhide the bug.
>
> Found by code review.
>
> Signed-off-by: Alexander Kochetkov
> Fixes: dd74548ddece4b9d68e5528287a272fa552c81d0 "i2c: omap: resize fifos
> before each message"
> Reported-by: Tony Lindgren
I think this is a different issue than what I'm seeing.
Not sure if I've seen what you're describing.. The $subject patch
should be reviewed by Felipe and Aaro, but this does not help
things on 2430.
Regards,
Tony
> drivers/i2c/busses/i2c-omap.c | 36
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 4563200..e890295 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -938,20 +938,30 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev)
> static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
> bool is_rdr)
> {
> - u16 w;
> + u16 w;
> +
> + if (unlikely(num_bytes > dev->buf_len)) {
> + dev_err(dev->dev, "%s interrupt can't receive %u byte(s)\n",
> + is_rdr ? "RDR" : "RRDY", (num_bytes - dev->buf_len));
> + num_bytes = dev->buf_len;
> + }
>
> - while (num_bytes--) {
> + while (num_bytes) {
> w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
> *dev->buf++ = w;
> dev->buf_len--;
> + num_bytes--;
>
> /*
>* Data reg in 2430, omap3 and
>* omap4 is 8 bit wide
>*/
> if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
> - *dev->buf++ = w >> 8;
> - dev->buf_len--;
> + if (num_bytes) {
> + *dev->buf++ = w >> 8;
> + dev->buf_len--;
> + num_bytes--;
> + }
> }
> }
> }
> @@ -959,19 +969,29 @@ static void omap_i2c_receive_data(struct omap_i2c_dev
> *dev, u8 num_bytes,
> static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
> bool is_xdr)
> {
> - u16 w;
> + u16 w;
> +
> + if (unlikely(num_bytes > dev->buf_len)) {
> + dev_err(dev->dev, "%s interrupt can't transmit %u byte(s)\n",
> + is_xdr ? "XDR" : "XRDY", (num_bytes - dev->buf_len));
> + num_bytes = dev->buf_len;
> + }
>
> - while (num_bytes--) {
> + while (num_bytes) {
> w = *dev->buf++;
> dev->buf_len--;
> + num_bytes--;
>
> /*
>* Data reg in 2430, omap3 and
>* omap4 is 8 bit wide
>*/
> if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
> - w |= *dev->buf++ << 8;
> - dev->buf_len--;
> + if (num_bytes) {
> + w |= *dev->buf++ << 8;
> + dev->buf_len--;
> + num_bytes--;
> + }
> }
>
> if (dev->errata & I2C_OMAP_ERRATA_I462) {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
* Alexander Kochetkov [141128 15:27]: > Hello, Tony! > > I just want to know, is multimaster i2c feature is interesting for TI SOC, > so I could send another patches? Sure and thanks for looking into fixing things. > Or it's better to leave the thing without changes, as current single master > version > well tested and work? Well once the fixes are in, I don't see any reason to not add multimaster support. > Also I have a draft version of mixed multimaster/slave version. But it could > introduce new bugs. > Are we ready for that? Thats because IP behavior, sometimes, doesn't > correspond to TRMs[4][5]. > It's the one of strange IP I ever seen on TI SOC. And TRM not as detailed as > DSP TRMs. I think we can pretty easily test the i2c support before things get merged. I guess it should then be possible to loop two i2c controllers and run automated tests on them :) > Looks, like you haven't seen my response in another thread[1]. > So, duplicate it here. Sorry I guess I forgot to reply, let me know if I still missed something. I'll give your two fixes a try on Monday hopefully. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
* Kevin Hilman [141126 13:27]: > Alexander Kochetkov writes: > > > NOT FOR UPSTREAM > > > > The patch checks if IP reset during probe could bring I2C bus > > to a free state on omap2430 - omap3530 boards. > > > > I guess, IP hold one of I2C lines in a low state. > > I guess, u-boot haven't sent a stop condition. > > > > The patch is rebased on branch 'i2c/for-next' of > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > > (6e79807443cba7397cd855ed29d6faba51d4c893) > > > > Signed-off-by: Alexander Kochetkov > > Reported-by: Kevin Hilman > > Tested-by: Kevin Hilman > > Built for omap2plus_defconfig and tested on all my OMAP boards. Results > here: > > http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/ And below is the output from 2430sdp with linux next plus Alexander's test patch. Looks like for some time 2430 i2c has not been behaving reliably unless I force compatible to ti,omap2420-i2c instead of ti,omap2430-i2c.. The output below is with ti,omap2430-i2c. Regards, Tony 8< - [0.913574] omap_i2c 4807.i2c: init0: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:493) [1.931365] omap_i2c 4807.i2c: timeout waiting for bus ready [1.931457] omap_i2c 4807.i2c: init1: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:497) [1.931518] omap_i2c 4807.i2c: init1: bb_valid=0 [2.949249] omap_i2c 4807.i2c: timeout waiting for bus ready [2.949340] omap_i2c 4807.i2c: init2: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:504) [2.949401] omap_i2c 4807.i2c: init2: bb_valid=0 [2.952941] omap_i2c 4807.i2c: bus 0 rev3.3 at 100 kHz (rev 0036) [2.969299] omap_i2c 48072000.i2c: init0: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:493) [3.987091] omap_i2c 48072000.i2c: timeout waiting for bus ready [3.987182] omap_i2c 48072000.i2c: init1: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:497) [3.987243] omap_i2c 48072000.i2c: init1: bb_valid=0 [5.004974] omap_i2c 48072000.i2c: timeout waiting for bus ready [5.005096] omap_i2c 48072000.i2c: init2: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:504) [5.005126] omap_i2c 48072000.i2c: init2: bb_valid=0 [5.017517] omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz (rev 0036) [7.555419] twl4030_keypad 48072000.i2c:twl@48:keypad: OF: linux,keymap property not defined in /ocp/i2c@48072000/twl@48/keypad [7.567626] twl4030_keypad 48072000.i2c:twl@48:keypad: Failed to build keymap [7.575439] twl4030_keypad: probe of 48072000.i2c:twl@48:keypad failed with error -2 [7.599639] input: twl4030_pwrbutton as /devices/platform/ocp/48072000.i2c/i2c-1/1-0048/48072000.i2c:twl@48:pwrbutton/input/input1 [7.624450] twl_rtc 48072000.i2c:twl@48:rtc: Power up reset detected. [7.631988] twl_rtc 48072000.i2c:twl@48:rtc: Enabling TWL-RTC [7.655456] twl_rtc 48072000.i2c:twl@48:rtc: rtc core: registered 48072000.i2c:twl@48 as rtc0 [7.923187] i2c /dev entries driver [8.246795] twl_rtc 48072000.i2c:twl@48:rtc: hctosys: unable to read the hardware clock [9.675994] omap_i2c 48072000.i2c: controller timed out [ 10.704010] omap_i2c 48072000.i2c: controller timed out [ 11.734069] omap_i2c 48072000.i2c: controller timed out root@omap2430sdp:/# [ 12.823638] omap_i2c 48072000.i2c: controller timed out [ 12.834747] twl4030: I2C error -110 reading PIH ISR -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Alexander Kochetkov [141124 16:11]: > > 24 нояб. 2014 г., в 23:05, Alexander Kochetkov > написал(а): > > > Something (u-boot, may be) leave the bus in the wrong state. > > Really strange. > > Actually something wrong with i2c-pullups on i2c.1 bus on fault boards. > May be these are boards without pull-ups? It could be. Boards that use external i2c pulls should have all the internal pulls disabled as the pulls get connected in parallel and the total resistance decreases. And then the i2c signals may not be up to the spec. Note that there are internal pulls in the i2c controller, and in the i2c padconf registers. > All beagles doesn't have internal pull-ups on i2c.1 since u-boot 2011.x. The pulls should be enabled based on the board and possibly based on the board revision. > Here is the bug in the u-boot related to beagle: > http://git.denx.de/?p=u-boot.git;a=commit;h=04e2a13336f0e507ef416bbede3be92b79c46594 > > Yes, I made fix, but keep that in mind. > > For example one of the boards (omap3-beagle): > http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ > http://status.armcloud.us/boot/omap3-beagle,legacy/job/next/kernel/next-20141124/defconfig/arm-omap2plus_defconfig/ > http://status.armcloud.us/boot/omap3-beagle/job/next/kernel/next-20141124/defconfig/arm-multi_v7_defconfig/ > > has following warning message in the u-boot log: > > U-Boot 2014.07 (Aug 21 2014 - 11:03:05) > > > > OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > > OMAP3 Beagle board + LPDDR/NAND > > > > Beagle Rev C1/C2/C3 > > Timed out in wait_for_event: status=1000 > > Check if pads/pull-ups of bus 1 are properly configured > > Also beagle schematic has following log entry for A3: > 4. Added optional pullup resistors on I2C2_SCL and I2C_SDA into the layout. > > Is the fault beagle is pre A3 revision? Seems to be C1/C2/C3 based on the above logs? > I can't tell anything about second one board (omap3-overo-tobi), because I > could not get it schematic. > > And how you have i2c.1 working without pull-ups I don't know. I checked on the LDP and it seems to have external pulls for i2c. I also tested n900 without your fix, and it's failing too. On n900 there are external pulls and all the internal pulls should be disabled. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: i2c: don't check bus state IP rev3.3 and earlier
* Alexander Kochetkov [141124 12:35]:
> Commit 903c3859f77f9b0aace551da03267ef7a211dbc4 ("i2c: omap: implement
> workaround for handling invalid BB-bit values") introduce the error result
> in boot test fault on OMAP3530 boards
>
> The patch fix the error (disable i2c bus test for OMAP3530).
Maybe add Reported-by: credit for Kevin Hilman here?
Other than that, this fixes the problem for me:
Tested-by: Tony Lindgren
> Signed-off-by: Alexander Kochetkov
> Fixes: 903c3859f77f9b0aace551da03267ef7a211dbc4
> ---
> drivers/i2c/busses/i2c-omap.c |8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5d92d0e..4563200 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -344,8 +344,10 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
> /* SYSC register is cleared by the reset; rewrite it */
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, sysc);
>
> - /* Schedule I2C-bus monitoring on the next transfer */
> - dev->bb_valid = 0;
> + if (dev->rev > OMAP_I2C_REV_ON_3430_3530) {
> + /* Schedule I2C-bus monitoring on the next transfer */
> + dev->bb_valid = 0;
> + }
> }
>
> return 0;
> @@ -460,7 +462,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> dev->scllstate = scll;
> dev->sclhstate = sclh;
>
> - if (dev->rev < OMAP_I2C_OMAP1_REV_2) {
> + if (dev->rev <= OMAP_I2C_REV_ON_3430_3530) {
> /* Not implemented */
> dev->bb_valid = 1;
> }
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Alexander Kochetkov [141124 11:41]: > > 24 нояб. 2014 г., в 22:08, Kevin Hilman написал(а): > > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > > was bisected down to this commit. > > > > Kevin > > > > [1] http://status.armcloud.us/boot/?next-20141124&omap > > > Could someone advice with debugging on OMAP3530? Just try to boot it with your patch? :) > I'd like to apply one one more commit to see events during boot and > see actual signals on wire (during of timeout)? If you post a patch, I can test boot with it. Looks like the failing ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx. But the test function should not loop forever in any case I take? So I doubt we just want to change the test for for a higher rev number for OMAP_I2C_REV_ON_3430_3530. > Otherwise, commit must dropped (or rewritten such way it is disabled by > default). > > > 24 нояб. 2014 г., в 22:13, Wolfram Sang написал(а): > > > OK, giving Alexander some time for a fix. If it can't be found, I'll > > revert this patch. Thanks! > > What deadline? I'd say by Tuesday as we have multiple automated test systems failing as soon as people update their trees. And when they are failing, we may miss other breakage happening in linux next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values
* Wolfram Sang [141124 11:14]: > On Mon, Nov 24, 2014 at 01:10:23PM -0600, Felipe Balbi wrote: > > On Mon, Nov 24, 2014 at 11:08:48AM -0800, Kevin Hilman wrote: > > > On Sat, Nov 22, 2014 at 11:47 AM, Alexander Kochetkov > > > wrote: > > > > In a multimaster environment, after IP software reset, BB-bit value > > > > doesn't > > > > correspond to the current bus state. It may happen what BB-bit will be > > > > 0, > > > > while the bus is busy due to another I2C master activity. > > > > > > > > Any transfer started when BB=0 and bus is busy wouldn't be completed by > > > > IP > > > > and results in controller timeout. More over, in some cases IP could > > > > interrupt another master's transfer and corrupt data on wire. > > > > > > > > The commit implement method allowing to prevent IP from entering into > > > > "controller timeout" state and from "data corruption" state. > > > > > > > > The one drawback is the need to wait for 10ms before the first transfer. > > > > > > > > Tested on Beagleboard XM C. > > > > Tested on BBB and AM437x Starter Kit by Felipe Balbi. > > > > > > > > Signed-off-by: Alexander Kochetkov > > > > Tested-by: Felipe Balbi > > > > Reviewed-by: Felipe Balbi > > > > > > This patch recently hit linux-next (as commit 903c3859f77f) and boot > > > breakage[1] in next-20141124 on OMAP3530 Beagle and Overo/Tobi boards > > > was bisected down to this commit. > > > > > > Kevin > > > > > > [1] http://status.armcloud.us/boot/?next-20141124&omap > > > > btw, based on Kevin's boot test, only OMAP3530 is failing. > > OK, giving Alexander some time for a fix. If it can't be found, I'll > revert this patch. Thanks! I can confirm reverting it fixes things for me as well thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio
* Wolfram Sang [131115 14:27]: > On Thu, Nov 14, 2013 at 03:08:42PM -0800, Tony Lindgren wrote: > > Looks like we're missing two lines needed to make it > > work properly with device tree. > > > > Cc: linux-i2c@vger.kernel.org > > Cc: Aaro Koskinen > > Cc: Wolfram Sang > > Signed-off-by: Tony Lindgren > > Applied to for-next, thanks! Thanks, will drop this one from my fixes series. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/8] i2c: Fix device tree binding for i2c-cbus-gpio
Looks like we're missing two lines needed to make it
work properly with device tree.
Cc: linux-i2c@vger.kernel.org
Cc: Aaro Koskinen
Cc: Wolfram Sang
Signed-off-by: Tony Lindgren
---
Wolfram, I found one more bug booting omaps with device tree.
--- a/drivers/i2c/busses/i2c-cbus-gpio.c
+++ b/drivers/i2c/busses/i2c-cbus-gpio.c
@@ -246,6 +246,7 @@ static int cbus_i2c_probe(struct platform_device *pdev)
adapter->owner = THIS_MODULE;
adapter->class = I2C_CLASS_HWMON;
adapter->dev.parent = &pdev->dev;
+ adapter->dev.of_node= pdev->dev.of_node;
adapter->nr = pdev->id;
adapter->timeout= HZ;
adapter->algo = &cbus_i2c_algo;
@@ -289,6 +290,7 @@ static struct platform_driver cbus_i2c_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "i2c-cbus-gpio",
+ .of_match_table = of_match_ptr(i2c_cbus_dt_ids),
},
};
module_platform_driver(cbus_i2c_driver);
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2
* Wolfram Sang [131114 09:49]:
>
> > > It would have been helpful if the message "PATCH [0/x]" would have been
> > > sent to the i2c-list also.
> >
> > Thanks, next time I'll try check the cc list in the cover letter
> > manually after running git format patch. I guess there's no way
> > to deal with that in an automated way.
>
> I use this hackish script as --cc-cmd with git:
>
> #! /bin/sh
> #
> # cocci_cc - send cover letter to all mailing lists referenced in a patch
> series
> # done by Wolfram Sang in 2012 - WTFPLv2
>
> name=${1##*/}
> num=${name%%-*}
>
> if [ "$num" = "" ]; then
> dir=${1%/*}
> for f in $dir/*; do
> patchname=${f##*/}
> [ "${patchname%%-*}" = "" ] && continue
> scripts/get_maintainer.pl --no-m $f
> done | sort -u
> else
> scripts/get_maintainer.pl $1
> fi
>
Cool thanks :) I'll give it a try next time.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2
* Wolfram Sang [131113 22:59]: > On Wed, Nov 13, 2013 at 06:35:33PM -0800, Tony Lindgren wrote: > > As we claim to support device tree for mach-omap2, we > > should have the necessary flags in the driver to make it > > usable. > > > > Cc: Wolfram Sang > > Cc: linux-i2c@vger.kernel.org > > Signed-off-by: Tony Lindgren > > Acked-by: Wolfram Sang > > It would have been helpful if the message "PATCH [0/x]" would have been > sent to the i2c-list also. Thanks, next time I'll try check the cc list in the cover letter manually after running git format patch. I guess there's no way to deal with that in an automated way. Here's a link to the whole thread for reference: http://www.spinics.net/lists/arm-kernel/msg286246.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2
* Mark Rutland [131114 03:08]:
>
> Please update Documentation/devicetree/bindings/i2c/i2c-omap.txt
>
> Otherwise, this is fine.
Here's this one with updated documentation.
Regards,
Tony
From: Tony Lindgren
Date: Wed, 13 Nov 2013 16:36:37 -0800
Subject: [PATCH] i2c: omap: Fix missing device tree flags for omap2
As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.
Cc: linux-i2c@vger.kernel.org
Acked-by: Wolfram Sang
Signed-off-by: Tony Lindgren
--- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-omap.txt
@@ -1,7 +1,8 @@
I2C for OMAP platforms
Required properties :
-- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
+- compatible : Must be "ti,omap2420-i2c", "ti,omap2430-i2c", "ti,omap3-i2c"
+ or "ti,omap4-i2c"
- ti,hwmods : Must be "i2c", n being the instance number (1-based)
- #address-cells = <1>;
- #size-cells = <0>;
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
};
#ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_NO_FIFO |
+ OMAP_I2C_FLAG_SIMPLE_CLOCK |
+ OMAP_I2C_FLAG_16BIT_DATA_REG |
+ OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
.compatible = "ti,omap3-i2c",
.data = &omap3_pdata,
},
+ {
+ .compatible = "ti,omap2430-i2c",
+ .data = &omap2430_pdata,
+ },
+ {
+ .compatible = "ti,omap2420-i2c",
+ .data = &omap2420_pdata,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] i2c: omap: Fix missing device tree flags for omap2
As we claim to support device tree for mach-omap2, we
should have the necessary flags in the driver to make it
usable.
Cc: Wolfram Sang
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Tony Lindgren
---
If this looks OK, I'd like to merge this as a fix via arm-soc tree
along with the other patches in this series as my later patches
depend on patches in this series.
---
drivers/i2c/busses/i2c-omap.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9967a6f..f04afd1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1037,6 +1037,20 @@ static const struct i2c_algorithm omap_i2c_algo = {
};
#ifdef CONFIG_OF
+static struct omap_i2c_bus_platform_data omap2420_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_NO_FIFO |
+ OMAP_I2C_FLAG_SIMPLE_CLOCK |
+ OMAP_I2C_FLAG_16BIT_DATA_REG |
+ OMAP_I2C_FLAG_BUS_SHIFT_2,
+};
+
+static struct omap_i2c_bus_platform_data omap2430_pdata = {
+ .rev = OMAP_I2C_IP_VERSION_1,
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
+};
+
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
.flags = OMAP_I2C_FLAG_BUS_SHIFT_2,
@@ -1055,6 +1069,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
.compatible = "ti,omap3-i2c",
.data = &omap3_pdata,
},
+ {
+ .compatible = "ti,omap2430-i2c",
+ .data = &omap2430_pdata,
+ },
+ {
+ .compatible = "ti,omap2420-i2c",
+ .data = &omap2420_pdata,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
* Tony Lindgren [131008 15:19]:
> * Wolfram Sang [131008 14:01]:
> > On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> > > * zhangfei gao [130829 23:36]:
> > > > What about concerns from Wolfram:
> > > > " Other people might be
> > > > depending on subsys_initcall to get I2C active before they want to
> > > > activate, say, PMICs. So, I fear regressions, since deferred probing
> > > > might not be available in the needed places to avoid these regressions."
> > >
> > > There should not be any reason to get a PMIC activated
> > > early on. The system should be booting already at that point,
> > > and the PMIC related init can be done later on.
> >
> > Okay, here is a more concrete example:
> >
> > Consider the amplifier driver 'sound/soc/codecs/max9768.c'. Back then,
> > unaware
> > of deferred probing, I wrote the following code to get the GPIOs (which are
> > optional):
> >
> > err = gpio_request_one(pdata->mute_gpio, GPIOF_INIT_HIGH, "MAX9768
> > Mute");
> > max9768->mute_gpio = err ?: pdata->mute_gpio;
> >
> > And later in the process:
> >
> > if (gpio_is_valid(max9768->mute_gpio)) {
> > ret = snd_soc_add_codec_controls(codec, max9768_mute,
> > ARRAY_SIZE(max9768_mute));
> > if (ret)
> > return ret;
> > }
> >
> > So, the mute control will only be added if the gpio_request succeeded. On
> > that
> > particular board, the mute GPIO was wired to an I2C GPIO controller. If I
> > now
> > change the I2C (or GPIO) driver from subsys_initcall to module_init, then
> > the
> > gpio_request in the amplifier driver could hit -EPROBE_DEFER and the mute
> > control will then disappear. Yes, the driver can be fixed easily, yet I
> > fear a
> > number of regressions like this. Instead of people digging into why things
> > disappear after a kernel update, I wonder if there is a way to guide users
> > if
> > this happens. I didn't have time for that, though, sadly. Still, it makes me
> > wonder how easily we could shift from subsys_initcall to module_init,
> > although
> > I'd really love to get away from subsys_initcall in device drivers.
>
> Well it should be pretty trivial to update drivers to use deferred
> probing. Maybe some spatch to check for that in driver probes would
> help getting an idea how many might be affected?
>
> Anyways, it should be fixed as otherwise we'll just dig ourselves
> deeper into the mess of things not working as loadable modules.
BTW, another place where things can go wrong is if there's an irqchip
driver that is being set up at module_init time. If an interrupt client
driver does irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0), the
resources may not have been initialize for the DT case as those are
populated triggered by of_platform_populate().
The fix there is to use irq = irq_of_parse_and_map(pdev->dev.of_node, 0)
instead. Or somehow make of_platform_populate() support -EPROBE_DEFER.
Just FYI,
Tony
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
* Wolfram Sang [131008 14:01]:
> On Fri, Aug 30, 2013 at 01:27:13AM -0700, Tony Lindgren wrote:
> > * zhangfei gao [130829 23:36]:
> > > What about concerns from Wolfram:
> > > " Other people might be
> > > depending on subsys_initcall to get I2C active before they want to
> > > activate, say, PMICs. So, I fear regressions, since deferred probing
> > > might not be available in the needed places to avoid these regressions."
> >
> > There should not be any reason to get a PMIC activated
> > early on. The system should be booting already at that point,
> > and the PMIC related init can be done later on.
>
> Okay, here is a more concrete example:
>
> Consider the amplifier driver 'sound/soc/codecs/max9768.c'. Back then, unaware
> of deferred probing, I wrote the following code to get the GPIOs (which are
> optional):
>
> err = gpio_request_one(pdata->mute_gpio, GPIOF_INIT_HIGH, "MAX9768
> Mute");
> max9768->mute_gpio = err ?: pdata->mute_gpio;
>
> And later in the process:
>
> if (gpio_is_valid(max9768->mute_gpio)) {
> ret = snd_soc_add_codec_controls(codec, max9768_mute,
> ARRAY_SIZE(max9768_mute));
> if (ret)
> return ret;
> }
>
> So, the mute control will only be added if the gpio_request succeeded. On that
> particular board, the mute GPIO was wired to an I2C GPIO controller. If I now
> change the I2C (or GPIO) driver from subsys_initcall to module_init, then the
> gpio_request in the amplifier driver could hit -EPROBE_DEFER and the mute
> control will then disappear. Yes, the driver can be fixed easily, yet I fear a
> number of regressions like this. Instead of people digging into why things
> disappear after a kernel update, I wonder if there is a way to guide users if
> this happens. I didn't have time for that, though, sadly. Still, it makes me
> wonder how easily we could shift from subsys_initcall to module_init, although
> I'd really love to get away from subsys_initcall in device drivers.
Well it should be pretty trivial to update drivers to use deferred
probing. Maybe some spatch to check for that in driver probes would
help getting an idea how many might be affected?
Anyways, it should be fixed as otherwise we'll just dig ourselves
deeper into the mess of things not working as loadable modules.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
* zhangfei gao [130829 23:36]: > What about concerns from Wolfram: > " Other people might be > depending on subsys_initcall to get I2C active before they want to > activate, say, PMICs. So, I fear regressions, since deferred probing > might not be available in the needed places to avoid these regressions." There should not be any reason to get a PMIC activated early on. The system should be booting already at that point, and the PMIC related init can be done later on. > Is it too late using module_init for PMIC? You can probably do it as a fix early on during the -rc cycle too. Of course it needs to be verified to work first :) > Besides, the deferred probing still there if depend on late registered > pin control driver. At least for omaps we have things working just fine with pinctrl-single and a PMIC on I2C controller. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: getting rid of subsys_initcall usage? (was: Re: [PATCH RESEND] i2c: designware: use module_platform_driver)
* zhangfei gao [130829 04:03]: > On Thu, Aug 29, 2013 at 4:58 PM, Linus Walleij > wrote: > > On Wed, Aug 28, 2013 at 11:57 AM, Wolfram Sang wrote: > >> On Tue, Aug 20, 2013 at 04:32:28PM +0800, Zhangfei Gao wrote: > > > >>> Instead of use platform_driver_probe, use module_platform_driver > >>> To support deferred probing > >>> Also subsys_initcall may too early to auto set pinctl > >>> > >>> Signed-off-by: Zhangfei Gao > >>> Acked-by: Baruch Siach > >> > >> This patch is tougher than it looks. You need it, because > >> subsys_initcall may be too early for pinctrl. > > > > pinctrl is initialized very early, core_initcall(). > > > > This is more a question of individual pin control drivers > > and when they probe, and dependencies trying to take > > a pinctrl handle before the pin controller is available > > will be deferred. Even by those grabbed in the core > > by drivers/base/pinctrl.c. > > Thanks Linus. > Your explanation is really make sense. > > We use drivers/pinctrl/pinctrl-single.c, if subsys_initcall for > pinctrl-single, no issue at all. So far we've seen that if you have issues with this, the real problem is that some other driver is trying to initialize way too early probably because of legacy reasons that no longer apply. FYI, it's best to have all the drivers initialize with just module_init and make them work as loadable modules because of the following reasons: 1. You will get real console error messages when something goes wrong with no need for debug_ll and earlyprintk 2. By creating loadable driver modules you're already getting some protection from spaghetti code as the interfaces are defined 3. It will be easier for distros to support various ARM SoCs with loadable driver modules Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP: fix boot sequence
* Grygorii Strashko [130423 06:25]: > Hi > > There are two public discussions now related to OMAP boot and drivers > initialization issues: > "Multiple issues with omap4 panda es in linux next" > http://www.spinics.net/lists/linux-omap/msg90241.html > "[BUG] omap: mfd/regulator: twl/core: init order" > http://www.spinics.net/lists/linux-omap/msg89980.html > > In both cases there are pinctrl-single/I2C/MFD/Regulators initailization > issue: > - regulators are not initialized because of twl, > - twl is not initialized because of I2C, > - I2C is not initialized because of pinctrl-single, > - pinctrl-single is initialized at mudule/device init time. > So, most everything will be shifted at late_initcall time. > > This may cause boot delay (more over, it can broken initialization of drivers > which are not ready to use deferred probe mechanism yet, for example DSS). > > Introduced pathes shift I2C and TWL iniialization to module/device init layer > instead of subsys init layer where initialization dependencies resolved > indirectly in drivers/Makefile now. > > Grygorii Strashko (2): > i2c: omap: convert to module_platform_driver() > mfd: twl-core: convert to module_i2c_driver() > > drivers/i2c/busses/i2c-omap.c | 14 +- > drivers/mfd/twl-core.c| 12 +--- > 2 files changed, 2 insertions(+), 24 deletions(-) Thanks, I have few questions: 1. It seems that the real fix to the issues we're seeing is to make the broken drivers to support -EPROBE_DEFER? 2. If so, can these be merged later on as clean-up? 3. Can these two patches be merged separately without breaking things? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] i2c-embedded for 3.8
* Linus Torvalds [121218 17:07]: > Ugh, guys. Please check this out. > > On Tue, Dec 18, 2012 at 3:41 PM, Wolfram Sang wrote: > > > > please pull the i2c-embedded changes for 3.8 which include: > > > > * CBUS driver (an I2C variant) > > * continued rework of the omap driver > > * s3c2410 gets lots of fixes and gains pinctrl support > > * at91 gains DMA support > > * the GPIO muxer gains devicetree probing > > * typical fixes and additions all over > > > > All patches have been in linux-next before. Please pull. > > I get a conflict because both sides have this: > >Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency > constraints" > > which re-introduced the omap-specific ->set_mpu_wkup_lat() thing. > > But in mainline the only *user* of that has gone away. And the call > location where it originally existed has moved. > > It originally existed in > > arch/arm/plat-omap/i2c.c > > but looking at the history, the omap i2c code first got split into > omap1 and omap2, and at that point the call-site got moved to > > arch/arm/mach-omap2/i2c.c > > but then the code that the revert re-introduced got lost. > > Now, in the merge I just did, I *reinstated* that > ->set_mpu_wkup_lat() code that had gotten lost in mainline. But quite > frankly, the thing is ugly as heck, and I hope it could just be > deleted. Clearly nobody had noticed yet that it got lost in some merge > (possibly an earlier one of mine, but considering that I usually > notice things like this, I suspect it's one of the internal ARM ones). Your merge looks good and has zero diff to what I resolved earlier, and what Arnd and Olof resolved earlier, and what Stephen resolved earlier. It seems that the right thing to do here would have been to pull that revert into arm-soc to avoid this. > I'm adding Arnd, Tony and Olof to the participants list, since they > are the main suspects. > > And guys, if you decide to remove the ->set_mpu_wkup_lat() from > arch/arm/mach-omap2/i2c.c again, please make sure that you remove the > whole infrastructure too: > > include/linux/i2c-omap.h > drivers/i2c/busses/i2c-omap.c Looks like that's still needed until runtime PM can deal with latencies, that's why the revert was needed :( > Hmm? Somebody *really* needs to double-check my merge, it's possibly > quite broken, since I have in no way tested it, and I did this by > looking at some *very* messy history with code being moved across > different files etc etc. Yes thanks again. We've now pretty much cut all the remaining nasty dependencies between arch/arm/*omap*/ code and drivers and can enable multiplatform support for omap2+ for v3.9. So things should be a lot easier with merge conflicts as far as omap is concerned. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tfp410 and i2c_bus_num
* Felipe Balbi [121119 04:25]: > On Mon, Nov 19, 2012 at 01:09:42PM +0200, Tomi Valkeinen wrote: > > On 2012-11-19 11:27, Felipe Balbi wrote: > > > > > > fair enough... it looks like this is going nowhere, so best we come back > > > to this later. No reason to block your patch. > > > > Well, the patch is a fix for stable kernels, so even if we had a great > > idea how to rewrite the dss device handling, it wouldn't affect this > > patch =). > > ok good ;-) FYI I'm assuming Tomi will resend the patch as there were some changes requested early on in the thread. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] i2c: introduce i2c-cbus driver
* Aaro Koskinen [121031 11:10]:
> Add i2c driver to enable access to devices behind CBUS on Nokia Internet
> Tablets.
>
> The patch also adds CBUS I2C configuration for N8x0 which is one of the
> users of this driver.
Added Wolfram Sang to cc so he
knows to pick this one if no more comments. You may need to
resend with him in cc.
Regards,
Tony
> Cc: linux-i2c@vger.kernel.org
> Acked-by: Felipe Balbi
> Acked-by: Tony Lindgren
> Signed-off-by: Aaro Koskinen
> ---
> arch/arm/mach-omap2/board-n8x0.c | 42 ++
> drivers/i2c/busses/Kconfig | 10 ++
> drivers/i2c/busses/Makefile |1 +
> drivers/i2c/busses/i2c-cbus.c| 300
> ++
> include/linux/i2c-cbus.h | 27
> 5 files changed, 380 insertions(+), 0 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-cbus.c
> create mode 100644 include/linux/i2c-cbus.h
>
> diff --git a/arch/arm/mach-omap2/board-n8x0.c
> b/arch/arm/mach-omap2/board-n8x0.c
> index d95f727..7ea0348 100644
> --- a/arch/arm/mach-omap2/board-n8x0.c
> +++ b/arch/arm/mach-omap2/board-n8x0.c
> @@ -16,8 +16,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +41,45 @@
> #define TUSB6010_GPIO_ENABLE 0
> #define TUSB6010_DMACHAN 0x3f
>
> +#if defined(CONFIG_I2C_CBUS) || defined(CONFIG_I2C_CBUS_MODULE)
> +static struct i2c_cbus_platform_data n8x0_cbus_data = {
> + .clk_gpio = 66,
> + .dat_gpio = 65,
> + .sel_gpio = 64,
> +};
> +
> +static struct platform_device n8x0_cbus_device = {
> + .name = "i2c-cbus",
> + .id = 3,
> + .dev= {
> + .platform_data = &n8x0_cbus_data,
> + },
> +};
> +
> +static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
> + {
> + I2C_BOARD_INFO("retu-mfd", 0x01),
> + },
> +};
> +
> +static void __init n8x0_cbus_init(void)
> +{
> + const int retu_irq_gpio = 108;
> +
> + if (gpio_request_one(retu_irq_gpio, GPIOF_IN, "Retu IRQ"))
> + return;
> + irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
> + n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
> + i2c_register_board_info(3, n8x0_i2c_board_info_3,
> + ARRAY_SIZE(n8x0_i2c_board_info_3));
> + platform_device_register(&n8x0_cbus_device);
> +}
> +#else /* CONFIG_I2C_CBUS */
> +static void __init n8x0_cbus_init(void)
> +{
> +}
> +#endif /* CONFIG_I2C_CBUS */
> +
> #if defined(CONFIG_USB_MUSB_TUSB6010) ||
> defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
> /*
> * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
> @@ -677,6 +718,7 @@ static void __init n8x0_init_machine(void)
> gpmc_onenand_init(board_onenand_data);
> n8x0_mmc_init();
> n8x0_usb_init();
> + n8x0_cbus_init();
> }
>
> MACHINE_START(NOKIA_N800, "Nokia N800")
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 65dd599..d01c8ef 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -338,6 +338,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
> help
> The unit of the TWI clock is kHz.
>
> +config I2C_CBUS
> + tristate "CBUS I2C driver"
> + depends on GENERIC_GPIO
> + help
> + Support for CBUS access using I2C API. Mostly relevant for Nokia
> + Internet Tablets (770, N800 and N810).
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-cbus.
> +
> config I2C_CPM
> tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
> depends on (CPM1 || CPM2) && OF_I2C
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 2d33d62..3c548b1 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_I2C_POWERMAC) += i2c-powermac.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
> +obj-$(CONFIG_I2C_CBUS) += i2c-cbus.o
> obj-$(CONFIG_I2C_CPM)+= i2c-cpm.o
> obj-$(CONFIG_I2C_DAVINCI)+= i2c-davinci.o
> obj-$(CONFIG_I2C_DESIGNWARE_CORE)+= i2c-designware-core.o
> diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
> new file mode 100644
> index 000..1ea7667
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-cbus.c
> @@ -0,0 +1,300 @@
>
Re: [PATCH] i2c: pinctrl-ify i2c-omap.c
* Pantelis Antoniou [121030 11:04]: > Enable pinctrl for i2c-omap. > > Signed-off-by: Pantelis Antoniou Looks good to me: Acked-by: Tony Lindgren > --- > drivers/i2c/busses/i2c-omap.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index db31eae..4c38aa0 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -44,6 +44,8 @@ > #include > #include > #include > +#include > +#include > > /* I2C controller revisions */ > #define OMAP_I2C_OMAP1_REV_2 0x20 > @@ -1064,6 +1066,7 @@ omap_i2c_probe(struct platform_device *pdev) > const struct of_device_id *match; > int irq; > int r; > + struct pinctrl *pinctrl; > > /* NOTE: driver uses the static register mapping */ > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > @@ -1202,6 +1205,13 @@ omap_i2c_probe(struct platform_device *pdev) > > of_i2c_register_devices(adap); > > + pinctrl = devm_pinctrl_get_select_default(&pdev->dev); > + if (IS_ERR(pinctrl)) > + dev_warn(dev->dev, "unable to select pin group\n"); > + > + dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr, > + dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed); > + > pm_runtime_mark_last_busy(dev->dev); > pm_runtime_put_autosuspend(dev->dev); > > -- > 1.7.12 > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
* Kevin Hilman [121015 10:32]: > Kalle Jokiniemi writes: > > > > Does not work for me :( > > > > As I said, the issue occurs for me when I enter static suspend (echo mem > >> /sys/power/autosleep or /sys/power/state). I don't think doing this > > just in runtime pm will fix my issue. Or do those handlers get run in > > the normal suspend path as well? > > If the I2C device is still active during the suspend path, these > handlers will get run by the PM domain code (in omap_device.) However, > now that I think about it, the current omap_device PM domain code calls > these at the noirq level, not the late/early level, so it does not > address your original problem. :( > > I suspect we'll need this and your original patch. Have you checked that this is not related to flushing the posted write? If it is, reading back any register from the i2c controller after writing to it ensures the write actually reaches the i2c controller. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
* Jean Pihet [120920 09:09]:
> Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
> API to the new PM QoS API.
> Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
> class of PM QoS. The resulting MPU constraints are used by cpuidle to
> decide the next power state of the MPU subsystem.
>
> The I2C device latency timing is derived from the FIFO size and the
> clock speed and so is applicable to all OMAP SoCs.
>
> Signed-off-by: Jean Pihet
Good to see this, probably should have an ack from
Kevin Hilman for this. Other than that it's best to
merge this via the i2c tree:
Acked-by: Tony Lindgren
> ---
> Rebased on git://git.pengutronix.de/git/wsa/linux.git, branch
> i2c-embedded/for-next
> ---
> arch/arm/plat-omap/i2c.c | 21 -
> drivers/i2c/busses/i2c-omap.c | 32 ++--
> include/linux/i2c-omap.h |1 -
> 3 files changed, 18 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index 40bc06a..d29a2cc 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -26,7 +26,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -34,7 +33,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #define OMAP_I2C_SIZE0x3f
> @@ -130,16 +128,6 @@ static inline int omap1_i2c_add_bus(int bus_id)
>
>
> #ifdef CONFIG_ARCH_OMAP2PLUS
> -/*
> - * XXX This function is a temporary compatibility wrapper - only
> - * needed until the I2C driver can be converted to call
> - * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
> - */
> -static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
> -{
> - omap_pm_set_max_mpu_wakeup_lat(dev, t);
> -}
> -
> static inline int omap2_i2c_add_bus(int bus_id)
> {
> int l;
> @@ -171,15 +159,6 @@ static inline int omap2_i2c_add_bus(int bus_id)
> dev_attr = (struct omap_i2c_dev_attr *)oh->dev_attr;
> pdata->flags = dev_attr->flags;
>
> - /*
> - * When waiting for completion of a i2c transfer, we need to
> - * set a wake up latency constraint for the MPU. This is to
> - * ensure quick enough wakeup from idle, when transfer
> - * completes.
> - * Only omap3 has support for constraints
> - */
> - if (cpu_is_omap34xx())
> - pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
> pdev = omap_device_build(name, bus_id, oh, pdata,
> sizeof(struct omap_i2c_bus_platform_data),
> NULL, 0, 0);
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 0b02543..db31eae 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
>
> /* I2C controller revisions */
> #define OMAP_I2C_OMAP1_REV_2 0x20
> @@ -186,9 +187,8 @@ struct omap_i2c_dev {
> int reg_shift; /* bit shift for I2C register
> addresses */
> struct completion cmd_complete;
> struct resource *ioarea;
> - u32 latency;/* maximum mpu wkup latency */
> - void(*set_mpu_wkup_lat)(struct device *dev,
> - long latency);
> + u32 latency;/* maximum MPU wkup latency */
> + struct pm_qos_request pm_qos_request;
> u32 speed; /* Speed of bus in kHz */
> u32 dtrev; /* extra revision from DT */
> u32 flags;
> @@ -494,9 +494,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev
> *dev, u8 size, bool is_rx)
> dev->b_hw = 1; /* Enable hardware fixes */
>
> /* calculate wakeup latency constraint for MPU */
> - if (dev->set_mpu_wkup_lat != NULL)
> - dev->latency = (100 * dev->threshold) /
> - (1000 * dev->speed / 8);
> + dev->latency = (100 * dev->threshold) / (1000 * dev->speed / 8);
> }
>
> /*
> @@ -631,8 +629,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
> msgs[], int num)
> if (r < 0)
> goto out;
>
> - if (dev->set_mpu_wkup_lat != NULL)
> - dev->set_mpu_wkup_lat(dev->dev, dev->latency);
> + /*
> + * When waiting for completion of a i2c transfer, we need to
>
Re: [RFC PATCH 1/5] i2c: introduce i2c-cbus driver
* Aaro Koskinen [120828 14:35]: > Add i2c driver to enable access to devices behind CBUS on Nokia Internet > Tablets. Can you please do also a separate patch for the device tree binding for getting the GPIO pins for this controller? Other than that thanks for doing this and: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
* Shubhrajyoti [120621 02:35]: > On Thursday 21 June 2012 12:50 PM, Tony Lindgren wrote: > > * Shubhrajyoti [120621 00:08]: > >> On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote: > >>> See the comments regarding driver specific resets in hwmod code. > >> you mean omap_hwmod.c > >>> The way to set this up is to have a shared inline function in > >>> i2c-omap.h that both the driver and hwmod code can use. > >> hwmod reset function uses oh (omap_hwmod). > >> > >> How could the driver also pass oh ? > >> Could we keep a local copy in driver data? > >>> Eventually hwmod code will do the reset only in late initcall > >>> if no driver is loaded for the device in question. > > There's no need for the driver to know anything about oh. > > The driver just needs to know the iobase. > I will rework to make the hwmod and driver use the same function. > In the meanwhile I will send a minimal/ remaining cleanups/ fixes so that > it might get some time to bake in the next branch. OK thanks! Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
* Shubhrajyoti [120621 00:08]: > On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote: > > See the comments regarding driver specific resets in hwmod code. > you mean omap_hwmod.c > > > > The way to set this up is to have a shared inline function in > > i2c-omap.h that both the driver and hwmod code can use. > hwmod reset function uses oh (omap_hwmod). > > How could the driver also pass oh ? > Could we keep a local copy in driver data? > > Eventually hwmod code will do the reset only in late initcall > > if no driver is loaded for the device in question. > There's no need for the driver to know anything about oh. The driver just needs to know the iobase. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
* Shubhrajyoti [120620 06:06]:
> On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
> > * Shubhrajyoti D [120618 07:35]:
> >> From: Jon Hunter
> >>
> >> The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
> >> revision is the same for 3430 and 3530. However, the OMAP3630 device has
> >> the
> >> same I2C revision as OMAP4. Correct the revision definition to reflect
> >> this.
> >>
> >> This patch is based on work done by Jon Hunter
> >> Changes from his patch
> >> - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
> > ...
> >> /* timeout waiting for the controller to respond */
> >> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> >> @@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
> >>omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
> >> SYSC_AUTOIDLE_MASK);
> >>
> >> - } else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
> >> + } else if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
> >>dev->syscstate = SYSC_AUTOIDLE_MASK;
> >>dev->syscstate |= SYSC_ENAWAKEUP_MASK;
> >>dev->syscstate |= (SYSC_IDLEMODE_SMART <<
> > Having to patch all over the place for these revision defines leads
> > into unmaintainable code as new SoCs get added.
> >
> > Please instead just check the revision once during init, then set
> > up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
> > code can check.
> Even now at probe
>
> dev->rev is set by reading the rev register.
>
> The (macro)name used to identify is only changed.
>
> Also all the ips need reset the difference is that 2430 has less bits eg only
> autoidle and reset.
> So a flag needs reset may not be meaningful.
Hmm OK so this is a cosmetic/readability fix..
..but your earlier patch now spreads the checking of revision
to the new non-init function omap_i2c_reset.
Why don't you just do this cosmetic/readability rename fix
before your 03/13 patch? Then set the already existing
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE during init for some
revisions and use that instead of the rev check in
omap_i2c_reset?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
* Shubhrajyoti D [120618 07:35]:
> From: Jon Hunter
>
> The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
> revision is the same for 3430 and 3530. However, the OMAP3630 device has the
> same I2C revision as OMAP4. Correct the revision definition to reflect this.
>
> This patch is based on work done by Jon Hunter
> Changes from his patch
> - Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> @@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
> SYSC_AUTOIDLE_MASK);
>
> - } else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
> + } else if (dev->rev >= OMAP_I2C_REV_ON_3430_3530) {
> dev->syscstate = SYSC_AUTOIDLE_MASK;
> dev->syscstate |= SYSC_ENAWAKEUP_MASK;
> dev->syscstate |= (SYSC_IDLEMODE_SMART <<
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
> @@ -1055,7 +1055,7 @@ omap_i2c_probe(struct platform_device *pdev)
> if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
> dev->errata |= I2C_OMAP_ERRATA_I207;
>
> - if (dev->rev <= OMAP_I2C_REV_ON_3430)
> + if (dev->rev <= OMAP_I2C_REV_ON_3430_3530)
> dev->errata |= I2C_OMAP_ERRATA_I462;
>
> if (!(dev->flags & OMAP_I2C_FLAG_NO_FIFO)) {
> @@ -1073,7 +1073,7 @@ omap_i2c_probe(struct platform_device *pdev)
>
> dev->fifo_size = (dev->fifo_size / 2);
>
> - if (dev->rev >= OMAP_I2C_REV_ON_3530_4430)
> + if (dev->rev >= OMAP_I2C_REV_ON_3630_4430)
> dev->b_hw = 0; /* Disable hardware fixes */
> else
> dev->b_hw = 1; /* Enable hardware fixes */
That way the code does not need to change when new SoC revisions
get added.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 03/13] I2C: OMAP: Remove reset at init
* Shubhrajyoti D [120618 07:35]: > The reset in the driver at init is not needed anymore as the > following patch has removed the HWMOD_INIT_NO_RESET flag. > 6d3c55f [OMAP: hwmod: fix the i2c-reset timeout during bootup] > > This patch does the following > -removes the reset from the probe and implements a omap_i2c_reset > function to reset. > - Reset is removed from omap_i2c_init, which was called > not only during probe, but also after time out and error handling. > omap_i2c_reset is added in those places to effect the reset. See the comments regarding driver specific resets in hwmod code. The way to set this up is to have a shared inline function in i2c-omap.h that both the driver and hwmod code can use. Eventually hwmod code will do the reset only in late initcall if no driver is loaded for the device in question. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 04/18] I2C: OMAP: I2C register restore only if context is lost
* Shubhrajyoti D [120412 06:10]:
> Currently i2c register restore is done always.
> Adding conditional restore.
> The i2c register restore is done only if the context is lost.
> Also remove the definition of SYSS_RESETDONE_MASK and use the
> one in omap_hwmod.h.
>
> Signed-off-by: Shubhrajyoti D
> ---
> arch/arm/plat-omap/i2c.c |3 ++
> drivers/i2c/busses/i2c-omap.c | 52 ++--
> include/linux/i2c-omap.h |1 +
> 3 files changed, 38 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index db071bc..4ccab07 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
>*/
> if (cpu_is_omap34xx())
> pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
> +
> + pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
> +
> pdev = omap_device_build(name, bus_id, oh, pdata,
> sizeof(struct omap_i2c_bus_platform_data),
> NULL, 0, 0);
This should be acked by Kevin, adding him to Cc.
For the arch/arm/plat-omap/i2c.c part:
Acked-by: Tony Lindgren
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a882558..45389db 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
>
> /* I2C controller revisions */
> #define OMAP_I2C_OMAP1_REV_2 0x20
> @@ -157,9 +158,6 @@ enum {
> #define OMAP_I2C_SYSTEST_SDA_I (1 << 1)/* SDA line
> sense in */
> #define OMAP_I2C_SYSTEST_SDA_O (1 << 0)/* SDA line
> drive out */
>
> -/* OCP_SYSSTATUS bit definitions */
> -#define SYSS_RESETDONE_MASK (1 << 0)
> -
> /* OCP_SYSCONFIG bit definitions */
> #define SYSC_CLOCKACTIVITY_MASK (0x3 << 8)
> #define SYSC_SIDLEMODE_MASK (0x3 << 3)
> @@ -184,6 +182,7 @@ struct omap_i2c_dev {
> u32 latency;/* maximum mpu wkup latency */
> void(*set_mpu_wkup_lat)(struct device *dev,
> long latency);
> + int (*get_context_loss_count)(struct device *dev);
> u32 speed; /* Speed of bus in kHz */
> u32 dtrev; /* extra revision from DT */
> u32 flags;
> @@ -206,6 +205,7 @@ struct omap_i2c_dev {
> u16 syscstate;
> u16 westate;
> u16 errata;
> + int dev_lost_count;
> };
>
> static const u8 reg_map_ip_v1[] = {
> @@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
> dev->speed = pdata->clkrate;
> dev->flags = pdata->flags;
> dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
> + dev->get_context_loss_count = pdata->get_context_loss_count;
> dev->dtrev = pdata->rev;
> }
>
> @@ -1151,12 +1152,32 @@ omap_i2c_remove(struct platform_device *pdev)
> }
>
> #ifdef CONFIG_PM_RUNTIME
> +static void omap_i2c_restore(struct omap_i2c_dev *dev)
> +{
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> + /*
> + * Don't write to this register if the IE state is 0 as it can
> + * cause deadlock.
> + */
> + if (dev->iestate)
> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> +
> +}
> static int omap_i2c_runtime_suspend(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
> u16 iv;
>
> + if (_dev->get_context_loss_count)
> + _dev->dev_lost_count = _dev->get_context_loss_count(dev);
> +
> _dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
> if (_dev->dtrev == OMAP_I2C_IP_VERSION_2)
> omap_i2c_write_reg(_dev, OMAP_I2C
Re: [PATCHv8 3/5] OMAP: I2C: Reset support
* Shubhrajyoti [111216 00:25]: > Hi Benoit, > > On Friday 16 December 2011 02:21 PM, Cousson, Benoit wrote: > > Hi Shubhro, > > > > On 12/13/2011 11:55 AM, Shubhrajyoti D wrote: > >> Under some error conditions the i2c driver may do a reset. > >> Adding a reset field and support in the device-specific code to aid > >> error-recovery. > >> > >> Signed-off-by: Shubhrajyoti D > >> --- > >> arch/arm/plat-omap/i2c.c |2 ++ > >> include/linux/i2c-omap.h |1 + > >> 2 files changed, 3 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c > >> index db071bc..6cddde2 100644 > >> --- a/arch/arm/plat-omap/i2c.c > >> +++ b/arch/arm/plat-omap/i2c.c > >> @@ -179,6 +179,8 @@ static inline int omap2_i2c_add_bus(int bus_id) > >>*/ > >> if (cpu_is_omap34xx()) > >> pdata->set_mpu_wkup_lat = > >> omap_pm_set_max_mpu_wakeup_lat_compat; > >> + > >> +pdata->device_reset = omap_device_reset; > > > > We should avoid introducing any new pdata function pointers since we > > are in the process of removing them for DT support. > However if the driver has to do a reset due to some error what is the > recommended way? > Currently we used to access the SYSC directly I am removing the same and > introducing this function pointer. Sounds like this sould be possible to handle with pm_runtime calls from the driver which should end up making the right hwmod calls. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap patches
Hi, Sorry for the delay, I've been on vacation. * Ben Dooks [110802 01:01]: > Hi, should I have been queing these, or is someone else > dealing with the dependencies between the omap arch and > these driver updates? Yes please. The following fix should go in during the -rc cycle: https://patchwork.kernel.org/patch/878772/ And then there's the i2c-omap.c series that you acked that no longer has dependencies to the arch/arm/*omap*/* code. So either I or Kevin will send a pull request for that for the next merge window after some minor updates so it merges cleanly. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: dt: Add device tree support for i2c instance 1 on exynos4 dt machine
* G, Manjunath Kondaiah [110719 09:59]: > On Tue, Jul 19, 2011 at 2:00 AM, Grant Likely > wrote: > > > > No, the i2c bus node should still appear in the SoC .dtsi file. If a > > board doesn't use a particular i2c bus, then the board.dts file can > > add a status = "disabled"; property to the i2c bus node to disable it. > > that's right. I am referring to I2C slave devices. For a given SoC, > two different > boards can have different i2c slave devices with different slave > address. In that case, > it is better to have i2c child/slave nodes in board .dts file. This is OK for now, but from bus/hwmod point of view we need to reset all the unused devices as otherwise PM will never work properly. Disabling each device in the board .dts file will never be done correctly for most boards.. And on each board, probably 2/3 of the devices are unused because of the pin limitations :) So the disabling of unused devices should be done with a late_initcall and controlled by kernel cmdline. We were thinking hwmod.disable=[0|1]. The late_initcall to disable unused device tree devices could also be added later on to device tree core code. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c-omap: Double clear of ARDY status in IRQ handler
* Keerthy [110215 20:53]:
> From: Richard woodruff
>
> This errata occurs when the ARDY interrupt generation is enabled.
> At the begining of every new transaction the ARDY interrupt is cleared.
>
> On continuous i2c transactions where after clearing the ARDY bit from
> I2C_STAT register (clearing the interrupt), the IRQ line is reasserted and the
> I2C_STAT[ARDY] bit set again on 1. In fact, the ARDY status bit is not cleared
> at the write access to I2C_STAT[ARDY] and only the IRQ line is deasserted and
> then reasserted. This is not captured in the usual errata documents.
>
> The workaround is to have a double clear of ARDY status in irq handler.
I'll add this to omap-testing for few days and then if no issue Ben
can merge this.
Regards,
Tony
> Signed-off-by: Richard woodruff
> Signed-off-by: Keerthy
> ---
> drivers/i2c/busses/i2c-omap.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index b605ff3..5b35cf4 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -847,11 +847,15 @@ complete:
> dev_err(dev->dev, "Arbitration lost\n");
> err |= OMAP_I2C_STAT_AL;
> }
> + /*
> + * ProDB0017052: Clear ARDY bit twice
> + */
> if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
> OMAP_I2C_STAT_AL)) {
> omap_i2c_ack_stat(dev, stat &
> (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
> - OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
> + OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
> + OMAP_I2C_STAT_ARDY));
> omap_i2c_complete_cmd(dev, err);
> return IRQ_HANDLED;
> }
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: Make sure i2c bus is free before setting it to idle
* Felipe Balbi [100826 00:34]: > Hi, > > On Thu, Aug 26, 2010 at 09:36:44AM +0200, Nyman Mathias (Nokia-MS/Helsinki) > wrote: > >If the i2c bus receives an interrupt with both BB (bus busy) and > >ARDY (register access ready) statuses set during the tranfer of the last > >message > >the bus was put to idle while still busy. > > > >This caused bus to timeout. > > > >Signed-off-by: Mathias Nyman > > adding linux-i2c and Ben Dooks to Cc list. Ben, can you please take this? The patchwork.kernel.org link is: http://patchwork.kernel.org/patch/133641/ Or let Mathias know if he should repost. Acked-by: Tony Lindgren > >--- > >drivers/i2c/busses/i2c-omap.c |2 ++ > >1 files changed, 2 insertions(+), 0 deletions(-) > > > >diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > >index 824ac1c..3271ce1 100644 > >--- a/drivers/i2c/busses/i2c-omap.c > >+++ b/drivers/i2c/busses/i2c-omap.c > >@@ -602,6 +602,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg > >msgs[], int num) > > > > if (r == 0) > > r = num; > >+ > >+omap_i2c_wait_for_bb(dev); > >out: > > omap_i2c_idle(dev); > > return r; > >-- > >1.5.6.5 > > > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-omap" in > >the body of a message to majord...@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > balbi > > DefectiveByDesign.org > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] i2c-omap patches for 2.6.35 merge window
* Ben Dooks [100511 16:05]: > On Tue, May 11, 2010 at 11:35:01AM -0700, Tony Lindgren wrote: > > Hi all, > > > > Here are the i2c-omap patches that we'd like to get in for 2.6.35. > > > > I believe all of these patches have been posted earlier already > > to the i2c list. They all have been merged into the linux-omap master > > branch for testing. > > > > I've removed some duplicate Cc fields from the commit messages > > for the obvious mailings lists and the people who will be merging > > them. > > > > Anyways, if no comments over the next few days, I'll reply to > > this message with a pull request for Ben. > > I've applied these to for-2635/i2c-omap to get them into -next OK, thanks! > please keep the start of each commit the same, I prefer i2c-omap: OK Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] i2c-omap: add mpu wake up latency constraint in i2c
From: Kalle Jokiniemi
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.
Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.
Updates by Kevin as requested by Tony:
- Remove omap_set_i2c_constraint_func() in favor of conditionally
adding the flag in omap_i2c_add_bus() in order to keep all the OMAP
conditional checking in a single location.
- Update set_mpu_wkup_lat prototypes to match OMAP PM layer so
OMAP PM function can be used directly in pdata.
Cc: Moiz Sonasath
Cc: Jarkko Nikula
Cc: Paul Walmsley
Cc: Nishanth Menon
Signed-off-by: Kalle Jokiniemi
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/i2c.c | 39 +++
drivers/i2c/busses/i2c-omap.c | 24
include/linux/i2c-omap.h |9 +
3 files changed, 56 insertions(+), 16 deletions(-)
create mode 100644 include/linux/i2c-omap.h
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 624e262..f044b59 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,9 +26,12 @@
#include
#include
#include
+#include
+
#include
#include
#include
+#include
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -70,14 +73,14 @@ static struct resource i2c_resources[][2] = {
}, \
}
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
static struct platform_device omap_i2c_devices[] = {
- I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+ I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
#ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+ I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
#endif
#ifdefined(CONFIG_ARCH_OMAP3)
- I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+ I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
#endif
};
@@ -100,10 +103,12 @@ static int __init omap_i2c_nr_ports(void)
static int __init omap_i2c_add_bus(int bus_id)
{
struct platform_device *pdev;
+ struct omap_i2c_bus_platform_data *pd;
struct resource *res;
resource_size_t base, irq;
pdev = &omap_i2c_devices[bus_id - 1];
+ pd = pdev->dev.platform_data;
if (bus_id == 1) {
res = pdev->resource;
if (cpu_class_is_omap1()) {
@@ -123,6 +128,15 @@ static int __init omap_i2c_add_bus(int bus_id)
if (cpu_class_is_omap2())
omap2_i2c_mux_pins(bus_id);
+ /*
+* When waiting for completion of a i2c transfer, we need to
+* set a wake up latency constraint for the MPU. This is to
+* ensure quick enough wakeup from idle, when transfer
+* completes.
+*/
+ if (cpu_is_omap34xx())
+ pd->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat;
+
return platform_device_register(pdev);
}
@@ -146,8 +160,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
- i2c_rate[ints[1] - 1] = ints[2];
- i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
+ i2c_pdata[ints[1] - 1].clkrate = ints[2];
+ i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
return 1;
}
@@ -161,9 +175,9 @@ static int __init omap_register_i2c_bus_cmdline(void)
{
int i, err = 0;
- for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
- if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
- i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
+ for (i = 0; i < ARRAY_SIZE(i2c_pdata); i++)
+ if (i2c_pdata[i].clkrate & OMAP_I2C_CMDLINE_SETUP) {
+ i2c_pdata[i].clkrate &= ~OMAP_I2C_CMDLINE_SETUP;
err = omap_i2c_add_bus(i + 1);
if (err)
goto out;
@@ -197,9 +211,10 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
return err;
}
- if (!i2c_rate[bus_id - 1])
- i2c_rate[bus_id - 1] = clkrate;
- i2c_rate[bus_id - 1] &= ~OMAP_I2C_CMDLINE_SETUP;
+ if (!i2c_
[PATCH 6/6] OMAP3: I2C: Clean up Errata 1p153 handling
From: manjugk manjugk
Clean up existing Errata 1p153 handling to use generic
errata handling mechanism through dev flag.
Signed-off-by: Manjunatha GK
Cc: Nishanth Menon
Cc: Alexander Shishkin
Signed-off-by: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fdba131..7674efb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -168,6 +168,7 @@ enum {
/* Errata definitions */
#define I2C_OMAP_ERRATA_I207 (1 << 0)
+#define I2C_OMAP3_1P153(1 << 1)
struct omap_i2c_dev {
struct device *dev;
@@ -954,7 +955,7 @@ complete:
break;
}
- if ((dev->rev <= OMAP_I2C_REV_ON_3430) &&
+ if ((dev->errata & I2C_OMAP3_1P153) &&
errata_omap3_1p153(dev, &stat, &err))
goto complete;
@@ -1057,6 +1058,9 @@ omap_i2c_probe(struct platform_device *pdev)
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+ if (dev->rev <= OMAP_I2C_REV_ON_3430)
+ dev->errata |= I2C_OMAP3_1P153;
+
if (!(cpu_class_is_omap1() || cpu_is_omap2420())) {
u16 s;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
From: manjugk manjugk
Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.
This patch handles and ignores RDR spurious interrupts.
The below sequence is required in interrupt handler for
handling this errata:
1. If RDR is set to 1, clear RDR
2. Read I2C status register and check for BusBusy bit. If BusBusy
bit is set, skip remaining steps.
3. If BusBusy bit is not set, perform read operation on I2C status
register.
4. If RDR is set, clear the same. Check RDR again and clear if it sets
RDR bit again.
5. Perform I2C Data Read operation N number of times(where N is value
read from the register BUFSTAT-RXSTAT bit fields).
Note:
This errata is not applicable for omap2420 and omap4.
It is applicable for:
1. omap2430
2. omap34xx(including omap3630).
Signed-off-by: Manjunatha GK
Cc: Hema Kalliguddi
Cc: Nishanth Menon
Cc: Aaro Koskinen
Signed-off-by: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 00fd02e..fdba131 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -166,6 +166,8 @@ enum {
#define SYSC_IDLEMODE_SMART0x2
#define SYSC_CLOCKACTIVITY_FCLK0x2
+/* Errata definitions */
+#define I2C_OMAP_ERRATA_I207 (1 << 0)
struct omap_i2c_dev {
struct device *dev;
@@ -199,6 +201,7 @@ struct omap_i2c_dev {
u16 bufstate;
u16 syscstate;
u16 westate;
+ u16 errata;
};
const static u8 reg_map[] = {
@@ -498,6 +501,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ dev->errata = 0;
+
+ if (cpu_is_omap2430() || cpu_is_omap34xx())
+ dev->errata |= I2C_OMAP_ERRATA_I207;
+
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
@@ -695,6 +703,34 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
+{
+ /*
+* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
+* Not applicable for OMAP4.
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then ignore the interrupt and
+* clear the interrupt.
+*/
+ if (stat & OMAP_I2C_STAT_RDR) {
+ /* Step 1: If RDR is set, clear it */
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ /* Step 2: */
+ if (!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_BB)) {
+
+ /* Step 3: */
+ if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_RDR) {
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ dev_dbg(dev->dev, "RDR when bus is busy.\n");
+ }
+
+ }
+ }
+}
+
/* rev1 devices are apparently only on some 15xx */
#ifdef CONFIG_ARCH_OMAP15XX
@@ -834,6 +870,10 @@ complete:
}
if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+ if (dev->errata & I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
if (dev->fifo_size) {
if (stat & OMAP_I2C_STAT_RRDY)
num_bytes = dev->fifo_size;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] omap: i2c: make errata 1.153 workaround a separate function
From: Alexander Shishkin
This is to avoid insanely long lines and levels of indentation.
Signed-off-by: Alexander Shishkin
Cc: Nishant Menon
Signed-off-by: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 43 +++--
1 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 42c0b91..ef73483 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -756,6 +756,27 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
#define omap_i2c_rev1_isr NULL
#endif
+/*
+ * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before writing
+ * data to DATA_REG. Otherwise some data bytes can be lost while transferring
+ * them from the memory to the I2C interface.
+ */
+static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+{
+ while (!(*stat & OMAP_I2C_STAT_XUDF)) {
+ if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
+ *err |= OMAP_I2C_STAT_XUDF;
+ return -ETIMEDOUT;
+ }
+ cpu_relax();
+ *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
@@ -885,25 +906,9 @@ complete:
break;
}
- /*
-* OMAP3430 Errata 1.153: When an XRDY/XDR
-* is hit, wait for XUDF before writing data
-* to DATA_REG. Otherwise some data bytes can
-* be lost while transferring them from the
-* memory to the I2C interface.
-*/
-
- if (dev->rev <= OMAP_I2C_REV_ON_3430) {
- while (!(stat &
OMAP_I2C_STAT_XUDF)) {
- if (stat &
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
-
omap_i2c_ack_stat(dev, stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
- err |=
OMAP_I2C_STAT_XUDF;
- goto complete;
- }
- cpu_relax();
- stat =
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
- }
+ if ((dev->rev <= OMAP_I2C_REV_ON_3430) &&
+ errata_omap3_1p153(dev, &stat, &err))
+ goto complete;
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] omap: i2c: add a timeout to the busy waiting
From: Alexander Shishkin
The errata 1.153 workaround is busy waiting on XUDF bit in interrupt
context, which may lead to kernel hangs. The problem can be reproduced
by running the bus with wrong (too high) speed.
Signed-off-by: Alexander Shishkin
Signed-off-by: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ef73483..00fd02e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,17 +763,25 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
*/
static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
{
- while (!(*stat & OMAP_I2C_STAT_XUDF)) {
+ unsigned long timeout = 1;
+
+ while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
*err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
+
cpu_relax();
*stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
+ if (!timeout) {
+ dev_err(dev->dev, "timeout waiting on XUDF bit\n");
+ return 0;
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] omap: i2c: Add i2c support on omap4 platform
From: Santosh Shilimkar
This patch is rebased version of earlier post to add I2C
driver support to OMAP4 platform. On OMAP4, all
I2C register address offsets are changed from OMAP1/2/3 I2C.
In order to not have #ifdef's at various places in code,
as well as to support multi-OMAP build, an array is created
to hold the register addresses with it's offset.
This patch was submitted, reviewed and acked on mailing list
already. For more details refer below link
http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg02281.html
This updated verion has a depedancy on "Add support for 16-bit registers"
posted on linux-omap. Below is the patch-works link for the same
http://patchwork.kernel.org/patch/72295/
Signed-off-by: Syed Rafiuddin
Signed-off-by: Santosh Shilimkar
Acked-by: Kevin Hilman
Reviewed-by: Paul Walmsley
Cc: Cory Maccarrone
Signed-off-by: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 146 -
1 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 389ac60..46111ff 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -45,29 +45,37 @@
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430 0x3C
+#define OMAP_I2C_REV_ON_4430 0x40
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
-#define OMAP_I2C_REV_REG 0x00
-#define OMAP_I2C_IE_REG0x01
-#define OMAP_I2C_STAT_REG 0x02
-#define OMAP_I2C_IV_REG0x03
/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
-#define OMAP_I2C_WE_REG0x03
-#define OMAP_I2C_SYSS_REG 0x04
-#define OMAP_I2C_BUF_REG 0x05
-#define OMAP_I2C_CNT_REG 0x06
-#define OMAP_I2C_DATA_REG 0x07
-#define OMAP_I2C_SYSC_REG 0x08
-#define OMAP_I2C_CON_REG 0x09
-#define OMAP_I2C_OA_REG0x0a
-#define OMAP_I2C_SA_REG0x0b
-#define OMAP_I2C_PSC_REG 0x0c
-#define OMAP_I2C_SCLL_REG 0x0d
-#define OMAP_I2C_SCLH_REG 0x0e
-#define OMAP_I2C_SYSTEST_REG 0x0f
-#define OMAP_I2C_BUFSTAT_REG 0x10
+enum {
+ OMAP_I2C_REV_REG = 0,
+ OMAP_I2C_IE_REG,
+ OMAP_I2C_STAT_REG,
+ OMAP_I2C_IV_REG,
+ OMAP_I2C_WE_REG,
+ OMAP_I2C_SYSS_REG,
+ OMAP_I2C_BUF_REG,
+ OMAP_I2C_CNT_REG,
+ OMAP_I2C_DATA_REG,
+ OMAP_I2C_SYSC_REG,
+ OMAP_I2C_CON_REG,
+ OMAP_I2C_OA_REG,
+ OMAP_I2C_SA_REG,
+ OMAP_I2C_PSC_REG,
+ OMAP_I2C_SCLL_REG,
+ OMAP_I2C_SCLH_REG,
+ OMAP_I2C_SYSTEST_REG,
+ OMAP_I2C_BUFSTAT_REG,
+ OMAP_I2C_REVNB_LO,
+ OMAP_I2C_REVNB_HI,
+ OMAP_I2C_IRQSTATUS_RAW,
+ OMAP_I2C_IRQENABLE_SET,
+ OMAP_I2C_IRQENABLE_CLR,
+};
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
#define OMAP_I2C_IE_XDR(1 << 14) /* TX Buffer drain int
enable */
@@ -170,6 +178,7 @@ struct omap_i2c_dev {
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
+ u8 *regs;
size_t buf_len;
struct i2c_adapter adapter;
u8 fifo_size; /* use as flag and value
@@ -188,15 +197,64 @@ struct omap_i2c_dev {
u16 westate;
};
+const static u8 reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x00,
+ [OMAP_I2C_IE_REG] = 0x01,
+ [OMAP_I2C_STAT_REG] = 0x02,
+ [OMAP_I2C_IV_REG] = 0x03,
+ [OMAP_I2C_WE_REG] = 0x03,
+ [OMAP_I2C_SYSS_REG] = 0x04,
+ [OMAP_I2C_BUF_REG] = 0x05,
+ [OMAP_I2C_CNT_REG] = 0x06,
+ [OMAP_I2C_DATA_REG] = 0x07,
+ [OMAP_I2C_SYSC_REG] = 0x08,
+ [OMAP_I2C_CON_REG] = 0x09,
+ [OMAP_I2C_OA_REG] = 0x0a,
+ [OMAP_I2C_SA_REG] = 0x0b,
+ [OMAP_I2C_PSC_REG] = 0x0c,
+ [OMAP_I2C_SCLL_REG] = 0x0d,
+ [OMAP_I2C_SCLH_REG] = 0x0e,
+ [OMAP_I2C_SYSTEST_REG] = 0x0f,
+ [OMAP_I2C_BUFSTAT_REG] = 0x10,
+};
+
+const static u8 omap4_reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x04,
+ [OMAP_I2C_IE_REG] = 0x2c,
+ [OMAP_I2C_STAT_REG] = 0x28,
+ [OMAP_I2C_IV_REG] = 0x34,
+ [OMAP_I2C_WE_REG] = 0x34,
+ [OMAP_I2C_SYSS_REG] = 0x90,
+ [OMAP_I2C_BUF_REG] = 0x94,
+ [OMAP_I2C_CNT_REG] = 0x98,
+ [OMAP_I2C_DATA_REG] = 0x9c,
+ [OMAP_I2C_SYSC_REG] = 0x20,
+ [OMAP_I2C_CON_REG] = 0xa4,
+ [OMAP_I2C_OA_REG] = 0xa8,
+ [OMAP_I2C_SA_REG] = 0xac,
+ [OMAP_I2C_PSC_REG] = 0xb0,
+ [OMAP_I2C_SCLL_REG] = 0xb4,
+
[PATCH 0/6] i2c-omap patches for 2.6.35 merge window
Hi all, Here are the i2c-omap patches that we'd like to get in for 2.6.35. I believe all of these patches have been posted earlier already to the i2c list. They all have been merged into the linux-omap master branch for testing. I've removed some duplicate Cc fields from the commit messages for the obvious mailings lists and the people who will be merging them. Anyways, if no comments over the next few days, I'll reply to this message with a pull request for Ben. Regards, Tony --- Alexander Shishkin (2): omap: i2c: make errata 1.153 workaround a separate function omap: i2c: add a timeout to the busy waiting Kalle Jokiniemi (1): i2c-omap: add mpu wake up latency constraint in i2c Santosh Shilimkar (1): omap: i2c: Add i2c support on omap4 platform manjugk manjugk (2): OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt OMAP3: I2C: Clean up Errata 1p153 handling arch/arm/plat-omap/i2c.c | 39 -- drivers/i2c/busses/i2c-omap.c | 265 - include/linux/i2c-omap.h |9 + 3 files changed, 246 insertions(+), 67 deletions(-) create mode 100644 include/linux/i2c-omap.h -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
* Manjunatha GK [100427 07:21]:
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -199,6 +199,7 @@ struct omap_i2c_dev {
> u16 bufstate;
> u16 syscstate;
> u16 westate;
> + boolerrata_i207;
> };
Thanks for updating this.
One more comment though to make this more generic for handling
the other errata for i2c-omap.
Can you please make errata_i207 to be just:
u16 errata;
And then we can use it for handing all the i2c-omap errata.
You also need something like
#define I2C_OMAP_ERRATA_I207(1 << 0)
> const static u8 reg_map[] = {
> @@ -498,6 +499,12 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> /* Take the I2C module out of reset: */
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>
> + dev->errata_i207 = false;
> +
> + if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> + dev->errata_i207 = true;
> + }
> +
> /* Enable interrupts */
> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
Then update this for for the bitmask too
dev->errata = 0;
if (cpu_is_omap2430() || cpu_is_omap34xx())
dev->errata |= I2C_OMAP_ERRATA_I207;
> @@ -695,6 +702,34 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
> }
>
> +static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
> +{
> + /*
> + * I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> + * Not applicable for OMAP4.
> + * Under certain rare conditions, RDR could be set again
> + * when the bus is busy, then ignore the interrupt and
> + * clear the interrupt.
> + */
> + if (stat & OMAP_I2C_STAT_RDR) {
> + /* Step 1: If RDR is set, clear it */
> + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
> +
> + /* Step 2: */
> + if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
Here you should have a space after if (
> + & OMAP_I2C_STAT_BB)) {
> +
> + /* Step 3: */
> + if(omap_i2c_read_reg(dev,OMAP_I2C_STAT_REG)
> + & OMAP_I2C_STAT_RDR) {
> + omap_i2c_ack_stat(dev,OMAP_I2C_STAT_RDR);
> + dev_dbg(dev->dev,"RDR when the bus is busy.\n");
> + }
> +
> + }
> + }
> +}
> +
> /* rev1 devices are apparently only on some 15xx */
> #ifdef CONFIG_ARCH_OMAP15XX
>
> @@ -826,6 +861,10 @@ complete:
> }
> if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> u8 num_bytes = 1;
> +
> + if (dev->errata_i207)
> + i2c_omap_errata_i207(dev, stat);
> +
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_RRDY)
> num_bytes = dev->fifo_size;
> --
And here you would need to test for the bitmask instead.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
* Ben Dooks [100419 17:12]:
> On Mon, Apr 19, 2010 at 12:44:22PM +0530, Manjunatha GK wrote:
> > Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> > and the corresponding interrupt fire, even there is no data in
> > the receive FIFO, or the I2C data transfer is still ongoing.
> > These spurious RDR events must be ignored by the software.
> >
> > This patch handles and ignores RDR spurious interrupts.
> >
> > The below sequence is required in interrupt handler for
> > handling this errata:
> > 1. If RDR is set to 1, clear RDR
> > 2. Read I2C status register and check for BusBusy bit. If BusBusy
> > bit is set, skip remaining steps.
> > 3. If BusBusy bit is not set, perform read operation on I2C status
> > register.
> > 4. If RDR is set, clear the same. Check RDR again and clear if it sets
> > RDR bit again.
> > 5. Perform I2C Data Read operation N number of times(where N is value
> > read from the register BUFSTAT-RXSTAT bit fields).
> >
> > Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
> > It is not applicable for OMAP4.
>
> If people can give me a yes/no before the end of play tomorrow (ie,
> 2300GMT) then I will get this applied to for-linus/i2c and send it
> for -rc.
This should be done as an inline function based on some flags set
during the init instead of testing for some constantly changing
combination of cpu_is_omap() macros.
IMHO, let's not keep piling up hacks.
Regards,
Tony
> > Signed-off-by: Manjunatha GK
> > Cc: linux-i2c@vger.kernel.org
> > Cc: ben-li...@fluff.org
> > Cc: Kalliguddi, Hema
> > Cc: Nishanth Menon
> > Cc: Aaro Koskinen
> >
> > ---
> > drivers/i2c/busses/i2c-omap.c | 28
> > 1 files changed, 28 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index f2019d2..8309eac 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -796,6 +796,34 @@ complete:
> > }
> > if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> > u8 num_bytes = 1;
> > +
> > + /*
> > +* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> > +* Not applicable for OMAP4.
> > +* Under certain rare conditions, RDR could be set again
> > +* when the bus is busy, then ignore the interrupt and
> > +* clear the interrupt.
> > +*/
> > + if ((stat & OMAP_I2C_STAT_RDR) && !cpu_is_omap44xx()) {
> > + /* Step 1: If RDR is set, clear it */
> > + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
> > +
> > + /* Step 2: */
> > + if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_BB)) {
> > + /* Step 3: */
> > + if(omap_i2c_read_reg(dev,
> > + OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_RDR) {
> > + omap_i2c_ack_stat(dev,
> > + OMAP_I2C_STAT_RDR);
> > + dev_err(dev->dev,
> > + "RDR when the bus is busy.\n");
> > + continue;
> > + }
> > +
> > + }
> > + }
> > if (dev->fifo_size) {
> > if (stat & OMAP_I2C_STAT_RRDY)
> > num_bytes = dev->fifo_size;
> > --
> > 1.6.0.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Ben (b...@fluff.org, http://www.fluff.org/)
>
> 'a smiley only costs 4 bytes'
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP3: I2C: Errata ID i207: Clear wrong RDR interrupt
* Manjunatha GK [100413 06:32]:
> Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> and the corresponding interrupt fire, even there is no data in
> the receive FIFO, or the I2C data transfer is still ongoing.
> These spurious RDR events must be ignored by the software.
>
> This patch handles and ignores RDR spurious interrupts.
>
> Patch tested on OMAP zoom3 board.
>
> Signed-off-by: Manjunatha GK
> Cc: linux-o...@vger.kernel.org
> Cc: linux-i2c@vger.kernel.org
> Cc: ben-li...@fluff.org
> Cc: Kalliguddi, Hema
> Cc: Nishanth Menon
> ---
> Review comments for earlier post can be found at:
> https://patchwork.kernel.org/patch/90122/
>
> drivers/i2c/busses/i2c-omap.c | 32 +++-
> 1 files changed, 31 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index ae6f5c1..d4ec886 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -733,10 +733,40 @@ complete:
> }
> if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> u8 num_bytes = 1;
> +
> + /*
> + * I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> + * Not applicable for OMAP4.
> + * Under certain rare conditions, RDR could be set again
> + * when the bus is busy, then ignore the interrupt and
> + * clear the interrupt.
> + */
> + if ((stat & OMAP_I2C_STAT_RDR) && !cpu_is_omap44xx()) {
> + /* Step 1: If RDR is set, clear it */
> + omap_i2c_ack_stat(dev, stat &
> OMAP_I2C_STAT_RDR);
> +
> + /* Step 2: */
> + if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> + & OMAP_I2C_STAT_BB)) {
> + /* Step 3: */
> + while(omap_i2c_read_reg(dev,
> + OMAP_I2C_STAT_REG)
> + & OMAP_I2C_STAT_RDR) {
> + omap_i2c_ack_stat(dev, stat
> + & OMAP_I2C_STAT_RDR);
> + dev_err(dev->dev,
> + "I2C : RDR when the bus is
> busy.\n");
> + continue;
> + }
> +
> + }
> + else
> + return IRQ_HANDLED;
> + }
Please move these hacks into a separate inline function that you initialize
during the init. Then in the function you do it if OMAP_I2C_QUIRK_1234 flag
has been set.
In general, it seems that a lot of TI omap4 patches just do:
if (!cpu_is_omap4430()) {
indent_old_code_even_more
...
} else {
add_hacks_for_omap4
...
}
And sprinkle that all over the place.
This is not a maintainable way of doing things. Please do something
like this instead:
#ifdef CONFIG_ARCH_OMAP4
static inline void omap_i2c_quirk_1234(struct device *dev)
{
/* Do hacks here */
}
#else
static inline void omap_i2c_quirk_1234(struct device *dev)
{
}
#endif
int omap_i2_some_function(struct device *dev)
{
...
if (dev->quirks & OMAP_I2C_QUIRK_1234)
omap_i2c_quirk_1234(dev);
...
}
And then in the driver init just set the quirks you need.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] omap i2c: make errata 1.153 workaround a separate function
* Alexander Shishkin [100316 04:28]: > On Wed, Dec 16, 2009 at 04:02:23 +0200, Alexander Shishkin wrote: > > This is to avoid insanely long lines and levels of indentation. > > These seem to be forgotten. Is there any problem with these I should address? Can you please repost and I'll add those too into omap-testing first? Or maybe point to the right patchwork.kernel.org link. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Kevin Hilman [100311 08:36]: > Tony Lindgren writes: > > > > Anyways, for the future, considering how critical this driver is > > for all omaps.. And considering how badly this driver needs some > > updates done.. > > > > How about we pile up the i2c-omap patches for testing into linux-omap > > branch first, then ask Ben to pull it around -rc6 after we've all > > acked and tested the changes? > > > > Ben does that sound OK to you? > > Here's another one to add to omap-testing then. > > This one has been submitted to linux-i2c a couple times and been in > the OMAP PM branch for a while. OK, let's add that to omap-testing after we're done with the initial fixes. This does not currently apply on top of omap-testing, BTW. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Kevin Hilman [100310 10:01]:
> Tony Lindgren writes:
>
> > * Cory Maccarrone [100109 10:34]:
> >> On Sat, Jan 9, 2010 at 10:33 AM, Tony Lindgren wrote:
> >> >
> >> > Let's plan on adding this into omap-testing branch next week so
> >> > we can make sure things are OK for the other platforms.
> >> >
> >> > Then assuming no issues, let's ask Ben can queue it.
> >> >
> >>
> >> Excellent, thank you!
> >
> > Applied to omap-testing with the following fix. Can you please merge
> > it into your original patch?
>
> Unfortunately, Tony's additional fix did not make it into the version
> that was merged to mainline, which results in a crash during
> probe when using v2.6.34-rc1.
>
> Ben, can you queue the fix below from Tony for -rc2?
The original patch attached again below.
Oops, did I maybe send a wrong patchwork link earlier to the
patch?
Anyways, for the future, considering how critical this driver is
for all omaps.. And considering how badly this driver needs some
updates done..
How about we pile up the i2c-omap patches for testing into linux-omap
branch first, then ask Ben to pull it around -rc6 after we've all
acked and tested the changes?
Ben does that sound OK to you?
Regards,
Tony
>From 07e3b9fc5a37c3d1228ecc6fb2726211bb8d41df Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Tue, 9 Mar 2010 16:53:18 -0800
Subject: [PATCH] i2c-omap: Fix reg_shift init
Otherwise register access won't work during probe
for omap_i2c_unidle.
Signed-off-by: Tony Lindgren
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c7c2375..3d7cf1f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -894,6 +894,12 @@ omap_i2c_probe(struct platform_device *pdev)
dev->idle = 1;
dev->dev = &pdev->dev;
dev->irq = irq->start;
+
+ if (cpu_is_omap7xx())
+ dev->reg_shift = 1;
+ else
+ dev->reg_shift = 2;
+
dev->base = ioremap(mem->start, resource_size(mem));
if (!dev->base) {
r = -ENOMEM;
@@ -925,11 +931,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->b_hw = 1; /* Enable hardware fixes */
}
- if (cpu_is_omap7xx())
- dev->reg_shift = 1;
- else
- dev->reg_shift = 2;
-
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
* Shilimkar, Santosh [100227 21:28]: > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Sunday, February 28, 2010 2:11 AM > > To: Shilimkar, Santosh > > Cc: ben-li...@fluff.org; linux-o...@vger.kernel.org; > > linux-i2c@vger.kernel.org; Syed, Rafiuddin; Cory > > Maccarrone; a...@linux-foundation.org > > Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform > > > > * Shilimkar, Santosh [100226 20:05]: > > > Tony, > > > What we do with patch now? It's more almost 6 months that this patch is > > > floating without merge. > > > > Well first we should test it for all omaps. So let's add it into > > omap-testing for a few days to make sure it does not break anything. > > > > Then let's ask Ben to queue it. > > > Ok with me. I've tried it out and seems to work just fine on 2420. I've applied it for testing into omap-testing (and master) branches now. Would be nice to get an ack from people using 7xx too on this. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
* Shilimkar, Santosh [100226 20:05]: > Tony, > What we do with patch now? It's more almost 6 months that this patch is > floating without merge. Well first we should test it for all omaps. So let's add it into omap-testing for a few days to make sure it does not break anything. Then let's ask Ben to queue it. Regards, Tony > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > > Shilimkar, Santosh > > Sent: Friday, February 26, 2010 10:28 AM > > To: Tony Lindgren > > Cc: ben-li...@fluff.org; linux-o...@vger.kernel.org; > > linux-i2c@vger.kernel.org; Syed, Rafiuddin; Cory > > Maccarrone > > Subject: RE: [PATCH] omap: i2c: Add i2c support on omap4 platform > > > > Tony, > > > -Original Message- > > > From: Tony Lindgren [mailto:t...@atomide.com] > > > Sent: Friday, February 26, 2010 3:17 AM > > > To: Shilimkar, Santosh > > > Cc: ben-li...@fluff.org; linux-o...@vger.kernel.org; > > > linux-i2c@vger.kernel.org; Syed, Rafiuddin; > > Cory > > > Maccarrone > > > Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform > > > > > > * Shilimkar, Santosh [100222 21:58]: > > > > Ben, > > > > Did you happen to look at this ? > > > > > > Santosh, can you please also please clarify which omaps this > > > patch has been tested on? > > > > > This patch is tested on OMAP3430 SDP and OMAP4430 SDP with regular defconfig > > builds and multi-omap build. > > > > > > > > -Original Message- > > > > > From: Shilimkar, Santosh > > > > > Sent: Friday, February 19, 2010 10:03 PM > > > > > To: ben-li...@fluff.org > > > > > Cc: linux-o...@vger.kernel.org; linux-i2c@vger.kernel.org; Shilimkar, > > > > > Santosh; Syed, Rafiuddin; > > > Cory > > > > > Maccarrone > > > > > Subject: [PATCH] omap: i2c: Add i2c support on omap4 platform > > > > > > > > > > This patch is rebased version of earlier post to add I2C > > > > > driver support to OMAP4 platform. On OMAP4, all > > > > > I2C register address offsets are changed from OMAP1/2/3 I2C. > > > > > In order to not have #ifdef's at various places in code, > > > > > as well as to support multi-OMAP build, an array is created > > > > > to hold the register addresses with it's offset. > > > > > > > > > > This patch was submitted, reviewed and acked on mailing list > > > > > already. For more details refer below link > > > > > http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg02281.html > > > > > > > > > > This updated verion has a depedancy on "Add support for 16-bit > > > > > registers" > > > > > posted on linux-omap. Below is the patch-works link for the same > > > > > > > > > > http://patchwork.kernel.org/patch/72295/ > > > > > > > > > > Signed-off-by: Syed Rafiuddin > > > > > Signed-off-by: Santosh Shilimkar > > > > > Acked-by: Kevin Hilman > > > > > Reviewed-by: Paul Walmsley > > > > > Reviewed-by: Tony Lindgren > > > > > Cc: Ben Dooks > > > > > Cc: Cory Maccarrone > > > > > --- > > > > > drivers/i2c/busses/i2c-omap.c | 146 > > > > > - > > > > > 1 files changed, 114 insertions(+), 32 deletions(-) > > > > > > > > > > diff --git a/drivers/i2c/busses/i2c-omap.c > > > > > b/drivers/i2c/busses/i2c-omap.c > > > > > index 9c3ce4d..7c15496 100644 > > > > > --- a/drivers/i2c/busses/i2c-omap.c > > > > > +++ b/drivers/i2c/busses/i2c-omap.c > > > > > @@ -44,29 +44,37 @@ > > > > > /* I2C controller revisions present on specific hardware */ > > > > > #define OMAP_I2C_REV_ON_2430 0x36 > > > > > #define OMAP_I2C_REV_ON_3430 0x3C > > > > > +#define OMAP_I2C_REV_ON_4430 0x40 > > > > > > > > > > /* timeout waiting for the controller to respond */ > > > > > #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) > > > > > > > > > > -#define OMAP_I2C_REV_REG 0x00 > > > > > -#define O
Re: bjdooks' git - current state of i2c-next
* Ben Dooks [100202 18:31]: > Current state of next-i2c branch, which should be the start > of the next merge window pull as long as there are no objections Can you also please merge the 16-bit register support for i2c-omap? The subject is "[v2,I2C-OMAP] Add support for 16-bit registers" It's been tested in linux-omap tree for several weeks. Available in mbox format at: http://patchwork.kernel.org/patch/72295/ Regards, Tony > The following changes since commit 1a45dcfe2525e9432cb4aba461d4994fc2befe42: > Linus Torvalds (1): > Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block > > are available in the git repository at: > > git://git.fluff.org/bjdooks/linux.git next-i2c > > Jean-Hugues Deschenes (3): > i2c-designware: Use local version of readl & writel > i2c-designware: Check component type register > i2c-designware: Allow mixed endianness accesses > > Richard Röjfors (1): > i2c: Add support for Xilinx XPS IIC Bus Interface > > Uwe Kleine-König (1): > i2c/imx: don't add probe function to the driver struct > > Wolfgang Grandegger (3): > i2c-mpc: use __devinit[data] for initialization functions and data > i2c-mpc: add support for the MPC512x processors from Freescale > powerpc: doc/dts-bindings: update doc of FSL I2C bindings > > srinidhi kasagar (1): > i2c: Add support for Ux500/Nomadik I2C controller > > Documentation/powerpc/dts-bindings/fsl/i2c.txt | 30 +- > drivers/i2c/busses/Kconfig | 24 +- > drivers/i2c/busses/Makefile|2 + > drivers/i2c/busses/i2c-designware.c| 116 ++- > drivers/i2c/busses/i2c-imx.c |1 - > drivers/i2c/busses/i2c-mpc.c | 198 +++-- > drivers/i2c/busses/i2c-nomadik.c | 959 > > drivers/i2c/busses/i2c-xiic.c | 823 > include/linux/i2c-xiic.h | 43 ++ > 9 files changed, 2068 insertions(+), 128 deletions(-) > create mode 100644 drivers/i2c/busses/i2c-nomadik.c > create mode 100644 drivers/i2c/busses/i2c-xiic.c > create mode 100644 include/linux/i2c-xiic.h > > -- > Ben (b...@fluff.org, http://www.fluff.org/) > > 'a smiley only costs 4 bytes' > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Cory Maccarrone [100111 17:49]:
> On Mon, Jan 11, 2010 at 5:28 PM, Tony Lindgren wrote:
> >
> > Applied to omap-testing with the following fix. Can you please merge
> > it into your original patch?
> >
>
> Done, I've attached the new patch to here. I've tested it and it
> works perfectly.
Here's my ack for this patch:
Acked-by: Tony Lindgren
>
> - Cory
>
>
> From 7c693afce8ffa3978b4fcecc56cd7d4a9d9d3b75 Mon Sep 17 00:00:00 2001
> From: Cory Maccarrone
> Date: Sat, 5 Dec 2009 22:00:25 -0800
> Subject: [PATCH] [I2C-OMAP] Add support for 16-bit registers
>
> The current i2c-omap driver is set up for 32-bit registers, which
> corresponds to most OMAP devices. However, OMAP730/850 based
> devices use a 16-bit register size.
>
> This change modifies the driver to perform a runtime CPU type check
> to determine the register sizes, and uses a bit shift of either 1
> or 2 bits to compute the proper register sizes for all registers.
>
> Signed-off-by: Cory Maccarrone
> ---
> drivers/i2c/busses/i2c-omap.c | 45 +++-
> 1 files changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 0037e31..9c3ce4d 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -49,24 +49,24 @@
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>
> #define OMAP_I2C_REV_REG 0x00
> -#define OMAP_I2C_IE_REG 0x04
> -#define OMAP_I2C_STAT_REG0x08
> -#define OMAP_I2C_IV_REG 0x0c
> +#define OMAP_I2C_IE_REG 0x01
> +#define OMAP_I2C_STAT_REG0x02
> +#define OMAP_I2C_IV_REG 0x03
> /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
> -#define OMAP_I2C_WE_REG 0x0c
> -#define OMAP_I2C_SYSS_REG0x10
> -#define OMAP_I2C_BUF_REG 0x14
> -#define OMAP_I2C_CNT_REG 0x18
> -#define OMAP_I2C_DATA_REG0x1c
> -#define OMAP_I2C_SYSC_REG0x20
> -#define OMAP_I2C_CON_REG 0x24
> -#define OMAP_I2C_OA_REG 0x28
> -#define OMAP_I2C_SA_REG 0x2c
> -#define OMAP_I2C_PSC_REG 0x30
> -#define OMAP_I2C_SCLL_REG0x34
> -#define OMAP_I2C_SCLH_REG0x38
> -#define OMAP_I2C_SYSTEST_REG 0x3c
> -#define OMAP_I2C_BUFSTAT_REG 0x40
> +#define OMAP_I2C_WE_REG 0x03
> +#define OMAP_I2C_SYSS_REG0x04
> +#define OMAP_I2C_BUF_REG 0x05
> +#define OMAP_I2C_CNT_REG 0x06
> +#define OMAP_I2C_DATA_REG0x07
> +#define OMAP_I2C_SYSC_REG0x08
> +#define OMAP_I2C_CON_REG 0x09
> +#define OMAP_I2C_OA_REG 0x0a
> +#define OMAP_I2C_SA_REG 0x0b
> +#define OMAP_I2C_PSC_REG 0x0c
> +#define OMAP_I2C_SCLL_REG0x0d
> +#define OMAP_I2C_SCLH_REG0x0e
> +#define OMAP_I2C_SYSTEST_REG 0x0f
> +#define OMAP_I2C_BUFSTAT_REG 0x10
>
> /* I2C Interrupt Enable Register (OMAP_I2C_IE): */
> #define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int
> enable */
> @@ -161,6 +161,7 @@ struct omap_i2c_dev {
> struct device *dev;
> void __iomem*base; /* virtual */
> int irq;
> + int reg_shift; /* bit shift for I2C register
> addresses */
> struct clk *iclk; /* Interface clock */
> struct clk *fclk; /* Functional clock */
> struct completion cmd_complete;
> @@ -189,12 +190,12 @@ struct omap_i2c_dev {
> static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
> int reg, u16 val)
> {
> - __raw_writew(val, i2c_dev->base + reg);
> + __raw_writew(val, i2c_dev->base + (reg << i2c_dev->reg_shift));
> }
>
> static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
> {
> - return __raw_readw(i2c_dev->base + reg);
> + return __raw_readw(i2c_dev->base + (reg << i2c_dev->reg_shift));
> }
>
> static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> @@ -893,6 +894,12 @@ omap_i2c_probe(struct platform_device *pdev)
> dev->idle = 1;
> dev->dev = &pdev->dev;
> dev->irq = irq->start;
> +
> + if (cpu_is_omap7xx())
> + dev->reg_shift = 1;
> + else
> + dev->reg_
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Cory Maccarrone [100109 10:34]:
> On Sat, Jan 9, 2010 at 10:33 AM, Tony Lindgren wrote:
> >
> > Let's plan on adding this into omap-testing branch next week so
> > we can make sure things are OK for the other platforms.
> >
> > Then assuming no issues, let's ask Ben can queue it.
> >
>
> Excellent, thank you!
Applied to omap-testing with the following fix. Can you please merge
it into your original patch?
Regards,
Tony
>From 5b640a850de9fb87b9e9e6dd2cfeb7144ada8053 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 11 Jan 2010 17:22:21 -0800
Subject: [PATCH] i2c-omap: Fix reg_shift init
Otherwise register access won't work during probe
for omap_i2c_unidle.
Signed-off-by: Tony Lindgren
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 913abd7..9c3ce4d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -894,6 +894,12 @@ omap_i2c_probe(struct platform_device *pdev)
dev->idle = 1;
dev->dev = &pdev->dev;
dev->irq = irq->start;
+
+ if (cpu_is_omap7xx())
+ dev->reg_shift = 1;
+ else
+ dev->reg_shift = 2;
+
dev->base = ioremap(mem->start, resource_size(mem));
if (!dev->base) {
r = -ENOMEM;
@@ -925,11 +931,6 @@ omap_i2c_probe(struct platform_device *pdev)
dev->b_hw = 1; /* Enable hardware fixes */
}
- if (cpu_is_omap7xx())
- dev->reg_shift = 1;
- else
- dev->reg_shift = 2;
-
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers
* Cory Maccarrone [100109 09:45]: > On Sat, Dec 12, 2009 at 5:54 PM, Cory Maccarrone > wrote: > > The current i2c-omap driver is set up for 32-bit registers, which > > corresponds to most OMAP devices. However, OMAP730/850 based > > devices use a 16-bit register size. > > > > This change modifies the driver to perform a runtime CPU type check > > to determine the register sizes, and uses a bit shift of either 1 > > or 2 bits to compute the proper register sizes for all registers. > > > > Signed-off-by: Cory Maccarrone > > Haven't heard anything recently on this one -- any chance of it > getting in for the next -rc merge window, or is this a change that'll > need to go in for the next release? Without it, I2C doesn't work on > omap7xx devices. Let's plan on adding this into omap-testing branch next week so we can make sure things are OK for the other platforms. Then assuming no issues, let's ask Ben can queue it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] omap i2c: add a timeout to the busy waiting
* Alexander Shishkin [091221 03:30]:
> The errata 1.153 workaround is busy waiting on XUDF bit in interrupt
> context, which may lead to kernel hangs. The problem can be reproduced
> by running the bus with wrong (too high) speed.
>
> Signed-off-by: Alexander Shishkin
> CC: linux-i2c@vger.kernel.org
> CC: linux-o...@vger.kernel.org
> CC: n...@ti.com
Acked-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 2d146ac..7d56a25 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -678,6 +678,8 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
> */
> static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
> {
> + unsigned long timeout = jiffies + msecs_to_jiffies(1);
> +
> while (!(*stat & OMAP_I2C_STAT_XUDF)) {
> if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
> omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
> @@ -685,6 +687,12 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev,
> u16 *stat, int *err)
> *err |= OMAP_I2C_STAT_XUDF;
> return -ETIMEDOUT;
> }
> +
> + if (time_after(jiffies, timeout)) {
> + dev_err(dev->dev, "timeout waiting on XUDF bit\n");
> + return 0;
> + }
> +
> cpu_relax();
> *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> }
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] omap i2c: make errata 1.153 workaround a separate function
* Alexander Shishkin [091221 03:29]:
> This is to avoid insanely long lines and levels of indentation.
>
> Signed-off-by: Alexander Shishkin
> CC: linux-i2c@vger.kernel.org
> CC: linux-o...@vger.kernel.org
> CC: n...@ti.com
Nice, this driver sure could use some clean-up.
Acked-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c | 43 ++--
> 1 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 75bf3ad..2d146ac 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -671,6 +671,27 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
> #define omap_i2c_rev1_isrNULL
> #endif
>
> +/*
> + * OMAP3430 Errata 1.153: When an XRDY/XDR is hit, wait for XUDF before
> writing
> + * data to DATA_REG. Otherwise some data bytes can be lost while transferring
> + * them from the memory to the I2C interface.
> + */
> +static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
> +{
> + while (!(*stat & OMAP_I2C_STAT_XUDF)) {
> + if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
> + omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
> + OMAP_I2C_STAT_XDR));
> + *err |= OMAP_I2C_STAT_XUDF;
> + return -ETIMEDOUT;
> + }
> + cpu_relax();
> + *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> + }
> +
> + return 0;
> +}
> +
> static irqreturn_t
> omap_i2c_isr(int this_irq, void *dev_id)
> {
> @@ -794,25 +815,9 @@ complete:
> break;
> }
>
> - /*
> - * OMAP3430 Errata 1.153: When an XRDY/XDR
> - * is hit, wait for XUDF before writing data
> - * to DATA_REG. Otherwise some data bytes can
> - * be lost while transferring them from the
> - * memory to the I2C interface.
> - */
> -
> - if (dev->rev <= OMAP_I2C_REV_ON_3430) {
> - while (!(stat &
> OMAP_I2C_STAT_XUDF)) {
> - if (stat &
> (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
> -
> omap_i2c_ack_stat(dev, stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
> - err |=
> OMAP_I2C_STAT_XUDF;
> - goto complete;
> - }
> - cpu_relax();
> - stat =
> omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> - }
> - }
> + if ((dev->rev <= OMAP_I2C_REV_ON_3430) &&
> + errata_omap3_1p153(dev, &stat, &err))
> + goto complete;
>
> omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
> }
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [I2C] OMAP: Don't write IE state in unidle if 0
* Cory Maccarrone [091222 17:05]: > Commit ef871432... (i2c-omap: OMAP3: PM: (re)init for every transfer > to support off-mode) introduced a change which make the dev->iestate > contents be written to the OMAP_I2C_IE_REG every time omap_i2c_unidle > is called. Previously, the state was only written if it wasn't equal > to zero. > > In omap_i2c_probe, omap_i2c_unidle() is called prior to omap_i2c_init(), > in which case dev->iestate has not yet been initialized and will be set > to zero. Having this value written to the registers causes deadlock > while booting. > > As such, this change restores the original functionality. Looks like initializing dev->iestate to something before calling omap_i2c_unidle in omap_i2c_probe is not an option in this case. We'd want to initialize it to zero, which causes the deadlock.. Acked-by: Tony Lindgren > > Signed-off-by: Cory Maccarrone > --- > drivers/i2c/busses/i2c-omap.c |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 3440d88..c0bb9eb 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -248,7 +248,13 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev) > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); > } > dev->idle = 0; > - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate); > + > + /* > + * Don't write to this register if the IE state is 0 as it can > + * cause deadlock. > + */ > + if (dev->iestate) > + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate); > } > > static void omap_i2c_idle(struct omap_i2c_dev *dev) > -- > 1.6.3.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c
* Jean Delvare [091217 08:35]: > On Thu, 17 Dec 2009 16:18:24 +0100, kalle.jokini...@nokia.com wrote: > > Hi Jean, > > > > > -Original Message- > > > From: Jokiniemi Kalle (Nokia-D/Tampere) > > > Sent: 11. joulukuuta 2009 12:47 > > > To: 'ext Paul Walmsley'; ben-li...@fluff.org > > > Cc: linux-i2c@vger.kernel.org; linux-o...@vger.kernel.org; > > > Ujfalusi Peter (Nokia-D/Tampere); Hogander Jouni > > > (Nokia-D/Tampere); khil...@deeprootsystems.com; > > > kalle.jokini...@digia.com; m-sonas...@ti.com; > > > jhnik...@gmail.com; n...@ti.com > > > Subject: RE: [PATCH] OMAP: I2C: Add mpu wake up latency > > > constraint in i2c > > > > > > Hi Ben, > > > > > > What's the status on this one? Have you had time to check it out? > > > > > > - Kalle > > > > > > > > > > -Original Message- > > > > From: ext Paul Walmsley [mailto:p...@pwsan.com] > > > > Sent: 30. marraskuuta 2009 9:24 > > > > To: Jokiniemi Kalle (Nokia-D/Tampere) > > > > Cc: ben-li...@fluff.org; linux-i2c@vger.kernel.org; > > > > linux-o...@vger.kernel.org; Ujfalusi Peter > > > (Nokia-D/Tampere); Hogander > > > > Jouni (Nokia-D/Tampere); khil...@deeprootsystems.com; > > > > kalle.jokini...@digia.com; m-sonas...@ti.com; jhnik...@gmail.com; > > > > n...@ti.com > > > > Subject: RE: [PATCH] OMAP: I2C: Add mpu wake up latency > > > constraint in > > > > i2c > > > > > > > > Hi Ben, Kalle, > > > > > > > > On Thu, 26 Nov 2009, kalle.jokini...@nokia.com wrote: > > > > > > > > > Could you take this patch to i2c tree? The patch has been > > > > discussed in linux-omap list, and this version was the one that was > > > > agreed to pushed forward. > > > > > > Ben is bit unresponsive about my patch. Would you Jean be the current > > linux-i2c maintainer? > > Only for the core and PC drivers. Not platform drivers. > > > Could you take my patch in? > > Not really. Either wait for Ben to respond, or push the patch through > the OMAP tree. If this really doesn't work, you might try Andrew Morton. Ack from me too for Ben. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 4/4] OMAP4: PMIC: Update TWL mfd driver to create twl6030 regulators
* Mark Brown [090803 17:23]:
> On Wed, Jul 29, 2009 at 10:06:13AM +0530, balaj...@ti.com wrote:
>
> > - if (twl_has_regulator()) {
> > + if (twl_has_regulator() && is_class_twl4030()) {
>
> is_class_twl4030() feels like it should have better namespacing, though
> having the part name in there means it's not actually an issue.
How about twl_is_4030()?
> > @@ -306,6 +306,7 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
> > num_bytes);
> > #define TWL4030_INT_PWR_EDR2 0x6
> > #define TWL4030_INT_PWR_SIH_CTRL 0x7
> >
> > +
> > /*--*/
> >
> > /* Power bus message definitions */
>
> Random unrelated indentation change?
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c-omap: Fix build breaking typo cpu_is_omap_2430
Hi Ben, Can you please queue this fix? Thanks, Tony >From ffe2b2cdf6283770b70a197e3748c6b40a1006be Mon Sep 17 00:00:00 2001 From: Tony Lindgren Date: Wed, 17 Jun 2009 13:14:23 +0300 Subject: [PATCH] i2c-omap: Fix build breaking typo in cpu_is_omap_2430 Commit 84bf2c86 introduced a typo, it should be cpu_is_omap2430 instead. The typo was probably caused by a mismerge. Without this patch all omaps fail to build with: error: implicit declaration of function 'cpu_is_omap_2430' Signed-off-by: Tony Lindgren diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b606db8..ad8d201 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -339,7 +339,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) * to get longer filter period for better noise suppression. * The filter is iclk (fclk for HS) period. */ - if (dev->speed > 400 || cpu_is_omap_2430()) + if (dev->speed > 400 || cpu_is_omap2430()) internal_clk = 19200; else if (dev->speed > 100) internal_clk = 9600;
Re: [PATCH 2/2] I2C: OMAP3: Better noise suppression for fast/standard modes
* Aaro Koskinen [090527 07:55]:
> Use longer noise filter period for fast and standard mode. Based on an
> earlier patch by Eero Nurkkala.
>
> Signed-off-by: Aaro Koskinen
Ben this should be queued too.
Acked-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c | 14 --
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5d9880c..8c76cea 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -333,8 +333,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>
> if (cpu_is_omap2430() || cpu_is_omap34xx()) {
>
> - /* HSI2C controller internal clk rate should be 19.2 Mhz */
> - internal_clk = 19200;
> + /*
> + * HSI2C controller internal clk rate should be 19.2 Mhz for
> + * HS and for all modes on 2430. On 34xx we can use lower rate
> + * to get longer filter period for better noise suppression.
> + * The filter is iclk (fclk for HS) period.
> + */
> + if (dev->speed > 400 || cpu_is_omap_2430())
> + internal_clk = 19200;
> + else if (dev->speed > 100)
> + internal_clk = 9600;
> + else
> + internal_clk = 4000;
> fclk_rate = clk_get_rate(dev->fclk) / 1000;
>
> /* Compute prescaler divisor */
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] I2C: OMAP2/3: Fix scll/sclh calculations
* Aaro Koskinen [090527 07:55]:
> Fix scll/sclh calculations for HS and fast modes. Currently the driver
> uses equal (roughly) low/high times which will result in too short
> low time.
>
> OMAP3430 TRM gives the following equations:
>
> F/S: tLow = (scll + 7) * internal_clk
>tHigh = (sclh + 5) * internal_clk
> HS: tLow = (scll + 7) * fclk
>tHigh = (sclh + 5) * fclk
>
> Furthermore, the I2C specification sets the following minimum values
> for HS tLow/tHigh for capacitive bus loads 100 pF (maximum speed 3400)
> and 400 pF (maximum speed 1700):
>
> speed tLowtHigh
> 3400160 ns 60 ns
> 1700320 ns 120 ns
>
> and for F/S:
>
> speed tLowtHigh
> 400 1300 ns 600 ns
> 100 4700 ns 4000 ns
>
> By using duty cycles 33/66 (HS, F) and 50/50 (S) we stay above these
> minimum values.
>
> Signed-off-by: Aaro Koskinen
Ben can you please queue this?
Acked-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c | 25 ++---
> 1 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 9919c08..5d9880c 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -343,17 +343,28 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>
> /* If configured for High Speed */
> if (dev->speed > 400) {
> + unsigned long scl;
> +
> /* For first phase of HS mode */
> - fsscll = internal_clk / (400 * 2) - 6;
> - fssclh = internal_clk / (400 * 2) - 6;
> + scl = internal_clk / 400;
> + fsscll = scl - (scl / 3) - 7;
> + fssclh = (scl / 3) - 5;
>
> /* For second phase of HS mode */
> - hsscll = fclk_rate / (dev->speed * 2) - 6;
> - hssclh = fclk_rate / (dev->speed * 2) - 6;
> + scl = fclk_rate / dev->speed;
> + hsscll = scl - (scl / 3) - 7;
> + hssclh = (scl / 3) - 5;
> + } else if (dev->speed > 100) {
> + unsigned long scl;
> +
> + /* Fast mode */
> + scl = internal_clk / dev->speed;
> + fsscll = scl - (scl / 3) - 7;
> + fssclh = (scl / 3) - 5;
> } else {
> - /* To handle F/S modes */
> - fsscll = internal_clk / (dev->speed * 2) - 6;
> - fssclh = internal_clk / (dev->speed * 2) - 6;
> + /* Standard mode */
> + fsscll = internal_clk / (dev->speed * 2) - 7;
> + fssclh = internal_clk / (dev->speed * 2) - 5;
> }
> scll = (hsscll << OMAP_I2C_SCLL_HSSCLL) | fsscll;
> sclh = (hssclh << OMAP_I2C_SCLH_HSSCLH) | fssclh;
> --
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C:Moving Register Defines to Header File
* Jagadeesh Bhaskar Pakaravoor [090514 03:34]: > > IMO, The regs do not need to move to a separate header unless they will > > be used outside of i2c-omap.c. > > > Would it not be cleaner to move them to a separate header file, > especially considering the fact that we have some 19 registers for > OMAP3 I2C and when we redefine them for OMAP4, there would be 38 > (infact 40, including the two new registers) lines of just register > definitions at the top of the file? I agree with Kevin, unless the defines are used in other files there should not be need for having a separate header file. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.29-rc7][take #2][PATCH 2/3] ARM: OMAP: Add command line option for I2C bus speed
* Jarkko Nikula [090310 01:47]:
> This patch adds a new command line option "i2c_bus=bus_id,clkrate" into
> I2C bus registration helper. Purpose of the option is to override the
> default board specific bus speed which is supplied by the
> omap_register_i2c_bus.
>
> The default bus speed is typically set to speed of slowest I2C chip on the
> bus and overriding allow to use some experimental configurations or updated
> chip versions without any kernel modifications.
Thanks for updating this. I've updated my omap-upstream series with your
patches #2 and #3, looks like #1 did not need updating.
Regards,
Tony
> Signed-off-by: Jarkko Nikula
> ---
> Documentation/kernel-parameters.txt |4 ++
> arch/arm/plat-omap/i2c.c| 54 --
> 2 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 54f21a5..d775076 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -830,6 +830,10 @@ and is between 256 and 4096 characters. It is defined in
> the file
> hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
> terminal devices. Valid values: 0..8
>
> + i2c_bus=[HW] Override the default board specific I2C bus speed
> + Format:
> + ,
> +
> i8042.debug [HW] Toggle i8042 debug mode
> i8042.direct[HW] Put keyboard port into non-translated mode
> i8042.dumbkbd [HW] Pretend that controller can only read data from
> diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
> index 3e95954..aa70e43 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -119,6 +119,46 @@ static void __init omap_i2c_mux_pins(int bus)
> omap_cfg_reg(scl);
> }
>
> +static int __init omap_i2c_nr_ports(void)
> +{
> + int ports = 0;
> +
> + if (cpu_class_is_omap1())
> + ports = 1;
> + else if (cpu_is_omap24xx())
> + ports = 2;
> + else if (cpu_is_omap34xx())
> + ports = 3;
> +
> + return ports;
> +}
> +
> +/**
> + * omap_i2c_bus_setup - Process command line options for the I2C bus speed
> + * @str: String of options
> + *
> + * This function allow to override the default I2C bus speed for given I2C
> + * bus with a command line option.
> + *
> + * Format: i2c_bus=bus_id,clkrate (in kHz)
> + *
> + * Returns 1 on success, 0 otherwise.
> + */
> +static int __init omap_i2c_bus_setup(char *str)
> +{
> + int ports;
> + int ints[3];
> +
> + ports = omap_i2c_nr_ports();
> + get_options(str, 3, ints);
> + if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
> + return 0;
> + i2c_rate[ints[1] - 1] = ints[2];
> +
> + return 1;
> +}
> +__setup("i2c_bus=", omap_i2c_bus_setup);
> +
> /**
> * omap_register_i2c_bus - register I2C bus with device descriptors
> * @bus_id: bus id counting from number 1
> @@ -132,19 +172,12 @@ int __init omap_register_i2c_bus(int bus_id, u32
> clkrate,
> struct i2c_board_info const *info,
> unsigned len)
> {
> - int ports, err;
> + int err;
> struct platform_device *pdev;
> struct resource *res;
> resource_size_t base, irq;
>
> - if (cpu_class_is_omap1())
> - ports = 1;
> - else if (cpu_is_omap24xx())
> - ports = 2;
> - else if (cpu_is_omap34xx())
> - ports = 3;
> -
> - BUG_ON(bus_id < 1 || bus_id > ports);
> + BUG_ON(bus_id < 1 || bus_id > omap_i2c_nr_ports());
>
> if (info) {
> err = i2c_register_board_info(bus_id, info, len);
> @@ -153,7 +186,8 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
> }
>
> pdev = &omap_i2c_devices[bus_id - 1];
> - *(u32 *)pdev->dev.platform_data = clkrate;
> + if (i2c_rate[bus_id - 1] == 0)
> + i2c_rate[bus_id - 1] = clkrate;
>
> if (bus_id == 1) {
> res = pdev->resource;
> --
> 1.6.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
* Tony Lindgren [090220 10:53]:
> Hi Ben,
>
> Here's a fix for i2c-omap fix from Eero Nurkkala that would be nice
> to get queued up for mainline.
Resent, I still had the old i2c list in my aliases..
> Regards,
>
> Tony
> From b3849f3074fe50f176e2e4d89be56854f7b02d3b Mon Sep 17 00:00:00 2001
> From: Eero Nurkkala
> Date: Fri, 20 Feb 2009 10:46:17 -0800
> Subject: [PATCH] i2c: i2c-omap: Fix BUFSTAT_REG reading
>
> The number of bytes to be received is read from wrong
> place with all OMAPs with highspeed I2C support,
> which involves a FIFO and BUFSTAT_REG. It is the 6
> bits starting from the bit 8 in the BUFSTAT_REG
> that indicate this amount of bytes to be read.
> Moreover, only the 6 LSB:s are relevant for the
> TXSTAT field.
>
> Signed-off-by: Eero Nurkkala
> Signed-off-by: Tony Lindgren
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index be8ee2c..0c3ed41 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -675,8 +675,9 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (stat & OMAP_I2C_STAT_RRDY)
> num_bytes = dev->fifo_size;
> else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + num_bytes = (omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG)
> + >> 8) & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
> @@ -714,8 +715,9 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (stat & OMAP_I2C_STAT_XRDY)
> num_bytes = dev->fifo_size;
> else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + num_bytes = (omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG))
> + & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP: Add missing wakeup events
* Pakaravoor, Jagadeesh [090202 07:28]: > Hi, > > Is it a necesary bugfix, or should it wait for the next merge window? > > You can line it up for the next merge window. Just for references, I'm assuming that Ben has picked up this for his queue, so not adding it to any of my ustream queues. Acked-by: Tony Lindgren Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New home for i2c-tools (RFC)
* Mike Frysinger [090129 08:48]: > On Thursday 29 January 2009 11:38:46 Tony Lindgren wrote: > > * Wolfram Sang [090129 08:31]: > > > > Sourceforge is fat and slow and their mailing lists are filled up with > > > > > > It is slow at times and even had annoying downtimes. Let's just hope the > > > alternatives won't grow that big ;) > > > > A git tree at kernel.org and a mailing list at vger.kernel.org works > > well. You could have separate branches in the master git tree and > > automatically fetch other people's branches in to that with minor > > scripting. > > but no tracker system. any package that wants to integrate/work with > downstream distros needs a tracker. things get lost on mailing lists. Maybe patchwork + bugzilla could do the job? http://patchwork.kernel.org/ Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New home for i2c-tools (RFC)
* Wolfram Sang [090129 08:31]: > > > Sourceforge is fat and slow and their mailing lists are filled up with > > It is slow at times and even had annoying downtimes. Let's just hope the > alternatives won't grow that big ;) A git tree at kernel.org and a mailing list at vger.kernel.org works well. You could have separate branches in the master git tree and automatically fetch other people's branches in to that with minor scripting. Also there's almost zero spam on the vger lists and no subscription is necessary. Just my 2c worth, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] i2c-omap: convert 'rev1' flag to generic 'rev' u8
* Ben Dooks [081216 14:07]:
> On Tue, Dec 16, 2008 at 09:59:59PM +, Ben Dooks wrote:
> > On Fri, Nov 28, 2008 at 05:34:57PM -0800, Tony Lindgren wrote:
> > > From: Paul Walmsley
> > >
> > > i2c-omap discriminates only between "revision 1" or "greater than
> > > revision 1." A following patch introduces code that must also
> > > discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support
> > > this by storing the full revision data from the I2C_REV register, rather
> > > than just a single bit.
> > >
> > > The revision definitions may need to be extended for other ES levels
> > > that aren't currently available here. rev3.6 is what's present on the
> > > 2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2
> > > here.
> > >
> > > Signed-off-by: Paul Walmsley
> > > Signed-off-by: Tony Lindgren
> > > ---
> > > drivers/i2c/busses/i2c-omap.c | 25 -
> > > 1 files changed, 16 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > > index 40a1e4b..3ac510d 100644
> > > --- a/drivers/i2c/busses/i2c-omap.c
> > > +++ b/drivers/i2c/busses/i2c-omap.c
> > > @@ -38,6 +38,13 @@
> > > #include
> > > #include
> > >
> > > +/* I2C controller revisions */
> > > +#define OMAP_I2C_REV_2 0x20
> > > +
> > > +/* I2C controller revisions present on specific hardware */
> > > +#define OMAP_I2C_REV_ON_2430 0x36
> > > +#define OMAP_I2C_REV_ON_3430 0x3C
> > > +
> > > /* timeout waiting for the controller to respond */
> > > #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> > >
> > > @@ -139,7 +146,7 @@ struct omap_i2c_dev {
> > >* fifo_size==0 implies no fifo
> > >* if set, should be trsh+1
> > >*/
> > > - unsignedrev1:1;
> > > + u8 rev;
> > > unsignedb_hw:1; /* bad h/w fixes */
> > > unsignedidle:1;
> > > u16 iestate;/* Saved interrupt register */
> > > @@ -209,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> > >
> > > dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> > > omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> > > - if (dev->rev1) {
> > > + if (dev->rev < OMAP_I2C_REV_2) {
> > > iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
> > > } else {
> > > omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> > > @@ -231,7 +238,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > unsigned long timeout;
> > > unsigned long internal_clk = 0;
> > >
> > > - if (!dev->rev1) {
> > > + if (dev->rev >= OMAP_I2C_REV_2) {
> > > omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
> > > /* For some reason we need to set the EN bit before the
> > >* reset done bit gets set. */
> > > @@ -710,6 +717,7 @@ omap_i2c_probe(struct platform_device *pdev)
> > > struct omap_i2c_dev *dev;
> > > struct i2c_adapter *adap;
> > > struct resource *mem, *irq, *ioarea;
> > > + void *isr;
> >
> > There is a proper definition for the function type in
> >
>
> I'm feeling a bit of Christmas spirit finally, will pull these and
> add a fix myself for this.
Thanks, I'll owe you a holiday ale for that :)
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any more i2c driver fixes or new drivers to check?
* Ben Dooks [081216 14:12]: > On Tue, Dec 16, 2008 at 01:09:09PM -0800, Tony Lindgren wrote: > > * Ben Dooks [081216 13:58]: > > > Are there any more fixes that anyone would like considering > > > for the current kernel, or new drivers to look at before the > > > next merge window. > > > > > > Any drivers or updates not on this list by 2008-12-19 will be too late > > > for the next merge. > > > > Well there's the i2c-omap.c series for the next merge window, > > but I guess that's already on your merge list? > > done. > > > Maybe post a list of what your're planning to merge so people will > > know if it's going in or not. Or do you have a link to your git-branch > > of the stuff going upstream? > > Already done, my dev machine now has a replacement CPU and memory and > seems to be stable now. Thanks! Tony > > -- > Ben (b...@fluff.org, http://www.fluff.org/) > > 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any more i2c driver fixes or new drivers to check?
* Ben Dooks [081216 13:58]: > Are there any more fixes that anyone would like considering > for the current kernel, or new drivers to look at before the > next merge window. > > Any drivers or updates not on this list by 2008-12-19 will be too late > for the next merge. Well there's the i2c-omap.c series for the next merge window, but I guess that's already on your merge list? Maybe post a list of what your're planning to merge so people will know if it's going in or not. Or do you have a link to your git-branch of the stuff going upstream? Cheers, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-pull request for i2c-omap updates (Re: [PATCH 00/12] Updates for i2c-omap for 2.6.29 merge window, v5)
Ben,
Here's the pull request for you.
Regards,
Tony
The following changes since commit 13d428afc007fcfcd6deeb215618f54cf9c0cae6:
Linus Torvalds (1):
Linux 2.6.28-rc6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
i2c-for-ben
Chandra shekhar (1):
i2c-omap: Add support for omap34xx
Jarkko Nikula (1):
i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
Kalle Jokiniemi (1):
i2c-omap: Enable I2C wakeups for 34xx
Nishanth Menon (1):
i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
Paul Walmsley (6):
i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
i2c-omap: Mark init-only functions as __init
i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
i2c-omap: fix I2C timeouts due to recursive omap_i2c_{un,}idle()
i2c-omap: convert 'rev1' flag to generic 'rev' u8
i2c-omap: reprogram OCP_SYSCONFIG register after reset
Syed Mohammed Khasim (1):
i2c-omap: Add high-speed support to omap-i2c
Tony Lindgren (1):
i2c-omap: Clean-up i2c-omap
arch/arm/mach-omap2/clock24xx.h |4 +-
drivers/i2c/busses/i2c-omap.c | 420 ++-
2 files changed, 330 insertions(+), 94 deletions(-)
[PATCH 12/12] i2c-omap: Enable I2C wakeups for 34xx
From: Kalle Jokiniemi <[EMAIL PROTECTED]> I2C_WE registers were not configured, which caused huge delays in I2C operations while cpu idle was enabled and omap entered WFI. This patch enables all I2C wakeup sources. Signed-off-by: Kalle Jokiniemi <[EMAIL PROTECTED]> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> --- drivers/i2c/busses/i2c-omap.c | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b202354..96f3bed 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -52,6 +52,8 @@ #define OMAP_I2C_IE_REG0x04 #define OMAP_I2C_STAT_REG 0x08 #define OMAP_I2C_IV_REG0x0c +/* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */ +#define OMAP_I2C_WE_REG0x0c #define OMAP_I2C_SYSS_REG 0x10 #define OMAP_I2C_BUF_REG 0x14 #define OMAP_I2C_CNT_REG 0x18 @@ -89,6 +91,24 @@ #define OMAP_I2C_STAT_NACK (1 << 1)/* No ack interrupt enable */ #define OMAP_I2C_STAT_AL (1 << 0)/* Arbitration lost int ena */ +/* I2C WE wakeup enable register */ +#define OMAP_I2C_WE_XDR_WE (1 << 14) /* TX drain wakup */ +#define OMAP_I2C_WE_RDR_WE (1 << 13) /* RX drain wakeup */ +#define OMAP_I2C_WE_AAS_WE (1 << 9)/* Address as slave wakeup*/ +#define OMAP_I2C_WE_BF_WE (1 << 8)/* Bus free wakeup */ +#define OMAP_I2C_WE_STC_WE (1 << 6)/* Start condition wakeup */ +#define OMAP_I2C_WE_GC_WE (1 << 5)/* General call wakeup */ +#define OMAP_I2C_WE_DRDY_WE(1 << 3)/* TX/RX data ready wakeup */ +#define OMAP_I2C_WE_ARDY_WE(1 << 2)/* Reg access ready wakeup */ +#define OMAP_I2C_WE_NACK_WE(1 << 1)/* No acknowledgment wakeup */ +#define OMAP_I2C_WE_AL_WE (1 << 0)/* Arbitration lost wakeup */ + +#define OMAP_I2C_WE_ALL(OMAP_I2C_WE_XDR_WE | OMAP_I2C_WE_RDR_WE | \ + OMAP_I2C_WE_AAS_WE | OMAP_I2C_WE_BF_WE | \ + OMAP_I2C_WE_STC_WE | OMAP_I2C_WE_GC_WE | \ + OMAP_I2C_WE_DRDY_WE | OMAP_I2C_WE_ARDY_WE | \ + OMAP_I2C_WE_NACK_WE | OMAP_I2C_WE_AL_WE) + /* I2C Buffer Configuration Register (OMAP_I2C_BUF): */ #define OMAP_I2C_BUF_RDMA_EN (1 << 15) /* RX DMA channel enable */ #define OMAP_I2C_BUF_RXFIF_CLR (1 << 14) /* RX FIFO Clear */ @@ -279,6 +299,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) __ffs(SYSC_CLOCKACTIVITY_MASK)); omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v); + /* +* Enabling all wakup sources to stop I2C freezing on +* WFI instruction. +* REVISIT: Some wkup sources might not be needed. +*/ + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, + OMAP_I2C_WE_ALL); } } -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] i2c-omap: reprogram OCP_SYSCONFIG register after reset
From: Paul Walmsley <[EMAIL PROTECTED]>
The I2C controller clears its OCP_SYSCONFIG register after an OCP soft reset.
Reprogram OCP_SYSCONFIG for maximum power savings on rev3.6 controllers
and beyond. On 2430, this involves setting the module AUTOIDLE bit.
On 3430, this includes module AUTOIDLE, wakeup enable, slave smart-idle,
and considers only the module functional clock state for idle-ack.
Boot-tested on 2430SDP and 3430SDP.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: Richard Woodruff <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 40 ++--
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3ac510d..b202354 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -123,11 +123,19 @@
#define OMAP_I2C_SYSTEST_SDA_O (1 << 0)/* SDA line drive out */
#endif
-/* I2C System Status register (OMAP_I2C_SYSS): */
-#define OMAP_I2C_SYSS_RDONE(1 << 0)/* Reset Done */
+/* OCP_SYSSTATUS bit definitions */
+#define SYSS_RESETDONE_MASK(1 << 0)
+
+/* OCP_SYSCONFIG bit definitions */
+#define SYSC_CLOCKACTIVITY_MASK(0x3 << 8)
+#define SYSC_SIDLEMODE_MASK(0x3 << 3)
+#define SYSC_ENAWAKEUP_MASK(1 << 2)
+#define SYSC_SOFTRESET_MASK(1 << 1)
+#define SYSC_AUTOIDLE_MASK (1 << 0)
+
+#define SYSC_IDLEMODE_SMART0x2
+#define SYSC_CLOCKACTIVITY_FCLK0x2
-/* I2C System Configuration Register (OMAP_I2C_SYSC): */
-#define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
struct omap_i2c_dev {
struct device *dev;
@@ -239,13 +247,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long internal_clk = 0;
if (dev->rev >= OMAP_I2C_REV_2) {
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, SYSC_SOFTRESET_MASK);
/* For some reason we need to set the EN bit before the
* reset done bit gets set. */
timeout = jiffies + OMAP_I2C_TIMEOUT;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG) &
-OMAP_I2C_SYSS_RDONE)) {
+SYSS_RESETDONE_MASK)) {
if (time_after(jiffies, timeout)) {
dev_warn(dev->dev, "timeout waiting "
"for controller reset\n");
@@ -253,6 +261,26 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
msleep(1);
}
+
+ /* SYSC register is cleared by the reset; rewrite it */
+ if (dev->rev == OMAP_I2C_REV_ON_2430) {
+
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ SYSC_AUTOIDLE_MASK);
+
+ } else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
+ u32 v;
+
+ v = SYSC_AUTOIDLE_MASK;
+ v |= SYSC_ENAWAKEUP_MASK;
+ v |= (SYSC_IDLEMODE_SMART <<
+ __ffs(SYSC_SIDLEMODE_MASK));
+ v |= (SYSC_CLOCKACTIVITY_FCLK <<
+ __ffs(SYSC_CLOCKACTIVITY_MASK));
+
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+
+ }
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] i2c-omap: convert 'rev1' flag to generic 'rev' u8
From: Paul Walmsley <[EMAIL PROTECTED]>
i2c-omap discriminates only between "revision 1" or "greater than
revision 1." A following patch introduces code that must also
discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support
this by storing the full revision data from the I2C_REV register, rather
than just a single bit.
The revision definitions may need to be extended for other ES levels
that aren't currently available here. rev3.6 is what's present on the
2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2
here.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 40a1e4b..3ac510d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,6 +38,13 @@
#include
#include
+/* I2C controller revisions */
+#define OMAP_I2C_REV_2 0x20
+
+/* I2C controller revisions present on specific hardware */
+#define OMAP_I2C_REV_ON_2430 0x36
+#define OMAP_I2C_REV_ON_3430 0x3C
+
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -139,7 +146,7 @@ struct omap_i2c_dev {
* fifo_size==0 implies no fifo
* if set, should be trsh+1
*/
- unsignedrev1:1;
+ u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
@@ -209,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
- if (dev->rev1) {
+ if (dev->rev < OMAP_I2C_REV_2) {
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
@@ -231,7 +238,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
- if (!dev->rev1) {
+ if (dev->rev >= OMAP_I2C_REV_2) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
/* For some reason we need to set the EN bit before the
* reset done bit gets set. */
@@ -710,6 +717,7 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
struct resource *mem, *irq, *ioarea;
+ void *isr;
int r;
u32 speed = 0;
@@ -760,8 +768,7 @@ omap_i2c_probe(struct platform_device *pdev)
omap_i2c_unidle(dev);
- if (cpu_is_omap15xx())
- dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
+ dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
@@ -782,16 +789,16 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- r = request_irq(dev->irq, dev->rev1 ? omap_i2c_rev1_isr : omap_i2c_isr,
- 0, pdev->name, dev);
+ isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
+ r = request_irq(dev->irq, isr, 0, pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
goto err_unuse_clocks;
}
- r = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+
dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n",
-pdev->id, r >> 4, r & 0xf, dev->speed);
+pdev->id, dev->rev >> 4, dev->rev & 0xf, dev->speed);
omap_i2c_idle(dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] i2c-omap: fix I2C timeouts due to recursive omap_i2c_{un, }idle()
From: Paul Walmsley <[EMAIL PROTECTED]>
omap_i2c_unidle() and omap_i2c_idle() are called recursively during
omap_i2c_probe(). This is evidently unexpected and will wipe
out the I2C interrupt enable register the second time that
omap_i2c_idle() is called consecutively. Any I2C transactions
following a probe of a bus with at least one device on it will then
time out.
Fix by moving omap_i2c_idle() further up in omap_i2c_probe(). Ensure
the I2C controller is marked as idle before the probe starts. Also
attempt to catch future reappearances of this bug early in development
by warning in omap_i2c_{un,}idle() when they are called recursively.
Problem reported by David Brownell <[EMAIL PROTECTED]>.
Tested on 3430SDP and 2430SDP.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Richard Woodruff <[EMAIL PROTECTED]>
Acked-by; Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 4aeebad..40a1e4b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -191,6 +191,8 @@ static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
+ WARN_ON(!dev->idle);
+
if (dev->iclk != NULL)
clk_enable(dev->iclk);
clk_enable(dev->fclk);
@@ -203,6 +205,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
+ WARN_ON(dev->idle);
+
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1) {
@@ -740,6 +744,7 @@ omap_i2c_probe(struct platform_device *pdev)
speed = 100;/* Defualt speed */
dev->speed = speed;
+ dev->idle = 1;
dev->dev = &pdev->dev;
dev->irq = irq->start;
dev->base = ioremap(mem->start, mem->end - mem->start + 1);
@@ -788,6 +793,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n",
pdev->id, r >> 4, r & 0xf, dev->speed);
+ omap_i2c_idle(dev);
+
adap = &dev->adapter;
i2c_set_adapdata(adap, dev);
adap->owner = THIS_MODULE;
@@ -804,8 +811,6 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_free_irq;
}
- omap_i2c_idle(dev);
-
return 0;
err_free_irq:
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/12] i2c-omap: Clean-up i2c-omap
Minor sparse, checkpatch and formatting clean-up. Also update copyrights.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 31 ++-
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 195c3d1..4aeebad 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -2,13 +2,16 @@
* TI OMAP I2C master mode driver
*
* Copyright (C) 2003 MontaVista Software, Inc.
- * Copyright (C) 2004 Texas Instruments.
- *
- * Updated to work with multiple I2C interfaces on 24xx by
- * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
* Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2004 - 2007 Texas Instruments.
*
- * Cleaned up by Juha Yrjölä <[EMAIL PROTECTED]>
+ * Originally written by MontaVista Software, Inc.
+ * Additional contributions by:
+ * Tony Lindgren <[EMAIL PROTECTED]>
+ * Imre Deak <[EMAIL PROTECTED]>
+ * Juha Yrjölä <[EMAIL PROTECTED]>
+ * Syed Khasim <[EMAIL PROTECTED]>
+ * Nishant Menon <[EMAIL PROTECTED]>
*
* 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
@@ -33,8 +36,7 @@
#include
#include
#include
-
-#include
+#include
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -204,7 +206,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
if (dev->rev1) {
- iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
+ iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
} else {
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
@@ -321,9 +323,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Enable interrupts */
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
- (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
+ OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
(OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -389,8 +391,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
w |= OMAP_I2C_CON_XA;
if (!(msg->flags & I2C_M_RD))
w |= OMAP_I2C_CON_TRX;
+
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
+
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
@@ -468,7 +472,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
omap_i2c_unidle(dev);
- if ((r = omap_i2c_wait_for_bb(dev)) < 0)
+ r = omap_i2c_wait_for_bb(dev);
+ if (r < 0)
goto out;
for (i = 0; i < num; i++) {
@@ -561,7 +566,7 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
#else
-#define omap_i2c_rev1_isr 0
+#define omap_i2c_rev1_isr NULL
#endif
static irqreturn_t
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
From: Paul Walmsley <[EMAIL PROTECTED]>
Skip compiling OMAP15xx I2C ISR for non-OMAP15xx builds. Saves 400 bytes
of text for most OMAP builds.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 61d2e5a..195c3d1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -503,6 +503,9 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+/* rev1 devices are apparently only on some 15xx */
+#ifdef CONFIG_ARCH_OMAP15XX
+
static irqreturn_t
omap_i2c_rev1_isr(int this_irq, void *dev_id)
{
@@ -557,6 +560,9 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
+#else
+#define omap_i2c_rev1_isr 0
+#endif
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/12] i2c-omap: Mark init-only functions as __init
From: Paul Walmsley <[EMAIL PROTECTED]>
Mark functions called only at init time as __init.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3f7726a..61d2e5a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -154,7 +154,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
return __raw_readw(i2c_dev->base + reg);
}
-static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
+static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
@@ -689,7 +689,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
-static int
+static int __init
omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/12] i2c-omap: Add support for omap34xx
From: Chandra shekhar <[EMAIL PROTECTED]>
Add support for omap34xx
Signed-off-by: chandra shekhar <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9ae4b74..3f7726a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -156,7 +156,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
{
- if (cpu_is_omap16xx() || cpu_is_omap24xx()) {
+ if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
dev->iclk = clk_get(dev->dev, "i2c_ick");
if (IS_ERR(dev->iclk)) {
dev->iclk = NULL;
@@ -266,7 +266,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* HSI2C controller internal clk rate should be 19.2 Mhz */
internal_clk = 19200;
@@ -608,7 +608,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
*dev->buf++ = w;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
*dev->buf++ = w >> 8;
dev->buf_len--;
@@ -646,7 +647,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
w = *dev->buf++;
dev->buf_len--;
/* Data reg from 2430 is 8 bit wide */
- if (!cpu_is_omap2430()) {
+ if (!cpu_is_omap2430() &&
+ !cpu_is_omap34xx()) {
if (dev->buf_len) {
w |= *dev->buf++ << 8;
dev->buf_len--;
@@ -694,7 +696,7 @@ omap_i2c_probe(struct platform_device *pdev)
struct i2c_adapter *adap;
struct resource *mem, *irq, *ioarea;
int r;
- u32 *speed = NULL;
+ u32 speed = 0;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -722,11 +724,11 @@ omap_i2c_probe(struct platform_device *pdev)
}
if (pdev->dev.platform_data != NULL)
- speed = (u32 *) pdev->dev.platform_data;
+ speed = *(u32 *)pdev->dev.platform_data;
else
- *speed = 100; /* Defualt speed */
+ speed = 100;/* Defualt speed */
- dev->speed = *speed;
+ dev->speed = speed;
dev->dev = &pdev->dev;
dev->irq = irq->start;
dev->base = ioremap(mem->start, mem->end - mem->start + 1);
@@ -745,7 +747,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (cpu_is_omap15xx())
dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
- if (cpu_is_omap2430()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
/* Set up the fifo size - Get total size */
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
From: Nishanth Menon <[EMAIL PROTECTED]>
Based on an earlier patch from Nishant Menon:
- Transfers can use FIFO on FIFO capable devices
- Prevents errors for HSI2C if FIFO is not used
- Implemented errenous handling of STT-STP handling on SDP2430
Also merged in is a fix from Jaron Marini to fix occasional i2c
hang if OMAP_I2C_CON_STT remains asserted.
Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
Signed-off-by: Nishanth Menon <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 190 -
1 files changed, 150 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b0aa0f8..9ae4b74 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -55,8 +55,11 @@
#define OMAP_I2C_SCLL_REG 0x34
#define OMAP_I2C_SCLH_REG 0x38
#define OMAP_I2C_SYSTEST_REG 0x3c
+#define OMAP_I2C_BUFSTAT_REG 0x40
/* I2C Interrupt Enable Register (OMAP_I2C_IE): */
+#define OMAP_I2C_IE_XDR(1 << 14) /* TX Buffer drain int
enable */
+#define OMAP_I2C_IE_RDR(1 << 13) /* RX Buffer drain int
enable */
#define OMAP_I2C_IE_XRDY (1 << 4)/* TX data ready int enable */
#define OMAP_I2C_IE_RRDY (1 << 3)/* RX data ready int enable */
#define OMAP_I2C_IE_ARDY (1 << 2)/* Access ready int enable */
@@ -64,7 +67,8 @@
#define OMAP_I2C_IE_AL (1 << 0)/* Arbitration lost int ena */
/* I2C Status Register (OMAP_I2C_STAT): */
-#define OMAP_I2C_STAT_SBD (1 << 15) /* Single byte data */
+#define OMAP_I2C_STAT_XDR (1 << 14) /* TX Buffer draining */
+#define OMAP_I2C_STAT_RDR (1 << 13) /* RX Buffer draining */
#define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */
#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */
#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */
@@ -78,12 +82,14 @@
/* I2C Buffer Configuration Register (OMAP_I2C_BUF): */
#define OMAP_I2C_BUF_RDMA_EN (1 << 15) /* RX DMA channel enable */
+#define OMAP_I2C_BUF_RXFIF_CLR (1 << 14) /* RX FIFO Clear */
#define OMAP_I2C_BUF_XDMA_EN (1 << 7)/* TX DMA channel enable */
+#define OMAP_I2C_BUF_TXFIF_CLR (1 << 6)/* TX FIFO Clear */
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN(1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE(1 << 14) /* Big endian mode */
-#define OMAP_I2C_CON_OPMODE(1 << 12) /* High Speed support */
+#define OMAP_I2C_CON_OPMODE_HS (1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
@@ -127,7 +133,12 @@ struct omap_i2c_dev {
u8 *buf;
size_t buf_len;
struct i2c_adapter adapter;
+ u8 fifo_size; /* use as flag and value
+* fifo_size==0 implies no fifo
+* if set, should be trsh+1
+*/
unsignedrev1:1;
+ unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
};
@@ -297,6 +308,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
+ if (dev->fifo_size)
+ /* Note: setup required fifo size - 1 */
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
+ (dev->fifo_size - 1) << 8 | /* RTRSH */
+ OMAP_I2C_BUF_RXFIF_CLR |
+ (dev->fifo_size - 1) | /* XTRSH */
+ OMAP_I2C_BUF_TXFIF_CLR);
+
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
@@ -304,7 +323,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
(OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL));
+ OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+
[PATCH 03/12] i2c-omap: Add high-speed support to omap-i2c
From: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Omap2430 has additional support for high-speed I2C.
This patch moves I2C speed parameter (from module) to platform data.
Also added basic High Speed support based on I2C bus speed.
This patch is tested for high speed I2C (with TWL4030 Keypad) and works as
expected.
Also change the 2430 i2chs_fck names to use the standard naming.
Cc: Russell King <[EMAIL PROTECTED]>
Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock24xx.h |4 +-
drivers/i2c/busses/i2c-omap.c | 82 +--
2 files changed, 62 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.h b/arch/arm/mach-omap2/clock24xx.h
index 242a19d..e5fc5bf 100644
--- a/arch/arm/mach-omap2/clock24xx.h
+++ b/arch/arm/mach-omap2/clock24xx.h
@@ -2321,7 +2321,7 @@ static struct clk i2c2_fck = {
};
static struct clk i2chs2_fck = {
- .name = "i2chs_fck",
+ .name = "i2c_fck",
.id = 2,
.parent = &func_96m_ck,
.flags = CLOCK_IN_OMAP243X,
@@ -2354,7 +2354,7 @@ static struct clk i2c1_fck = {
};
static struct clk i2chs1_fck = {
- .name = "i2chs_fck",
+ .name = "i2c_fck",
.id = 1,
.parent = &func_96m_ck,
.flags = CLOCK_IN_OMAP243X,
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5ca0e00..b0aa0f8 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -83,6 +83,7 @@
/* I2C Configuration Register (OMAP_I2C_CON): */
#define OMAP_I2C_CON_EN(1 << 15) /* I2C module enable */
#define OMAP_I2C_CON_BE(1 << 14) /* Big endian mode */
+#define OMAP_I2C_CON_OPMODE(1 << 12) /* High Speed support */
#define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
#define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
#define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
@@ -91,6 +92,10 @@
#define OMAP_I2C_CON_STP (1 << 1)/* Stop cond (master only) */
#define OMAP_I2C_CON_STT (1 << 0)/* Start condition (master) */
+/* I2C SCL time value when Master */
+#define OMAP_I2C_SCLL_HSSCLL 8
+#define OMAP_I2C_SCLH_HSSCLH 8
+
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 << 15) /* System test enable */
@@ -109,12 +114,6 @@
/* I2C System Configuration Register (OMAP_I2C_SYSC): */
#define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
-/* REVISIT: Use platform_data instead of module parameters */
-/* Fast Mode = 400 kHz, Standard = 100 kHz */
-static int clock = 100; /* Default: 100 kHz */
-module_param(clock, int, 0);
-MODULE_PARM_DESC(clock, "Set I2C clock in kHz: 400=fast mode (default ==
100)");
-
struct omap_i2c_dev {
struct device *dev;
void __iomem*base; /* virtual */
@@ -123,6 +122,7 @@ struct omap_i2c_dev {
struct clk *fclk; /* Functional clock */
struct completion cmd_complete;
struct resource *ioarea;
+ u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
size_t buf_len;
@@ -208,9 +208,11 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
+ unsigned long internal_clk = 0;
if (!dev->rev1) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
@@ -253,18 +255,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
psc = fclk_rate / 1200;
}
+ if (cpu_is_omap2430()) {
+
+ /* HSI2C controller internal clk rate should be 19.2 Mhz */
+ internal_clk = 19200;
+ fclk_rate = clk_get_rate(dev->fclk) / 1000;
+
+ /* Compute prescaler divisor */
+ psc = fclk_rate / internal_clk;
+ psc = psc - 1;
+
+ /* If configured for High Speed */
+ if (dev->speed > 400) {
+ /* For first phase of HS mode */
+ fsscll = internal_clk / (400 * 2) - 6;
+ fssclh = internal_clk / (400 * 2) - 6;
+
+ /* For second phase of HS mode */
+
[PATCH 02/12] i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
From: Paul Walmsley <[EMAIL PROTECTED]>
omap_i2c_idle() sets an internal flag, "dev->idle", instructing its
ISR to decline interrupts. It sets this flag before it actually masks
the interrupts on the I2C controller. This is problematic, since an
I2C interrupt could arrive after dev->idle is set, but before the
interrupt source is masked. When this happens, Linux disables the I2C
controller's IRQ, causing all future transactions on the bus to fail.
Symptoms, happening on about 7% of boots:
irq 56: nobody cared (try booting with the "irqpoll" option)
Disabling IRQ #56
i2c_omap i2c_omap.1: controller timed out
In omap_i2c_idle(), this patch sets dev->idle only after the interrupt
mask write to the I2C controller has left the ARM write buffer.
That's probably the major offender. For additional prophylaxis, in
omap_i2c_unidle(), the patch clears the dev->idle flag before
interrupts are enabled, rather than afterwards.
The patch has survived twenty-two reboots on the 3430SDP here without
wedging I2C1. Not absolutely dispositive, but promising!
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 17476ec..5ca0e00 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -181,22 +181,26 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
if (dev->iclk != NULL)
clk_enable(dev->iclk);
clk_enable(dev->fclk);
+ dev->idle = 0;
if (dev->iestate)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- dev->idle = 0;
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
{
u16 iv;
- dev->idle = 1;
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
- if (dev->rev1)
+ if (dev->rev1) {
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
*/
- else
+ } else {
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
+
+ /* Flush posted write before the dev->idle store occurs */
+ omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ }
+ dev->idle = 1;
clk_disable(dev->fclk);
if (dev->iclk != NULL)
clk_disable(dev->iclk);
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
From: Jarkko Nikula <[EMAIL PROTECTED]> If there is a signal pending and wait_for_completion_interruptible_timeout terminates with -ERESTARTSYS, we return and disable the i2c clocks in omap_i2c_xfer. If we terminate before sending last i2c message with a stop condition, the bus remains busy and we are not able to send new messages into bus with successive omap_i2c_xfer calls. Therefore a pending signal is not caught here and we return only because of timeout or i2c error. Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]> Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> --- drivers/i2c/busses/i2c-omap.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 608038d..17476ec 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -328,8 +328,12 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, w |= OMAP_I2C_CON_STP; omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w); - r = wait_for_completion_interruptible_timeout(&dev->cmd_complete, - OMAP_I2C_TIMEOUT); + /* +* REVISIT: We should abort the transfer on signals, but the bus goes +* into arbitration and we're currently unable to recover from it. +*/ + r = wait_for_completion_timeout(&dev->cmd_complete, + OMAP_I2C_TIMEOUT); dev->buf_len = 0; if (r < 0) return r; -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/12] Updates for i2c-omap for 2.6.29 merge window, v5
Hi all,
Here are the i2c-omap patches again for next merge window.
Regards,
Tony
---
Chandra shekhar (1):
i2c-omap: Add support for omap34xx
Jarkko Nikula (1):
i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
Kalle Jokiniemi (1):
i2c-omap: Enable I2C wakeups for 34xx
Nishanth Menon (1):
i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
Paul Walmsley (6):
i2c-omap: reprogram OCP_SYSCONFIG register after reset
i2c-omap: convert 'rev1' flag to generic 'rev' u8
i2c-omap: fix I2C timeouts due to recursive omap_i2c_{un,}idle()
i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
i2c-omap: Mark init-only functions as __init
i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
Syed Mohammed Khasim (1):
i2c-omap: Add high-speed support to omap-i2c
Tony Lindgren (1):
i2c-omap: Clean-up i2c-omap
arch/arm/mach-omap2/clock24xx.h |4
drivers/i2c/busses/i2c-omap.c | 420 ++-
2 files changed, 330 insertions(+), 94 deletions(-)
--
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
