diff for duplicates of <87txzeybhu.fsf@ti.com> diff --git a/a/1.txt b/N1/1.txt index 9917820..58dffaa 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -16,12 +16,12 @@ >>>>>> GIC distributor control register has changed between CortexA9 r1pX and >>>>>> r2pX. The Control Register secure banked version is now composed of 2 >>>>>> bits: ->>>>>> bit 0 == Secure Enable ->>>>>> bit 1 == Non-Secure Enable +>>>>>> ? ? ?bit 0 == Secure Enable +>>>>>> ? ? ?bit 1 == Non-Secure Enable >>>>>> The Non-Secure banked register has not changed. >>>>> >>>>> For those without the r1pX TRM handy, please include what this look like ->>>>> before (presumably 1 bit?) The changelog and in-code comments should +>>>>> before (presumably 1 bit?) ?The changelog and in-code comments should >>>>> both be enhanced. >>>>> >>>> You are right. There was only one bit previously which was used for @@ -36,9 +36,9 @@ >>>>> >>> Below is the updated changelog. >> ->> Much better, thanks. But it still took me several reads to fully ->> understand. Maybe it's because the cold I have is stuffing up my head, ->> so it takes me awhile to understand... Anyways, some minor comments to +>> Much better, thanks. ?But it still took me several reads to fully +>> understand. ?Maybe it's because the cold I have is stuffing up my head, +>> so it takes me awhile to understand... ?Anyways, some minor comments to >> help clarify... >> >> Sorry to be so picky about changelogs, but this is a really nasty bug, @@ -69,10 +69,10 @@ >> before r1pX? > I mean r1px, r0px etc. >> ->>> bit 0 == Secure Enable ->>> bit 1 == Non-Secure Enable +>>> ? ? ?bit 0 == Secure Enable +>>> ? ? ?bit 1 == Non-Secure Enable >> ->> And what did this look like for r1pX? Presumably bit0 was non-secure +>> And what did this look like for r1pX? ? ?Presumably bit0 was non-secure >> enable? >> > Yes. Same bit is used. It's banked bit which has secure and non-secure view. @@ -102,7 +102,7 @@ Why will the secure enable bit be set on GP devices? >> > Hmm. > ->> On r2pX, NS enable bit is bit 1. It's not mentioned here, but I'm +>> On r2pX, NS enable bit is bit 1. ?It's not mentioned here, but I'm >> assuming that it's bit 0 on r1pX, right? (I can't seem to find an r1pX >> TRM) >> @@ -111,7 +111,7 @@ Why will the secure enable bit be set on GP devices? >> Since ROM code is r1pX-based, I would assume that it would continue to >> clear bit 0, which is only now the secure enable bit? >> ->> Or, is it the case that ROM code clears all the bits? That should be described. +>> Or, is it the case that ROM code clears all the bits? ?That should be described. >> > ROM code reads the register value and compares it with value == 1 > " If the GIC Distributor Control Register = 1, the @@ -127,20 +127,20 @@ that it doesn't touch anything other than bit 0. >>> Since the GIC distributor gets disabled in a live system, CPU1 will >>> hang because the interrupts stop firing. ->>> 1) Before doing the CPU1 wakeup, CPU0 must disable ->>> the GIC distributor and wait for it to be enabled. +>>> ? ? ?1) Before doing the CPU1 wakeup, CPU0 must disable +>>> ? ? ? ? the GIC distributor and wait for it to be enabled. >> ->> what does 'disable GIC distributor' mean. secure? non-secure? both? +>> what does 'disable GIC distributor' mean. ?secure? non-secure? both? >> > HLOS is a non-secure view so it can disable only non-secure bit. The changelog is not talking about the HLOS, it's talking about the ROM code, which presumably can set/clear both bits. ->>> 2) CPU1 must re-enable the GIC distributor on ->>> it's wakeup path. +>>> ? ? ?2) CPU1 must re-enable the GIC distributor on +>>> ? ? ? ? it's wakeup path. >> ->> Describe why this works. e.g. because it cause ROM code to skip its +>> Describe why this works. ?e.g. because it cause ROM code to skip its >> broken restore path. >> > ROM code logic find the control register value 1 because bit 1 is @@ -160,7 +160,3 @@ familiar with this bug read the changelog and try and describe it back to you. Kevin --- -To unsubscribe from this list: send the line "unsubscribe linux-omap" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 3996a4a..4bd614d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,15 +5,10 @@ "ref\04FB39C5A.5080404@ti.com\0" "ref\087mx586pci.fsf@ti.com\0" "ref\0CAMQu2gxKmeEnZr8PHZjuC_PUUzjbn7gDkG5NDKM6h2kuS+aJVQ@mail.gmail.com\0" - "From\0Kevin Hilman <khilman@ti.com>\0" - "Subject\0Re: [PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change\0" + "From\0khilman@ti.com (Kevin Hilman)\0" + "Subject\0[PATCHv5 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change\0" "Date\0Thu, 17 May 2012 10:15:57 -0700\0" - "To\0Shilimkar" - " Santosh <santosh.shilimkar@ti.com>\0" - "Cc\0Tero Kristo <t-kristo@ti.com>" - linux-omap@vger.kernel.org - paul@pwsan.com - " linux-arm-kernel@lists.infradead.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "\"Shilimkar, Santosh\" <santosh.shilimkar@ti.com> writes:\n" @@ -34,12 +29,12 @@ ">>>>>> GIC distributor control register has changed between CortexA9 r1pX and\n" ">>>>>> r2pX. The Control Register secure banked version is now composed of 2\n" ">>>>>> bits:\n" - ">>>>>> \302\240 \302\240 \302\240bit 0 == Secure Enable\n" - ">>>>>> \302\240 \302\240 \302\240bit 1 == Non-Secure Enable\n" + ">>>>>> ? ? ?bit 0 == Secure Enable\n" + ">>>>>> ? ? ?bit 1 == Non-Secure Enable\n" ">>>>>> The Non-Secure banked register has not changed.\n" ">>>>>\n" ">>>>> For those without the r1pX TRM handy, please include what this look like\n" - ">>>>> before (presumably 1 bit?) \302\240The changelog and in-code comments should\n" + ">>>>> before (presumably 1 bit?) ?The changelog and in-code comments should\n" ">>>>> both be enhanced.\n" ">>>>>\n" ">>>> You are right. There was only one bit previously which was used for\n" @@ -54,9 +49,9 @@ ">>>>>\n" ">>> Below is the updated changelog.\n" ">>\n" - ">> Much better, thanks. \302\240But it still took me several reads to fully\n" - ">> understand. \302\240Maybe it's because the cold I have is stuffing up my head,\n" - ">> so it takes me awhile to understand... \302\240Anyways, some minor comments to\n" + ">> Much better, thanks. ?But it still took me several reads to fully\n" + ">> understand. ?Maybe it's because the cold I have is stuffing up my head,\n" + ">> so it takes me awhile to understand... ?Anyways, some minor comments to\n" ">> help clarify...\n" ">>\n" ">> Sorry to be so picky about changelogs, but this is a really nasty bug,\n" @@ -87,10 +82,10 @@ ">> before r1pX?\n" "> I mean r1px, r0px etc.\n" ">>\n" - ">>> \302\240 \302\240 \302\240bit 0 == Secure Enable\n" - ">>> \302\240 \302\240 \302\240bit 1 == Non-Secure Enable\n" + ">>> ? ? ?bit 0 == Secure Enable\n" + ">>> ? ? ?bit 1 == Non-Secure Enable\n" ">>\n" - ">> And what did this look like for r1pX? \302\240 \302\240Presumably bit0 was non-secure\n" + ">> And what did this look like for r1pX? ? ?Presumably bit0 was non-secure\n" ">> enable?\n" ">>\n" "> Yes. Same bit is used. It's banked bit which has secure and non-secure view.\n" @@ -120,7 +115,7 @@ ">>\n" "> Hmm.\n" ">\n" - ">> On r2pX, NS enable bit is bit 1. \302\240It's not mentioned here, but I'm\n" + ">> On r2pX, NS enable bit is bit 1. ?It's not mentioned here, but I'm\n" ">> assuming that it's bit 0 on r1pX, right? (I can't seem to find an r1pX\n" ">> TRM)\n" ">>\n" @@ -129,7 +124,7 @@ ">> Since ROM code is r1pX-based, I would assume that it would continue to\n" ">> clear bit 0, which is only now the secure enable bit?\n" ">>\n" - ">> Or, is it the case that ROM code clears all the bits? \302\240That should be described.\n" + ">> Or, is it the case that ROM code clears all the bits? ?That should be described.\n" ">>\n" "> ROM code reads the register value and compares it with value == 1\n" "> \" If the GIC Distributor Control Register = 1, the\n" @@ -145,20 +140,20 @@ "\n" ">>> Since the GIC distributor gets disabled in a live system, CPU1 will\n" ">>> hang because the interrupts stop firing.\n" - ">>> \302\240 \302\240 \302\2401) Before doing the CPU1 wakeup, CPU0 must disable\n" - ">>> \302\240 \302\240 \302\240 \302\240 the GIC distributor and wait for it to be enabled.\n" + ">>> ? ? ?1) Before doing the CPU1 wakeup, CPU0 must disable\n" + ">>> ? ? ? ? the GIC distributor and wait for it to be enabled.\n" ">>\n" - ">> what does 'disable GIC distributor' mean. \302\240secure? non-secure? both?\n" + ">> what does 'disable GIC distributor' mean. ?secure? non-secure? both?\n" ">>\n" "> HLOS is a non-secure view so it can disable only non-secure bit.\n" "\n" "The changelog is not talking about the HLOS, it's talking about the ROM\n" "code, which presumably can set/clear both bits.\n" "\n" - ">>> \302\240 \302\240 \302\2402) CPU1 must re-enable the GIC distributor on\n" - ">>> \302\240 \302\240 \302\240 \302\240 it's wakeup path.\n" + ">>> ? ? ?2) CPU1 must re-enable the GIC distributor on\n" + ">>> ? ? ? ? it's wakeup path.\n" ">>\n" - ">> Describe why this works. \302\240e.g. because it cause ROM code to skip its\n" + ">> Describe why this works. ?e.g. because it cause ROM code to skip its\n" ">> broken restore path.\n" ">>\n" "> ROM code logic find the control register value 1 because bit 1 is\n" @@ -177,10 +172,6 @@ "familiar with this bug read the changelog and try and describe it back\n" "to you.\n" "\n" - "Kevin\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + Kevin -a58f3848d62f10fefcfe89d379d91eb875c6dfe80004f53be4fce8dacc932065 +39040c03b940f0af692208405b9de19a067f651db960c07538e356f0a7939c52
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.