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

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

[Stephen Warren]

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

[GIT PULL 2/3] ARM: tegra: device tree changes for 3.18

[Stephen Warren]

The main highlights are:
* SATA and PCIe support added to Tegra124, and enabled on Jetson TK1.
* Touchpad enabled on Venice2 (although the driver still has a few issues
  to be worked out).
* NVIDIA reference boards rely on the bootloader to program the pinmux.
* Support added for the Acer Chromebook 13 (CB5).
* DT nodes added for the Tegra flow controller HW module. This will
  help reduce use of iomap.h in a future code cleanup.

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

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-dt

for you to fetch changes up to 8e2b9e4df655f3708fb8b712f0e66e6ea700995e:

  ARM: tegra: enable PCIe in Jetson TK1 DT

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

Dylan Reid (2):
      ARM: tegra: Move pwm and dpaux labels to tegra124.dtsi
      ARM: tegra: add Acer Chromebook 13 device tree

Mikko Perttunen (2):
      ARM: tegra: Add SATA controller to Tegra124 device tree
      ARM: tegra: Add SATA and SATA power to Jetson TK1 device tree

Stephen Warren (3):
      ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
      ARM: tegra: add touchpad to Venice2 DT
      ARM: tegra: rely on bootloader pinmux programming on Tegra124

Thierry Reding (3):
      ARM: tegra: Add device tree nodes for flow controller
      ARM: tegra: add PCIe to Tegra124 DT
      ARM: tegra: enable PCIe in Jetson TK1 DT

 arch/arm/boot/dts/Makefile                |    1 +
 arch/arm/boot/dts/tegra114.dtsi           |    5 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |   98 +-
 arch/arm/boot/dts/tegra124-nyan-big.dts   | 1136 ++++++++++++++++++++++++
 arch/arm/boot/dts/tegra124-venice2.dts    |   18 +-
 arch/arm/boot/dts/tegra124.dtsi           |  100 ++-
 arch/arm/boot/dts/tegra20.dtsi            |    5 +
 arch/arm/boot/dts/tegra30.dtsi            |    5 +
 8 files changed, 1357 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/boot/dts/tegra124-nyan-big.dts

[GIT PULL 3/3] ARM: tegra: tegra_defconfig changes for 3.18

[Stephen Warren]

Support is enabled for Venice2's touchpad, and Tegra124's AHCI (SATA)
controller, as used on Jetson TK1.

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

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-defconfig

for you to fetch changes up to b82daf87a82fc2261f86f48d1bd0706da9e4a675:

  ARM: tegra: enable Atmel touchpad in defconfig

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

Mikko Perttunen (1):
      ARM: tegra: Add options for Tegra AHCI support to tegra_defconfig

Stephen Warren (1):
      ARM: tegra: enable Atmel touchpad in defconfig

 arch/arm/configs/tegra_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

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

[Arnd Bergmann]

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

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

[Stephen Warren]

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.

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

[Arnd Bergmann]

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