diff for duplicates of <1519304304.2982.21.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index 1ee065b..a1fd222 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,28 +1,28 @@ Hi Vineet, -On Wed, 2018-02-21@15:42 -0800, Vineet Gupta wrote: +On Wed, 2018-02-21 at 15:42 -0800, Vineet Gupta wrote: > On 02/21/2018 12:31 PM, Vineet Gupta wrote: > > Hi Eugeniy, > > > > > Starting from ARC HS v3.0 > > -> > ?From the STAR fix, it seem this was fixed in HS 2.1c, so you should be able to? -> > test it on HSDK, which was my next question: where and how did you test this and? -> > verify that it works as we think it does. I tried the patch on HSDK and I still? -> > see the rcu_preempt self-detected stall error splat when running hackbench and? -> > pausing the target with Metaware debugger. Perhaps we need to write a small test? -> > case to check what's going on. Also try that on AXS103 release which is definitely? +> > From the STAR fix, it seem this was fixed in HS 2.1c, so you should be able to +> > test it on HSDK, which was my next question: where and how did you test this and +> > verify that it works as we think it does. I tried the patch on HSDK and I still +> > see the rcu_preempt self-detected stall error splat when running hackbench and +> > pausing the target with Metaware debugger. Perhaps we need to write a small test +> > case to check what's going on. Also try that on AXS103 release which is definitely > > HS 3.0 ! > > So I tried this on both. -> ? - HSDK???(HS 2.1c): Doesn't work -> ? - AXS103 (HS 3.0) : Works +> - HSDK (HS 2.1c): Doesn't work +> - AXS103 (HS 3.0) : Works I checked the HS_3.00a and HS_2.1c documentation - GFRC HALT commands/settings exist only in HS_3.00a. > -> Fortunately we can read (yet another BCR: GFRC_BUILD) and infer whether this is? +> Fortunately we can read (yet another BCR: GFRC_BUILD) and infer whether this is > supported or not. So add that check in mcip_update_gfrc_halt_mask() Ok, I'll add GFRC_BUILD read. @@ -31,18 +31,18 @@ Ok, I'll add GFRC_BUILD read. > > > ARC cores with help of GFRC's CORE register where we set a mask for > > > cores which state we need to rely on. > -> On second thoughts, do we really have to do this per cpu. Just write 0xf once just? +> On second thoughts, do we really have to do this per cpu. Just write 0xf once just > as Alexey did in first iteration. And we will face with same problems like with MCIP debug. Remember what happens when we launch kernel on one CPU on board which has several CPUs. -> In theory this could be called concurrently by multiple cpus and mcip doesn't? +> In theory this could be called concurrently by multiple cpus and mcip doesn't > guarantee any internal serialization/buffering. Granted, current use -case is fine? -> as mcip_setup_per_cpu --> plat_smp_ops.init_per_cpu is serialized by master core,? +case is fine +> as mcip_setup_per_cpu --> plat_smp_ops.init_per_cpu is serialized by master core, > we could run into issue when say cpu hot plug etc -works. So better to wrap this? +works. So better to wrap this > inside the spinlock which we already have. Yep, I was also thinking about adding the spinlock here... @@ -50,4 +50,4 @@ I'll add it in next patch version. > -Vineet -- -?Eugeniy Paltsev + Eugeniy Paltsev diff --git a/a/content_digest b/N1/content_digest index a2d742d..bb570bb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,37 +1,41 @@ "ref\020180221094027.12674-1-Eugeniy.Paltsev@synopsys.com\0" "ref\0a4a20519-e8b0-3522-0528-6de2595635ed@synopsys.com\0" "ref\08c86b9f9-a4b7-1217-7cf3-1d8891292679@synopsys.com\0" - "From\0Eugeniy.Paltsev@synopsys.com (Eugeniy Paltsev)\0" - "Subject\0[PATCH 1/3] ARC: mcip: halt GFRC together with ARC cores\0" + "From\0Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>\0" + "Subject\0Re: [PATCH 1/3] ARC: mcip: halt GFRC together with ARC cores\0" "Date\0Thu, 22 Feb 2018 12:58:25 +0000\0" - "To\0linux-snps-arc@lists.infradead.org\0" + "To\0Eugeniy.Paltsev@synopsys.com <Eugeniy.Paltsev@synopsys.com>" + Vineet Gupta <Vineet.Gupta1@synopsys.com> + " linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org>\0" + "Cc\0linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>" + " Alexey.Brodkin@synopsys.com <Alexey.Brodkin@synopsys.com>\0" "\00:1\0" "b\0" "Hi Vineet,\n" "\n" - "On Wed, 2018-02-21@15:42 -0800, Vineet Gupta wrote:\n" + "On Wed, 2018-02-21 at 15:42 -0800, Vineet Gupta wrote:\n" "> On 02/21/2018 12:31 PM, Vineet Gupta wrote:\n" "> > Hi Eugeniy,\n" "> > \n" "> > > Starting from ARC HS v3.0\n" "> > \n" - "> > ?From the STAR fix, it seem this was fixed in HS 2.1c, so you should be able to?\n" - "> > test it on HSDK, which was my next question: where and how did you test this and?\n" - "> > verify that it works as we think it does. I tried the patch on HSDK and I still?\n" - "> > see the rcu_preempt self-detected stall error splat when running hackbench and?\n" - "> > pausing the target with Metaware debugger. Perhaps we need to write a small test?\n" - "> > case to check what's going on. Also try that on AXS103 release which is definitely?\n" + "> > \302\240From the STAR fix, it seem this was fixed in HS 2.1c, so you should be able to\302\240\n" + "> > test it on HSDK, which was my next question: where and how did you test this and\302\240\n" + "> > verify that it works as we think it does. I tried the patch on HSDK and I still\302\240\n" + "> > see the rcu_preempt self-detected stall error splat when running hackbench and\302\240\n" + "> > pausing the target with Metaware debugger. Perhaps we need to write a small test\302\240\n" + "> > case to check what's going on. Also try that on AXS103 release which is definitely\302\240\n" "> > HS 3.0 !\n" "> \n" "> So I tried this on both.\n" - "> ? - HSDK???(HS 2.1c): Doesn't work\n" - "> ? - AXS103 (HS 3.0) : Works\n" + "> \302\240 - HSDK\302\240\302\240\302\240(HS 2.1c): Doesn't work\n" + "> \302\240 - AXS103 (HS 3.0) : Works\n" "\n" "I checked the HS_3.00a and HS_2.1c documentation - GFRC HALT commands/settings exist\n" "only in HS_3.00a.\n" "\n" "> \n" - "> Fortunately we can read (yet another BCR: GFRC_BUILD) and infer whether this is?\n" + "> Fortunately we can read (yet another BCR: GFRC_BUILD) and infer whether this is\302\240\n" "> supported or not. So add that check in mcip_update_gfrc_halt_mask()\n" "\n" "Ok, I'll add GFRC_BUILD read.\n" @@ -40,18 +44,18 @@ "> > > ARC cores with help of GFRC's CORE register where we set a mask for\n" "> > > cores which state we need to rely on.\n" "> \n" - "> On second thoughts, do we really have to do this per cpu. Just write 0xf once just?\n" + "> On second thoughts, do we really have to do this per cpu. Just write 0xf once just\302\240\n" "> as Alexey did in first iteration.\n" "\n" "And we will face with same problems like with MCIP debug.\n" "Remember what happens when we launch kernel on one CPU on board which has several CPUs.\n" "\n" - "> In theory this could be called concurrently by multiple cpus and mcip doesn't?\n" + "> In theory this could be called concurrently by multiple cpus and mcip doesn't\302\240\n" "> guarantee any internal serialization/buffering. Granted, current use\n" - "case is fine?\n" - "> as mcip_setup_per_cpu --> plat_smp_ops.init_per_cpu is serialized by master core,?\n" + "case is fine\302\240\n" + "> as mcip_setup_per_cpu --> plat_smp_ops.init_per_cpu is serialized by master core,\302\240\n" "> we could run into issue when say cpu hot plug etc\n" - "works. So better to wrap this?\n" + "works. So better to wrap this\302\240\n" "> inside the spinlock which we already have.\n" "\n" "Yep, I was also thinking about adding the spinlock here...\n" @@ -59,6 +63,6 @@ "\n" "> -Vineet\n" "-- \n" - ?Eugeniy Paltsev + "\302\240Eugeniy Paltsev" -ccd249ba1eff8e6bdb343916094737f1c67a357f8fde8c7cd9ea4851b34635df +f5e6fdbba4048483308ee5074a2b60bdac055e226834b07c5b95cb3db9d487a4
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.