diff for duplicates of <2921453.1266505456809.JavaMail.ngmail@webmail09.arcor-online.net> diff --git a/a/1.txt b/N1/1.txt index 6815847..acce05f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -14,12 +14,12 @@ Hi Joakim: > > - writeccr(i2c, CCR_MEN); > > - udelay(30); > > + int k; -> > + u32 delay_val =3D 1000000 / i2c->real_clk + 1; +> > + u32 delay_val = 1000000 / i2c->real_clk + 1; > > + > > + if (delay_val < 2) -> > + delay_val =3D 2; +> > + delay_val = 2; > > + -> > + for (k =3D 9; k; k--) { +> > + for (k = 9; k; k--) { > > + writeccr(i2c, 0); > > + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN); > > + udelay(delay_val); @@ -27,30 +27,19 @@ Hi Joakim: > > + udelay(delay_val << 1); > > + } > > } ->=20 +> > I am curious, didn't old method work with by just wrapping -> a for(k=3D9; k; k--) around it? How did the wave form look? +> a for(k=9; k; k--) around it? How did the wave form look? -Sure does that work! The waveform was somewhat "streched", mainly due to t= -he delays between some of the writeccr() calls which don't change the sda/s= -cl lines. Unfortunately I didn't take shots from the scope. +Sure does that work! The waveform was somewhat "streched", mainly due to the delays between some of the writeccr() calls which don't change the sda/scl lines. Unfortunately I didn't take shots from the scope. -However, for *one* cycle, the old code needed (only counting the udelay's) = -150 us. For 9 cycles, it's 1.35 ms, which isn't really nice ;-). At 375 k= -Hz real clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us= - for the whole fixup procedure. If the clock is slower, the gain is of cou= -rse a lot smaller, and at 20.5 kHz each cycle again needs 150 us... +However, for *one* cycle, the old code needed (only counting the udelay's) 150 us. For 9 cycles, it's 1.35 ms, which isn't really nice ;-). At 375 kHz real clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us for the whole fixup procedure. If the clock is slower, the gain is of course a lot smaller, and at 20.5 kHz each cycle again needs 150 us... -My feeling is that the delays used in the old code are just "some" values w= -hich work for sure, to if you like, my change is basically optimisation... +My feeling is that the delays used in the old code are just "some" values which work for sure, to if you like, my change is basically optimisation... -BTW, related to your earlier question, I checked the timings recorded with = -the scope at 100 and at 20 kHz against the nxp's "I2C bus specification and= - user manual", rev. 03 - everything seems to be fine. +BTW, related to your earlier question, I checked the timings recorded with the scope at 100 and at 20 kHz against the nxp's "I2C bus specification and user manual", rev. 03 - everything seems to be fine. Thanks, Albrecht. -Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns f= -=FCr Sie: der neue Arcor.de-Newsletter! -Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.news= -letter +Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns für Sie: der neue Arcor.de-Newsletter! +Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.newsletter diff --git a/a/content_digest b/N1/content_digest index b163a3a..3934ce7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,11 +1,11 @@ - "From\0Albrecht Dre\303\237 <albrecht.dress@arcor.de>\0" + "From\0Albrecht Dre\303\237 <albrecht.dress-KvP5wT2u2U0@public.gmane.org>\0" "Subject\0Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery\0" "Date\0Thu, 18 Feb 2010 16:04:16 +0100 (CET)\0" - "To\0joakim.tjernlund@transmode.se\0" - "Cc\0linuxppc-dev@ozlabs.org" - devicetree-discuss@lists.ozlabs.org - ben-linux@fluff.org - " iws@ovro.caltech.edu\0" + "To\0joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org\0" + "Cc\0linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org" + devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org + ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org + " iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org\0" "\00:1\0" "b\0" "Hi Joakim:\n" @@ -24,12 +24,12 @@ "> > - writeccr(i2c, CCR_MEN);\n" "> > - udelay(30);\n" "> > + int k;\n" - "> > + u32 delay_val =3D 1000000 / i2c->real_clk + 1;\n" + "> > + u32 delay_val = 1000000 / i2c->real_clk + 1;\n" "> > +\n" "> > + if (delay_val < 2)\n" - "> > + delay_val =3D 2;\n" + "> > + delay_val = 2;\n" "> > +\n" - "> > + for (k =3D 9; k; k--) {\n" + "> > + for (k = 9; k; k--) {\n" "> > + writeccr(i2c, 0);\n" "> > + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);\n" "> > + udelay(delay_val);\n" @@ -37,32 +37,21 @@ "> > + udelay(delay_val << 1);\n" "> > + }\n" "> > }\n" - ">=20\n" + "> \n" "> I am curious, didn't old method work with by just wrapping\n" - "> a for(k=3D9; k; k--) around it? How did the wave form look?\n" + "> a for(k=9; k; k--) around it? How did the wave form look?\n" "\n" - "Sure does that work! The waveform was somewhat \"streched\", mainly due to t=\n" - "he delays between some of the writeccr() calls which don't change the sda/s=\n" - "cl lines. Unfortunately I didn't take shots from the scope.\n" + "Sure does that work! The waveform was somewhat \"streched\", mainly due to the delays between some of the writeccr() calls which don't change the sda/scl lines. Unfortunately I didn't take shots from the scope.\n" "\n" - "However, for *one* cycle, the old code needed (only counting the udelay's) =\n" - "150 us. For 9 cycles, it's 1.35 ms, which isn't really nice ;-). At 375 k=\n" - "Hz real clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us=\n" - " for the whole fixup procedure. If the clock is slower, the gain is of cou=\n" - "rse a lot smaller, and at 20.5 kHz each cycle again needs 150 us...\n" + "However, for *one* cycle, the old code needed (only counting the udelay's) 150 us. For 9 cycles, it's 1.35 ms, which isn't really nice ;-). At 375 kHz real clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us for the whole fixup procedure. If the clock is slower, the gain is of course a lot smaller, and at 20.5 kHz each cycle again needs 150 us...\n" "\n" - "My feeling is that the delays used in the old code are just \"some\" values w=\n" - "hich work for sure, to if you like, my change is basically optimisation...\n" + "My feeling is that the delays used in the old code are just \"some\" values which work for sure, to if you like, my change is basically optimisation...\n" "\n" - "BTW, related to your earlier question, I checked the timings recorded with =\n" - "the scope at 100 and at 20 kHz against the nxp's \"I2C bus specification and=\n" - " user manual\", rev. 03 - everything seems to be fine.\n" + "BTW, related to your earlier question, I checked the timings recorded with the scope at 100 and at 20 kHz against the nxp's \"I2C bus specification and user manual\", rev. 03 - everything seems to be fine.\n" "\n" "Thanks, Albrecht.\n" "\n" - "Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns f=\n" - "=FCr Sie: der neue Arcor.de-Newsletter!\n" - "Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.news=\n" - letter + "Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns f\303\274r Sie: der neue Arcor.de-Newsletter!\n" + Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.newsletter -39ea5702478b6e02f916c1dc880fc1ebfba15f664c7ce2045f43eec8b0f081f4 +41c88818c599e6e7a599d55d0f8c709db8a1b4c711a9cef9e519d05bbae7cf8c
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.