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

2012-11-08 Thread Tomi Valkeinen
On 2012-11-07 21:18, Rob Clark wrote: > On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen wrote: >> On 2012-11-07 16:32, Rob Clark wrote: >>> On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen >>> wrote: >> Hotplugging is not some abstract future scenario, we already have hardware that could

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

2012-11-08 Thread Tomi Valkeinen
On 2012-11-07 21:18, Rob Clark wrote: > On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen > wrote: >> On 2012-11-07 16:32, Rob Clark wrote: >>> On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen >>> wrote: >> Hotplugging is not some abstract future scenario, we already have hardware that cou

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

2012-11-07 Thread Tomi Valkeinen
On 2012-11-07 16:32, Rob Clark wrote: > On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen wrote: >> Hotplugging is not some abstract future scenario, we already have >> hardware that could use it. For example, omap3 SDP board has a >> switchable output to DVI or LCD panel. In this case we know what

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

2012-11-07 Thread Tomi Valkeinen
On 2012-11-07 16:32, Rob Clark wrote: > On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen > wrote: >> Hotplugging is not some abstract future scenario, we already have >> hardware that could use it. For example, omap3 SDP board has a >> switchable output to DVI or LCD panel. In this case we know wh

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

2012-11-07 Thread Rob Clark
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen wrote: > On 2012-11-07 16:32, Rob Clark wrote: >> On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen >> wrote: > >>> Hotplugging is not some abstract future scenario, we already have >>> hardware that could use it. For example, omap3 SDP board has a >>>

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

2012-11-07 Thread Tomi Valkeinen
On 2012-11-06 16:40, Rob Clark wrote: > I mean, similar to how we handle the subdev for dmm.. the > omap_drm_init() does the platform_driver_register() for the dmm device > before the platform_driver_register() for omapdrm itself, so we know > if there is a dmm device, the driver gets probed firs

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

2012-11-07 Thread Rob Clark
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen wrote: > On 2012-11-07 16:32, Rob Clark wrote: >> On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen wrote: > >>> Hotplugging is not some abstract future scenario, we already have >>> hardware that could use it. For example, omap3 SDP board has a >>> swi

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

2012-11-07 Thread Rob Clark
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen wrote: > On 2012-11-06 16:40, Rob Clark wrote: > >> I mean, similar to how we handle the subdev for dmm.. the >> omap_drm_init() does the platform_driver_register() for the dmm device >> before the platform_driver_register() for omapdrm itself, so we

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

2012-11-07 Thread Rob Clark
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen wrote: > On 2012-11-06 16:40, Rob Clark wrote: > >> I mean, similar to how we handle the subdev for dmm.. the >> omap_drm_init() does the platform_driver_register() for the dmm device >> before the platform_driver_register() for omapdrm itself, so we

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

2012-11-07 Thread Tomi Valkeinen
On 2012-11-06 16:40, Rob Clark wrote: > I mean, similar to how we handle the subdev for dmm.. the > omap_drm_init() does the platform_driver_register() for the dmm device > before the platform_driver_register() for omapdrm itself, so we know > if there is a dmm device, the driver gets probed firs

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

2012-11-06 Thread Tomi Valkeinen
On 2012-11-05 16:21, Rob Clark wrote: > On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the >>manager needs to observe all the possible displays used at the same >>time... >>> > >>> >Right. I was wondering if omapfb/om

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

2012-11-06 Thread Rob Clark
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen wrote: > On 2012-11-05 16:21, Rob Clark wrote: >> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: > But even then, choosing the manager is not easy, as whoever chooses the > >>manager needs to observe all the possible displays used at the same >

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

2012-11-06 Thread Rob Clark
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen wrote: > On 2012-11-05 16:21, Rob Clark wrote: >> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: > But even then, choosing the manager is not easy, as whoever chooses the > >>manager needs to observe all the possible displays used at the same >

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

2012-11-06 Thread Tomi Valkeinen
On 2012-11-05 16:21, Rob Clark wrote: > On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the >>manager needs to observe all the possible displays used at the same >>time... >>> > >>> >Right. I was wondering if omapfb/om

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

2012-11-05 Thread Rob Clark
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the >>manager needs to observe all the possible displays used at the same >>time... > >Right. I was wondering if omapfb/omapdrm could understand the 'all >possible displays informati

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

2012-11-05 Thread Rob Clark
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: >>> But even then, choosing the manager is not easy, as whoever chooses the >>> >>manager needs to observe all the possible displays used at the same >>> >>time... >> > >> >Right. I was wondering if omapfb/omapdrm could understand the 'all >> >possible