All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <t.figa@samsung.com>
To: Kukjin Kim <kgene.kim@samsung.com>, linux-samsung-soc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	'Marek Szyprowski' <m.szyprowski@samsung.com>,
	'Mike Turquette' <mturquette@linaro.org>,
	'Rob Herring' <robh+dt@kernel.org>,
	'Mark Rutland' <mark.rutland@arm.com>,
	'Pankaj Dubey' <pankaj.dubey@samsung.com>,
	'Rahul Sharma' <rahul.sharma@samsung.com>,
	'Mark Brown' <broonie@kernel.org>,
	'Sylwester Nawrocki' <s.nawrocki@samsung.com>,
	'Daniel Drake' <drake@endlessm.com>,
	'Tomasz Figa' <tomasz.figa@gmail.com>
Subject: Re: [PATCH v2 0/4] Add support for Exynos clock output configuration
Date: Wed, 25 Jun 2014 12:50:42 +0200	[thread overview]
Message-ID: <53AAA982.9050308@samsung.com> (raw)
In-Reply-To: <026001cf9061$5fef9d00$1fced700$@samsung.com>

Hi Kukjin,

On 25.06.2014 12:36, Kukjin Kim wrote:
> Tomasz Figa wrote:
>>
> Hi Tomasz,
> 
>> On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of
>> internal SoC clocks to be output from the SoC. The hardware structure
> 
> Yeah, because the CLKOUT pin is used for measure of the clock for debug on all
> of exynos SoCs commonly.
> 
>> of CLKOUT related clocks looks as follows:
>>
>> 	CMU	|---> clock0 --------->	|	PMU	|
>> 		|			|		|
>>     several	|---> clock1 ---------> |	mux	|
>>     muxes	|			|	+	|---> CLKOUT
>>     dividers	|       ...		|	gate	|
>>     and gates	|			|		|
>> 		|---> clockN ---------> |		|
>>
>> Since the block responsible for handling the pin is PMU, not CMU,
>> a separate driver, that binds to PMU node is required and acquires
>> all input clocks by standard DT clock look-up. This way we don't need
>> any cross-IP block drivers and cross-driver register sharing or
>> nodes for fake devices.
>>
> BTW, upcoming exynos5 SoCs have two muxs for CLKOUT and each mux is controlled
> by CMU and PMU, so
> 
> The mux1 for CLKOUT in CMU is used to decide which clock in each sub-domain
> will be out and the mux2 in PMU is used to decide which sub-domain will be out
> via CLKOUT. So I want you to consider of all of exynos SoCs including upcoming
> SoCs.

Is it something similar to what I implemented for Exynos4 in patch 2/4?
The same has to be done for other Exynos SoCs as well, but i don't have
any board on which I could test this, so I just added a subset of
available inputs of PMU mux in current implementation.

Anyway, anything in CMU can be handled in normal SoC clock driver, so I
don't think this poses any problem for this series.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: t.figa@samsung.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/4] Add support for Exynos clock output configuration
Date: Wed, 25 Jun 2014 12:50:42 +0200	[thread overview]
Message-ID: <53AAA982.9050308@samsung.com> (raw)
In-Reply-To: <026001cf9061$5fef9d00$1fced700$@samsung.com>

Hi Kukjin,

On 25.06.2014 12:36, Kukjin Kim wrote:
> Tomasz Figa wrote:
>>
> Hi Tomasz,
> 
>> On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of
>> internal SoC clocks to be output from the SoC. The hardware structure
> 
> Yeah, because the CLKOUT pin is used for measure of the clock for debug on all
> of exynos SoCs commonly.
> 
>> of CLKOUT related clocks looks as follows:
>>
>> 	CMU	|---> clock0 --------->	|	PMU	|
>> 		|			|		|
>>     several	|---> clock1 ---------> |	mux	|
>>     muxes	|			|	+	|---> CLKOUT
>>     dividers	|       ...		|	gate	|
>>     and gates	|			|		|
>> 		|---> clockN ---------> |		|
>>
>> Since the block responsible for handling the pin is PMU, not CMU,
>> a separate driver, that binds to PMU node is required and acquires
>> all input clocks by standard DT clock look-up. This way we don't need
>> any cross-IP block drivers and cross-driver register sharing or
>> nodes for fake devices.
>>
> BTW, upcoming exynos5 SoCs have two muxs for CLKOUT and each mux is controlled
> by CMU and PMU, so
> 
> The mux1 for CLKOUT in CMU is used to decide which clock in each sub-domain
> will be out and the mux2 in PMU is used to decide which sub-domain will be out
> via CLKOUT. So I want you to consider of all of exynos SoCs including upcoming
> SoCs.

Is it something similar to what I implemented for Exynos4 in patch 2/4?
The same has to be done for other Exynos SoCs as well, but i don't have
any board on which I could test this, so I just added a subset of
available inputs of PMU mux in current implementation.

Anyway, anything in CMU can be handled in normal SoC clock driver, so I
don't think this poses any problem for this series.

Best regards,
Tomasz

  reply	other threads:[~2014-06-25 10:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 16:08 [PATCH v2 0/4] Add support for Exynos clock output configuration Tomasz Figa
2014-06-24 16:08 ` Tomasz Figa
2014-06-24 16:08 ` [PATCH v2 1/4] clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy Tomasz Figa
2014-06-24 16:08   ` Tomasz Figa
2014-06-24 16:08 ` [PATCH v2 2/4] clk: samsung: exynos4: Add CLKOUT " Tomasz Figa
2014-06-24 16:08   ` Tomasz Figa
2014-06-24 16:08   ` Tomasz Figa
2014-06-24 16:08 ` [PATCH v2 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs Tomasz Figa
2014-06-24 16:08   ` Tomasz Figa
2014-06-24 16:08 ` [PATCH v2 4/4] ARM: dts: exynos: Update PMU node with CLKOUT related data Tomasz Figa
2014-06-24 16:08   ` Tomasz Figa
2014-06-25  8:56 ` [PATCH v2 0/4] Add support for Exynos clock output configuration Daniel Drake
2014-06-25  8:56   ` Daniel Drake
2014-06-25 10:36 ` Kukjin Kim
2014-06-25 10:36   ` Kukjin Kim
2014-06-25 10:50   ` Tomasz Figa [this message]
2014-06-25 10:50     ` Tomasz Figa
2014-07-03  0:14   ` Mike Turquette
2014-07-03  0:14     ` Mike Turquette
2014-07-08 14:04     ` Tomasz Figa
2014-07-08 14:04       ` Tomasz Figa
2014-07-09 16:53 ` Tomasz Figa
2014-07-09 16:53   ` Tomasz Figa

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=53AAA982.9050308@samsung.com \
    --to=t.figa@samsung.com \
    --cc=broonie@kernel.org \
    --cc=drake@endlessm.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=pankaj.dubey@samsung.com \
    --cc=rahul.sharma@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=s.nawrocki@samsung.com \
    --cc=tomasz.figa@gmail.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.