diff for duplicates of <524C1058.2050500@samsung.com>

diff --git a/a/1.txt b/N1/1.txt
index 731ab02..c3bc8b2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -22,7 +22,8 @@ On 09/30/2013 03:48 PM, Tomi Valkeinen wrote:
 > something about this.
 > 
 > Using Linux buses for DBI/DSI
-> ==============> 
+> =============================
+> 
 > I still don't see how it would work. I've covered this multiple times in
 > previous posts so I'm not going into more details now.
 > 
@@ -32,7 +33,7 @@ On 09/30/2013 03:48 PM, Tomi Valkeinen wrote:
 Could you post the list of ops you have to create.
 
 I have posted some time ago my implementation of DSI bus:
-http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focusi362
+http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focus=69362
 
 I needed three quite generic ops to make it working:
 - set_power(on/off),
@@ -56,7 +57,7 @@ and disadvantages.
 
 > 
 > Call model
-> =====
+> ==========
 > 
 > It may be that I just don't get how things are supposed to work with the RFC's
 > ops, but I couldn't figure out how to use it in practice. I tried it for a few
@@ -72,7 +73,8 @@ and disadvantages.
 > verifying videomodes, fetching them via EDID, etc.
 > 
 > Multiple inputs/outputs
-> ===========> 
+> =======================
+> 
 > I think changing the model from single-input & single output to multiple inputs
 > and outputs increases the difficulty of the implementation considerably. That's
 > not a complaint as such, just an observation. I do think multiple inputs &
@@ -86,7 +88,7 @@ and disadvantages.
 > cases).
 > 
 > Internal connections
-> ==========
+> ====================
 > 
 > The model currently only represents connections between entities. With multiple
 > inputs & outputs I think it's important to maintain also connections inside the
@@ -98,7 +100,7 @@ and disadvantages.
 > outputs, so I can follow the pipeline trivially.
 > 
 > Central entity
-> =======
+> ==============
 > 
 > If I understand the RFC correctly, there's a "central" entity that manages all
 > other entities connected to it. This central entity would normally be the
@@ -114,7 +116,8 @@ and disadvantages.
 > implemented it.
 > 
 > Media entity/pads
-> ========> 
+> =================
+> 
 > Using media_entity and media_pad fits quite well for CDF, but... It is quite
 > cumbersome to use. The constant switching between media_entity and
 > display_entity needs quite a lot of code in total, as it has to be done almost
@@ -146,7 +149,8 @@ and disadvantages.
 > be done except by modifying the media_link or media_pad themselves.
 > 
 > DT data & platform data
-> ===========> 
+> =======================
+> 
 > I think the V4L2 style port/endpoint description in DT data should work well. I
 > don't see a need for specifying the remote-endpoint in the upstream entity, but
 > then again, it doesn't hurt either.
@@ -161,7 +165,7 @@ and disadvantages.
 > and in my model each display entity has its own platform data.
 > 
 > Final thoughts
-> =======
+> ==============
 > 
 > So many of the comments above are somewhat gut-feelings. I don't have concrete
 > evidence that my ideas are better, as I haven't been able to finalize the code
diff --git a/a/content_digest b/N1/content_digest
index 6f29ede..2a265bd 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,7 +2,7 @@
  "ref\052498146.4050600@ti.com\0"
  "From\0Andrzej Hajda <a.hajda@samsung.com>\0"
  "Subject\0Re: [PATCH/RFC v3 00/19] Common Display Framework\0"
- "Date\0Wed, 02 Oct 2013 12:23:52 +0000\0"
+ "Date\0Wed, 02 Oct 2013 14:23:52 +0200\0"
  "To\0Tomi Valkeinen <tomi.valkeinen@ti.com>"
  " Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>\0"
  "Cc\0linux-fbdev@vger.kernel.org"
@@ -47,7 +47,8 @@
  "> something about this.\n"
  "> \n"
  "> Using Linux buses for DBI/DSI\n"
- "> ==============> \n"
+ "> =============================\n"
+ "> \n"
  "> I still don't see how it would work. I've covered this multiple times in\n"
  "> previous posts so I'm not going into more details now.\n"
  "> \n"
@@ -57,7 +58,7 @@
  "Could you post the list of ops you have to create.\n"
  "\n"
  "I have posted some time ago my implementation of DSI bus:\n"
- "http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focusi362\n"
+ "http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focus=69362\n"
  "\n"
  "I needed three quite generic ops to make it working:\n"
  "- set_power(on/off),\n"
@@ -81,7 +82,7 @@
  "\n"
  "> \n"
  "> Call model\n"
- "> =====\n"
+ "> ==========\n"
  "> \n"
  "> It may be that I just don't get how things are supposed to work with the RFC's\n"
  "> ops, but I couldn't figure out how to use it in practice. I tried it for a few\n"
@@ -97,7 +98,8 @@
  "> verifying videomodes, fetching them via EDID, etc.\n"
  "> \n"
  "> Multiple inputs/outputs\n"
- "> ===========> \n"
+ "> =======================\n"
+ "> \n"
  "> I think changing the model from single-input & single output to multiple inputs\n"
  "> and outputs increases the difficulty of the implementation considerably. That's\n"
  "> not a complaint as such, just an observation. I do think multiple inputs &\n"
@@ -111,7 +113,7 @@
  "> cases).\n"
  "> \n"
  "> Internal connections\n"
- "> ==========\n"
+ "> ====================\n"
  "> \n"
  "> The model currently only represents connections between entities. With multiple\n"
  "> inputs & outputs I think it's important to maintain also connections inside the\n"
@@ -123,7 +125,7 @@
  "> outputs, so I can follow the pipeline trivially.\n"
  "> \n"
  "> Central entity\n"
- "> =======\n"
+ "> ==============\n"
  "> \n"
  "> If I understand the RFC correctly, there's a \"central\" entity that manages all\n"
  "> other entities connected to it. This central entity would normally be the\n"
@@ -139,7 +141,8 @@
  "> implemented it.\n"
  "> \n"
  "> Media entity/pads\n"
- "> ========> \n"
+ "> =================\n"
+ "> \n"
  "> Using media_entity and media_pad fits quite well for CDF, but... It is quite\n"
  "> cumbersome to use. The constant switching between media_entity and\n"
  "> display_entity needs quite a lot of code in total, as it has to be done almost\n"
@@ -171,7 +174,8 @@
  "> be done except by modifying the media_link or media_pad themselves.\n"
  "> \n"
  "> DT data & platform data\n"
- "> ===========> \n"
+ "> =======================\n"
+ "> \n"
  "> I think the V4L2 style port/endpoint description in DT data should work well. I\n"
  "> don't see a need for specifying the remote-endpoint in the upstream entity, but\n"
  "> then again, it doesn't hurt either.\n"
@@ -186,7 +190,7 @@
  "> and in my model each display entity has its own platform data.\n"
  "> \n"
  "> Final thoughts\n"
- "> =======\n"
+ "> ==============\n"
  "> \n"
  "> So many of the comments above are somewhat gut-feelings. I don't have concrete\n"
  "> evidence that my ideas are better, as I haven't been able to finalize the code\n"
@@ -214,4 +218,4 @@
  "> http://lists.freedesktop.org/mailman/listinfo/dri-devel\n"
  >
 
-2630bc68c72b4568a65fd34f7ba853691dbf262201e87f6c35c97753d628d174
+fe6617ae0584273a593ad6c66d4251bb9b278107c0ac6077171c86bd389d39bc
