Patchwork [GIT,PULL,5/8] ARM: tegra: SCU base rework

login
register
mail settings
Submitter Stephen Warren
Date Jan. 30, 2013, 9:42 p.m.
Message ID <1359582159-28816-5-git-send-email-swarren@wwwdotorg.org>
Download mbox
Permalink /patch/217179/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-scu-base-rework

Comments

Stephen Warren - Jan. 30, 2013, 9:42 p.m.
Tegra currently relies on the SCU to determine the number of CPU
cores, and also hard-codes the SCU physical address.

This series adds a /cpus node to the Tegra device tree, and updates
the code to rely solely on that to determine the CPU count. A new
API is introduced to query for the existence of SCU registers, and the
SCU register address. Tegra and OMAP2 are converted to use these new
APIs.

This pull request is based on a merge of v3.8-rc3, and arm-soc's
depends/rmk-perf branch.

----------------------------------------------------------------

The following changes since commit 5681f76576af872ced97e8c58ccab3c84a6627e6:

  Merge remote-tracking branch 'korg_arm-soc/depends/rmk-perf' into for-3.9/scu-base-rework

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-scu-base-rework

for you to fetch changes up to 80d9375617f7544f7475e7f07003a08930559d43:

  ARM: OMAP: Make use of available scu_a9_get_base() interface

----------------------------------------------------------------

Hiroshi Doyu (5):
      ARM: tegra: Add CPU nodes to Tegra20 device tree
      ARM: tegra: Add CPU nodes to Tegra30 device tree
      ARM: tegra: Use DT /cpu node to detect number of CPU core
      ARM: Add API to detect SCU base address from CP15
      ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9

Santosh Shilimkar (1):
      ARM: OMAP: Make use of available scu_a9_get_base() interface

 arch/arm/boot/dts/tegra20.dtsi |   17 +++++++++++++++++
 arch/arm/boot/dts/tegra30.dtsi |   29 +++++++++++++++++++++++++++++
 arch/arm/include/asm/smp_scu.h |   17 +++++++++++++++++
 arch/arm/mach-omap2/omap-smp.c |    2 +-
 arch/arm/mach-omap2/omap44xx.h |    1 -
 arch/arm/mach-tegra/platsmp.c  |   20 ++------------------
 6 files changed, 66 insertions(+), 20 deletions(-)
Olof Johansson - Feb. 1, 2013, 4:32 a.m.
On Wed, Jan 30, 2013 at 02:42:36PM -0700, Stephen Warren wrote:
> Tegra currently relies on the SCU to determine the number of CPU
> cores, and also hard-codes the SCU physical address.
> 
> This series adds a /cpus node to the Tegra device tree, and updates
> the code to rely solely on that to determine the CPU count. A new
> API is introduced to query for the existence of SCU registers, and the
> SCU register address. Tegra and OMAP2 are converted to use these new
> APIs.
> 
> This pull request is based on a merge of v3.8-rc3, and arm-soc's
> depends/rmk-perf branch.

This one looks like it should also be based on your cleanup, since it has
conflicts with it. Please rebase accordingly.


-Olof
Olof Johansson - Feb. 1, 2013, 4:35 a.m.
On Thu, Jan 31, 2013 at 8:32 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Jan 30, 2013 at 02:42:36PM -0700, Stephen Warren wrote:
>> Tegra currently relies on the SCU to determine the number of CPU
>> cores, and also hard-codes the SCU physical address.
>>
>> This series adds a /cpus node to the Tegra device tree, and updates
>> the code to rely solely on that to determine the CPU count. A new
>> API is introduced to query for the existence of SCU registers, and the
>> SCU register address. Tegra and OMAP2 are converted to use these new
>> APIs.
>>
>> This pull request is based on a merge of v3.8-rc3, and arm-soc's
>> depends/rmk-perf branch.
>
> This one looks like it should also be based on your cleanup, since it has
> conflicts with it. Please rebase accordingly.

By the way, just in case this looks like a random request...

A few merge conflicts between independent topic branches is not a big
deal; we can deal with those.

What's somewhat annoying though, is when a previous cleanup branch
conflicts with later features. So, please base features on top of
cleanups accordingly.


Thanks,

-Olof
Stephen Warren - Feb. 1, 2013, 4:46 a.m.
On 01/31/2013 09:35 PM, Olof Johansson wrote:
> On Thu, Jan 31, 2013 at 8:32 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Wed, Jan 30, 2013 at 02:42:36PM -0700, Stephen Warren wrote:
>>> Tegra currently relies on the SCU to determine the number of CPU
>>> cores, and also hard-codes the SCU physical address.
>>>
>>> This series adds a /cpus node to the Tegra device tree, and updates
>>> the code to rely solely on that to determine the CPU count. A new
>>> API is introduced to query for the existence of SCU registers, and the
>>> SCU register address. Tegra and OMAP2 are converted to use these new
>>> APIs.
>>>
>>> This pull request is based on a merge of v3.8-rc3, and arm-soc's
>>> depends/rmk-perf branch.
>>
>> This one looks like it should also be based on your cleanup, since it has
>> conflicts with it. Please rebase accordingly.
> 
> By the way, just in case this looks like a random request...
> 
> A few merge conflicts between independent topic branches is not a big
> deal; we can deal with those.
> 
> What's somewhat annoying though, is when a previous cleanup branch
> conflicts with later features. So, please base features on top of
> cleanups accordingly.

Hmm. And here I was thinking that I was basing branches on top of
each-other too much given your previous comments about merge conflicts
being OK!

In case it helps, the following commit in linux-next shows the conflict
resolution:

ee05948 Merge branch 'for-3.9/scu-base-rework' into for-3.9/soc-t114

I guess I missed this because I didn't merge for-3.9/scu-base-rework
into my for-next on its own, but only as part of for-3.9/soc-t114,
within which I had resolved the conflict as above.

So, you could just skip this pull request, and it'll be pulled in when
you merge for-3.9/soc-t114.

It that doesn't work for you, I can do the rebase tomorrow morning.
Arnd Bergmann - Feb. 1, 2013, 3:51 p.m.
On Friday 01 February 2013, Stephen Warren wrote:
> Hmm. And here I was thinking that I was basing branches on top of
> each-other too much given your previous comments about merge conflicts
> being OK!

IMHO the cleanup branches are special in this regard because they
are primarily meant as a way to resolve the merge conflicts.
If you are able to put all the conflicts between the normal branches
into cleanup patches, you can put them all in one branch and
base your other branches on top of that. Of course that doesn't
always work, but it would solve this particular instance.

	Arnd