diff for duplicates of <2305295.bk1TpuGLMv@avalon> diff --git a/a/1.txt b/N1/1.txt index af7b206..4c0058b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -47,7 +47,7 @@ On Friday 09 August 2013 11:38:45 Tomi Valkeinen wrote: > work/dss-dev-model-dt > > Vocabulary -> ===== +> ========== > > Display Entity - a hardware entity that takes one or more video streams as > input and outputs one or more video streams. @@ -70,7 +70,7 @@ On Friday 09 August 2013 11:38:45 Tomi Valkeinen wrote: > monitor is connected. > > About Stable DT Bindings -> ============ +> ======================== > > Generally speaking, the DT bindings should be stable. This brings the > following problems: @@ -113,7 +113,7 @@ stabilizing them, but that's obviously not a reason not to think them properly from the start. > General description of the DT bindings -> =================== +> ====================================== > > All the display entities are represented as DT nodes of their own, and have > a matching Linux driver. The display entities are organized by their control @@ -193,7 +193,7 @@ them for the OMAPDSS (even if you don't use the CDF helpers to start with) ? > number of data-lines. > > Video bus properties -> ========== +> ==================== > > One question I've been pondering for a long time is related to the bus > between two display entities. As an example, DPI (parallel RGB) requires @@ -223,7 +223,8 @@ I believe we should go for the port-based approach, even if you don't use the CDF helpers (possibly at first only). > DSI Module ID -> ======> +> ============= +> > On OMAP4 we have two DSI modules. To configure the clock routing and pin > muxing, we need to know the hardware module ID for the DSI device, i.e. is > this Linux platform device DSI1 or DSI2. The same issue exists with other @@ -248,7 +249,8 @@ but not more than the current method. > complications, like the pins requiring a regulator to be enabled. > > Display names and aliases -> ============> +> ========================= +> > With the board-file based model each display was given a name in the board > file. Additionally, each display was given an alias in the style "displayX", > where X is in incrementing number. @@ -267,7 +269,7 @@ but not more than the current method. > display to use initially if the user has not specified it. > > omapdss virtual device -> =========== +> ====================== > > In addition to the DSS devices matching to DSS hardware modules, we have a > "virtual" omapdss device which does not match to any actual HW module. The @@ -322,7 +324,8 @@ nodes. > the current solution it exists for the above reasons. > > DSS submodules in DT bindings -> ==============> +> ============================= +> > The OMAP DSS modules are accessed via L4 or L3, and in that sense they > should be on the same level in the DT bindings. However, we do not have them > in the same level, but there is a main "dss" node, under which all the @@ -362,7 +365,8 @@ we need to make sure that the DT bindings will allow an easy path forward if needed. > DT Node Names -> ======> +> ============= +> > I have used the following naming conventions with DT nodes: > > - Panels are named "display" @@ -376,7 +380,8 @@ needed. > number for the address, as in "tpd12s015: encoder@1". > > Final words -> =====> +> =========== +> > So as is evident, I have things in my mind that should be improved. Maybe > the most important question for short term future is: > @@ -405,7 +410,7 @@ you'll come back :-) > ARM: OMAP: remove DSS DT hack > OMAPDSS: remove DT hacks for regulators > ARM: OMAP2+: add omapdss_init_of() -> OMAPDSS: if dssdev->name=NULL, use alias +> OMAPDSS: if dssdev->name==NULL, use alias > OMAPDSS: get dssdev->alias from DT alias > OMAPFB: clean up default display search > OMAPFB: search for default display with DT alias diff --git a/a/content_digest b/N1/content_digest index a2c9a74..d52a5d2 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,7 +1,7 @@ "ref\01376037547-10859-1-git-send-email-tomi.valkeinen@ti.com\0" "From\0Laurent Pinchart <laurent.pinchart@ideasonboard.com>\0" "Subject\0Re: [RFC 00/22] OMAPDSS: DT support\0" - "Date\0Wed, 21 Aug 2013 21:07:02 +0000\0" + "Date\0Wed, 21 Aug 2013 23:07:02 +0200\0" "To\0Tomi Valkeinen <tomi.valkeinen@ti.com>\0" "Cc\0linux-omap@vger.kernel.org" linux-fbdev@vger.kernel.org @@ -62,7 +62,7 @@ "> work/dss-dev-model-dt\n" "> \n" "> Vocabulary\n" - "> =====\n" + "> ==========\n" "> \n" "> Display Entity - a hardware entity that takes one or more video streams as\n" "> input and outputs one or more video streams.\n" @@ -85,7 +85,7 @@ "> monitor is connected.\n" "> \n" "> About Stable DT Bindings\n" - "> ============\n" + "> ========================\n" "> \n" "> Generally speaking, the DT bindings should be stable. This brings the\n" "> following problems:\n" @@ -128,7 +128,7 @@ "from the start.\n" "\n" "> General description of the DT bindings\n" - "> ===================\n" + "> ======================================\n" "> \n" "> All the display entities are represented as DT nodes of their own, and have\n" "> a matching Linux driver. The display entities are organized by their control\n" @@ -208,7 +208,7 @@ "> number of data-lines.\n" "> \n" "> Video bus properties\n" - "> ==========\n" + "> ====================\n" "> \n" "> One question I've been pondering for a long time is related to the bus\n" "> between two display entities. As an example, DPI (parallel RGB) requires\n" @@ -238,7 +238,8 @@ "CDF helpers (possibly at first only).\n" "\n" "> DSI Module ID\n" - "> ======> \n" + "> =============\n" + "> \n" "> On OMAP4 we have two DSI modules. To configure the clock routing and pin\n" "> muxing, we need to know the hardware module ID for the DSI device, i.e. is\n" "> this Linux platform device DSI1 or DSI2. The same issue exists with other\n" @@ -263,7 +264,8 @@ "> complications, like the pins requiring a regulator to be enabled.\n" ">\n" "> Display names and aliases\n" - "> ============> \n" + "> =========================\n" + "> \n" "> With the board-file based model each display was given a name in the board\n" "> file. Additionally, each display was given an alias in the style \"displayX\",\n" "> where X is in incrementing number.\n" @@ -282,7 +284,7 @@ "> display to use initially if the user has not specified it.\n" "> \n" "> omapdss virtual device\n" - "> ===========\n" + "> ======================\n" "> \n" "> In addition to the DSS devices matching to DSS hardware modules, we have a\n" "> \"virtual\" omapdss device which does not match to any actual HW module. The\n" @@ -337,7 +339,8 @@ "> the current solution it exists for the above reasons.\n" "> \n" "> DSS submodules in DT bindings\n" - "> ==============> \n" + "> =============================\n" + "> \n" "> The OMAP DSS modules are accessed via L4 or L3, and in that sense they\n" "> should be on the same level in the DT bindings. However, we do not have them\n" "> in the same level, but there is a main \"dss\" node, under which all the\n" @@ -377,7 +380,8 @@ "needed.\n" "\n" "> DT Node Names\n" - "> ======> \n" + "> =============\n" + "> \n" "> I have used the following naming conventions with DT nodes:\n" "> \n" "> - Panels are named \"display\"\n" @@ -391,7 +395,8 @@ "> number for the address, as in \"tpd12s015: encoder@1\".\n" "> \n" "> Final words\n" - "> =====> \n" + "> ===========\n" + "> \n" "> So as is evident, I have things in my mind that should be improved. Maybe\n" "> the most important question for short term future is:\n" "> \n" @@ -420,7 +425,7 @@ "> ARM: OMAP: remove DSS DT hack\n" "> OMAPDSS: remove DT hacks for regulators\n" "> ARM: OMAP2+: add omapdss_init_of()\n" - "> OMAPDSS: if dssdev->name=NULL, use alias\n" + "> OMAPDSS: if dssdev->name==NULL, use alias\n" "> OMAPDSS: get dssdev->alias from DT alias\n" "> OMAPFB: clean up default display search\n" "> OMAPFB: search for default display with DT alias\n" @@ -473,4 +478,4 @@ "\n" Laurent Pinchart -5739b92c9b5ad9b9ed86799610b601f635d88852f125cfb76dce38cf905d7530 +b70cd901ed49ce53dce47f60ef5eff769fc5f79f1a58ebad2b33b9a7f0b2cbe5
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.