From: Archit Taneja <archit@ti.com>
To: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
Date: Fri, 01 Apr 2011 09:38:36 +0000 [thread overview]
Message-ID: <4D959A4C.3050305@ti.com> (raw)
In-Reply-To: <1301647184.3393.29.camel@deskari>
On Friday 01 April 2011 02:09 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:
>
>> But there are some parameters which might get common across dss devices.
>> Things like dispc clock source, dispc core clock divider will be shared
>> across the panels. We had discussed the possibility of declaring this
>> common info in omap_dss_board_info or as a separate common_clocks
>> structure. Each device could pick this filled up common_clocks struct,
>> or fill it up its own way (for the use cases which has only one panel on
>> at a time). I was wondering if it would be easy to move to this approach
>> with your patch. dispc itself would now have some common clock stuff and
>> per panel clock stuff. Is that a very clean approach?
>
> I don't know =). I think the simplest solution is to have full divisor
> info for each dss_device. And it's up to the board file writer to make
> sure the divisors match for all the displays that can be enabled at the
> same time.
>
> I don't think that is perfect, but trying to share the data sounds a bit
> confusing. Especially as there are just a divisor and a clock source
> that are shared. If we have a lot of common data, then a shared struct
> would of course be better.
>
>> Anyway, I think it would be good to have a channel struct, as there are
>> more things to put in dispc clocks, it should look something like:
>>
>> struct clocks {
>> struct {
>> struct {
>> u16 lck_div;
>> u16 pck_div;
>> enum clock_source lcd_clk_src;
>> } channel;
>> ...
>> ...
>> u16 core_clk_div;
>> } dispc;
>> ...
>> ...
>> };
>
> In my original patch I had:
>
> struct {
> struct {
> u16 fck_div;
> } dss;
>
> struct {
> u16 lck_div;
> u16 pck_div;
>
> bool fclk_from_dsi_pll;
> } dispc;
>
> ...
> };
>
> Which I removed due to comments and slight confusion how to handle the
> DSS_FCLK divisor and the clock source.
>
> Adding the clock source there needs some more work, moving the enum to
> public include file, and implementing the support. If you agree that
> this patch in its current form is an improvement, I'd like to go forward
> with this and work on the clock source later.
Yeah it is, sure.
Archit
WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <archit@ti.com>
To: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
Date: Fri, 1 Apr 2011 14:56:36 +0530 [thread overview]
Message-ID: <4D959A4C.3050305@ti.com> (raw)
In-Reply-To: <1301647184.3393.29.camel@deskari>
On Friday 01 April 2011 02:09 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:
>
>> But there are some parameters which might get common across dss devices.
>> Things like dispc clock source, dispc core clock divider will be shared
>> across the panels. We had discussed the possibility of declaring this
>> common info in omap_dss_board_info or as a separate common_clocks
>> structure. Each device could pick this filled up common_clocks struct,
>> or fill it up its own way (for the use cases which has only one panel on
>> at a time). I was wondering if it would be easy to move to this approach
>> with your patch. dispc itself would now have some common clock stuff and
>> per panel clock stuff. Is that a very clean approach?
>
> I don't know =). I think the simplest solution is to have full divisor
> info for each dss_device. And it's up to the board file writer to make
> sure the divisors match for all the displays that can be enabled at the
> same time.
>
> I don't think that is perfect, but trying to share the data sounds a bit
> confusing. Especially as there are just a divisor and a clock source
> that are shared. If we have a lot of common data, then a shared struct
> would of course be better.
>
>> Anyway, I think it would be good to have a channel struct, as there are
>> more things to put in dispc clocks, it should look something like:
>>
>> struct clocks {
>> struct {
>> struct {
>> u16 lck_div;
>> u16 pck_div;
>> enum clock_source lcd_clk_src;
>> } channel;
>> ...
>> ...
>> u16 core_clk_div;
>> } dispc;
>> ...
>> ...
>> };
>
> In my original patch I had:
>
> struct {
> struct {
> u16 fck_div;
> } dss;
>
> struct {
> u16 lck_div;
> u16 pck_div;
>
> bool fclk_from_dsi_pll;
> } dispc;
>
> ...
> };
>
> Which I removed due to comments and slight confusion how to handle the
> DSS_FCLK divisor and the clock source.
>
> Adding the clock source there needs some more work, moving the enum to
> public include file, and implementing the support. If you agree that
> this patch in its current form is an improvement, I'd like to go forward
> with this and work on the clock source later.
Yeah it is, sure.
Archit
next prev parent reply other threads:[~2011-04-01 9:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-31 10:10 [PATCH 0/9] Miscellaneous OMAP DSS patches Tomi Valkeinen
2011-03-31 10:10 ` Tomi Valkeinen
2011-03-31 10:10 ` [PATCH 1/9] OMAP: DSS2: move dss device clock configuration Tomi Valkeinen
2011-03-31 10:10 ` Tomi Valkeinen
2011-04-01 7:05 ` Archit Taneja
2011-04-01 7:17 ` Archit Taneja
2011-04-01 7:07 ` Tomi Valkeinen
2011-04-01 7:07 ` Tomi Valkeinen
2011-04-01 7:47 ` Archit Taneja
2011-04-01 7:51 ` Archit Taneja
2011-04-01 7:50 ` Tomi Valkeinen
2011-04-01 7:50 ` Tomi Valkeinen
2011-04-01 8:19 ` Archit Taneja
2011-04-01 8:31 ` Archit Taneja
2011-04-01 8:39 ` Tomi Valkeinen
2011-04-01 8:39 ` Tomi Valkeinen
2011-04-01 9:26 ` Archit Taneja [this message]
2011-04-01 9:38 ` Archit Taneja
2011-03-31 10:10 ` [PATCH 2/9] OMAP: DSS2: remove non-working msleep(40) workaround Tomi Valkeinen
2011-03-31 10:10 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 3/9] OMAP: DSS2: make 50ms bug-fix sleep optional Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 4/9] OMAP: DSS2: VENC: make 20ms venc " Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 5/9] OMAP: DSS2: VENC: Remove sleeps at venc enable/disable Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 6/9] OMAP: DSS2: Add method for querying display dimensions from DSS drivers Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 7/9] OMAP: DSS2: OMAPFB: Handle errors when initializing panel Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 8/9] OMAP: DSS2: OMAPFB: Remove implicit display update on unblank Tomi Valkeinen
2011-03-31 10:11 ` Tomi Valkeinen
2011-03-31 10:11 ` [PATCH 9/9] OMAP: DSS2: VENC: Add missing start/stop_device calls Tomi Valkeinen
2011-03-31 10:11 ` 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=4D959A4C.3050305@ti.com \
--to=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--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.