diff for duplicates of <20160105012954.15239.57130@quark.deferred.io>

diff --git a/a/1.txt b/N1/1.txt
index e96042e..8200771 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -17,31 +17,29 @@ Quoting Tero Kristo (2016-01-03 23:36:05)
 > >
 > >> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
 > >> +{
-> >> +       struct clk_hw_omap *clk =3D to_clk_hw_omap(hw);
+> >> +       struct clk_hw_omap *clk = to_clk_hw_omap(hw);
 > >> +       u32 val;
-> >> +       int timeout =3D 0;
+> >> +       int timeout = 0;
 > >> +       int ret;
 > >> +
 > >> +       if (!clk->enable_bit)
 > >> +               return 0;
 > >> +
 > >> +       if (clk->clkdm) {
-> >> +               ret =3D ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw=
-->clk);
+> >> +               ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);
 > >> +               if (ret) {
 > >> +                       WARN(1,
-> >> +                            "%s: could not enable %s's clockdomain %s=
-: %d\n",
+> >> +                            "%s: could not enable %s's clockdomain %s: %d\n",
 > >> +                            __func__, clk_hw_get_name(hw),
 > >> +                            clk->clkdm_name, ret);
 > >> +                       return ret;
 > >> +               }
 > >> +       }
 > >> +
-> >> +       val =3D ti_clk_ll_ops->clk_readl(clk->enable_reg);
+> >> +       val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
 > >> +
-> >> +       val &=3D ~OMAP4_MODULEMODE_MASK;
-> >> +       val |=3D clk->enable_bit;
+> >> +       val &= ~OMAP4_MODULEMODE_MASK;
+> >> +       val |= clk->enable_bit;
 > >> +
 > >> +       ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
 > >> +
@@ -51,51 +49,39 @@ Quoting Tero Kristo (2016-01-03 23:36:05)
 > >
 > > This should really be a .prepare callback if you plan to keep the delays
 > > in there.
-> =
-
-> If this is changed to a .prepare, then all OMAP power management is =
-
-> effectively ruined as all clocks are going to be enabled all the time. =
-
+> 
+> If this is changed to a .prepare, then all OMAP power management is 
+> effectively ruined as all clocks are going to be enabled all the time. 
 
 Let's not ruin system PM.
 
-> hwmod core doesn't support .prepare/.enable at the moment that well, and =
-
-> changing that is going to be a big burden (educated guess, haven't =
-
+> hwmod core doesn't support .prepare/.enable at the moment that well, and 
+> changing that is going to be a big burden (educated guess, haven't 
 > checked this yet)... The call chain that comes here is:
-> =
-
+> 
 > device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.
 
 Right, and for calls to pm_runtime_get/put from process context it
 should result in a call to clk_prepare_enable/clk_disable_unprepare. I
 guess that change is hugely invasive from your statements above?
 
-> =
-
-> The delay within this function should usually be pretty short, just to =
-
+> 
+> The delay within this function should usually be pretty short, just to 
 > wait that the module comes up from idle.
-> =
-
-> I recall the discussions regarding the udelays within clk_enable/disable =
-
+> 
+> I recall the discussions regarding the udelays within clk_enable/disable 
 > calls, but what is the preferred approach then?
 
 There are many cases where a clk only provides .{un}prepare ops and does
 NOT provide any .{en,dis}able ops.
 
-> Typically =
-
+> Typically 
 > clk_enable/disable just becomes a NOP
 
 Yes, it becomes a NOP (though it is critical that drivers with knowledge
 of this do not try to skip the step of calling clk_enable).
 
-> if it is not allowed to wait for =
-
+> if it is not allowed to wait for 
 > hardware to complete transitioning before exiting the function.
 
 The clk.h api clearly states that clk_prepare must be called and
@@ -107,13 +93,11 @@ returns.
 Regards,
 Mike
 
-> =
-
+> 
 > -Tero
-> =
-
+> 
 > >
 > > Regards,
 > > Mike
 > >
->=20
\ No newline at end of file
+>
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index d71b4d8..007a2d7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -55,31 +55,29 @@
   "> >\n",
   "> >> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)\n",
   "> >> +{\n",
-  "> >> +       struct clk_hw_omap *clk =3D to_clk_hw_omap(hw);\n",
+  "> >> +       struct clk_hw_omap *clk = to_clk_hw_omap(hw);\n",
   "> >> +       u32 val;\n",
-  "> >> +       int timeout =3D 0;\n",
+  "> >> +       int timeout = 0;\n",
   "> >> +       int ret;\n",
   "> >> +\n",
   "> >> +       if (!clk->enable_bit)\n",
   "> >> +               return 0;\n",
   "> >> +\n",
   "> >> +       if (clk->clkdm) {\n",
-  "> >> +               ret =3D ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw=\n",
-  "->clk);\n",
+  "> >> +               ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);\n",
   "> >> +               if (ret) {\n",
   "> >> +                       WARN(1,\n",
-  "> >> +                            \"%s: could not enable %s's clockdomain %s=\n",
-  ": %d\\n\",\n",
+  "> >> +                            \"%s: could not enable %s's clockdomain %s: %d\\n\",\n",
   "> >> +                            __func__, clk_hw_get_name(hw),\n",
   "> >> +                            clk->clkdm_name, ret);\n",
   "> >> +                       return ret;\n",
   "> >> +               }\n",
   "> >> +       }\n",
   "> >> +\n",
-  "> >> +       val =3D ti_clk_ll_ops->clk_readl(clk->enable_reg);\n",
+  "> >> +       val = ti_clk_ll_ops->clk_readl(clk->enable_reg);\n",
   "> >> +\n",
-  "> >> +       val &=3D ~OMAP4_MODULEMODE_MASK;\n",
-  "> >> +       val |=3D clk->enable_bit;\n",
+  "> >> +       val &= ~OMAP4_MODULEMODE_MASK;\n",
+  "> >> +       val |= clk->enable_bit;\n",
   "> >> +\n",
   "> >> +       ti_clk_ll_ops->clk_writel(val, clk->enable_reg);\n",
   "> >> +\n",
@@ -89,51 +87,39 @@
   "> >\n",
   "> > This should really be a .prepare callback if you plan to keep the delays\n",
   "> > in there.\n",
-  "> =\n",
-  "\n",
-  "> If this is changed to a .prepare, then all OMAP power management is =\n",
-  "\n",
-  "> effectively ruined as all clocks are going to be enabled all the time. =\n",
-  "\n",
+  "> \n",
+  "> If this is changed to a .prepare, then all OMAP power management is \n",
+  "> effectively ruined as all clocks are going to be enabled all the time. \n",
   "\n",
   "Let's not ruin system PM.\n",
   "\n",
-  "> hwmod core doesn't support .prepare/.enable at the moment that well, and =\n",
-  "\n",
-  "> changing that is going to be a big burden (educated guess, haven't =\n",
-  "\n",
+  "> hwmod core doesn't support .prepare/.enable at the moment that well, and \n",
+  "> changing that is going to be a big burden (educated guess, haven't \n",
   "> checked this yet)... The call chain that comes here is:\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.\n",
   "\n",
   "Right, and for calls to pm_runtime_get/put from process context it\n",
   "should result in a call to clk_prepare_enable/clk_disable_unprepare. I\n",
   "guess that change is hugely invasive from your statements above?\n",
   "\n",
-  "> =\n",
-  "\n",
-  "> The delay within this function should usually be pretty short, just to =\n",
-  "\n",
+  "> \n",
+  "> The delay within this function should usually be pretty short, just to \n",
   "> wait that the module comes up from idle.\n",
-  "> =\n",
-  "\n",
-  "> I recall the discussions regarding the udelays within clk_enable/disable =\n",
-  "\n",
+  "> \n",
+  "> I recall the discussions regarding the udelays within clk_enable/disable \n",
   "> calls, but what is the preferred approach then?\n",
   "\n",
   "There are many cases where a clk only provides .{un}prepare ops and does\n",
   "NOT provide any .{en,dis}able ops.\n",
   "\n",
-  "> Typically =\n",
-  "\n",
+  "> Typically \n",
   "> clk_enable/disable just becomes a NOP\n",
   "\n",
   "Yes, it becomes a NOP (though it is critical that drivers with knowledge\n",
   "of this do not try to skip the step of calling clk_enable).\n",
   "\n",
-  "> if it is not allowed to wait for =\n",
-  "\n",
+  "> if it is not allowed to wait for \n",
   "> hardware to complete transitioning before exiting the function.\n",
   "\n",
   "The clk.h api clearly states that clk_prepare must be called and\n",
@@ -145,16 +131,14 @@
   "Regards,\n",
   "Mike\n",
   "\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> -Tero\n",
-  "> =\n",
-  "\n",
+  "> \n",
   "> >\n",
   "> > Regards,\n",
   "> > Mike\n",
   "> >\n",
-  ">=20"
+  ">"
 ]
 
-36fddd6637382402324b6702d7cdb33cdf7d6b3e0603bdb7d4807412e583e5be
+64bd7918e15f7f467ad61a682eb736d4650a031b5f70bb0d70370248c7b99144
