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
---
drivers/video/omap2/dss/dpi.
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.
Sig
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_fcl
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 =
-dssdev->clocks.dispc.dispc_fclk_s
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 th
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 do
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 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,
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
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
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
>
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
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
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
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
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
17 matches
Mail list logo
