diff for duplicates of <BANLkTimY1cxqaPG1T=_xKPustXR1GSmUKQ@mail.gmail.com>
diff --git a/a/content_digest b/N1/content_digest
index d917835..16ddde8 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -14,10 +14,17 @@
"Subject\0Re: [PATCH 0/4] Add a generic struct clk\0"
]
[
- "Date\0Tue, 24 May 2011 17:52:53 +0000\0"
+ "Date\0Tue, 24 May 2011 10:52:53 -0700\0"
]
[
- "To\0linux-arm-kernel\@lists.infradead.org\0"
+ "To\0Richard Zhao <linuxzsc\@gmail.com>\0"
+]
+[
+ "Cc\0Jeremy Kerr <jeremy.kerr\@canonical.com>",
+ " Thomas Gleixner <tglx\@linutronix.de>",
+ " lkml <linux-kernel\@vger.kernel.org>",
+ " linux-arm-kernel\@lists.infradead.org <linux-arm-kernel\@lists.infradead.org>",
+ " linux-sh\@vger.kernel.org\0"
]
[
"\0000:1\0"
@@ -201,4 +208,4 @@
">"
]
-56d0a297d858aa5f382c8c0ae897587af1aee873de7d4bed88244f1f8e33f785
+acce2268a871b7ffd6d2bacc58d760356238b2211d96f4aa6c956e3a9b5afc16
diff --git a/a/1.txt b/N2/1.txt
index e12717b..1ed8bdc 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -33,37 +33,37 @@ On Tue, May 24, 2011 at 10:22 AM, Richard Zhao <linuxzsc@gmail.com> wrote:
>> > hardware clocks.
>> >
>> > Many thanks to the following for their input:
->> > * Benjamin Herrenschmidt <benh@kernel.crashing.org>
->> > * Thomas Gleixner <tglx@linutronix.de>
->> > * Ben Dooks <ben-linux@fluff.org>
->> > * Baruch Siach <baruch@tkos.co.il>
->> > * Russell King <linux@arm.linux.org.uk>
->> > * Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
->> > * Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
->> > * Vincent Guittot <vincent.guittot@linaro.org>
->> > * Sascha Hauer <s.hauer@pengutronix.de>
->> > * Ryan Mallon <ryan@bluewatersys.com>
->> > * Colin Cross <ccross@google.com>
->> > * Jassi Brar <jassisinghbrar@gmail.com>
->> > * Saravana Kannan <skannan@codeaurora.org>
+>> > ?* Benjamin Herrenschmidt <benh@kernel.crashing.org>
+>> > ?* Thomas Gleixner <tglx@linutronix.de>
+>> > ?* Ben Dooks <ben-linux@fluff.org>
+>> > ?* Baruch Siach <baruch@tkos.co.il>
+>> > ?* Russell King <linux@arm.linux.org.uk>
+>> > ?* Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
+>> > ?* Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
+>> > ?* Vincent Guittot <vincent.guittot@linaro.org>
+>> > ?* Sascha Hauer <s.hauer@pengutronix.de>
+>> > ?* Ryan Mallon <ryan@bluewatersys.com>
+>> > ?* Colin Cross <ccross@google.com>
+>> > ?* Jassi Brar <jassisinghbrar@gmail.com>
+>> > ?* Saravana Kannan <skannan@codeaurora.org>
>>
>> I have a similar set of patches I was working on that handles a little
->> more of the common code than these. I can post them if you want, but
+>> more of the common code than these. ?I can post them if you want, but
>> for now I'll just point out where I had different ideas, and not muddy
>> the waters with conflicting patches.
>>
>> > TODO:
>> >
->> > * Need to figure out the locking around clk_set_parent. Changing the in-kernel
->> > clock topology requires acquiring both the mutex (to prevent against races
->> > with clk_prepare, which may propagate to the parent clock) and the spinlock
->> > (to prevent the same race with clk_enable).
+>> > ?* Need to figure out the locking around clk_set_parent. Changing the in-kernel
+>> > ? clock topology requires acquiring both the mutex (to prevent against races
+>> > ? with clk_prepare, which may propagate to the parent clock) and the spinlock
+>> > ? (to prevent the same race with clk_enable).
>> >
->> > However, we should also be changing the hardware clock topology in sync with
->> > the in-kernel clock topology, which would imply that both locks *also* need
->> > to be held while updating the parent in the hardware (ie, in
->> > clk_hw_ops->set_parent) too. However, I believe some platform clock
->> > implementations may require this callback to be able to sleep. Comments?
+>> > ? However, we should also be changing the hardware clock topology in sync with
+>> > ? the in-kernel clock topology, which would imply that both locks *also* need
+>> > ? to be held while updating the parent in the hardware (ie, in
+>> > ? clk_hw_ops->set_parent) too. ?However, I believe some platform clock
+>> > ? implementations may require this callback to be able to sleep. Comments?
>>
>> This sequence is the best I could come up with without adding a
>> temporary 2nd parent:
@@ -96,8 +96,8 @@ Yes, propagate rate is needed.
>> The only possible problem I see is that if a clock starts disabled at
>> step 1., and clk_enable is called on it between steps 6 and 7,
>> clk_enable will return having enabled the new parent, but the clock is
->> still running off the old parent. As soon as the clock gets switched
->> to the new parent, the clock will be properly enabled. I don't see
+>> still running off the old parent. ?As soon as the clock gets switched
+>> to the new parent, the clock will be properly enabled. ?I don't see
>> this as a huge problem - calling clk_set_parent on a clock while it is
>> enabled may not even work without causing glitches on some platforms.
> some do be glitch free, especially for cpu clock parents.
@@ -105,35 +105,35 @@ Yes, propagate rate is needed.
>> I guess the only way around it would be to store a temporary
>> "new_parent" pointer between steps 5 and 9, and have
>> clk_enable/disable operate on both the current parent and the new
->> parent. They would also need to refcount the extra enables separately
+>> parent. ?They would also need to refcount the extra enables separately
>> to undo on the old parent.
>>
->> > * tglx and I have been discussing different ways of passing clock information
->> > to the clock hardware implementation. I'm proposing providing a base 'struct
->> > clk_hw', which implementations subclass by wrapping in their own structure
->> > (or one of a set of simple 'library' structures, like clk_hw_mux or
->> > clk_hw_gate). The clk_hw base is passed as the first argument to all
->> > clk_hw_ops callbacks.
->> >
->> > tglx's plan is to create a separate struct clk_hwdata, which contains a
->> > union of base data structures for common clocks: div, mux, gate, etc. The
->> > ops callbacks are passed a clk_hw, plus a clk_hwdata, and most of the base
->> > hwdata fields are handled within the core clock code. This means less
->> > encapsulation of clock implementation logic, but more coverage of
->> > clock basics through the core code.
+>> > ?* tglx and I have been discussing different ways of passing clock information
+>> > ? to the clock hardware implementation. I'm proposing providing a base 'struct
+>> > ? clk_hw', which implementations subclass by wrapping in their own structure
+>> > ? (or one of a set of simple 'library' structures, like clk_hw_mux or
+>> > ? clk_hw_gate). ?The clk_hw base is passed as the first argument to all
+>> > ? clk_hw_ops callbacks.
+>> >
+>> > ? tglx's plan is to create a separate struct clk_hwdata, which contains a
+>> > ? union of base data structures for common clocks: div, mux, gate, etc. The
+>> > ? ops callbacks are passed a clk_hw, plus a clk_hwdata, and most of the base
+>> > ? hwdata fields are handled within the core clock code. This means less
+>> > ? encapsulation of clock implementation logic, but more coverage of
+>> > ? clock basics through the core code.
>>
>> I don't think they should be a union, I think there should be 3
>> separate private datas, and three sets of clock ops, for the three
>> different types of clock blocks: rate changers (dividers and plls),
->> muxes, and gates. These blocks are very often combined - a device
+>> muxes, and gates. ?These blocks are very often combined - a device
>> clock often has a mux and a divider, and clk_set_parent and
>> clk_set_rate on the same struct clk both need to work.
>>
->> > tglx, could you send some details about your approach? I'm aiming to refine
->> > this series with the good bits from each technique.
+>> > ? tglx, could you send some details about your approach? I'm aiming to refine
+>> > ? this series with the good bits from each technique.
>> >
->> > * The clock registration code probably needs work. This is the domain
->> > of the platform/board maintainers, any wishes here?
+>> > ?* The clock registration code probably needs work. This is the domain
+>> > ? of the platform/board maintainers, any wishes here?
> When clock init, data in struct clk may not be synced with hw registers. After
> enabled minimal needed clk (cpu, core bus etc), we need sync the whole tree,
> disable zero enable_count clocks, set correct .rate ... . The sync function
@@ -154,20 +154,20 @@ by calling the recalc_rate and get_parent callbacks.
>> >
>> > ---
>> > Jeremy Kerr (4):
->> > clk: Add a generic clock infrastructure
->> > clk: Implement clk_set_rate
->> > clk: Add fixed-rate clock
->> > clk: Add simple gated clock
+>> > ? ? ?clk: Add a generic clock infrastructure
+>> > ? ? ?clk: Implement clk_set_rate
+>> > ? ? ?clk: Add fixed-rate clock
+>> > ? ? ?clk: Add simple gated clock
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
->> > the body of a message to majordomo@vger.kernel.org
->> > More majordomo info at http://vger.kernel.org/majordomo-info.html
->> > Please read the FAQ at http://www.tux.org/lkml/
+>> > the body of a message to majordomo at vger.kernel.org
+>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
+>> > Please read the FAQ at ?http://www.tux.org/lkml/
>> >
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
->> linux-arm-kernel@lists.infradead.org
+>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
\ No newline at end of file
diff --git a/a/content_digest b/N2/content_digest
index d917835..8196979 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -8,13 +8,13 @@
"ref\00020110524172231.GA2764\@b20223-02.ap.freescale.net\0"
]
[
- "From\0Colin Cross <ccross\@google.com>\0"
+ "From\0ccross\@google.com (Colin Cross)\0"
]
[
- "Subject\0Re: [PATCH 0/4] Add a generic struct clk\0"
+ "Subject\0[PATCH 0/4] Add a generic struct clk\0"
]
[
- "Date\0Tue, 24 May 2011 17:52:53 +0000\0"
+ "Date\0Tue, 24 May 2011 10:52:53 -0700\0"
]
[
"To\0linux-arm-kernel\@lists.infradead.org\0"
@@ -61,37 +61,37 @@
">> > hardware clocks.\n",
">> >\n",
">> > Many thanks to the following for their input:\n",
- ">> > \302\240* Benjamin Herrenschmidt <benh\@kernel.crashing.org>\n",
- ">> > \302\240* Thomas Gleixner <tglx\@linutronix.de>\n",
- ">> > \302\240* Ben Dooks <ben-linux\@fluff.org>\n",
- ">> > \302\240* Baruch Siach <baruch\@tkos.co.il>\n",
- ">> > \302\240* Russell King <linux\@arm.linux.org.uk>\n",
- ">> > \302\240* Uwe Kleine-K\303\266nig <u.kleine-koenig\@pengutronix.de>\n",
- ">> > \302\240* Lorenzo Pieralisi <Lorenzo.Pieralisi\@arm.com>\n",
- ">> > \302\240* Vincent Guittot <vincent.guittot\@linaro.org>\n",
- ">> > \302\240* Sascha Hauer <s.hauer\@pengutronix.de>\n",
- ">> > \302\240* Ryan Mallon <ryan\@bluewatersys.com>\n",
- ">> > \302\240* Colin Cross <ccross\@google.com>\n",
- ">> > \302\240* Jassi Brar <jassisinghbrar\@gmail.com>\n",
- ">> > \302\240* Saravana Kannan <skannan\@codeaurora.org>\n",
+ ">> > ?* Benjamin Herrenschmidt <benh\@kernel.crashing.org>\n",
+ ">> > ?* Thomas Gleixner <tglx\@linutronix.de>\n",
+ ">> > ?* Ben Dooks <ben-linux\@fluff.org>\n",
+ ">> > ?* Baruch Siach <baruch\@tkos.co.il>\n",
+ ">> > ?* Russell King <linux\@arm.linux.org.uk>\n",
+ ">> > ?* Uwe Kleine-K?nig <u.kleine-koenig\@pengutronix.de>\n",
+ ">> > ?* Lorenzo Pieralisi <Lorenzo.Pieralisi\@arm.com>\n",
+ ">> > ?* Vincent Guittot <vincent.guittot\@linaro.org>\n",
+ ">> > ?* Sascha Hauer <s.hauer\@pengutronix.de>\n",
+ ">> > ?* Ryan Mallon <ryan\@bluewatersys.com>\n",
+ ">> > ?* Colin Cross <ccross\@google.com>\n",
+ ">> > ?* Jassi Brar <jassisinghbrar\@gmail.com>\n",
+ ">> > ?* Saravana Kannan <skannan\@codeaurora.org>\n",
">>\n",
">> I have a similar set of patches I was working on that handles a little\n",
- ">> more of the common code than these. \302\240I can post them if you want, but\n",
+ ">> more of the common code than these. ?I can post them if you want, but\n",
">> for now I'll just point out where I had different ideas, and not muddy\n",
">> the waters with conflicting patches.\n",
">>\n",
">> > TODO:\n",
">> >\n",
- ">> > \302\240* Need to figure out the locking around clk_set_parent. Changing the in-kernel\n",
- ">> > \302\240 clock topology requires acquiring both the mutex (to prevent against races\n",
- ">> > \302\240 with clk_prepare, which may propagate to the parent clock) and the spinlock\n",
- ">> > \302\240 (to prevent the same race with clk_enable).\n",
+ ">> > ?* Need to figure out the locking around clk_set_parent. Changing the in-kernel\n",
+ ">> > ? clock topology requires acquiring both the mutex (to prevent against races\n",
+ ">> > ? with clk_prepare, which may propagate to the parent clock) and the spinlock\n",
+ ">> > ? (to prevent the same race with clk_enable).\n",
">> >\n",
- ">> > \302\240 However, we should also be changing the hardware clock topology in sync with\n",
- ">> > \302\240 the in-kernel clock topology, which would imply that both locks *also* need\n",
- ">> > \302\240 to be held while updating the parent in the hardware (ie, in\n",
- ">> > \302\240 clk_hw_ops->set_parent) too. \302\240However, I believe some platform clock\n",
- ">> > \302\240 implementations may require this callback to be able to sleep. Comments?\n",
+ ">> > ? However, we should also be changing the hardware clock topology in sync with\n",
+ ">> > ? the in-kernel clock topology, which would imply that both locks *also* need\n",
+ ">> > ? to be held while updating the parent in the hardware (ie, in\n",
+ ">> > ? clk_hw_ops->set_parent) too. ?However, I believe some platform clock\n",
+ ">> > ? implementations may require this callback to be able to sleep. Comments?\n",
">>\n",
">> This sequence is the best I could come up with without adding a\n",
">> temporary 2nd parent:\n",
@@ -124,8 +124,8 @@
">> The only possible problem I see is that if a clock starts disabled at\n",
">> step 1., and clk_enable is called on it between steps 6 and 7,\n",
">> clk_enable will return having enabled the new parent, but the clock is\n",
- ">> still running off the old parent. \302\240As soon as the clock gets switched\n",
- ">> to the new parent, the clock will be properly enabled. \302\240I don't see\n",
+ ">> still running off the old parent. ?As soon as the clock gets switched\n",
+ ">> to the new parent, the clock will be properly enabled. ?I don't see\n",
">> this as a huge problem - calling clk_set_parent on a clock while it is\n",
">> enabled may not even work without causing glitches on some platforms.\n",
"> some do be glitch free, especially for cpu clock parents.\n",
@@ -133,35 +133,35 @@
">> I guess the only way around it would be to store a temporary\n",
">> \"new_parent\" pointer between steps 5 and 9, and have\n",
">> clk_enable/disable operate on both the current parent and the new\n",
- ">> parent. \302\240They would also need to refcount the extra enables separately\n",
+ ">> parent. ?They would also need to refcount the extra enables separately\n",
">> to undo on the old parent.\n",
">>\n",
- ">> > \302\240* tglx and I have been discussing different ways of passing clock information\n",
- ">> > \302\240 to the clock hardware implementation. I'm proposing providing a base 'struct\n",
- ">> > \302\240 clk_hw', which implementations subclass by wrapping in their own structure\n",
- ">> > \302\240 (or one of a set of simple 'library' structures, like clk_hw_mux or\n",
- ">> > \302\240 clk_hw_gate). \302\240The clk_hw base is passed as the first argument to all\n",
- ">> > \302\240 clk_hw_ops callbacks.\n",
- ">> >\n",
- ">> > \302\240 tglx's plan is to create a separate struct clk_hwdata, which contains a\n",
- ">> > \302\240 union of base data structures for common clocks: div, mux, gate, etc. The\n",
- ">> > \302\240 ops callbacks are passed a clk_hw, plus a clk_hwdata, and most of the base\n",
- ">> > \302\240 hwdata fields are handled within the core clock code. This means less\n",
- ">> > \302\240 encapsulation of clock implementation logic, but more coverage of\n",
- ">> > \302\240 clock basics through the core code.\n",
+ ">> > ?* tglx and I have been discussing different ways of passing clock information\n",
+ ">> > ? to the clock hardware implementation. I'm proposing providing a base 'struct\n",
+ ">> > ? clk_hw', which implementations subclass by wrapping in their own structure\n",
+ ">> > ? (or one of a set of simple 'library' structures, like clk_hw_mux or\n",
+ ">> > ? clk_hw_gate). ?The clk_hw base is passed as the first argument to all\n",
+ ">> > ? clk_hw_ops callbacks.\n",
+ ">> >\n",
+ ">> > ? tglx's plan is to create a separate struct clk_hwdata, which contains a\n",
+ ">> > ? union of base data structures for common clocks: div, mux, gate, etc. The\n",
+ ">> > ? ops callbacks are passed a clk_hw, plus a clk_hwdata, and most of the base\n",
+ ">> > ? hwdata fields are handled within the core clock code. This means less\n",
+ ">> > ? encapsulation of clock implementation logic, but more coverage of\n",
+ ">> > ? clock basics through the core code.\n",
">>\n",
">> I don't think they should be a union, I think there should be 3\n",
">> separate private datas, and three sets of clock ops, for the three\n",
">> different types of clock blocks: rate changers (dividers and plls),\n",
- ">> muxes, and gates. \302\240These blocks are very often combined - a device\n",
+ ">> muxes, and gates. ?These blocks are very often combined - a device\n",
">> clock often has a mux and a divider, and clk_set_parent and\n",
">> clk_set_rate on the same struct clk both need to work.\n",
">>\n",
- ">> > \302\240 tglx, could you send some details about your approach? I'm aiming to refine\n",
- ">> > \302\240 this series with the good bits from each technique.\n",
+ ">> > ? tglx, could you send some details about your approach? I'm aiming to refine\n",
+ ">> > ? this series with the good bits from each technique.\n",
">> >\n",
- ">> > \302\240* The clock registration code probably needs work. This is the domain\n",
- ">> > \302\240 of the platform/board maintainers, any wishes here?\n",
+ ">> > ?* The clock registration code probably needs work. This is the domain\n",
+ ">> > ? of the platform/board maintainers, any wishes here?\n",
"> When clock init, data in struct clk may not be synced with hw registers. After\n",
"> enabled minimal needed clk (cpu, core bus etc), we need sync the whole tree,\n",
"> disable zero enable_count clocks, set correct .rate ... . The sync function\n",
@@ -182,23 +182,23 @@
">> >\n",
">> > ---\n",
">> > Jeremy Kerr (4):\n",
- ">> > \302\240 \302\240 \302\240clk: Add a generic clock infrastructure\n",
- ">> > \302\240 \302\240 \302\240clk: Implement clk_set_rate\n",
- ">> > \302\240 \302\240 \302\240clk: Add fixed-rate clock\n",
- ">> > \302\240 \302\240 \302\240clk: Add simple gated clock\n",
+ ">> > ? ? ?clk: Add a generic clock infrastructure\n",
+ ">> > ? ? ?clk: Implement clk_set_rate\n",
+ ">> > ? ? ?clk: Add fixed-rate clock\n",
+ ">> > ? ? ?clk: Add simple gated clock\n",
">> >\n",
">> > --\n",
">> > To unsubscribe from this list: send the line \"unsubscribe linux-kernel\" in\n",
- ">> > the body of a message to majordomo\@vger.kernel.org\n",
- ">> > More majordomo info at \302\240http://vger.kernel.org/majordomo-info.html\n",
- ">> > Please read the FAQ at \302\240http://www.tux.org/lkml/\n",
+ ">> > the body of a message to majordomo at vger.kernel.org\n",
+ ">> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html\n",
+ ">> > Please read the FAQ at ?http://www.tux.org/lkml/\n",
">> >\n",
">>\n",
">> _______________________________________________\n",
">> linux-arm-kernel mailing list\n",
- ">> linux-arm-kernel\@lists.infradead.org\n",
+ ">> linux-arm-kernel at lists.infradead.org\n",
">> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n",
">"
]
-56d0a297d858aa5f382c8c0ae897587af1aee873de7d4bed88244f1f8e33f785
+e92990535c515700ca8e71c99069c5ea9eee6fb019a386eb70383ff1120622b7
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.