From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, rob@ti.com
Subject: Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
Date: Fri, 02 Nov 2012 11:56:55 +0000 [thread overview]
Message-ID: <5093B4F3.1000703@ti.com> (raw)
In-Reply-To: <5093AE79.9010603@ti.com>
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 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
>
> Hmm, I'm not sure I understand what's your point above? If figuring out
> the mgr is done in panel's probe, the mgr->output link is not yet made
> before that time.
My point is that we are trying to find a manager at panel's probe
itself. It think that's what we do now. But one of your recent patch
moves that to omapfb.
>
>> omapfb/omapdrm have just the job of connecting the overlays to the
>> manager. Do you think that's okay?
>
> Yes, that's how I think it should be. I don't see why omapfb/omapdrm
> should care about which manager is being used for the output, it doesn't
> really matter as long there is one and it works.
>
> Then again, I don't have anything against omapfb/omapdrm choosing the
> manager, but I don't see how they would have any better idea of which
> manager to use than omapdss.
>
> But as doing the connections at probe time is a bit problematic, perhaps
> we should have a new step in this whole sequence. Something like
> "connect" or whatever, which would lock the required blocks in the whole
> pipeline, and acquire the required resources that couldn't be gotten at
> probe time.
>
> 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' better compared to a panel's probe.
Even omapdrm/omafb can't be perfect because we could insert a panel
driver module at any time, and omapfb/omapdrm may miss that out.
Archit
WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, rob@ti.com
Subject: Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
Date: Fri, 2 Nov 2012 17:26:35 +0530 [thread overview]
Message-ID: <5093B4F3.1000703@ti.com> (raw)
In-Reply-To: <5093AE79.9010603@ti.com>
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 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
>
> Hmm, I'm not sure I understand what's your point above? If figuring out
> the mgr is done in panel's probe, the mgr->output link is not yet made
> before that time.
My point is that we are trying to find a manager at panel's probe
itself. It think that's what we do now. But one of your recent patch
moves that to omapfb.
>
>> omapfb/omapdrm have just the job of connecting the overlays to the
>> manager. Do you think that's okay?
>
> Yes, that's how I think it should be. I don't see why omapfb/omapdrm
> should care about which manager is being used for the output, it doesn't
> really matter as long there is one and it works.
>
> Then again, I don't have anything against omapfb/omapdrm choosing the
> manager, but I don't see how they would have any better idea of which
> manager to use than omapdss.
>
> But as doing the connections at probe time is a bit problematic, perhaps
> we should have a new step in this whole sequence. Something like
> "connect" or whatever, which would lock the required blocks in the whole
> pipeline, and acquire the required resources that couldn't be gotten at
> probe time.
>
> 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' better compared to a panel's probe.
Even omapdrm/omafb can't be perfect because we could insert a panel
driver module at any time, and omapfb/omapdrm may miss that out.
Archit
next prev parent reply other threads:[~2012-11-02 11:56 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 16:09 [PATCH 00/12] OMAPDSS: use DSI PLL clk for DPI Tomi Valkeinen
2012-10-30 16:09 ` Tomi Valkeinen
2012-10-30 16:09 ` [PATCH 01/12] OMAPFB: remove use of extended edid block Tomi Valkeinen
2012-10-30 16:09 ` Tomi Valkeinen
2012-10-31 6:10 ` Archit Taneja
2012-10-31 6:22 ` Archit Taneja
2012-10-31 6:23 ` Tomi Valkeinen
2012-10-31 6:23 ` Tomi Valkeinen
2012-10-30 16:09 ` [PATCH 02/12] OMAPFB: improve mode selection from EDID Tomi Valkeinen
2012-10-30 16:09 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 03/12] OMAPDSS: fix DPI & DSI init order Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck >= 100MHz Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 6:45 ` Archit Taneja
2012-10-31 6:57 ` Archit Taneja
2012-10-31 7:26 ` Tomi Valkeinen
2012-10-31 7:26 ` Tomi Valkeinen
2012-10-31 7:32 ` Archit Taneja
2012-10-31 7:44 ` Archit Taneja
2012-10-30 16:10 ` [PATCH 06/12] OMAPDSS: DSI: workaround for HSDiv problem Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 08/12] OMAPDSS: setup default dss fck Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 6:31 ` Archit Taneja
2012-10-31 6:43 ` Archit Taneja
2012-10-31 7:32 ` Tomi Valkeinen
2012-10-31 7:32 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source() Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 6:54 ` Archit Taneja
2012-10-31 6:54 ` Archit Taneja
2012-10-31 7:17 ` Tomi Valkeinen
2012-10-31 7:17 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 10/12] OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 11/12] OMAPDSS: DPI: verify if DSI PLL is operational Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-30 16:10 ` [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available Tomi Valkeinen
2012-10-30 16:10 ` Tomi Valkeinen
2012-10-31 7:26 ` Archit Taneja
2012-10-31 7:38 ` Archit Taneja
2012-11-02 10:08 ` Tomi Valkeinen
2012-11-02 10:08 ` Tomi Valkeinen
2012-11-02 10:44 ` Archit Taneja
2012-11-02 10:56 ` Archit Taneja
2012-11-02 10:49 ` Tomi Valkeinen
2012-11-02 10:49 ` Tomi Valkeinen
2012-11-02 11:09 ` Archit Taneja
2012-11-02 11:21 ` Archit Taneja
2012-11-02 11:28 ` Tomi Valkeinen
2012-11-02 11:28 ` Tomi Valkeinen
2012-11-02 11:56 ` Archit Taneja [this message]
2012-11-02 11:56 ` Archit Taneja
2012-11-05 8:55 ` Tomi Valkeinen
2012-11-05 8:55 ` Tomi Valkeinen
2012-11-05 14:21 ` Rob Clark
2012-11-05 14:21 ` Rob Clark
2012-11-06 13:41 ` Tomi Valkeinen
2012-11-06 13:41 ` Tomi Valkeinen
2012-11-06 14:40 ` Rob Clark
2012-11-06 14:40 ` Rob Clark
2012-11-07 10:01 ` Tomi Valkeinen
2012-11-07 10:01 ` Tomi Valkeinen
2012-11-07 14:32 ` Rob Clark
2012-11-07 14:32 ` Rob Clark
2012-11-07 15:13 ` Tomi Valkeinen
2012-11-07 15:13 ` Tomi Valkeinen
2012-11-07 19:18 ` Rob Clark
2012-11-07 19:18 ` Rob Clark
2012-11-08 7:39 ` Tomi Valkeinen
2012-11-08 7:39 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5093B4F3.1000703@ti.com \
--to=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=rob@ti.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.