From: Magnus Damm <magnus.damm@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
Date: Wed, 09 Oct 2013 07:29:56 +0000 [thread overview]
Message-ID: <CANqRtoSGFEjcBPDAtq3YCDbkiFCftyr8b=qniYqyMafng=zurw@mail.gmail.com> (raw)
In-Reply-To: <20131009065438.GA7220@verge.net.au>
Hi Simon,
On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote:
>> >> Use common clock framework version of clock
>> >> drivers/clk/shmobile/clk-emev2.c
>> >> instead of sh-clkfwk version
>> >> arch/arm/mach-shmobile/clock-emev2.c
>> >> when it is configured as a part of multi-platform.
>> >>
>> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>> >
>> > Thanks.
>> >
>> > I plan to add this patch to a new topic branch,
>> > topic/emev2-common-clock, in the renesas tree and
>> > queue it up from there for inclusion in mainline
>> > if/when the first patch of this series is accepted
>> > by Mike Turquette.
>>
>> Thanks for picking up patches, Simon.
>>
>> I think you can simply merge this patch after the following series:
>>
>> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
>
> This is already queued up.
Yes, I know, thanks for that. I tried to explain the dependency in the
00/00 cover letter but I will try to be more clear next time!
>> There are no build time dependencies on patch 1 and 2 so this patch
>> can be merged independently. Regarding run-time operation, the
>> multiplatform series above makes KZM9D DT reference only build for
>> multiplatform, and in such case CCF is required.
>>
>> So if you want to keep KZM9D DT reference working until Mike Turquette
>> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
>> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
>> have been merged.
>>
>> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
>> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
>> well merge this patch as well IMO. This
>> multiplatform-update-series-merge-before-CCF plan will result in
>> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
>> fine with me.
>
> I am mainly concerned that the bindings may change before
> they are finally merged. And I thought it would be nice to avoid
> having to fix up the usage of the bindings if they change.
Sure, but the code in this patch looks like it simply starts DT CCF
probing regardless of what the bindings look like. So I don't think
you will have to worry about actual bindings detail.
> But I'm happy to just queue-up patches 2 and 3 of this series
> now if you prefer.
Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
/ magnus
WARNING: multiple messages have this Message-ID (diff)
From: Magnus Damm <magnus.damm@gmail.com>
To: Simon Horman <horms@verge.net.au>
Cc: takasi-y@ops.dti.ne.jp, SH-Linux <linux-sh@vger.kernel.org>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>,
Mike Turquette <mturquette@linaro.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
devicetree@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
Date: Wed, 9 Oct 2013 16:29:56 +0900 [thread overview]
Message-ID: <CANqRtoSGFEjcBPDAtq3YCDbkiFCftyr8b=qniYqyMafng=zurw@mail.gmail.com> (raw)
In-Reply-To: <20131009065438.GA7220@verge.net.au>
Hi Simon,
On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote:
>> >> Use common clock framework version of clock
>> >> drivers/clk/shmobile/clk-emev2.c
>> >> instead of sh-clkfwk version
>> >> arch/arm/mach-shmobile/clock-emev2.c
>> >> when it is configured as a part of multi-platform.
>> >>
>> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>> >
>> > Thanks.
>> >
>> > I plan to add this patch to a new topic branch,
>> > topic/emev2-common-clock, in the renesas tree and
>> > queue it up from there for inclusion in mainline
>> > if/when the first patch of this series is accepted
>> > by Mike Turquette.
>>
>> Thanks for picking up patches, Simon.
>>
>> I think you can simply merge this patch after the following series:
>>
>> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
>
> This is already queued up.
Yes, I know, thanks for that. I tried to explain the dependency in the
00/00 cover letter but I will try to be more clear next time!
>> There are no build time dependencies on patch 1 and 2 so this patch
>> can be merged independently. Regarding run-time operation, the
>> multiplatform series above makes KZM9D DT reference only build for
>> multiplatform, and in such case CCF is required.
>>
>> So if you want to keep KZM9D DT reference working until Mike Turquette
>> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
>> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
>> have been merged.
>>
>> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
>> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
>> well merge this patch as well IMO. This
>> multiplatform-update-series-merge-before-CCF plan will result in
>> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
>> fine with me.
>
> I am mainly concerned that the bindings may change before
> they are finally merged. And I thought it would be nice to avoid
> having to fix up the usage of the bindings if they change.
Sure, but the code in this patch looks like it simply starts DT CCF
probing regardless of what the bindings look like. So I don't think
you will have to worry about actual bindings detail.
> But I'm happy to just queue-up patches 2 and 3 of this series
> now if you prefer.
Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
/ magnus
WARNING: multiple messages have this Message-ID (diff)
From: Magnus Damm <magnus.damm@gmail.com>
To: Simon Horman <horms@verge.net.au>
Cc: takasi-y@ops.dti.ne.jp, SH-Linux <linux-sh@vger.kernel.org>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>,
Mike Turquette <mturquette@linaro.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
devicetree@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
Date: Wed, 9 Oct 2013 16:29:56 +0900 [thread overview]
Message-ID: <CANqRtoSGFEjcBPDAtq3YCDbkiFCftyr8b=qniYqyMafng=zurw@mail.gmail.com> (raw)
In-Reply-To: <20131009065438.GA7220@verge.net.au>
Hi Simon,
On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y@ops.dti.ne.jp wrote:
>> >> Use common clock framework version of clock
>> >> drivers/clk/shmobile/clk-emev2.c
>> >> instead of sh-clkfwk version
>> >> arch/arm/mach-shmobile/clock-emev2.c
>> >> when it is configured as a part of multi-platform.
>> >>
>> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>> >
>> > Thanks.
>> >
>> > I plan to add this patch to a new topic branch,
>> > topic/emev2-common-clock, in the renesas tree and
>> > queue it up from there for inclusion in mainline
>> > if/when the first patch of this series is accepted
>> > by Mike Turquette.
>>
>> Thanks for picking up patches, Simon.
>>
>> I think you can simply merge this patch after the following series:
>>
>> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
>
> This is already queued up.
Yes, I know, thanks for that. I tried to explain the dependency in the
00/00 cover letter but I will try to be more clear next time!
>> There are no build time dependencies on patch 1 and 2 so this patch
>> can be merged independently. Regarding run-time operation, the
>> multiplatform series above makes KZM9D DT reference only build for
>> multiplatform, and in such case CCF is required.
>>
>> So if you want to keep KZM9D DT reference working until Mike Turquette
>> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
>> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
>> have been merged.
>>
>> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
>> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
>> well merge this patch as well IMO. This
>> multiplatform-update-series-merge-before-CCF plan will result in
>> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
>> fine with me.
>
> I am mainly concerned that the bindings may change before
> they are finally merged. And I thought it would be nice to avoid
> having to fix up the usage of the bindings if they change.
Sure, but the code in this patch looks like it simply starts DT CCF
probing regardless of what the bindings look like. So I don't think
you will have to worry about actual bindings detail.
> But I'm happy to just queue-up patches 2 and 3 of this series
> now if you prefer.
Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
/ magnus
WARNING: multiple messages have this Message-ID (diff)
From: magnus.damm@gmail.com (Magnus Damm)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework
Date: Wed, 9 Oct 2013 16:29:56 +0900 [thread overview]
Message-ID: <CANqRtoSGFEjcBPDAtq3YCDbkiFCftyr8b=qniYqyMafng=zurw@mail.gmail.com> (raw)
In-Reply-To: <20131009065438.GA7220@verge.net.au>
Hi Simon,
On Wed, Oct 9, 2013 at 3:54 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Oct 09, 2013 at 01:59:46PM +0900, Magnus Damm wrote:
>> Hi Simon,
>>
>> On Wed, Oct 9, 2013 at 12:40 PM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, Oct 08, 2013 at 02:34:03PM +0900, takasi-y at ops.dti.ne.jp wrote:
>> >> Use common clock framework version of clock
>> >> drivers/clk/shmobile/clk-emev2.c
>> >> instead of sh-clkfwk version
>> >> arch/arm/mach-shmobile/clock-emev2.c
>> >> when it is configured as a part of multi-platform.
>> >>
>> >> Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
>> >
>> > Thanks.
>> >
>> > I plan to add this patch to a new topic branch,
>> > topic/emev2-common-clock, in the renesas tree and
>> > queue it up from there for inclusion in mainline
>> > if/when the first patch of this series is accepted
>> > by Mike Turquette.
>>
>> Thanks for picking up patches, Simon.
>>
>> I think you can simply merge this patch after the following series:
>>
>> [PATCH 00/05] ARM: shmobile: KZM9D Multiplatform update
>
> This is already queued up.
Yes, I know, thanks for that. I tried to explain the dependency in the
00/00 cover letter but I will try to be more clear next time!
>> There are no build time dependencies on patch 1 and 2 so this patch
>> can be merged independently. Regarding run-time operation, the
>> multiplatform series above makes KZM9D DT reference only build for
>> multiplatform, and in such case CCF is required.
>>
>> So if you want to keep KZM9D DT reference working until Mike Turquette
>> accepts the CCF bits, then I recommend you to wait with "[PATCH 00/05]
>> ARM: shmobile: KZM9D Multiplatform update" until all EMEV2 CCF bits
>> have been merged.
>>
>> Another way is to merge "[PATCH 00/05] ARM: shmobile: KZM9D
>> Multiplatform update" before the EMEV2 CCF bits, but if so you may as
>> well merge this patch as well IMO. This
>> multiplatform-update-series-merge-before-CCF plan will result in
>> untestable KZM9D DT reference until EMEV2 CCF is merged. Either way is
>> fine with me.
>
> I am mainly concerned that the bindings may change before
> they are finally merged. And I thought it would be nice to avoid
> having to fix up the usage of the bindings if they change.
Sure, but the code in this patch looks like it simply starts DT CCF
probing regardless of what the bindings look like. So I don't think
you will have to worry about actual bindings detail.
> But I'm happy to just queue-up patches 2 and 3 of this series
> now if you prefer.
Well, I meant patch 3 only. Patch 1 and 2 are tied together by dependencies. =)
/ magnus
next prev parent reply other threads:[~2013-10-09 7:29 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 5:30 [PATCH v2 0/3] ARM: shmobile: kzm9d: migrate to common clock framework with DT takasi-y
2013-10-08 5:30 ` takasi-y at ops.dti.ne.jp
2013-10-08 5:30 ` takasi-y
2013-10-08 5:32 ` [PATCH v2 1/3] clk: emev2: Add support for emev2 SMU clocks " takasi-y
2013-10-08 5:32 ` takasi-y at ops.dti.ne.jp
2013-10-08 5:32 ` takasi-y
2013-10-08 5:58 ` Magnus Damm
2013-10-08 5:58 ` Magnus Damm
2013-10-08 5:58 ` Magnus Damm
2013-10-08 5:58 ` Magnus Damm
2013-10-09 3:38 ` Simon Horman
2013-10-09 3:38 ` Simon Horman
2013-10-09 3:38 ` Simon Horman
2013-10-09 3:38 ` Simon Horman
2013-10-09 6:10 ` Ben Dooks
2013-10-09 6:10 ` Ben Dooks
2013-10-09 6:10 ` Ben Dooks
2013-10-09 6:10 ` Ben Dooks
2013-10-08 5:33 ` [PATCH v2 2/3] ARM: shmobile: emev2: Add clock tree description in DT takasi-y
2013-10-08 5:33 ` takasi-y at ops.dti.ne.jp
2013-10-08 5:33 ` takasi-y
2013-10-08 5:54 ` Magnus Damm
2013-10-08 5:54 ` Magnus Damm
2013-10-08 5:54 ` Magnus Damm
2013-10-08 5:54 ` Magnus Damm
2013-10-09 3:40 ` Simon Horman
2013-10-09 3:40 ` Simon Horman
2013-10-09 3:40 ` Simon Horman
2013-10-09 3:40 ` Simon Horman
2013-10-08 5:34 ` [PATCH v2 3/3] ARM: shmobile: kzm9d: Use common clock framework takasi-y
2013-10-08 5:34 ` takasi-y at ops.dti.ne.jp
2013-10-08 5:34 ` takasi-y
2013-10-08 5:52 ` Magnus Damm
2013-10-08 5:52 ` Magnus Damm
2013-10-08 5:52 ` Magnus Damm
2013-10-08 5:52 ` Magnus Damm
2013-10-09 3:40 ` Simon Horman
2013-10-09 3:40 ` Simon Horman
2013-10-09 3:40 ` Simon Horman
2013-10-09 4:59 ` Magnus Damm
2013-10-09 4:59 ` Magnus Damm
2013-10-09 4:59 ` Magnus Damm
2013-10-09 4:59 ` Magnus Damm
2013-10-09 6:54 ` Simon Horman
2013-10-09 6:54 ` Simon Horman
2013-10-09 6:54 ` Simon Horman
2013-10-09 6:54 ` Simon Horman
2013-10-09 7:29 ` Magnus Damm [this message]
2013-10-09 7:29 ` Magnus Damm
2013-10-09 7:29 ` Magnus Damm
2013-10-09 7:29 ` Magnus Damm
2013-10-09 10:39 ` Simon Horman
2013-10-09 10:39 ` Simon Horman
2013-10-09 10:39 ` Simon Horman
2013-10-09 10:39 ` Simon Horman
2013-10-29 4:42 ` Simon Horman
2013-10-29 4:42 ` Simon Horman
2013-10-29 4:42 ` Simon Horman
2013-10-29 4:42 ` Simon Horman
2013-12-02 2:25 ` Simon Horman
2013-12-02 2:25 ` Simon Horman
2013-12-02 2:25 ` Simon Horman
2013-12-02 2:25 ` Simon Horman
2013-12-23 6:41 ` Mike Turquette
2013-12-23 6:41 ` Mike Turquette
2013-12-23 6:41 ` Mike Turquette
2013-12-23 6:41 ` Mike Turquette
2013-12-23 8:00 ` Simon Horman
2013-12-23 8:00 ` Simon Horman
2013-12-23 8:00 ` Simon Horman
2013-12-23 8:00 ` Simon Horman
2014-01-06 8:10 ` Simon Horman
2014-01-06 8:10 ` Simon Horman
2014-01-06 8:10 ` Simon Horman
2014-01-06 8:10 ` Simon Horman
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='CANqRtoSGFEjcBPDAtq3YCDbkiFCftyr8b=qniYqyMafng=zurw@mail.gmail.com' \
--to=magnus.damm@gmail.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.