All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ying.Liu@freescale.com (Liu Ying)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] refactor some ldb related clocks
Date: Tue, 20 Aug 2013 18:08:48 +0800	[thread overview]
Message-ID: <52134030.4030502@freescale.com> (raw)
In-Reply-To: <1376991823.4000.22.camel@pizza.hi.pengutronix.de>

On 08/20/2013 05:43 PM, Philipp Zabel wrote:
> Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
>> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
>> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
>> drivider or a 1/7 divider. The common clock framework cannot
>> deal with the two dividers directly even with the divider table
>> which only supports integral dividers. So, the idea is to take
>> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and
>> introduce a new multiplexer clock to be derived from the them.
>> Then, the ldb display clock trees can be setup correctly.
>> This series contains the necessary clock driver changes, dts code
>> changes and imx-drm/ldb driver changes to fullfill the task.
> 
> I don't see how this improves the situation. Does this solve any real
> problem?
>

I don't see any functional problem without this series.
But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider.
Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e.,
only calling clk_set_rate() for ldb_di[n] clock would be an alternative.

> While I admit to having introduced the combination of 1/3.5 fixed
> divider and configurable 1/1,1/2 divder clocks to describe this
> fractional divider for the reasons you state, I think the correct
> solution would be to improve the table divider to support fractional
> values and get rid of the virtual ldb_di<n>_div_3_5 clocks, not
> introduce more virtual clocks.

Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this).
I see there is something similar in 'include/linux/sh_clk.h'.

> 
> regards
> Philipp
> 
> 

Regards,
Liu Ying

WARNING: multiple messages have this Message-ID (diff)
From: Liu Ying <Ying.Liu@freescale.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: kernel@pengutronix.de, gregkh@linuxfoundation.org,
	shawn.guo@linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/3] refactor some ldb related clocks
Date: Tue, 20 Aug 2013 18:08:48 +0800	[thread overview]
Message-ID: <52134030.4030502@freescale.com> (raw)
In-Reply-To: <1376991823.4000.22.camel@pizza.hi.pengutronix.de>

On 08/20/2013 05:43 PM, Philipp Zabel wrote:
> Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
>> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
>> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
>> drivider or a 1/7 divider. The common clock framework cannot
>> deal with the two dividers directly even with the divider table
>> which only supports integral dividers. So, the idea is to take
>> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and
>> introduce a new multiplexer clock to be derived from the them.
>> Then, the ldb display clock trees can be setup correctly.
>> This series contains the necessary clock driver changes, dts code
>> changes and imx-drm/ldb driver changes to fullfill the task.
> 
> I don't see how this improves the situation. Does this solve any real
> problem?
>

I don't see any functional problem without this series.
But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider.
Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e.,
only calling clk_set_rate() for ldb_di[n] clock would be an alternative.

> While I admit to having introduced the combination of 1/3.5 fixed
> divider and configurable 1/1,1/2 divder clocks to describe this
> fractional divider for the reasons you state, I think the correct
> solution would be to improve the table divider to support fractional
> values and get rid of the virtual ldb_di<n>_div_3_5 clocks, not
> introduce more virtual clocks.

Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this).
I see there is something similar in 'include/linux/sh_clk.h'.

> 
> regards
> Philipp
> 
> 

Regards,
Liu Ying

WARNING: multiple messages have this Message-ID (diff)
From: Liu Ying <Ying.Liu@freescale.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: <kernel@pengutronix.de>, <gregkh@linuxfoundation.org>,
	<shawn.guo@linaro.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/3] refactor some ldb related clocks
Date: Tue, 20 Aug 2013 18:08:48 +0800	[thread overview]
Message-ID: <52134030.4030502@freescale.com> (raw)
In-Reply-To: <1376991823.4000.22.camel@pizza.hi.pengutronix.de>

On 08/20/2013 05:43 PM, Philipp Zabel wrote:
> Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying:
>> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register
>> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5
>> drivider or a 1/7 divider. The common clock framework cannot
>> deal with the two dividers directly even with the divider table
>> which only supports integral dividers. So, the idea is to take
>> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and
>> introduce a new multiplexer clock to be derived from the them.
>> Then, the ldb display clock trees can be setup correctly.
>> This series contains the necessary clock driver changes, dts code
>> changes and imx-drm/ldb driver changes to fullfill the task.
> 
> I don't see how this improves the situation. Does this solve any real
> problem?
>

I don't see any functional problem without this series.
But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider.
Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e.,
only calling clk_set_rate() for ldb_di[n] clock would be an alternative.

> While I admit to having introduced the combination of 1/3.5 fixed
> divider and configurable 1/1,1/2 divder clocks to describe this
> fractional divider for the reasons you state, I think the correct
> solution would be to improve the table divider to support fractional
> values and get rid of the virtual ldb_di<n>_div_3_5 clocks, not
> introduce more virtual clocks.

Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this).
I see there is something similar in 'include/linux/sh_clk.h'.

> 
> regards
> Philipp
> 
> 

Regards,
Liu Ying


  reply	other threads:[~2013-08-20 10:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  8:38 [PATCH 0/3] refactor some ldb related clocks Liu Ying
2013-08-20  8:38 ` Liu Ying
2013-08-20  8:38 ` Liu Ying
2013-08-20  8:38 ` [PATCH 1/3] ARM: imx6q: " Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20 15:40   ` Fabio Estevam
2013-08-20 15:40     ` Fabio Estevam
2013-08-20 21:18     ` Mike Turquette
2013-08-20 21:18       ` Mike Turquette
2013-08-21  1:40       ` Shawn Guo
2013-08-21  1:40         ` Shawn Guo
2013-08-21  4:20     ` Liu Ying
2013-08-21  4:20       ` Liu Ying
2013-08-20  8:38 ` [PATCH 2/3] ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20  8:38 ` [PATCH 3/3] staging: drm/imx: ldb: correct the ldb di clock trees Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20  8:38   ` Liu Ying
2013-08-20  9:43 ` [PATCH 0/3] refactor some ldb related clocks Philipp Zabel
2013-08-20  9:43   ` Philipp Zabel
2013-08-20 10:08   ` Liu Ying [this message]
2013-08-20 10:08     ` Liu Ying
2013-08-20 10:08     ` Liu Ying
2013-08-21  1:59     ` Shawn Guo
2013-08-21  1:59       ` Shawn Guo
2013-08-21  1:59       ` Shawn Guo
2013-08-21  4:12       ` Liu Ying
2013-08-21  4:12         ` Liu Ying
2013-08-21  4:12         ` Liu Ying

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=52134030.4030502@freescale.com \
    --to=ying.liu@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.