All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Peter De Schrijver
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Mike Turquette
	<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Prashant Gaikwad
	<pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
Date: Mon, 7 Oct 2013 16:53:44 +0200	[thread overview]
Message-ID: <20131007145343.GA19045@ulmo.nvidia.com> (raw)
In-Reply-To: <20131007142839.GC3973-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

On Mon, Oct 07, 2013 at 05:28:39PM +0300, Peter De Schrijver wrote:
> On Mon, Oct 07, 2013 at 02:14:33AM +0200, Mike Turquette wrote:
> > Quoting Stephen Warren (2013-10-04 10:00:38)
> > > On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > > > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > > > same names on Tegra114 for consistency.
> > > 
> > > The series,
> > > Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > 
> > > Although I wonder if there will be merge conflicts with Peter's "clk:
> > > tegra: replace enum tegra114_clk by binding header"?
> > 
> > There are merge conflicts in other places too. The latest clk-next
> > branch is based on -rc3 with only a few patches (publicly) applied so
> > far. As of the time of this writing the top-most commit is
> > 96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.
> > 
> > Can the Tegra folks send me a pull request with the following
> > patches applied? (likely in this order):
> > 
> > ARM: tegra114: add missing clocks to binding
> > clk: tegra: replace enum tegra114_clk by binding header
> > [PATCH v2] clk: tegra: Correct sbc mux width & parent
> > clk: tegra: Fix vde/2d/3d clock src offset
> > clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
> > clk: tegra: Set the clk parent of host1x to pll_p
> > clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
> > clk: tegra114: Initialize gr2d clock
> 
> This conflicts with 'clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2'
> I suggest we drop 'clk: tegra114: Initialize gr2d clock' and use pll_c2 to clock gr2d.

What's wrong with pll_c? We've used it for Tegra20 and Tegra30 and I
have at least tested that gr2d works properly with it. It will also
cause both host1x and gr2d to run off the same clock, which I guess may
not matter at all.

Furthermore we've usually only added clock initialization when a driver
became available to use it. There is currently no driver for gr3d in the
upstream kernel, so perhaps we should leave the gr3d clock unconfigured
for now?

> > The set of patches above (with their functional dependencies) were
> > giving me some conflict resolution issues (e.g. large data tables that
> > needed to be updated in clk-tegra-114.c) against the latest clk-next.
> > 
> > Additionally I've looked at the following patches on the list which can
> > be added to the pull request if you want (these patches all look fine
> > but I haven't yet Acked each individually):
> > 
> > clk: tegra30: Don't wait for PLL_U lock bit
> 
> This is already part of next-20130927.
> 
> > clk: tegra114: Initialize host1x and related clocks
> 
> This conflicts with 'clk: tegra: Set the clk parent of host1x to pll_p'. I
> suggest we drop 'clk: tegra: Set the clk parent of host1x to pll_p' and run
> host1x from pll_c. Mark, Thierry, is this ok?

Sounds good to me. We use pll_c for host1x on earlier SoC generations as
well.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
Date: Mon, 7 Oct 2013 16:53:44 +0200	[thread overview]
Message-ID: <20131007145343.GA19045@ulmo.nvidia.com> (raw)
In-Reply-To: <20131007142839.GC3973@tbergstrom-lnx.Nvidia.com>

On Mon, Oct 07, 2013 at 05:28:39PM +0300, Peter De Schrijver wrote:
> On Mon, Oct 07, 2013 at 02:14:33AM +0200, Mike Turquette wrote:
> > Quoting Stephen Warren (2013-10-04 10:00:38)
> > > On 10/02/2013 03:12 PM, Thierry Reding wrote:
> > > > These clocks were named gr2d and gr3d on Tegra20 and Tegra30, so use the
> > > > same names on Tegra114 for consistency.
> > > 
> > > The series,
> > > Acked-by: Stephen Warren <swarren@nvidia.com>
> > > 
> > > Although I wonder if there will be merge conflicts with Peter's "clk:
> > > tegra: replace enum tegra114_clk by binding header"?
> > 
> > There are merge conflicts in other places too. The latest clk-next
> > branch is based on -rc3 with only a few patches (publicly) applied so
> > far. As of the time of this writing the top-most commit is
> > 96a7ed9079a3483c5681b17f4713c37c1cf2b1c9.
> > 
> > Can the Tegra folks send me a pull request with the following
> > patches applied? (likely in this order):
> > 
> > ARM: tegra114: add missing clocks to binding
> > clk: tegra: replace enum tegra114_clk by binding header
> > [PATCH v2] clk: tegra: Correct sbc mux width & parent
> > clk: tegra: Fix vde/2d/3d clock src offset
> > clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2
> > clk: tegra: Set the clk parent of host1x to pll_p
> > clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d
> > clk: tegra114: Initialize gr2d clock
> 
> This conflicts with 'clk: tegra: Set the clock parent of gr2d/gr3d to pll_c2'
> I suggest we drop 'clk: tegra114: Initialize gr2d clock' and use pll_c2 to clock gr2d.

What's wrong with pll_c? We've used it for Tegra20 and Tegra30 and I
have at least tested that gr2d works properly with it. It will also
cause both host1x and gr2d to run off the same clock, which I guess may
not matter at all.

Furthermore we've usually only added clock initialization when a driver
became available to use it. There is currently no driver for gr3d in the
upstream kernel, so perhaps we should leave the gr3d clock unconfigured
for now?

> > The set of patches above (with their functional dependencies) were
> > giving me some conflict resolution issues (e.g. large data tables that
> > needed to be updated in clk-tegra-114.c) against the latest clk-next.
> > 
> > Additionally I've looked at the following patches on the list which can
> > be added to the pull request if you want (these patches all look fine
> > but I haven't yet Acked each individually):
> > 
> > clk: tegra30: Don't wait for PLL_U lock bit
> 
> This is already part of next-20130927.
> 
> > clk: tegra114: Initialize host1x and related clocks
> 
> This conflicts with 'clk: tegra: Set the clk parent of host1x to pll_p'. I
> suggest we drop 'clk: tegra: Set the clk parent of host1x to pll_p' and run
> host1x from pll_c. Mark, Thierry, is this ok?

Sounds good to me. We use pll_c for host1x on earlier SoC generations as
well.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131007/894433c3/attachment-0001.sig>

  parent reply	other threads:[~2013-10-07 14:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-02 21:12 [PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d Thierry Reding
2013-10-02 21:12 ` Thierry Reding
     [not found] ` <1380748361-32459-1-git-send-email-treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-02 21:12   ` [PATCH 2/2] clk: tegra114: Initialize gr2d clock Thierry Reding
2013-10-02 21:12     ` Thierry Reding
2013-10-04 17:00   ` [PATCH 1/2] clk: tegra114: Rename gr_2d/gr_3d to gr2d/gr3d Stephen Warren
2013-10-04 17:00     ` Stephen Warren
     [not found]     ` <524EF436.4000704-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-07  0:14       ` Mike Turquette
2013-10-07  0:14         ` Mike Turquette
2013-10-07 14:28         ` Peter De Schrijver
2013-10-07 14:28           ` Peter De Schrijver
     [not found]           ` <20131007142839.GC3973-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-10-07 14:53             ` Thierry Reding [this message]
2013-10-07 14:53               ` Thierry Reding
     [not found]               ` <20131007145343.GA19045-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-08  7:53                 ` Peter De Schrijver
2013-10-08  7:53                   ` Peter De Schrijver
     [not found]                   ` <20131008075356.GD3973-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-10-08  8:20                     ` Terje Bergström
2013-10-08  8:20                       ` Terje Bergström

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=20131007145343.GA19045@ulmo.nvidia.com \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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.