[GIT,PULL,1/3] ARM: tegra: core SoC code changes for 3.18

the primary change here gets its address information from DT rather than
iomap.h. This removes one more user of iomap.h, and will help allow the
code to move to a location that can be shared between arch/arm and
arch/arm64.

An unused header file was also removed.

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

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.18-soc

for you to fetch changes up to d37aba521379203b740a2929e6e6f6bd2485f5d7:

  ARM: tegra: remove unused tegra_emc.h

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

Rasmus Villemoes (1):
      ARM: tegra: remove unused tegra_emc.h

Thierry Reding (2):
      of: Add NVIDIA Tegra flow controller bindings
      ARM: tegra: Initialize flow controller from DT

 .../arm/tegra/nvidia,tegra20-flowctrl.txt       | 12 ++++++
 arch/arm/mach-tegra/flowctrl.c                  | 44 ++++++++++++++++----
 arch/arm/mach-tegra/flowctrl.h                  |  2 +
 arch/arm/mach-tegra/tegra.c                     |  2 +
 include/linux/platform_data/tegra_emc.h         | 34 ---------------
 5 files changed, 53 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt
 delete mode 100644 include/linux/platform_data/tegra_emc.h

On Thursday 18 September 2014, Stephen Warren wrote:
> the primary change here gets its address information from DT rather than
> iomap.h. This removes one more user of iomap.h, and will help allow the
> code to move to a location that can be shared between arch/arm and
> arch/arm64.
> 
> An unused header file was also removed.
> 

Pulled all three into the respective soc, dt and defconfig branches.

The defconfig branch was based on -rc2 rather than -rc1, which is mildly
annoying since it means we are backmerging commits from upstream, please
try to avoid that in the future, or describe why it was done if you
had a good reason.

Also I noticed that your defconfig changes enable things in the tegra
defconfig that are not part of multi_v7_defconfig. Could you create
another patch to enable everything you need in terms of Tegra hardware
support in multi_v7_defconfig as well, preferably as loadable modules?

Thanks!

	Arnd

On 09/25/2014 10:01 AM, Arnd Bergmann wrote:
> On Thursday 18 September 2014, Stephen Warren wrote:
>> the primary change here gets its address information from DT rather than
>> iomap.h. This removes one more user of iomap.h, and will help allow the
>> code to move to a location that can be shared between arch/arm and
>> arch/arm64.
>>
>> An unused header file was also removed.
>>
>
> Pulled all three into the respective soc, dt and defconfig branches.
>
> The defconfig branch was based on -rc2 rather than -rc1, which is mildly
> annoying since it means we are backmerging commits from upstream, please
> try to avoid that in the future, or describe why it was done if you
> had a good reason.

Hmm. I don't understand the issue here.

I don't recall the exact commits, but I ended up needing to base one of 
the branches on -rc2. So, I then based all the branches on the same 
commit. When I create Tegra's for-next, I start with that baseline 
branch and merge in each Tegra topic branch. That way, the merges only 
bring in exactly what's in that branch, and it's easy to validate the 
final result in gitk/similar. I suppose it'd work fine if I start with 
the newest base of any branch and then merged the topic branches in; 
that would at least restrict the merges to only the contents of the 
branch, although it'd create a far more difficult to validate history, 
since the different topic branches would be based in different places.

> Also I noticed that your defconfig changes enable things in the tegra
> defconfig that are not part of multi_v7_defconfig. Could you create
> another patch to enable everything you need in terms of Tegra hardware
> support in multi_v7_defconfig as well, preferably as loadable modules?

I had asked individual authors of the various defconfig changes to 
submit equivalent changes to multi_v7_defconfig, and I thought they had. 
I guess I'll take a look and see what's missing.

On Thursday 25 September 2014 10:40:46 Stephen Warren wrote:
> 
> I don't recall the exact commits, but I ended up needing to base one of 
> the branches on -rc2. So, I then based all the branches on the same 
> commit. When I create Tegra's for-next, I start with that baseline 
> branch and merge in each Tegra topic branch. That way, the merges only 
> bring in exactly what's in that branch, and it's easy to validate the 
> final result in gitk/similar.

I see. For us it's actually more helpful if every single topic branch
is on the oldest possible state.

> I suppose it'd work fine if I start with 
> the newest base of any branch and then merged the topic branches in; 
> that would at least restrict the merges to only the contents of the 
> branch, although it'd create a far more difficult to validate history, 
> since the different topic branches would be based in different places.

Yes, I fear there is no perfect solution to this. Someone also suggested
switching around the parent commits during a merge that updates one of
our branches to a newer base. That would solve the backmerge problem but
in turn break 'git log --first-parent'.

	Arnd