[PATCH 00/12] OMAPDSS: use DSI PLL clk for DPI · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 01/12] OMAPFB: remove use of extended edid block · Tomi Valkeinen <hidden> · 2012-10-30
Re: [PATCH 01/12] OMAPFB: remove use of extended edid block · Archit Taneja <hidden> · 2012-10-31
Re: [PATCH 01/12] OMAPFB: remove use of extended edid block · Tomi Valkeinen <hidden> · 2012-10-31
[PATCH 02/12] OMAPFB: improve mode selection from EDID · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 03/12] OMAPDSS: fix DPI & DSI init order · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz · Tomi Valkeinen <hidden> · 2012-10-30
Re: [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz · Archit Taneja <hidden> · 2012-10-31
Re: [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz · Tomi Valkeinen <hidden> · 2012-10-31
Re: [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz · Archit Taneja <hidden> · 2012-10-31
[PATCH 06/12] OMAPDSS: DSI: workaround for HSDiv problem · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 08/12] OMAPDSS: setup default dss fck · Tomi Valkeinen <hidden> · 2012-10-30
Re: [PATCH 08/12] OMAPDSS: setup default dss fck · Archit Taneja <hidden> · 2012-10-31
Re: [PATCH 08/12] OMAPDSS: setup default dss fck · Tomi Valkeinen <hidden> · 2012-10-31
[PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source() · Tomi Valkeinen <hidden> · 2012-10-30
Re: [PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source() · Archit Taneja <hidden> · 2012-10-31
Re: [PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source() · Tomi Valkeinen <hidden> · 2012-10-31
[PATCH 10/12] OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 11/12] OMAPDSS: DPI: verify if DSI PLL is operational · Tomi Valkeinen <hidden> · 2012-10-30
[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-10-30
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Archit Taneja <hidden> · 2012-10-31
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Archit Taneja <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Archit Taneja <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Archit Taneja <hidden> · 2012-11-02
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-05
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Rob Clark <hidden> · 2012-11-05
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-06
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Rob Clark <hidden> · 2012-11-06
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-07
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Rob Clark <hidden> · 2012-11-07
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-07
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Rob Clark <hidden> · 2012-11-07
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available · Tomi Valkeinen <hidden> · 2012-11-08

Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

From: Archit Taneja <hidden>
Date: 2012-11-02 11:21:28
Also in: linux-omap

On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:

On 2012-11-02 12:44, Archit Taneja wrote:

quoted

Hmm, that makes sense. Anyway, I don't think it's really bad if we refer
to dssdev->channel for now.

It is, because dssdev->channel doesn't exist with DT.

With DT we either need to figure out the channel in omapdss at runtime,
or add a property to the DT data telling the channel. And adding such a
property is not correct, as DT should be about describing the HW.

Ok.

I don't totally agree with your idea of figuring out the manager in 
panel the panel's probe. If it's done in the panel driver's probe 
itself, then by this point of time we have already set 
mgr->output->device links. If omapdss only does this stuff, then 
omapfb/omapdrm have just the job of connecting the overlays to the 
manager. Do you think that's okay?

Archit

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help