diff for duplicates of <1473940088.10230.65.camel@nexus-software.ie> diff --git a/a/1.txt b/N1/1.txt index 92b94b6..392824d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -23,8 +23,8 @@ On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote: > > > > > > On Thu, Sep 15, 2016 at 10:35:33AM +0100, Bryan O'Donoghue wrote: > > > > -> > > > ? -> > > I don't think the history matters,? +> > > > +> > > I don't think the history matters, > > Your comment seemed to indicate you thought we were reading a > > architectural timer directly - which we aren't. > Sure, and as I pointed out, the comment in the HEAD commit still @@ -54,7 +54,7 @@ not much else that can be done bar custom silicon - this particular timer is as good as it gets, more of a "how do we synchronise time with the hardware we have" than a "lets design in a feature to synchronise time" - which was something we were focusing in on for later -silicon...? +silicon... > > For example, you have absolutely no guarantee as to what backs @@ -85,14 +85,14 @@ greybus with some x86/x86-platform code... > > processor in the system. > > > > > -> > > ?Looking at the +> > > Looking at the > > > state of the tree [1] as of the final commit [2] in the greybus > > > branch, > > > my points still stand: > > > > > > * The "google,greybus-frame-time-counter" node is superfluous. It > > > does -> > > ? not describe a particular device, +> > > not describe a particular device, > > It describes a timer running @ 19.2MHz, clocked by PMIC refclk. > ... which you assume is whatever backs get_cycles(), which you in > practice assume is the architected timer. For which we *already* have @@ -103,7 +103,7 @@ It's a requirement rather than assumption. If you declare that node, it's assumed the timer driving get_cycles() does what it says on the greybus-frame-time-counter tin. -> > > ?and duplicates information we have ? elsewhere. +> > > and duplicates information we have elsewhere. > > Can you give an example ? > Trivially, the CNTFRQ register in the architected timer (which is > common diff --git a/a/content_digest b/N1/content_digest index 1ed0877..afd6e68 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,10 +6,27 @@ "ref\020160915101330.GB6718@leverpostej\0" "ref\01473935756.10230.42.camel@nexus-software.ie\0" "ref\020160915112029.GC6718@leverpostej\0" - "From\0pure.logic@nexus-software.ie (Bryan O'Donoghue)\0" - "Subject\0[GIT PULL] Greybus driver subsystem for 4.9-rc1\0" + "From\0Bryan O'Donoghue <pure.logic@nexus-software.ie>\0" + "Subject\0Re: [GIT PULL] Greybus driver subsystem for 4.9-rc1\0" "Date\0Thu, 15 Sep 2016 12:48:08 +0100\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Mark Rutland <mark.rutland@arm.com>\0" + "Cc\0Greg KH <gregkh@linuxfoundation.org>" + Arnd Bergmann <arnd@arndb.de> + linux-kernel@vger.kernel.org + Johan Hovold <johan@hovoldconsulting.com> + Rui Miguel Silva <rmfrfs@gmail.com> + Laurent Pinchart <laurent.pinchart@ideasonboard.com> + Sandeep Patil <sspatil@google.com> + Matt Porter <mporter@kernel.crashing.org> + John Stultz <john.stultz@linaro.org> + Rob Herring <robh@kernel.org> + Viresh Kumar <viresh.kumar@linaro.org> + Alex Elder <elder@linaro.org> + David Lin <dtwlin@google.com> + Vaibhav Agarwal <vaibhav.agarwal@linaro.org> + Mark Greer <mgreer@animalcreek.com> + marc.zyngier@arm.com + " linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:\n" @@ -37,8 +54,8 @@ "> > > \n" "> > > On Thu, Sep 15, 2016 at 10:35:33AM +0100, Bryan O'Donoghue wrote:\n" "> > > > \n" - "> > > > ?\n" - "> > > I don't think the history matters,?\n" + "> > > > \302\240\n" + "> > > I don't think the history matters,\302\240\n" "> > Your comment seemed to indicate you thought we were reading a\n" "> > architectural timer directly - which we aren't.\n" "> Sure, and as I pointed out, the comment in the HEAD commit still\n" @@ -68,7 +85,7 @@ "timer is as good as it gets, more of a \"how do we synchronise time with\n" "the hardware we have\" than a \"lets design in a feature to synchronise\n" "time\" - which was something we were focusing in on for later\n" - "silicon...?\n" + "silicon...\302\240\n" "\n" "> \n" "> For example, you have absolutely no guarantee as to what backs\n" @@ -99,14 +116,14 @@ "> > processor in the system.\n" "> > \n" "> > > \n" - "> > > ?Looking at the\n" + "> > > \302\240Looking at the\n" "> > > state of the tree [1] as of the final commit [2] in the greybus\n" "> > > branch,\n" "> > > my points still stand:\n" "> > > \n" "> > > * The \"google,greybus-frame-time-counter\" node is superfluous. It\n" "> > > does\n" - "> > > ? not describe a particular device,\n" + "> > > \302\240 not describe a particular device,\n" "> > It describes a timer running @ 19.2MHz, clocked by PMIC refclk.\n" "> ... which you assume is whatever backs get_cycles(), which you in\n" "> practice assume is the architected timer. For which we *already* have\n" @@ -117,7 +134,7 @@ "it's assumed the timer driving get_cycles() does what it says on the\n" "greybus-frame-time-counter tin.\n" "\n" - "> > > ?and duplicates information we have ? elsewhere.\n" + "> > > \302\240and duplicates information we have \302\240 elsewhere.\n" "> > Can you give an example ?\n" "> Trivially, the CNTFRQ register in the architected timer (which is\n" "> common\n" @@ -153,4 +170,4 @@ "---\n" bod -4dd24315df466d7191b32528a279119baeedea9c4c926a2de979563afcc30028 +e0f4184f8abbaaf659f922e1da1e817f8ffd7fec5f5cbcc389082b4d2d9f1761
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.