diff for duplicates of <4BAB609A.9030407@artecdesign.ee> diff --git a/a/1.txt b/N1/1.txt index 66ab799..7923d25 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -19,3 +19,38 @@ some bits in rx data counter have changed and some bits are old. So to be fully sure, we should wait until the bit has been cleared and then perform another read to be sure that the rest of the bits have been changed as well. See my 2009-03-25 17:08 e-mail for details. + +>From practical standpoint: I have not seen a case where the +second read was not ready. If this delay is adequate for the worst +case propagate time it takes for the bits to change, it is not +needed to read the register more than twice. I determined this +experimentally by reading the register 3 times right after write +and comparing the 2nd and 3rd read when doing different transfers +between PC and ARM. As I have tested it only on 9261, somebody should +either run the same kind of tests on other SoC's as well or figure +out the worst case timings on all of them. +The datasheet describes that some changes are performed in +3 USB clock + 3 master clock periods. If so, then one/some extra reads +could create the master-clock dependant small delay needed to +be sure that everything is ready. + +Actually, this leads to a another problem. We are able to read the +rx fifo count when the bits are changing there. If some data is being +received at the very moment when we read the register, we're in +trouble. When some bits are old and some new, we can get values that +are larger or smaller than the actual value (ie 0111->1000 change). +This is a rare condition, but it might happen. Should this register +be read always twice to check that nothing was unstable during the +first read? + +I would still leave in this extra read because it is known to be +unstable. If it is needed on some SoC's, we could read out the +register value until we get 2 same results to verify that it is +stable. But there is no point of reading the first (known bad) value. + +-- +Anti Sullin +Embedded Software Engineer +Artec Design LLC +Teaduspargi 6/2, 12618, Tallinn, Estonia +http://www.artecdesign.ee diff --git a/a/content_digest b/N1/content_digest index 99493f6..e073676 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,10 +2,18 @@ "ref\020100203143803.528679118@gmail.com\0" "ref\0cd73a99e1003231326r7623bbc0icba163f9b2e0e96e@mail.gmail.com\0" "ref\06681f8e11003250503k20efc864ve6d916ad5a7c67b2@mail.gmail.com\0" - "From\0anti.sullin@artecdesign.ee (Anti Sullin)\0" - "Subject\0[patch v3 2/3] at91_udc HW glitch\0" + "From\0Anti Sullin <anti.sullin@artecdesign.ee>\0" + "Subject\0Re: [patch v3 2/3] at91_udc HW glitch\0" "Date\0Thu, 25 Mar 2010 15:09:46 +0200\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Harro Haan <hrhaan@gmail.com>" + " Andrew Victor <avictor.za@gmail.com>\0" + "Cc\0Ryan Mallon <ryan@bluewatersys.com>" + Remy Bohmer <linux@bohmer.net> + Andrew Victor <linux@maxim.org.za> + David Brownell <dbrownell@users.sourceforge.net> + H Hartley Sweeten <hartleys@visionengravers.com> + linux-arm-kernel@lists.infradead.org + " linux-kernel@vger.kernel.org\0" "\00:1\0" "b\0" "Harro Haan wrote:\n" @@ -28,6 +36,41 @@ "some bits in rx data counter have changed and some bits are old.\n" "So to be fully sure, we should wait until the bit has been cleared\n" "and then perform another read to be sure that the rest of the bits\n" - have been changed as well. See my 2009-03-25 17:08 e-mail for details. + "have been changed as well. See my 2009-03-25 17:08 e-mail for details.\n" + "\n" + ">From practical standpoint: I have not seen a case where the\n" + "second read was not ready. If this delay is adequate for the worst\n" + "case propagate time it takes for the bits to change, it is not\n" + "needed to read the register more than twice. I determined this\n" + "experimentally by reading the register 3 times right after write\n" + "and comparing the 2nd and 3rd read when doing different transfers\n" + "between PC and ARM. As I have tested it only on 9261, somebody should\n" + "either run the same kind of tests on other SoC's as well or figure\n" + "out the worst case timings on all of them.\n" + "The datasheet describes that some changes are performed in\n" + "3 USB clock + 3 master clock periods. If so, then one/some extra reads\n" + "could create the master-clock dependant small delay needed to\n" + "be sure that everything is ready.\n" + "\n" + "Actually, this leads to a another problem. We are able to read the\n" + "rx fifo count when the bits are changing there. If some data is being\n" + "received at the very moment when we read the register, we're in\n" + "trouble. When some bits are old and some new, we can get values that\n" + "are larger or smaller than the actual value (ie 0111->1000 change).\n" + "This is a rare condition, but it might happen. Should this register\n" + "be read always twice to check that nothing was unstable during the\n" + "first read?\n" + "\n" + "I would still leave in this extra read because it is known to be\n" + "unstable. If it is needed on some SoC's, we could read out the\n" + "register value until we get 2 same results to verify that it is\n" + "stable. But there is no point of reading the first (known bad) value.\n" + "\n" + "-- \n" + "Anti Sullin\n" + "Embedded Software Engineer\n" + "Artec Design LLC\n" + "Teaduspargi 6/2, 12618, Tallinn, Estonia\n" + http://www.artecdesign.ee -ed2bb1c49cd14ab0e95e31027114bded8a1dab6e2657ca66c7442373c0f7e533 +833cc4b5d625bfceec1127f15f9a7496655434f4e84453c4e5d81257751e988b
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.