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 first
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com 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
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com 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
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hotplugging is not some abstract future scenario, we already have
hardware that could use it. For
On 2012-11-07 21:18, Rob Clark wrote:
On Wed, Nov 7, 2012 at 9:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2012-11-07 16:32, Rob Clark wrote:
On Wed, Nov 7, 2012 at 4:01 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hotplugging is not some abstract future scenario, we already
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/omapdrm could understand
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen to...@iki.fi 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
On 2012-11-02 13:56, Archit Taneja wrote:
On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote:
On 2012-11-02 13:09, Archit Taneja wrote:
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
Hmm, that makes sense. Anyway, I don't think
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 information'
On 2012-10-31 09:26, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
-if (dpi_use_dsi_pll(dssdev)) {
-enum omap_dss_clk_source dispc_fclk_src =
-dssdev-clocks.dispc.dispc_fclk_src;
-dpi.dsidev = dpi_get_dsidev(dispc_fclk_src);
On Friday 02 November 2012 03:38 PM, Tomi Valkeinen wrote:
On 2012-10-31 09:26, Archit Taneja wrote:
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
-if (dpi_use_dsi_pll(dssdev)) {
-enum omap_dss_clk_source dispc_fclk_src =
-
On 2012-11-02 12:44, Archit Taneja wrote:
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
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
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
On 2012-11-02 13:09, Archit Taneja wrote:
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
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
On Friday 02 November 2012 04:58 PM, Tomi Valkeinen wrote:
On 2012-11-02 13:09, Archit Taneja wrote:
On Friday 02 November 2012 04:19 PM, Tomi Valkeinen wrote:
On 2012-11-02 12:44, Archit Taneja wrote:
Hmm, that makes sense. Anyway, I don't think it's really bad if we refer
to dssdev-channel
On Tuesday 30 October 2012 09:40 PM, Tomi Valkeinen wrote:
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
17 matches
Mail list logo
