[GIT PULL 0/8] ARM: tegra: Changes for v4.2-rc1

[GIT PULL 0/8] ARM: tegra: Changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers, Mike, Stephen,

Here's a set of first pull requests with changes for v4.2-rc1. This is
mostly the same as I sent out during the last cycle but which ended up
getting rejected. To avoid this I'm sending them out earlier this time
around. I've also split the changes into smaller chunks to make them
easier to digest.

Note that the work on Tegra210 is coming along pretty nicely, so I may
send some more changes later on, maybe a week or two from now.

Thanks,
Thierry

[GIT PULL 0/8] ARM: tegra: Changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers, Mike, Stephen,

Here's a set of first pull requests with changes for v4.2-rc1. This is
mostly the same as I sent out during the last cycle but which ended up
getting rejected. To avoid this I'm sending them out earlier this time
around. I've also split the changes into smaller chunks to make them
easier to digest.

Note that the work on Tegra210 is coming along pretty nicely, so I may
send some more changes later on, maybe a week or two from now.

Thanks,
Thierry

[GIT PULL 1/8] ARM: tegra: Cleanup patches for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-cleanup

for you to fetch changes up to 85aa5047e369d963b88af3e817dd40e692175153:

  ARM: tegra: Fix typo (reset -> rest) in comment (2015-05-04 13:25:19 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Cleanup patches for v4.2-rc1

Just a couple of trivial cleanups such as a typofix and conversion of
hexadecimal numbers to all lower-case in DTS files for consistency.

----------------------------------------------------------------
Thierry Reding (2):
      ARM: tegra: Use lower-case hexadecimal digits
      ARM: tegra: Fix typo (reset -> rest) in comment

 Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt | 2 +-
 arch/arm/boot/dts/tegra124.dtsi                                | 2 +-
 arch/arm/boot/dts/tegra20.dtsi                                 | 2 +-
 arch/arm/mach-tegra/sleep-tegra30.S                            | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

[GIT PULL 1/8] ARM: tegra: Cleanup patches for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-cleanup

for you to fetch changes up to 85aa5047e369d963b88af3e817dd40e692175153:

  ARM: tegra: Fix typo (reset -> rest) in comment (2015-05-04 13:25:19 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Cleanup patches for v4.2-rc1

Just a couple of trivial cleanups such as a typofix and conversion of
hexadecimal numbers to all lower-case in DTS files for consistency.

----------------------------------------------------------------
Thierry Reding (2):
      ARM: tegra: Use lower-case hexadecimal digits
      ARM: tegra: Fix typo (reset -> rest) in comment

 Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt | 2 +-
 arch/arm/boot/dts/tegra124.dtsi                                | 2 +-
 arch/arm/boot/dts/tegra20.dtsi                                 | 2 +-
 arch/arm/mach-tegra/sleep-tegra30.S                            | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

[GIT PULL 2/8] ARM: tegra: Memory controller updates for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-memory

for you to fetch changes up to 6f0a4d0c26f17e93f296e43c7b9f44733ea188ae:

  memory: tegra: Disable ARBITRATION_EMEM interrupt (2015-05-04 15:09:36 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Memory controller updates for v4.2-rc1

Adds support for Tegra132 (which is mostly the same as for Tegra124,
except for cache maintenance). debugfs support is also introduced for
the SMMU part of the memory controller, which allows users to inspect
the translation state for SWGROUPs and memory clients.

----------------------------------------------------------------
Thierry Reding (3):
      memory: tegra: Add SWGROUP names
      iommu/tegra-smmu: Add debugfs support
      memory: tegra: Add Tegra132 support

Tomeu Vizoso (1):
      memory: tegra: Disable ARBITRATION_EMEM interrupt

 drivers/iommu/Kconfig           |   2 +-
 drivers/iommu/tegra-smmu.c      | 109 ++++++++++++++++++++++++++++++++++++++++
 drivers/memory/tegra/Makefile   |   1 +
 drivers/memory/tegra/mc.c       |   7 ++-
 drivers/memory/tegra/mc.h       |   4 ++
 drivers/memory/tegra/tegra114.c |  32 ++++++------
 drivers/memory/tegra/tegra124.c |  79 ++++++++++++++++++++---------
 drivers/memory/tegra/tegra30.c  |  32 ++++++------
 include/soc/tegra/mc.h          |   6 +++
 9 files changed, 214 insertions(+), 58 deletions(-)

[GIT PULL 2/8] ARM: tegra: Memory controller updates for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-memory

for you to fetch changes up to 6f0a4d0c26f17e93f296e43c7b9f44733ea188ae:

  memory: tegra: Disable ARBITRATION_EMEM interrupt (2015-05-04 15:09:36 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Memory controller updates for v4.2-rc1

Adds support for Tegra132 (which is mostly the same as for Tegra124,
except for cache maintenance). debugfs support is also introduced for
the SMMU part of the memory controller, which allows users to inspect
the translation state for SWGROUPs and memory clients.

----------------------------------------------------------------
Thierry Reding (3):
      memory: tegra: Add SWGROUP names
      iommu/tegra-smmu: Add debugfs support
      memory: tegra: Add Tegra132 support

Tomeu Vizoso (1):
      memory: tegra: Disable ARBITRATION_EMEM interrupt

 drivers/iommu/Kconfig           |   2 +-
 drivers/iommu/tegra-smmu.c      | 109 ++++++++++++++++++++++++++++++++++++++++
 drivers/memory/tegra/Makefile   |   1 +
 drivers/memory/tegra/mc.c       |   7 ++-
 drivers/memory/tegra/mc.h       |   4 ++
 drivers/memory/tegra/tegra114.c |  32 ++++++------
 drivers/memory/tegra/tegra124.c |  79 ++++++++++++++++++++---------
 drivers/memory/tegra/tegra30.c  |  32 ++++++------
 include/soc/tegra/mc.h          |   6 +++
 9 files changed, 214 insertions(+), 58 deletions(-)

[GIT PULL 3/8] ARM: tegra: RAM code access for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers, Mike, Stephen,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-ramcode

for you to fetch changes up to 6ea2609ab386f6bfeebc39e1418b7497a9deb55c:

  soc/tegra: fuse: Add RAM code reader helper (2015-05-04 14:21:21 +0200)

Note that this is a shared dependency for the tegra-for-4.2-clk and the
tegra-for-4.2-emc pull requests and they are already based on this, so
it's sufficient if you pull those in individually.

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: RAM code access for v4.2-rc1

The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.

----------------------------------------------------------------
Mikko Perttunen (1):
      soc/tegra: fuse: Add RAM code reader helper

Tomeu Vizoso (1):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc

 .../bindings/misc/nvidia,tegra20-apbmisc.txt        |  2 ++
 drivers/soc/tegra/fuse/tegra-apbmisc.c              | 21 +++++++++++++++++++++
 include/soc/tegra/fuse.h                            |  1 +
 3 files changed, 24 insertions(+)

[GIT PULL 3/8] ARM: tegra: RAM code access for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers, Mike, Stephen,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-ramcode

for you to fetch changes up to 6ea2609ab386f6bfeebc39e1418b7497a9deb55c:

  soc/tegra: fuse: Add RAM code reader helper (2015-05-04 14:21:21 +0200)

Note that this is a shared dependency for the tegra-for-4.2-clk and the
tegra-for-4.2-emc pull requests and they are already based on this, so
it's sufficient if you pull those in individually.

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: RAM code access for v4.2-rc1

The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.

----------------------------------------------------------------
Mikko Perttunen (1):
      soc/tegra: fuse: Add RAM code reader helper

Tomeu Vizoso (1):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc

 .../bindings/misc/nvidia,tegra20-apbmisc.txt        |  2 ++
 drivers/soc/tegra/fuse/tegra-apbmisc.c              | 21 +++++++++++++++++++++
 include/soc/tegra/fuse.h                            |  1 +
 3 files changed, 24 insertions(+)

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Thierry Reding]

Hi Mike, Stephen,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk

for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:

  clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)

I've based this pull request on top of the tegra-for-4.2-ramcode pull
request, so pulling only this one should be sufficient to resolve the
dependency.

Thanks,
Thierry

----------------------------------------------------------------
clk: tegra: Changes for v4.2-rc1

This contains the EMC clock driver that's been exhaustively reviewed and
tested. It also includes a change to the clock core that allows a clock
provider to perform low-level reparenting of clocks. This is required by
the EMC clock driver because the reparenting needs to be done at a very
specific point in time during the EMC frequency switch.

----------------------------------------------------------------
Marcel Ziswiler (1):
      clk: tegra: Fix hda2codec_2x clock name for Tegra30

Mikko Perttunen (3):
      soc/tegra: fuse: Add RAM code reader helper
      clk: tegra: Remove old Tegra124 EMC clock
      clk: tegra: Add EMC clock driver

Thierry Reding (2):
      Merge branch 'for-4.2/ramcode' into for-4.2/clk
      clk: tegra: EMC clock driver depends on EMC driver

Tomeu Vizoso (6):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc
      clk: Expose clk_hw_reparent() to providers
      of: document new emc-timings subnode in nvidia,tegra124-car
      of: document external-memory-controller property in tegra124-car
      clk: tegra: Set the EMC clock as the parent of the MC clock
      clk: tegra: Have EMC clock implement determine_rate()

 .../bindings/clock/nvidia,tegra124-car.txt         |  44 +-
 .../bindings/misc/nvidia,tegra20-apbmisc.txt       |   2 +
 drivers/clk/Kconfig                                |   1 +
 drivers/clk/clk.c                                  |   8 +
 drivers/clk/tegra/Kconfig                          |   3 +
 drivers/clk/tegra/Makefile                         |   1 +
 drivers/clk/tegra/clk-emc.c                        | 538 +++++++++++++++++++++
 drivers/clk/tegra/clk-tegra124.c                   |  19 +-
 drivers/clk/tegra/clk-tegra30.c                    |   2 +-
 drivers/clk/tegra/clk.h                            |  12 +
 drivers/soc/tegra/fuse/tegra-apbmisc.c             |  21 +
 include/linux/clk-provider.h                       |   1 +
 include/soc/tegra/fuse.h                           |   1 +
 13 files changed, 637 insertions(+), 16 deletions(-)
 create mode 100644 drivers/clk/tegra/Kconfig
 create mode 100644 drivers/clk/tegra/clk-emc.c

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Thierry Reding]

Hi Mike, Stephen,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk

for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:

  clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)

I've based this pull request on top of the tegra-for-4.2-ramcode pull
request, so pulling only this one should be sufficient to resolve the
dependency.

Thanks,
Thierry

----------------------------------------------------------------
clk: tegra: Changes for v4.2-rc1

This contains the EMC clock driver that's been exhaustively reviewed and
tested. It also includes a change to the clock core that allows a clock
provider to perform low-level reparenting of clocks. This is required by
the EMC clock driver because the reparenting needs to be done at a very
specific point in time during the EMC frequency switch.

----------------------------------------------------------------
Marcel Ziswiler (1):
      clk: tegra: Fix hda2codec_2x clock name for Tegra30

Mikko Perttunen (3):
      soc/tegra: fuse: Add RAM code reader helper
      clk: tegra: Remove old Tegra124 EMC clock
      clk: tegra: Add EMC clock driver

Thierry Reding (2):
      Merge branch 'for-4.2/ramcode' into for-4.2/clk
      clk: tegra: EMC clock driver depends on EMC driver

Tomeu Vizoso (6):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc
      clk: Expose clk_hw_reparent() to providers
      of: document new emc-timings subnode in nvidia,tegra124-car
      of: document external-memory-controller property in tegra124-car
      clk: tegra: Set the EMC clock as the parent of the MC clock
      clk: tegra: Have EMC clock implement determine_rate()

 .../bindings/clock/nvidia,tegra124-car.txt         |  44 +-
 .../bindings/misc/nvidia,tegra20-apbmisc.txt       |   2 +
 drivers/clk/Kconfig                                |   1 +
 drivers/clk/clk.c                                  |   8 +
 drivers/clk/tegra/Kconfig                          |   3 +
 drivers/clk/tegra/Makefile                         |   1 +
 drivers/clk/tegra/clk-emc.c                        | 538 +++++++++++++++++++++
 drivers/clk/tegra/clk-tegra124.c                   |  19 +-
 drivers/clk/tegra/clk-tegra30.c                    |   2 +-
 drivers/clk/tegra/clk.h                            |  12 +
 drivers/soc/tegra/fuse/tegra-apbmisc.c             |  21 +
 include/linux/clk-provider.h                       |   1 +
 include/soc/tegra/fuse.h                           |   1 +
 13 files changed, 637 insertions(+), 16 deletions(-)
 create mode 100644 drivers/clk/tegra/Kconfig
 create mode 100644 drivers/clk/tegra/clk-emc.c

[GIT PULL 5/8] ARM: tegra: Add EMC driver for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-emc

for you to fetch changes up to 9c77a81f215bfeee8f96c50c8ab27dbebffec80d:

  memory: tegra: Add EMC frequency debugfs entry (2015-05-05 11:39:48 +0200)

I've based this pull request on top of the tegra-for-4.2-ramcode pull
request, so pulling only this one should be sufficient to resolve the
dependency.

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Add EMC driver for v4.2-rc1

This introduces the EMC driver that's required to scale the external
memory frequency.

----------------------------------------------------------------
Mikko Perttunen (5):
      soc/tegra: fuse: Add RAM code reader helper
      of: Add Tegra124 EMC bindings
      memory: tegra: Add API needed by the EMC driver
      memory: tegra: Add EMC (external memory controller) driver
      memory: tegra: Add EMC frequency debugfs entry

Thierry Reding (1):
      Merge branch 'for-4.2/ramcode' into for-4.2/emc

Tomeu Vizoso (2):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc
      of: Document timings subnode of nvidia,tegra-mc

 .../memory-controllers/nvidia,tegra-mc.txt         |   84 +-
 .../bindings/memory-controllers/tegra-emc.txt      |  374 +++++++
 .../bindings/misc/nvidia,tegra20-apbmisc.txt       |    2 +
 drivers/memory/tegra/Kconfig                       |   10 +
 drivers/memory/tegra/Makefile                      |    2 +
 drivers/memory/tegra/mc.c                          |  136 +++
 drivers/memory/tegra/tegra124-emc.c                | 1140 ++++++++++++++++++++
 drivers/memory/tegra/tegra124.c                    |   44 +
 drivers/soc/tegra/fuse/tegra-apbmisc.c             |   21 +
 include/soc/tegra/emc.h                            |   19 +
 include/soc/tegra/fuse.h                           |    1 +
 include/soc/tegra/mc.h                             |   14 +-
 12 files changed, 1844 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
 create mode 100644 drivers/memory/tegra/tegra124-emc.c
 create mode 100644 include/soc/tegra/emc.h

[GIT PULL 5/8] ARM: tegra: Add EMC driver for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-emc

for you to fetch changes up to 9c77a81f215bfeee8f96c50c8ab27dbebffec80d:

  memory: tegra: Add EMC frequency debugfs entry (2015-05-05 11:39:48 +0200)

I've based this pull request on top of the tegra-for-4.2-ramcode pull
request, so pulling only this one should be sufficient to resolve the
dependency.

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Add EMC driver for v4.2-rc1

This introduces the EMC driver that's required to scale the external
memory frequency.

----------------------------------------------------------------
Mikko Perttunen (5):
      soc/tegra: fuse: Add RAM code reader helper
      of: Add Tegra124 EMC bindings
      memory: tegra: Add API needed by the EMC driver
      memory: tegra: Add EMC (external memory controller) driver
      memory: tegra: Add EMC frequency debugfs entry

Thierry Reding (1):
      Merge branch 'for-4.2/ramcode' into for-4.2/emc

Tomeu Vizoso (2):
      of: Document long-ram-code property in nvidia,tegra20-apbmisc
      of: Document timings subnode of nvidia,tegra-mc

 .../memory-controllers/nvidia,tegra-mc.txt         |   84 +-
 .../bindings/memory-controllers/tegra-emc.txt      |  374 +++++++
 .../bindings/misc/nvidia,tegra20-apbmisc.txt       |    2 +
 drivers/memory/tegra/Kconfig                       |   10 +
 drivers/memory/tegra/Makefile                      |    2 +
 drivers/memory/tegra/mc.c                          |  136 +++
 drivers/memory/tegra/tegra124-emc.c                | 1140 ++++++++++++++++++++
 drivers/memory/tegra/tegra124.c                    |   44 +
 drivers/soc/tegra/fuse/tegra-apbmisc.c             |   21 +
 include/soc/tegra/emc.h                            |   19 +
 include/soc/tegra/fuse.h                           |    1 +
 include/soc/tegra/mc.h                             |   14 +-
 12 files changed, 1844 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt
 create mode 100644 drivers/memory/tegra/tegra124-emc.c
 create mode 100644 include/soc/tegra/emc.h

[GIT PULL 6/8] ARM: tegra: Core SoC changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-soc

for you to fetch changes up to 7892158a96629c46c46dfae52eaf951f51222cf5:

  soc/tegra: pmc: move to using a restart handler (2015-05-04 14:21:45 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Core SoC changes for v4.2-rc1

A couple of changes to the core SoC support code. Perhaps the most
important part is a fix for a regression in LP1 suspend/resume code that
was introduced a while back.

----------------------------------------------------------------
David Riley (1):
      soc/tegra: pmc: move to using a restart handler

Dmitry Osipenko (1):
      ARM: tegra20: Store CPU "resettable" status in IRAM

Nicholas Mc Guire (1):
      soc/tegra: Watch wait_for_completion_timeout() return type

 arch/arm/mach-tegra/cpuidle-tegra20.c |  5 ++---
 arch/arm/mach-tegra/reset-handler.S   | 10 +++++++---
 arch/arm/mach-tegra/reset.h           |  4 ++++
 arch/arm/mach-tegra/sleep-tegra20.S   | 37 ++++++++++++++++++++---------------
 arch/arm/mach-tegra/sleep.h           |  4 ++++
 arch/arm/mach-tegra/tegra.c           |  1 -
 drivers/soc/tegra/fuse/fuse-tegra20.c |  6 ++++--
 drivers/soc/tegra/pmc.c               | 23 ++++++++++++++++------
 include/soc/tegra/pmc.h               |  2 --
 9 files changed, 59 insertions(+), 33 deletions(-)

[GIT PULL 6/8] ARM: tegra: Core SoC changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-soc

for you to fetch changes up to 7892158a96629c46c46dfae52eaf951f51222cf5:

  soc/tegra: pmc: move to using a restart handler (2015-05-04 14:21:45 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Core SoC changes for v4.2-rc1

A couple of changes to the core SoC support code. Perhaps the most
important part is a fix for a regression in LP1 suspend/resume code that
was introduced a while back.

----------------------------------------------------------------
David Riley (1):
      soc/tegra: pmc: move to using a restart handler

Dmitry Osipenko (1):
      ARM: tegra20: Store CPU "resettable" status in IRAM

Nicholas Mc Guire (1):
      soc/tegra: Watch wait_for_completion_timeout() return type

 arch/arm/mach-tegra/cpuidle-tegra20.c |  5 ++---
 arch/arm/mach-tegra/reset-handler.S   | 10 +++++++---
 arch/arm/mach-tegra/reset.h           |  4 ++++
 arch/arm/mach-tegra/sleep-tegra20.S   | 37 ++++++++++++++++++++---------------
 arch/arm/mach-tegra/sleep.h           |  4 ++++
 arch/arm/mach-tegra/tegra.c           |  1 -
 drivers/soc/tegra/fuse/fuse-tegra20.c |  6 ++++--
 drivers/soc/tegra/pmc.c               | 23 ++++++++++++++++------
 include/soc/tegra/pmc.h               |  2 --
 9 files changed, 59 insertions(+), 33 deletions(-)

[GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-dt

for you to fetch changes up to 869bd180b8e6a81525acab21a5ee4428685bda2a:

  ARM: tegra: Fix hda2codec_2x clock and reset names (2015-05-05 14:09:02 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.2-rc1

Contains a couple of fixes and additions to device tree files. The most
notable change is a fix for a misapplied patch that was only exposed by
a recent change in the regulator subsystem that caused USB to break on
Tegra124 recently.

Other than that there are a more or less random assortment of additions
to enable various features on a couple of boards.

----------------------------------------------------------------
Marcel Ziswiler (3):
      ARM: tegra: Cardhu device-tree comment spelling fix
      ARM: tegra: Add Tegra30 HDA support
      ARM: tegra: Fix hda2codec_2x clock and reset names

Thierry Reding (5):
      ARM: tegra: cardhu: Add power and volume keys
      ARM: tegra: Add missing HDMI +5V regulator
      ARM: tegra: jetson-tk1: Enable HDA support
      ARM: tegra: venice2: Mark eMMC as non-removable
      ARM: tegra: venice2: Set min-/max-microvolt for VDD_LED supply

Tomeu Vizoso (1):
      ARM: tegra: Correct which USB controller has the UTMI pad registers

 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 ++++
 arch/arm/boot/dts/tegra124-venice2.dts    |  3 +++
 arch/arm/boot/dts/tegra124.dtsi           | 12 ++++++------
 arch/arm/boot/dts/tegra20-seaboard.dts    | 12 ++++++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi     | 30 +++++++++++++++++++++++++++++-
 arch/arm/boot/dts/tegra30.dtsi            | 15 +++++++++++++++
 6 files changed, 69 insertions(+), 7 deletions(-)

[GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-dt

for you to fetch changes up to 869bd180b8e6a81525acab21a5ee4428685bda2a:

  ARM: tegra: Fix hda2codec_2x clock and reset names (2015-05-05 14:09:02 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.2-rc1

Contains a couple of fixes and additions to device tree files. The most
notable change is a fix for a misapplied patch that was only exposed by
a recent change in the regulator subsystem that caused USB to break on
Tegra124 recently.

Other than that there are a more or less random assortment of additions
to enable various features on a couple of boards.

----------------------------------------------------------------
Marcel Ziswiler (3):
      ARM: tegra: Cardhu device-tree comment spelling fix
      ARM: tegra: Add Tegra30 HDA support
      ARM: tegra: Fix hda2codec_2x clock and reset names

Thierry Reding (5):
      ARM: tegra: cardhu: Add power and volume keys
      ARM: tegra: Add missing HDMI +5V regulator
      ARM: tegra: jetson-tk1: Enable HDA support
      ARM: tegra: venice2: Mark eMMC as non-removable
      ARM: tegra: venice2: Set min-/max-microvolt for VDD_LED supply

Tomeu Vizoso (1):
      ARM: tegra: Correct which USB controller has the UTMI pad registers

 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 ++++
 arch/arm/boot/dts/tegra124-venice2.dts    |  3 +++
 arch/arm/boot/dts/tegra124.dtsi           | 12 ++++++------
 arch/arm/boot/dts/tegra20-seaboard.dts    | 12 ++++++++++++
 arch/arm/boot/dts/tegra30-cardhu.dtsi     | 30 +++++++++++++++++++++++++++++-
 arch/arm/boot/dts/tegra30.dtsi            | 15 +++++++++++++++
 6 files changed, 69 insertions(+), 7 deletions(-)

[GIT PULL 8/8] ARM: tegra: Default configuration updates for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-defconfig

for you to fetch changes up to 5f9c2187d6cfac15b44b584c403e187321a4c062:

  ARM: tegra: Update default configuration (2015-05-05 14:20:16 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.2-rc1

This is a set of changes to the Tegra default configuration that enable
various new features (HDMI audio, watchdog) on Toradex Apalis T30.

----------------------------------------------------------------
Thierry Reding (1):
      ARM: tegra: Update default configuration

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

[GIT PULL 8/8] ARM: tegra: Default configuration updates for v4.2-rc1

[Thierry Reding]

Hi ARM SoC maintainers,

The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

  Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-defconfig

for you to fetch changes up to 5f9c2187d6cfac15b44b584c403e187321a4c062:

  ARM: tegra: Update default configuration (2015-05-05 14:20:16 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.2-rc1

This is a set of changes to the Tegra default configuration that enable
various new features (HDMI audio, watchdog) on Toradex Apalis T30.

----------------------------------------------------------------
Thierry Reding (1):
      ARM: tegra: Update default configuration

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

Re: [GIT PULL 1/8] ARM: tegra: Cleanup patches for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:33 Thierry Reding wrote:
> ARM: tegra: Cleanup patches for v4.2-rc1
> 
> Just a couple of trivial cleanups such as a typofix and conversion of
> hexadecimal numbers to all lower-case in DTS files for consistency.
> 
> 

Pulled into next/cleanup, thanks!

	Arnd

[GIT PULL 1/8] ARM: tegra: Cleanup patches for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:33 Thierry Reding wrote:
> ARM: tegra: Cleanup patches for v4.2-rc1
> 
> Just a couple of trivial cleanups such as a typofix and conversion of
> hexadecimal numbers to all lower-case in DTS files for consistency.
> 
> 

Pulled into next/cleanup, thanks!

	Arnd

Re: [GIT PULL 2/8] ARM: tegra: Memory controller updates for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:34 Thierry Reding wrote:
> ----------------------------------------------------------------
> ARM: tegra: Memory controller updates for v4.2-rc1
> 
> Adds support for Tegra132 (which is mostly the same as for Tegra124,
> except for cache maintenance). debugfs support is also introduced for
> the SMMU part of the memory controller, which allows users to inspect
> the translation state for SWGROUPs and memory clients.
> 
> 

Pulled into next/drivers, thanks!

	Arnd

[GIT PULL 2/8] ARM: tegra: Memory controller updates for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:34 Thierry Reding wrote:
> ----------------------------------------------------------------
> ARM: tegra: Memory controller updates for v4.2-rc1
> 
> Adds support for Tegra132 (which is mostly the same as for Tegra124,
> except for cache maintenance). debugfs support is also introduced for
> the SMMU part of the memory controller, which allows users to inspect
> the translation state for SWGROUPs and memory clients.
> 
> 

Pulled into next/drivers, thanks!

	Arnd

Re: [GIT PULL 3/8] ARM: tegra: RAM code access for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:35 Thierry Reding wrote:
> Note that this is a shared dependency for the tegra-for-4.2-clk and the
> tegra-for-4.2-emc pull requests and they are already based on this, so
> it's sufficient if you pull those in individually.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> ARM: tegra: RAM code access for v4.2-rc1
> 
> The RAM code is used by the memory and external memory controllers to
> determine which set of timings to use for memory frequency scaling.
> 

I've pulled it into next/drivers separately for documentation purposes,
even if it's not strictly necessary as you say. Thanks!

	Arnd

[GIT PULL 3/8] ARM: tegra: RAM code access for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:35 Thierry Reding wrote:
> Note that this is a shared dependency for the tegra-for-4.2-clk and the
> tegra-for-4.2-emc pull requests and they are already based on this, so
> it's sufficient if you pull those in individually.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> ARM: tegra: RAM code access for v4.2-rc1
> 
> The RAM code is used by the memory and external memory controllers to
> determine which set of timings to use for memory frequency scaling.
> 

I've pulled it into next/drivers separately for documentation purposes,
even if it's not strictly necessary as you say. Thanks!

	Arnd

Re: [GIT PULL 5/8] ARM: tegra: Add EMC driver for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:37 Thierry Reding wrote:
> 
> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> request, so pulling only this one should be sufficient to resolve the
> dependency.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> ARM: tegra: Add EMC driver for v4.2-rc1
> 
> This introduces the EMC driver that's required to scale the external
> memory frequency.
> 
> 

Pulled into next/drivers, on top of the first one, thanks!

	Arnd

[GIT PULL 5/8] ARM: tegra: Add EMC driver for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:37 Thierry Reding wrote:
> 
> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> request, so pulling only this one should be sufficient to resolve the
> dependency.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> ARM: tegra: Add EMC driver for v4.2-rc1
> 
> This introduces the EMC driver that's required to scale the external
> memory frequency.
> 
> 

Pulled into next/drivers, on top of the first one, thanks!

	Arnd

Re: [GIT PULL 6/8] ARM: tegra: Core SoC changes for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:38 Thierry Reding wrote:
> ARM: tegra: Core SoC changes for v4.2-rc1
> 
> A couple of changes to the core SoC support code. Perhaps the most
> important part is a fix for a regression in LP1 suspend/resume code that
> was introduced a while back.
> 

Pulled into next/soc, thanks!

	Arnd

[GIT PULL 6/8] ARM: tegra: Core SoC changes for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:38 Thierry Reding wrote:
> ARM: tegra: Core SoC changes for v4.2-rc1
> 
> A couple of changes to the core SoC support code. Perhaps the most
> important part is a fix for a regression in LP1 suspend/resume code that
> was introduced a while back.
> 

Pulled into next/soc, thanks!

	Arnd

Re: [GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> ARM: tegra: Devicetree changes for v4.2-rc1
> 
> Contains a couple of fixes and additions to device tree files. The most
> notable change is a fix for a misapplied patch that was only exposed by
> a recent change in the regulator subsystem that caused USB to break on
> Tegra124 recently.

It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
which USB controller has the UTMI pad registers") into the 4.1 fixes
branch as well. Please confirm.

> Other than that there are a more or less random assortment of additions
> to enable various features on a couple of boards.
> 

Pulled into next/dt, thanks!

	Arnd

[GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> ARM: tegra: Devicetree changes for v4.2-rc1
> 
> Contains a couple of fixes and additions to device tree files. The most
> notable change is a fix for a misapplied patch that was only exposed by
> a recent change in the regulator subsystem that caused USB to break on
> Tegra124 recently.

It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
which USB controller has the UTMI pad registers") into the 4.1 fixes
branch as well. Please confirm.

> Other than that there are a more or less random assortment of additions
> to enable various features on a couple of boards.
> 

Pulled into next/dt, thanks!

	Arnd

Re: [GIT PULL 8/8] ARM: tegra: Default configuration updates for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:40 Thierry Reding wrote:
> ARM: tegra: Default configuration updates for v4.2-rc1
> 
> This is a set of changes to the Tegra default configuration that enable
> various new features (HDMI audio, watchdog) on Toradex Apalis T30.
> 

Applied into next/defconfig.

I noticed that you have not included the config options in
multi_v7_defconfig. Please check that all drivers you need
are also enabled in that generic configuration (as loadable
modules if possible), and send an update for that config as
well.

Thanks,

	Arnd

[GIT PULL 8/8] ARM: tegra: Default configuration updates for v4.2-rc1

[Arnd Bergmann]

On Wednesday 13 May 2015 15:49:40 Thierry Reding wrote:
> ARM: tegra: Default configuration updates for v4.2-rc1
> 
> This is a set of changes to the Tegra default configuration that enable
> various new features (HDMI audio, watchdog) on Toradex Apalis T30.
> 

Applied into next/defconfig.

I noticed that you have not included the config options in
multi_v7_defconfig. Please check that all drivers you need
are also enabled in that generic configuration (as loadable
modules if possible), and send an update for that config as
well.

Thanks,

	Arnd

Re: [GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Thierry Reding]

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

On Wed, May 13, 2015 at 06:09:20PM +0200, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> > ARM: tegra: Devicetree changes for v4.2-rc1
> > 
> > Contains a couple of fixes and additions to device tree files. The most
> > notable change is a fix for a misapplied patch that was only exposed by
> > a recent change in the regulator subsystem that caused USB to break on
> > Tegra124 recently.
> 
> It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
> which USB controller has the UTMI pad registers") into the 4.1 fixes
> branch as well. Please confirm.

I think you already did. I sent out a pull request for that not very
long ago and I must have forgotten to drop this patch from the Tegra
tree after it got applied to arm-soc. The merge commit for this in
the fixes branch is here:

	https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=155171274d1dd9d9e5a012bd912c592402aa31d2

Hopefully git will be able to merge these together without conflicts.
Sorry about the dupe.

Thierry

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

[GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Thierry Reding]

On Wed, May 13, 2015 at 06:09:20PM +0200, Arnd Bergmann wrote:
> On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> > ARM: tegra: Devicetree changes for v4.2-rc1
> > 
> > Contains a couple of fixes and additions to device tree files. The most
> > notable change is a fix for a misapplied patch that was only exposed by
> > a recent change in the regulator subsystem that caused USB to break on
> > Tegra124 recently.
> 
> It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
> which USB controller has the UTMI pad registers") into the 4.1 fixes
> branch as well. Please confirm.

I think you already did. I sent out a pull request for that not very
long ago and I must have forgotten to drop this patch from the Tegra
tree after it got applied to arm-soc. The merge commit for this in
the fixes branch is here:

	https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=155171274d1dd9d9e5a012bd912c592402aa31d2

Hopefully git will be able to merge these together without conflicts.
Sorry about the dupe.

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

Re: [GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Arnd Bergmann]

On Friday 15 May 2015 12:43:34 Thierry Reding wrote:
> On Wed, May 13, 2015 at 06:09:20PM +0200, Arnd Bergmann wrote:
> > On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> > > ARM: tegra: Devicetree changes for v4.2-rc1
> > > 
> > > Contains a couple of fixes and additions to device tree files. The most
> > > notable change is a fix for a misapplied patch that was only exposed by
> > > a recent change in the regulator subsystem that caused USB to break on
> > > Tegra124 recently.
> > 
> > It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
> > which USB controller has the UTMI pad registers") into the 4.1 fixes
> > branch as well. Please confirm.
> 
> I think you already did. I sent out a pull request for that not very
> long ago and I must have forgotten to drop this patch from the Tegra
> tree after it got applied to arm-soc. The merge commit for this in
> the fixes branch is here:
> 
>         https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=155171274d1dd9d9e5a012bd912c592402aa31d2
> 
> Hopefully git will be able to merge these together without conflicts.
> Sorry about the dupe.
> 

Everything is fine. Since both branches have the same commit ID,
git can figure out how to do the merges. It would only be annoying
to get the same patch with two different commit IDs.

Ideally, your pull request would mention this kind of situation, so
I don't need to ask or research myself about it.

	Arnd

[GIT PULL 7/8] ARM: tegra: Devicetree changes for v4.2-rc1

[Arnd Bergmann]

On Friday 15 May 2015 12:43:34 Thierry Reding wrote:
> On Wed, May 13, 2015 at 06:09:20PM +0200, Arnd Bergmann wrote:
> > On Wednesday 13 May 2015 15:49:39 Thierry Reding wrote:
> > > ARM: tegra: Devicetree changes for v4.2-rc1
> > > 
> > > Contains a couple of fixes and additions to device tree files. The most
> > > notable change is a fix for a misapplied patch that was only exposed by
> > > a recent change in the regulator subsystem that caused USB to break on
> > > Tegra124 recently.
> > 
> > It sounds like I should merge commit a4b6916cb35 ("ARM: tegra: Correct
> > which USB controller has the UTMI pad registers") into the 4.1 fixes
> > branch as well. Please confirm.
> 
> I think you already did. I sent out a pull request for that not very
> long ago and I must have forgotten to drop this patch from the Tegra
> tree after it got applied to arm-soc. The merge commit for this in
> the fixes branch is here:
> 
>         https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=155171274d1dd9d9e5a012bd912c592402aa31d2
> 
> Hopefully git will be able to merge these together without conflicts.
> Sorry about the dupe.
> 

Everything is fine. Since both branches have the same commit ID,
git can figure out how to do the merges. It would only be annoying
to get the same patch with two different commit IDs.

Ideally, your pull request would mention this kind of situation, so
I don't need to ask or research myself about it.

	Arnd

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Stephen Boyd]

On 05/13, Thierry Reding wrote:
> Hi Mike, Stephen,
> 
> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> 
>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> 
> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> 
>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> 
> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> request, so pulling only this one should be sufficient to resolve the
> dependency.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> clk: tegra: Changes for v4.2-rc1
> 
> This contains the EMC clock driver that's been exhaustively reviewed and
> tested. It also includes a change to the clock core that allows a clock
> provider to perform low-level reparenting of clocks. This is required by
> the EMC clock driver because the reparenting needs to be done at a very
> specific point in time during the EMC frequency switch.

Can someone please describe why we need to do software
reparenting at a specific point in time during a frequency
switch? I must have missed out on the conversation somewhere and
looking at the commit that introduces the function, the argument
for why the API is exposed:

      To be used by clock implementations for switching to a new
      parent during rate change.

is lacking in any details about *why* we need it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Stephen Boyd]

On 05/13, Thierry Reding wrote:
> Hi Mike, Stephen,
> 
> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> 
>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> 
> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> 
>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> 
> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> request, so pulling only this one should be sufficient to resolve the
> dependency.
> 
> Thanks,
> Thierry
> 
> ----------------------------------------------------------------
> clk: tegra: Changes for v4.2-rc1
> 
> This contains the EMC clock driver that's been exhaustively reviewed and
> tested. It also includes a change to the clock core that allows a clock
> provider to perform low-level reparenting of clocks. This is required by
> the EMC clock driver because the reparenting needs to be done at a very
> specific point in time during the EMC frequency switch.

Can someone please describe why we need to do software
reparenting at a specific point in time during a frequency
switch? I must have missed out on the conversation somewhere and
looking at the commit that introduces the function, the argument
for why the API is exposed:

      To be used by clock implementations for switching to a new
      parent during rate change.

is lacking in any details about *why* we need it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> On 05/13, Thierry Reding wrote:
>> Hi Mike, Stephen,
>>
>> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
>>
>>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
>>
>> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
>>
>>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
>>
>> I've based this pull request on top of the tegra-for-4.2-ramcode pull
>> request, so pulling only this one should be sufficient to resolve the
>> dependency.
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> clk: tegra: Changes for v4.2-rc1
>>
>> This contains the EMC clock driver that's been exhaustively reviewed and
>> tested. It also includes a change to the clock core that allows a clock
>> provider to perform low-level reparenting of clocks. This is required by
>> the EMC clock driver because the reparenting needs to be done at a very
>> specific point in time during the EMC frequency switch.
> 
> Can someone please describe why we need to do software
> reparenting at a specific point in time during a frequency
> switch? I must have missed out on the conversation somewhere and
> looking at the commit that introduces the function, the argument
> for why the API is exposed:
> 
>       To be used by clock implementations for switching to a new
>       parent during rate change.
> 
> is lacking in any details about *why* we need it.
> 

Hi Stephen,

the way the EMC clock rate is set in hardware is similar to other
clocks, i.e. there's a register and you write the new divider and parent
id to it. However, with EMC, you cannot just do this any time you want;
writing to the register initiates a state machine in the clock hardware
that changes a large number of other parameters regarding DRAM timings
as well. These parameters need to be programmed into shadow registers
before the rate change write is done. This means that both the new
divisor and the parent must be written in the same register write.

The CCF has a callback, set_rate_and_parent, which allows for both to be
passed to the driver at the same time. However, it also requires
set_rate and set_parent to be implemented, which the EMC driver cannot do.

Furthermore, the CCF cannot help with parent selection for the EMC clock
at all. The parent for each rate is selected by the board designer.

There is also the issue that sometimes, the EMC driver cannot directly
switch to the target (rate, parent) pair; instead it is necessary to
switch first to another pair we call a backup timing. In this situation,
we temporarily have a parent that is neither the one we had before the
set_rate call or the one it will be after. Especially, if the switch to
the backup timing succeeds but the following switch to the target timing
fails, then without the reparent call the parent in hardware would be
left inconsistent with the software state.

This is why we've decided to implement the driver with only the set_rate
callback and decide the required transitions within the driver.
This also means that the driver needs to have a function to tell the CCF
that it has changed its parent.

Thanks,
Mikko.

nvpublic

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> On 05/13, Thierry Reding wrote:
>> Hi Mike, Stephen,
>>
>> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
>>
>>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
>>
>> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
>>
>>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
>>
>> I've based this pull request on top of the tegra-for-4.2-ramcode pull
>> request, so pulling only this one should be sufficient to resolve the
>> dependency.
>>
>> Thanks,
>> Thierry
>>
>> ----------------------------------------------------------------
>> clk: tegra: Changes for v4.2-rc1
>>
>> This contains the EMC clock driver that's been exhaustively reviewed and
>> tested. It also includes a change to the clock core that allows a clock
>> provider to perform low-level reparenting of clocks. This is required by
>> the EMC clock driver because the reparenting needs to be done at a very
>> specific point in time during the EMC frequency switch.
> 
> Can someone please describe why we need to do software
> reparenting at a specific point in time during a frequency
> switch? I must have missed out on the conversation somewhere and
> looking at the commit that introduces the function, the argument
> for why the API is exposed:
> 
>       To be used by clock implementations for switching to a new
>       parent during rate change.
> 
> is lacking in any details about *why* we need it.
> 

Hi Stephen,

the way the EMC clock rate is set in hardware is similar to other
clocks, i.e. there's a register and you write the new divider and parent
id to it. However, with EMC, you cannot just do this any time you want;
writing to the register initiates a state machine in the clock hardware
that changes a large number of other parameters regarding DRAM timings
as well. These parameters need to be programmed into shadow registers
before the rate change write is done. This means that both the new
divisor and the parent must be written in the same register write.

The CCF has a callback, set_rate_and_parent, which allows for both to be
passed to the driver at the same time. However, it also requires
set_rate and set_parent to be implemented, which the EMC driver cannot do.

Furthermore, the CCF cannot help with parent selection for the EMC clock
at all. The parent for each rate is selected by the board designer.

There is also the issue that sometimes, the EMC driver cannot directly
switch to the target (rate, parent) pair; instead it is necessary to
switch first to another pair we call a backup timing. In this situation,
we temporarily have a parent that is neither the one we had before the
set_rate call or the one it will be after. Especially, if the switch to
the backup timing succeeds but the following switch to the target timing
fails, then without the reparent call the parent in hardware would be
left inconsistent with the software state.

This is why we've decided to implement the driver with only the set_rate
callback and decide the required transitions within the driver.
This also means that the driver needs to have a function to tell the CCF
that it has changed its parent.

Thanks,
Mikko.

nvpublic

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/21/2015 09:25 AM, Mikko Perttunen wrote:
> On 05/20/2015 10:54 PM, Stephen Boyd wrote:
>> On 05/13, Thierry Reding wrote:
>>> ...

Hi Mike, Stephen,

just reminding about this PR :)

Thanks,
Mikko.

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/21/2015 09:25 AM, Mikko Perttunen wrote:
> On 05/20/2015 10:54 PM, Stephen Boyd wrote:
>> On 05/13, Thierry Reding wrote:
>>> ...

Hi Mike, Stephen,

just reminding about this PR :)

Thanks,
Mikko.

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Stephen Boyd]

On 05/21, Mikko Perttunen wrote:
> On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> > On 05/13, Thierry Reding wrote:
> >> Hi Mike, Stephen,
> >>
> >> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> >>
> >>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> >>
> >> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> >>
> >>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> >>
> >> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> >> request, so pulling only this one should be sufficient to resolve the
> >> dependency.
> >>
> >> Thanks,
> >> Thierry
> >>
> >> ----------------------------------------------------------------
> >> clk: tegra: Changes for v4.2-rc1
> >>
> >> This contains the EMC clock driver that's been exhaustively reviewed and
> >> tested. It also includes a change to the clock core that allows a clock
> >> provider to perform low-level reparenting of clocks. This is required by
> >> the EMC clock driver because the reparenting needs to be done at a very
> >> specific point in time during the EMC frequency switch.
> > 
> > Can someone please describe why we need to do software
> > reparenting at a specific point in time during a frequency
> > switch? I must have missed out on the conversation somewhere and
> > looking at the commit that introduces the function, the argument
> > for why the API is exposed:
> > 
> >       To be used by clock implementations for switching to a new
> >       parent during rate change.
> > 
> > is lacking in any details about *why* we need it.
> > 
> 
> Hi Stephen,
> 
> the way the EMC clock rate is set in hardware is similar to other
> clocks, i.e. there's a register and you write the new divider and parent
> id to it. However, with EMC, you cannot just do this any time you want;
> writing to the register initiates a state machine in the clock hardware
> that changes a large number of other parameters regarding DRAM timings
> as well. These parameters need to be programmed into shadow registers
> before the rate change write is done. This means that both the new
> divisor and the parent must be written in the same register write.
> 
> The CCF has a callback, set_rate_and_parent, which allows for both to be
> passed to the driver at the same time. However, it also requires
> set_rate and set_parent to be implemented, which the EMC driver cannot do.

Ok so we should change the framework to allow drivers to only
implement set_rate_and_parent and use that in set_rate and
set_parent implementations if it's the only option available. Or
is there a problem if CCF allows clk_set_parent() on the EMC
clock by calling set_rate_and_parent() with the new parent and
whatever recalc_rate returns for the new parent's rate going into
the clock?

> 
> Furthermore, the CCF cannot help with parent selection for the EMC clock
> at all. The parent for each rate is selected by the board designer.

I'm not following this part. The CCF mostly asks clock providers
what parent should be used when clk_set_rate() is called.

> 
> There is also the issue that sometimes, the EMC driver cannot directly
> switch to the target (rate, parent) pair; instead it is necessary to
> switch first to another pair we call a backup timing. In this situation,
> we temporarily have a parent that is neither the one we had before the
> set_rate call or the one it will be after. Especially, if the switch to
> the backup timing succeeds but the following switch to the target timing
> fails, then without the reparent call the parent in hardware would be
> left inconsistent with the software state.

Yes, I've sent a patch a while ago to support an idea of a "safe
parent" or a backup timing that can be used while a clock is
reprogrammed. Mike has also proposed the concept of "coordinated
clock rates" which would do something similar and allow clock
providers to control complicated rate transitions themselves. It
seems that we may be able to use the "safe parent" concept here,
where first we switch to some other parent, call the set_rate*
op, and then switch the parent back if we're not already using
the parent that we should be using.

This sort of thing becomes important for things like per-clock
locking where we need to know how the clock tree is going to
change *before* we modify the clock tree. If we go back and forth
between the clock providers and the clock tree while we're in the
middle of making irreversible changes to the hardware, we may get
stuck in a situation where we need to lock more clocks and then
we may need to undo hardware changes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Stephen Boyd]

On 05/21, Mikko Perttunen wrote:
> On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> > On 05/13, Thierry Reding wrote:
> >> Hi Mike, Stephen,
> >>
> >> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> >>
> >>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> >>
> >> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> >>
> >>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> >>
> >> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> >> request, so pulling only this one should be sufficient to resolve the
> >> dependency.
> >>
> >> Thanks,
> >> Thierry
> >>
> >> ----------------------------------------------------------------
> >> clk: tegra: Changes for v4.2-rc1
> >>
> >> This contains the EMC clock driver that's been exhaustively reviewed and
> >> tested. It also includes a change to the clock core that allows a clock
> >> provider to perform low-level reparenting of clocks. This is required by
> >> the EMC clock driver because the reparenting needs to be done at a very
> >> specific point in time during the EMC frequency switch.
> > 
> > Can someone please describe why we need to do software
> > reparenting at a specific point in time during a frequency
> > switch? I must have missed out on the conversation somewhere and
> > looking at the commit that introduces the function, the argument
> > for why the API is exposed:
> > 
> >       To be used by clock implementations for switching to a new
> >       parent during rate change.
> > 
> > is lacking in any details about *why* we need it.
> > 
> 
> Hi Stephen,
> 
> the way the EMC clock rate is set in hardware is similar to other
> clocks, i.e. there's a register and you write the new divider and parent
> id to it. However, with EMC, you cannot just do this any time you want;
> writing to the register initiates a state machine in the clock hardware
> that changes a large number of other parameters regarding DRAM timings
> as well. These parameters need to be programmed into shadow registers
> before the rate change write is done. This means that both the new
> divisor and the parent must be written in the same register write.
> 
> The CCF has a callback, set_rate_and_parent, which allows for both to be
> passed to the driver at the same time. However, it also requires
> set_rate and set_parent to be implemented, which the EMC driver cannot do.

Ok so we should change the framework to allow drivers to only
implement set_rate_and_parent and use that in set_rate and
set_parent implementations if it's the only option available. Or
is there a problem if CCF allows clk_set_parent() on the EMC
clock by calling set_rate_and_parent() with the new parent and
whatever recalc_rate returns for the new parent's rate going into
the clock?

> 
> Furthermore, the CCF cannot help with parent selection for the EMC clock
> at all. The parent for each rate is selected by the board designer.

I'm not following this part. The CCF mostly asks clock providers
what parent should be used when clk_set_rate() is called.

> 
> There is also the issue that sometimes, the EMC driver cannot directly
> switch to the target (rate, parent) pair; instead it is necessary to
> switch first to another pair we call a backup timing. In this situation,
> we temporarily have a parent that is neither the one we had before the
> set_rate call or the one it will be after. Especially, if the switch to
> the backup timing succeeds but the following switch to the target timing
> fails, then without the reparent call the parent in hardware would be
> left inconsistent with the software state.

Yes, I've sent a patch a while ago to support an idea of a "safe
parent" or a backup timing that can be used while a clock is
reprogrammed. Mike has also proposed the concept of "coordinated
clock rates" which would do something similar and allow clock
providers to control complicated rate transitions themselves. It
seems that we may be able to use the "safe parent" concept here,
where first we switch to some other parent, call the set_rate*
op, and then switch the parent back if we're not already using
the parent that we should be using.

This sort of thing becomes important for things like per-clock
locking where we need to know how the clock tree is going to
change *before* we modify the clock tree. If we go back and forth
between the clock providers and the clock tree while we're in the
middle of making irreversible changes to the hardware, we may get
stuck in a situation where we need to lock more clocks and then
we may need to undo hardware changes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> On 05/21, Mikko Perttunen wrote:
>>
>> Hi Stephen,
>>
>> the way the EMC clock rate is set in hardware is similar to other
>> clocks, i.e. there's a register and you write the new divider and parent
>> id to it. However, with EMC, you cannot just do this any time you want;
>> writing to the register initiates a state machine in the clock hardware
>> that changes a large number of other parameters regarding DRAM timings
>> as well. These parameters need to be programmed into shadow registers
>> before the rate change write is done. This means that both the new
>> divisor and the parent must be written in the same register write.
>>
>> The CCF has a callback, set_rate_and_parent, which allows for both to be
>> passed to the driver at the same time. However, it also requires
>> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> 
> Ok so we should change the framework to allow drivers to only
> implement set_rate_and_parent and use that in set_rate and
> set_parent implementations if it's the only option available. Or
> is there a problem if CCF allows clk_set_parent() on the EMC
> clock by calling set_rate_and_parent() with the new parent and
> whatever recalc_rate returns for the new parent's rate going into
> the clock?

There isn't really a problem, but the EMC driver cannot implement this
operation sensibly so it would just always return an error if the (rate,
parent) pair given to set_rate_and_parent() doesn't exactly match one of
the entries specified in device tree.

> 
>>
>> Furthermore, the CCF cannot help with parent selection for the EMC clock
>> at all. The parent for each rate is selected by the board designer.
> 
> I'm not following this part. The CCF mostly asks clock providers
> what parent should be used when clk_set_rate() is called.

Yep, that much is fine; what I was alluding was the above (set_parent
and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)

> 
>>
>> There is also the issue that sometimes, the EMC driver cannot directly
>> switch to the target (rate, parent) pair; instead it is necessary to
>> switch first to another pair we call a backup timing. In this situation,
>> we temporarily have a parent that is neither the one we had before the
>> set_rate call or the one it will be after. Especially, if the switch to
>> the backup timing succeeds but the following switch to the target timing
>> fails, then without the reparent call the parent in hardware would be
>> left inconsistent with the software state.
> 
> Yes, I've sent a patch a while ago to support an idea of a "safe
> parent" or a backup timing that can be used while a clock is
> reprogrammed. Mike has also proposed the concept of "coordinated
> clock rates" which would do something similar and allow clock
> providers to control complicated rate transitions themselves. It
> seems that we may be able to use the "safe parent" concept here,
> where first we switch to some other parent, call the set_rate*
> op, and then switch the parent back if we're not already using
> the parent that we should be using.

While I'm not sure how much sophistication is warranted in the CCF, for
our use case this backup timing has to be able to be a function of the
timing we are leaving and preferably also the target timing. Also, as
usual, the backup timings are (rate, parent) pairs, and just changing
rate or just changing parent are both impossible.

> 
> This sort of thing becomes important for things like per-clock
> locking where we need to know how the clock tree is going to
> change *before* we modify the clock tree. If we go back and forth
> between the clock providers and the clock tree while we're in the
> middle of making irreversible changes to the hardware, we may get
> stuck in a situation where we need to lock more clocks and then
> we may need to undo hardware changes.
> 

Yeah, makes sense.

Do you think you can still pull this patchset? There's other code in
linux-next that depends on it and I'd prefer to have a working driver in
the kernel; if/when the improvements to CCF materialize we could update
the driver to use them.

Thanks,
Mikko.

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> On 05/21, Mikko Perttunen wrote:
>>
>> Hi Stephen,
>>
>> the way the EMC clock rate is set in hardware is similar to other
>> clocks, i.e. there's a register and you write the new divider and parent
>> id to it. However, with EMC, you cannot just do this any time you want;
>> writing to the register initiates a state machine in the clock hardware
>> that changes a large number of other parameters regarding DRAM timings
>> as well. These parameters need to be programmed into shadow registers
>> before the rate change write is done. This means that both the new
>> divisor and the parent must be written in the same register write.
>>
>> The CCF has a callback, set_rate_and_parent, which allows for both to be
>> passed to the driver at the same time. However, it also requires
>> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> 
> Ok so we should change the framework to allow drivers to only
> implement set_rate_and_parent and use that in set_rate and
> set_parent implementations if it's the only option available. Or
> is there a problem if CCF allows clk_set_parent() on the EMC
> clock by calling set_rate_and_parent() with the new parent and
> whatever recalc_rate returns for the new parent's rate going into
> the clock?

There isn't really a problem, but the EMC driver cannot implement this
operation sensibly so it would just always return an error if the (rate,
parent) pair given to set_rate_and_parent() doesn't exactly match one of
the entries specified in device tree.

> 
>>
>> Furthermore, the CCF cannot help with parent selection for the EMC clock
>> at all. The parent for each rate is selected by the board designer.
> 
> I'm not following this part. The CCF mostly asks clock providers
> what parent should be used when clk_set_rate() is called.

Yep, that much is fine; what I was alluding was the above (set_parent
and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)

> 
>>
>> There is also the issue that sometimes, the EMC driver cannot directly
>> switch to the target (rate, parent) pair; instead it is necessary to
>> switch first to another pair we call a backup timing. In this situation,
>> we temporarily have a parent that is neither the one we had before the
>> set_rate call or the one it will be after. Especially, if the switch to
>> the backup timing succeeds but the following switch to the target timing
>> fails, then without the reparent call the parent in hardware would be
>> left inconsistent with the software state.
> 
> Yes, I've sent a patch a while ago to support an idea of a "safe
> parent" or a backup timing that can be used while a clock is
> reprogrammed. Mike has also proposed the concept of "coordinated
> clock rates" which would do something similar and allow clock
> providers to control complicated rate transitions themselves. It
> seems that we may be able to use the "safe parent" concept here,
> where first we switch to some other parent, call the set_rate*
> op, and then switch the parent back if we're not already using
> the parent that we should be using.

While I'm not sure how much sophistication is warranted in the CCF, for
our use case this backup timing has to be able to be a function of the
timing we are leaving and preferably also the target timing. Also, as
usual, the backup timings are (rate, parent) pairs, and just changing
rate or just changing parent are both impossible.

> 
> This sort of thing becomes important for things like per-clock
> locking where we need to know how the clock tree is going to
> change *before* we modify the clock tree. If we go back and forth
> between the clock providers and the clock tree while we're in the
> middle of making irreversible changes to the hardware, we may get
> stuck in a situation where we need to lock more clocks and then
> we may need to undo hardware changes.
> 

Yeah, makes sense.

Do you think you can still pull this patchset? There's other code in
linux-next that depends on it and I'd prefer to have a working driver in
the kernel; if/when the improvements to CCF materialize we could update
the driver to use them.

Thanks,
Mikko.

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Peter De Schrijver]

On Wed, May 27, 2015 at 12:50:21PM -0700, Stephen Boyd wrote:
> On 05/21, Mikko Perttunen wrote:
> > On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> > > On 05/13, Thierry Reding wrote:
> > >> Hi Mike, Stephen,
> > >>
> > >> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> > >>
> > >>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> > >>
> > >> are available in the git repository at:
> > >>
> > >>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> > >>
> > >> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> > >>
> > >>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> > >>
> > >> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> > >> request, so pulling only this one should be sufficient to resolve the
> > >> dependency.
> > >>
> > >> Thanks,
> > >> Thierry
> > >>
> > >> ----------------------------------------------------------------
> > >> clk: tegra: Changes for v4.2-rc1
> > >>
> > >> This contains the EMC clock driver that's been exhaustively reviewed and
> > >> tested. It also includes a change to the clock core that allows a clock
> > >> provider to perform low-level reparenting of clocks. This is required by
> > >> the EMC clock driver because the reparenting needs to be done at a very
> > >> specific point in time during the EMC frequency switch.
> > > 
> > > Can someone please describe why we need to do software
> > > reparenting at a specific point in time during a frequency
> > > switch? I must have missed out on the conversation somewhere and
> > > looking at the commit that introduces the function, the argument
> > > for why the API is exposed:
> > > 
> > >       To be used by clock implementations for switching to a new
> > >       parent during rate change.
> > > 
> > > is lacking in any details about *why* we need it.
> > > 
> > 
> > Hi Stephen,
> > 
> > the way the EMC clock rate is set in hardware is similar to other
> > clocks, i.e. there's a register and you write the new divider and parent
> > id to it. However, with EMC, you cannot just do this any time you want;
> > writing to the register initiates a state machine in the clock hardware
> > that changes a large number of other parameters regarding DRAM timings
> > as well. These parameters need to be programmed into shadow registers
> > before the rate change write is done. This means that both the new
> > divisor and the parent must be written in the same register write.
> > 
> > The CCF has a callback, set_rate_and_parent, which allows for both to be
> > passed to the driver at the same time. However, it also requires
> > set_rate and set_parent to be implemented, which the EMC driver cannot do.
> 
> Ok so we should change the framework to allow drivers to only
> implement set_rate_and_parent and use that in set_rate and
> set_parent implementations if it's the only option available. Or
> is there a problem if CCF allows clk_set_parent() on the EMC
> clock by calling set_rate_and_parent() with the new parent and
> whatever recalc_rate returns for the new parent's rate going into
> the clock?
> 
> > 
> > Furthermore, the CCF cannot help with parent selection for the EMC clock
> > at all. The parent for each rate is selected by the board designer.
> 
> I'm not following this part. The CCF mostly asks clock providers
> what parent should be used when clk_set_rate() is called.
> 

There are a fixed number of allowed EMC OPPs per board. For each OPP there is
a set of EMC parameters, the parent clock and the rate for the parent clock
defined. Due to jitter requirements these settings have to be used. It's
not allowed to choose a different parent even when that would result in the
same clock rate.

> > 
> > There is also the issue that sometimes, the EMC driver cannot directly
> > switch to the target (rate, parent) pair; instead it is necessary to
> > switch first to another pair we call a backup timing. In this situation,
> > we temporarily have a parent that is neither the one we had before the
> > set_rate call or the one it will be after. Especially, if the switch to
> > the backup timing succeeds but the following switch to the target timing
> > fails, then without the reparent call the parent in hardware would be
> > left inconsistent with the software state.
> 
> Yes, I've sent a patch a while ago to support an idea of a "safe
> parent" or a backup timing that can be used while a clock is
> reprogrammed. Mike has also proposed the concept of "coordinated
> clock rates" which would do something similar and allow clock
> providers to control complicated rate transitions themselves. It
> seems that we may be able to use the "safe parent" concept here,
> where first we switch to some other parent, call the set_rate*
> op, and then switch the parent back if we're not already using
> the parent that we should be using.
> 

Due to the interlock between the CAR block and the EMC controller, there
is a precise sequence of register accesses to be followed when doing a EMC
frequency switch. Changing the EMC clock parent or divider in CAR triggers
a state machine in the EMC controller which causes a bunch of shadow registers
to take effect and a FIFO of commands to be send to the SDRAM chips.
Because of this precise sequence, I think a single entity should be responsible
for handling this. Splitting the sequence in multiple parts maintained by
different people, will greatly increase the risk of difficult to trace
stability regressions.

Peter.

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Peter De Schrijver]

On Wed, May 27, 2015 at 12:50:21PM -0700, Stephen Boyd wrote:
> On 05/21, Mikko Perttunen wrote:
> > On 05/20/2015 10:54 PM, Stephen Boyd wrote:
> > > On 05/13, Thierry Reding wrote:
> > >> Hi Mike, Stephen,
> > >>
> > >> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> > >>
> > >>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> > >>
> > >> are available in the git repository at:
> > >>
> > >>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.2-clk
> > >>
> > >> for you to fetch changes up to 36b7be6d3ea8f434f1e0723f3fb0e85c3e00ebc2:
> > >>
> > >>   clk: tegra: Fix hda2codec_2x clock name for Tegra30 (2015-05-13 15:17:14 +0200)
> > >>
> > >> I've based this pull request on top of the tegra-for-4.2-ramcode pull
> > >> request, so pulling only this one should be sufficient to resolve the
> > >> dependency.
> > >>
> > >> Thanks,
> > >> Thierry
> > >>
> > >> ----------------------------------------------------------------
> > >> clk: tegra: Changes for v4.2-rc1
> > >>
> > >> This contains the EMC clock driver that's been exhaustively reviewed and
> > >> tested. It also includes a change to the clock core that allows a clock
> > >> provider to perform low-level reparenting of clocks. This is required by
> > >> the EMC clock driver because the reparenting needs to be done at a very
> > >> specific point in time during the EMC frequency switch.
> > > 
> > > Can someone please describe why we need to do software
> > > reparenting at a specific point in time during a frequency
> > > switch? I must have missed out on the conversation somewhere and
> > > looking at the commit that introduces the function, the argument
> > > for why the API is exposed:
> > > 
> > >       To be used by clock implementations for switching to a new
> > >       parent during rate change.
> > > 
> > > is lacking in any details about *why* we need it.
> > > 
> > 
> > Hi Stephen,
> > 
> > the way the EMC clock rate is set in hardware is similar to other
> > clocks, i.e. there's a register and you write the new divider and parent
> > id to it. However, with EMC, you cannot just do this any time you want;
> > writing to the register initiates a state machine in the clock hardware
> > that changes a large number of other parameters regarding DRAM timings
> > as well. These parameters need to be programmed into shadow registers
> > before the rate change write is done. This means that both the new
> > divisor and the parent must be written in the same register write.
> > 
> > The CCF has a callback, set_rate_and_parent, which allows for both to be
> > passed to the driver at the same time. However, it also requires
> > set_rate and set_parent to be implemented, which the EMC driver cannot do.
> 
> Ok so we should change the framework to allow drivers to only
> implement set_rate_and_parent and use that in set_rate and
> set_parent implementations if it's the only option available. Or
> is there a problem if CCF allows clk_set_parent() on the EMC
> clock by calling set_rate_and_parent() with the new parent and
> whatever recalc_rate returns for the new parent's rate going into
> the clock?
> 
> > 
> > Furthermore, the CCF cannot help with parent selection for the EMC clock
> > at all. The parent for each rate is selected by the board designer.
> 
> I'm not following this part. The CCF mostly asks clock providers
> what parent should be used when clk_set_rate() is called.
> 

There are a fixed number of allowed EMC OPPs per board. For each OPP there is
a set of EMC parameters, the parent clock and the rate for the parent clock
defined. Due to jitter requirements these settings have to be used. It's
not allowed to choose a different parent even when that would result in the
same clock rate.

> > 
> > There is also the issue that sometimes, the EMC driver cannot directly
> > switch to the target (rate, parent) pair; instead it is necessary to
> > switch first to another pair we call a backup timing. In this situation,
> > we temporarily have a parent that is neither the one we had before the
> > set_rate call or the one it will be after. Especially, if the switch to
> > the backup timing succeeds but the following switch to the target timing
> > fails, then without the reparent call the parent in hardware would be
> > left inconsistent with the software state.
> 
> Yes, I've sent a patch a while ago to support an idea of a "safe
> parent" or a backup timing that can be used while a clock is
> reprogrammed. Mike has also proposed the concept of "coordinated
> clock rates" which would do something similar and allow clock
> providers to control complicated rate transitions themselves. It
> seems that we may be able to use the "safe parent" concept here,
> where first we switch to some other parent, call the set_rate*
> op, and then switch the parent back if we're not already using
> the parent that we should be using.
> 

Due to the interlock between the CAR block and the EMC controller, there
is a precise sequence of register accesses to be followed when doing a EMC
frequency switch. Changing the EMC clock parent or divider in CAR triggers
a state machine in the EMC controller which causes a bunch of shadow registers
to take effect and a FIFO of commands to be send to the SDRAM chips.
Because of this precise sequence, I think a single entity should be responsible
for handling this. Splitting the sequence in multiple parts maintained by
different people, will greatly increase the risk of difficult to trace
stability regressions.

Peter.

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Michael Turquette]

Quoting Mikko Perttunen (2015-05-28 00:03:01)
> On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> > On 05/21, Mikko Perttunen wrote:
> >>
> >> Hi Stephen,
> >>
> >> the way the EMC clock rate is set in hardware is similar to other
> >> clocks, i.e. there's a register and you write the new divider and parent
> >> id to it. However, with EMC, you cannot just do this any time you want;
> >> writing to the register initiates a state machine in the clock hardware
> >> that changes a large number of other parameters regarding DRAM timings
> >> as well. These parameters need to be programmed into shadow registers
> >> before the rate change write is done. This means that both the new
> >> divisor and the parent must be written in the same register write.
> >>
> >> The CCF has a callback, set_rate_and_parent, which allows for both to be
> >> passed to the driver at the same time. However, it also requires
> >> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> > 
> > Ok so we should change the framework to allow drivers to only
> > implement set_rate_and_parent and use that in set_rate and
> > set_parent implementations if it's the only option available. Or
> > is there a problem if CCF allows clk_set_parent() on the EMC
> > clock by calling set_rate_and_parent() with the new parent and
> > whatever recalc_rate returns for the new parent's rate going into
> > the clock?
> 
> There isn't really a problem, but the EMC driver cannot implement this
> operation sensibly so it would just always return an error if the (rate,
> parent) pair given to set_rate_and_parent() doesn't exactly match one of
> the entries specified in device tree.
> 
> > 
> >>
> >> Furthermore, the CCF cannot help with parent selection for the EMC clock
> >> at all. The parent for each rate is selected by the board designer.
> > 
> > I'm not following this part. The CCF mostly asks clock providers
> > what parent should be used when clk_set_rate() is called.
> 
> Yep, that much is fine; what I was alluding was the above (set_parent
> and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
> 
> > 
> >>
> >> There is also the issue that sometimes, the EMC driver cannot directly
> >> switch to the target (rate, parent) pair; instead it is necessary to
> >> switch first to another pair we call a backup timing. In this situation,
> >> we temporarily have a parent that is neither the one we had before the
> >> set_rate call or the one it will be after. Especially, if the switch to
> >> the backup timing succeeds but the following switch to the target timing
> >> fails, then without the reparent call the parent in hardware would be
> >> left inconsistent with the software state.
> > 
> > Yes, I've sent a patch a while ago to support an idea of a "safe
> > parent" or a backup timing that can be used while a clock is
> > reprogrammed. Mike has also proposed the concept of "coordinated
> > clock rates" which would do something similar and allow clock
> > providers to control complicated rate transitions themselves. It
> > seems that we may be able to use the "safe parent" concept here,
> > where first we switch to some other parent, call the set_rate*
> > op, and then switch the parent back if we're not already using
> > the parent that we should be using.
> 
> While I'm not sure how much sophistication is warranted in the CCF, for
> our use case this backup timing has to be able to be a function of the
> timing we are leaving and preferably also the target timing. Also, as
> usual, the backup timings are (rate, parent) pairs, and just changing
> rate or just changing parent are both impossible.
> 
> > 
> > This sort of thing becomes important for things like per-clock
> > locking where we need to know how the clock tree is going to
> > change *before* we modify the clock tree. If we go back and forth
> > between the clock providers and the clock tree while we're in the
> > middle of making irreversible changes to the hardware, we may get
> > stuck in a situation where we need to lock more clocks and then
> > we may need to undo hardware changes.
> > 
> 
> Yeah, makes sense.
> 
> Do you think you can still pull this patchset? There's other code in
> linux-next that depends on it and I'd prefer to have a working driver in
> the kernel; if/when the improvements to CCF materialize we could update
> the driver to use them.

I'm not really sure what to do with this PR. This seems to fall into the
same category as the Exynos "cpu clocks" series: you have a complex
sequence that requires multiple clock nodes to be changes in a
coordinated fashion.

I'm working on some core infrastructure to fix this. I'd like to get
that on the list asap and possibly merged for 4.3. I think it can
benefit your case and remove the need to export clk_hw_reparent, which
is pretty nasty.

What exactly will break if this is not pulled? I appreciate your offer
to update this driver when the core changes are merged, but I would
prefer to do it the right way first, instead of fixing up something that
is already merged after the fact.

Regards,
Mike

> 
> Thanks,
> Mikko.

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Michael Turquette]

Quoting Mikko Perttunen (2015-05-28 00:03:01)
> On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> > On 05/21, Mikko Perttunen wrote:
> >>
> >> Hi Stephen,
> >>
> >> the way the EMC clock rate is set in hardware is similar to other
> >> clocks, i.e. there's a register and you write the new divider and parent
> >> id to it. However, with EMC, you cannot just do this any time you want;
> >> writing to the register initiates a state machine in the clock hardware
> >> that changes a large number of other parameters regarding DRAM timings
> >> as well. These parameters need to be programmed into shadow registers
> >> before the rate change write is done. This means that both the new
> >> divisor and the parent must be written in the same register write.
> >>
> >> The CCF has a callback, set_rate_and_parent, which allows for both to be
> >> passed to the driver at the same time. However, it also requires
> >> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> > 
> > Ok so we should change the framework to allow drivers to only
> > implement set_rate_and_parent and use that in set_rate and
> > set_parent implementations if it's the only option available. Or
> > is there a problem if CCF allows clk_set_parent() on the EMC
> > clock by calling set_rate_and_parent() with the new parent and
> > whatever recalc_rate returns for the new parent's rate going into
> > the clock?
> 
> There isn't really a problem, but the EMC driver cannot implement this
> operation sensibly so it would just always return an error if the (rate,
> parent) pair given to set_rate_and_parent() doesn't exactly match one of
> the entries specified in device tree.
> 
> > 
> >>
> >> Furthermore, the CCF cannot help with parent selection for the EMC clock
> >> at all. The parent for each rate is selected by the board designer.
> > 
> > I'm not following this part. The CCF mostly asks clock providers
> > what parent should be used when clk_set_rate() is called.
> 
> Yep, that much is fine; what I was alluding was the above (set_parent
> and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
> 
> > 
> >>
> >> There is also the issue that sometimes, the EMC driver cannot directly
> >> switch to the target (rate, parent) pair; instead it is necessary to
> >> switch first to another pair we call a backup timing. In this situation,
> >> we temporarily have a parent that is neither the one we had before the
> >> set_rate call or the one it will be after. Especially, if the switch to
> >> the backup timing succeeds but the following switch to the target timing
> >> fails, then without the reparent call the parent in hardware would be
> >> left inconsistent with the software state.
> > 
> > Yes, I've sent a patch a while ago to support an idea of a "safe
> > parent" or a backup timing that can be used while a clock is
> > reprogrammed. Mike has also proposed the concept of "coordinated
> > clock rates" which would do something similar and allow clock
> > providers to control complicated rate transitions themselves. It
> > seems that we may be able to use the "safe parent" concept here,
> > where first we switch to some other parent, call the set_rate*
> > op, and then switch the parent back if we're not already using
> > the parent that we should be using.
> 
> While I'm not sure how much sophistication is warranted in the CCF, for
> our use case this backup timing has to be able to be a function of the
> timing we are leaving and preferably also the target timing. Also, as
> usual, the backup timings are (rate, parent) pairs, and just changing
> rate or just changing parent are both impossible.
> 
> > 
> > This sort of thing becomes important for things like per-clock
> > locking where we need to know how the clock tree is going to
> > change *before* we modify the clock tree. If we go back and forth
> > between the clock providers and the clock tree while we're in the
> > middle of making irreversible changes to the hardware, we may get
> > stuck in a situation where we need to lock more clocks and then
> > we may need to undo hardware changes.
> > 
> 
> Yeah, makes sense.
> 
> Do you think you can still pull this patchset? There's other code in
> linux-next that depends on it and I'd prefer to have a working driver in
> the kernel; if/when the improvements to CCF materialize we could update
> the driver to use them.

I'm not really sure what to do with this PR. This seems to fall into the
same category as the Exynos "cpu clocks" series: you have a complex
sequence that requires multiple clock nodes to be changes in a
coordinated fashion.

I'm working on some core infrastructure to fix this. I'd like to get
that on the list asap and possibly merged for 4.3. I think it can
benefit your case and remove the need to export clk_hw_reparent, which
is pretty nasty.

What exactly will break if this is not pulled? I appreciate your offer
to update this driver when the core changes are merged, but I would
prefer to do it the right way first, instead of fixing up something that
is already merged after the fact.

Regards,
Mike

> 
> Thanks,
> Mikko.

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Michael Turquette]

Quoting Michael Turquette (2015-06-18 16:41:26)
> Quoting Mikko Perttunen (2015-05-28 00:03:01)
> > On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> > > On 05/21, Mikko Perttunen wrote:
> > >>
> > >> Hi Stephen,
> > >>
> > >> the way the EMC clock rate is set in hardware is similar to other
> > >> clocks, i.e. there's a register and you write the new divider and parent
> > >> id to it. However, with EMC, you cannot just do this any time you want;
> > >> writing to the register initiates a state machine in the clock hardware
> > >> that changes a large number of other parameters regarding DRAM timings
> > >> as well. These parameters need to be programmed into shadow registers
> > >> before the rate change write is done. This means that both the new
> > >> divisor and the parent must be written in the same register write.
> > >>
> > >> The CCF has a callback, set_rate_and_parent, which allows for both to be
> > >> passed to the driver at the same time. However, it also requires
> > >> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> > > 
> > > Ok so we should change the framework to allow drivers to only
> > > implement set_rate_and_parent and use that in set_rate and
> > > set_parent implementations if it's the only option available. Or
> > > is there a problem if CCF allows clk_set_parent() on the EMC
> > > clock by calling set_rate_and_parent() with the new parent and
> > > whatever recalc_rate returns for the new parent's rate going into
> > > the clock?
> > 
> > There isn't really a problem, but the EMC driver cannot implement this
> > operation sensibly so it would just always return an error if the (rate,
> > parent) pair given to set_rate_and_parent() doesn't exactly match one of
> > the entries specified in device tree.
> > 
> > > 
> > >>
> > >> Furthermore, the CCF cannot help with parent selection for the EMC clock
> > >> at all. The parent for each rate is selected by the board designer.
> > > 
> > > I'm not following this part. The CCF mostly asks clock providers
> > > what parent should be used when clk_set_rate() is called.
> > 
> > Yep, that much is fine; what I was alluding was the above (set_parent
> > and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
> > 
> > > 
> > >>
> > >> There is also the issue that sometimes, the EMC driver cannot directly
> > >> switch to the target (rate, parent) pair; instead it is necessary to
> > >> switch first to another pair we call a backup timing. In this situation,
> > >> we temporarily have a parent that is neither the one we had before the
> > >> set_rate call or the one it will be after. Especially, if the switch to
> > >> the backup timing succeeds but the following switch to the target timing
> > >> fails, then without the reparent call the parent in hardware would be
> > >> left inconsistent with the software state.
> > > 
> > > Yes, I've sent a patch a while ago to support an idea of a "safe
> > > parent" or a backup timing that can be used while a clock is
> > > reprogrammed. Mike has also proposed the concept of "coordinated
> > > clock rates" which would do something similar and allow clock
> > > providers to control complicated rate transitions themselves. It
> > > seems that we may be able to use the "safe parent" concept here,
> > > where first we switch to some other parent, call the set_rate*
> > > op, and then switch the parent back if we're not already using
> > > the parent that we should be using.
> > 
> > While I'm not sure how much sophistication is warranted in the CCF, for
> > our use case this backup timing has to be able to be a function of the
> > timing we are leaving and preferably also the target timing. Also, as
> > usual, the backup timings are (rate, parent) pairs, and just changing
> > rate or just changing parent are both impossible.
> > 
> > > 
> > > This sort of thing becomes important for things like per-clock
> > > locking where we need to know how the clock tree is going to
> > > change *before* we modify the clock tree. If we go back and forth
> > > between the clock providers and the clock tree while we're in the
> > > middle of making irreversible changes to the hardware, we may get
> > > stuck in a situation where we need to lock more clocks and then
> > > we may need to undo hardware changes.
> > > 
> > 
> > Yeah, makes sense.
> > 
> > Do you think you can still pull this patchset? There's other code in
> > linux-next that depends on it and I'd prefer to have a working driver in
> > the kernel; if/when the improvements to CCF materialize we could update
> > the driver to use them.
> 
> I'm not really sure what to do with this PR. This seems to fall into the
> same category as the Exynos "cpu clocks" series: you have a complex
> sequence that requires multiple clock nodes to be changes in a
> coordinated fashion.

I've decided to pull this in the interest of fairness. I'm taking the
Exynos cpu clock patches, which will need to be updated in the future to
use some new infrastructure for coordinating rate changes across
multiple clock nodes. I'm merging the EMC stuff with the same
expectation that it will need to migrate to the new infrastructure when
it becomes available and we'll get rid of clk_hw_reparent.

Sound good?

Regards,
Mike

> 
> I'm working on some core infrastructure to fix this. I'd like to get
> that on the list asap and possibly merged for 4.3. I think it can
> benefit your case and remove the need to export clk_hw_reparent, which
> is pretty nasty.
> 
> What exactly will break if this is not pulled? I appreciate your offer
> to update this driver when the core changes are merged, but I would
> prefer to do it the right way first, instead of fixing up something that
> is already merged after the fact.
> 
> Regards,
> Mike
> 
> > 
> > Thanks,
> > Mikko.

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Michael Turquette]

Quoting Michael Turquette (2015-06-18 16:41:26)
> Quoting Mikko Perttunen (2015-05-28 00:03:01)
> > On 05/27/2015 10:50 PM, Stephen Boyd wrote:
> > > On 05/21, Mikko Perttunen wrote:
> > >>
> > >> Hi Stephen,
> > >>
> > >> the way the EMC clock rate is set in hardware is similar to other
> > >> clocks, i.e. there's a register and you write the new divider and parent
> > >> id to it. However, with EMC, you cannot just do this any time you want;
> > >> writing to the register initiates a state machine in the clock hardware
> > >> that changes a large number of other parameters regarding DRAM timings
> > >> as well. These parameters need to be programmed into shadow registers
> > >> before the rate change write is done. This means that both the new
> > >> divisor and the parent must be written in the same register write.
> > >>
> > >> The CCF has a callback, set_rate_and_parent, which allows for both to be
> > >> passed to the driver at the same time. However, it also requires
> > >> set_rate and set_parent to be implemented, which the EMC driver cannot do.
> > > 
> > > Ok so we should change the framework to allow drivers to only
> > > implement set_rate_and_parent and use that in set_rate and
> > > set_parent implementations if it's the only option available. Or
> > > is there a problem if CCF allows clk_set_parent() on the EMC
> > > clock by calling set_rate_and_parent() with the new parent and
> > > whatever recalc_rate returns for the new parent's rate going into
> > > the clock?
> > 
> > There isn't really a problem, but the EMC driver cannot implement this
> > operation sensibly so it would just always return an error if the (rate,
> > parent) pair given to set_rate_and_parent() doesn't exactly match one of
> > the entries specified in device tree.
> > 
> > > 
> > >>
> > >> Furthermore, the CCF cannot help with parent selection for the EMC clock
> > >> at all. The parent for each rate is selected by the board designer.
> > > 
> > > I'm not following this part. The CCF mostly asks clock providers
> > > what parent should be used when clk_set_rate() is called.
> > 
> > Yep, that much is fine; what I was alluding was the above (set_parent
> > and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
> > 
> > > 
> > >>
> > >> There is also the issue that sometimes, the EMC driver cannot directly
> > >> switch to the target (rate, parent) pair; instead it is necessary to
> > >> switch first to another pair we call a backup timing. In this situation,
> > >> we temporarily have a parent that is neither the one we had before the
> > >> set_rate call or the one it will be after. Especially, if the switch to
> > >> the backup timing succeeds but the following switch to the target timing
> > >> fails, then without the reparent call the parent in hardware would be
> > >> left inconsistent with the software state.
> > > 
> > > Yes, I've sent a patch a while ago to support an idea of a "safe
> > > parent" or a backup timing that can be used while a clock is
> > > reprogrammed. Mike has also proposed the concept of "coordinated
> > > clock rates" which would do something similar and allow clock
> > > providers to control complicated rate transitions themselves. It
> > > seems that we may be able to use the "safe parent" concept here,
> > > where first we switch to some other parent, call the set_rate*
> > > op, and then switch the parent back if we're not already using
> > > the parent that we should be using.
> > 
> > While I'm not sure how much sophistication is warranted in the CCF, for
> > our use case this backup timing has to be able to be a function of the
> > timing we are leaving and preferably also the target timing. Also, as
> > usual, the backup timings are (rate, parent) pairs, and just changing
> > rate or just changing parent are both impossible.
> > 
> > > 
> > > This sort of thing becomes important for things like per-clock
> > > locking where we need to know how the clock tree is going to
> > > change *before* we modify the clock tree. If we go back and forth
> > > between the clock providers and the clock tree while we're in the
> > > middle of making irreversible changes to the hardware, we may get
> > > stuck in a situation where we need to lock more clocks and then
> > > we may need to undo hardware changes.
> > > 
> > 
> > Yeah, makes sense.
> > 
> > Do you think you can still pull this patchset? There's other code in
> > linux-next that depends on it and I'd prefer to have a working driver in
> > the kernel; if/when the improvements to CCF materialize we could update
> > the driver to use them.
> 
> I'm not really sure what to do with this PR. This seems to fall into the
> same category as the Exynos "cpu clocks" series: you have a complex
> sequence that requires multiple clock nodes to be changes in a
> coordinated fashion.

I've decided to pull this in the interest of fairness. I'm taking the
Exynos cpu clock patches, which will need to be updated in the future to
use some new infrastructure for coordinating rate changes across
multiple clock nodes. I'm merging the EMC stuff with the same
expectation that it will need to migrate to the new infrastructure when
it becomes available and we'll get rid of clk_hw_reparent.

Sound good?

Regards,
Mike

> 
> I'm working on some core infrastructure to fix this. I'd like to get
> that on the list asap and possibly merged for 4.3. I think it can
> benefit your case and remove the need to export clk_hw_reparent, which
> is pretty nasty.
> 
> What exactly will break if this is not pulled? I appreciate your offer
> to update this driver when the core changes are merged, but I would
> prefer to do it the right way first, instead of fixing up something that
> is already merged after the fact.
> 
> Regards,
> Mike
> 
> > 
> > Thanks,
> > Mikko.

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 06/20/15 23:41, Michael Turquette wrote:
> Quoting Michael Turquette (2015-06-18 16:41:26)
>> Quoting Mikko Perttunen (2015-05-28 00:03:01)
>>> On 05/27/2015 10:50 PM, Stephen Boyd wrote:
>>>> On 05/21, Mikko Perttunen wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> the way the EMC clock rate is set in hardware is similar to other
>>>>> clocks, i.e. there's a register and you write the new divider and parent
>>>>> id to it. However, with EMC, you cannot just do this any time you want;
>>>>> writing to the register initiates a state machine in the clock hardware
>>>>> that changes a large number of other parameters regarding DRAM timings
>>>>> as well. These parameters need to be programmed into shadow registers
>>>>> before the rate change write is done. This means that both the new
>>>>> divisor and the parent must be written in the same register write.
>>>>>
>>>>> The CCF has a callback, set_rate_and_parent, which allows for both to be
>>>>> passed to the driver at the same time. However, it also requires
>>>>> set_rate and set_parent to be implemented, which the EMC driver cannot do.
>>>>
>>>> Ok so we should change the framework to allow drivers to only
>>>> implement set_rate_and_parent and use that in set_rate and
>>>> set_parent implementations if it's the only option available. Or
>>>> is there a problem if CCF allows clk_set_parent() on the EMC
>>>> clock by calling set_rate_and_parent() with the new parent and
>>>> whatever recalc_rate returns for the new parent's rate going into
>>>> the clock?
>>>
>>> There isn't really a problem, but the EMC driver cannot implement this
>>> operation sensibly so it would just always return an error if the (rate,
>>> parent) pair given to set_rate_and_parent() doesn't exactly match one of
>>> the entries specified in device tree.
>>>
>>>>
>>>>>
>>>>> Furthermore, the CCF cannot help with parent selection for the EMC clock
>>>>> at all. The parent for each rate is selected by the board designer.
>>>>
>>>> I'm not following this part. The CCF mostly asks clock providers
>>>> what parent should be used when clk_set_rate() is called.
>>>
>>> Yep, that much is fine; what I was alluding was the above (set_parent
>>> and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
>>>
>>>>
>>>>>
>>>>> There is also the issue that sometimes, the EMC driver cannot directly
>>>>> switch to the target (rate, parent) pair; instead it is necessary to
>>>>> switch first to another pair we call a backup timing. In this situation,
>>>>> we temporarily have a parent that is neither the one we had before the
>>>>> set_rate call or the one it will be after. Especially, if the switch to
>>>>> the backup timing succeeds but the following switch to the target timing
>>>>> fails, then without the reparent call the parent in hardware would be
>>>>> left inconsistent with the software state.
>>>>
>>>> Yes, I've sent a patch a while ago to support an idea of a "safe
>>>> parent" or a backup timing that can be used while a clock is
>>>> reprogrammed. Mike has also proposed the concept of "coordinated
>>>> clock rates" which would do something similar and allow clock
>>>> providers to control complicated rate transitions themselves. It
>>>> seems that we may be able to use the "safe parent" concept here,
>>>> where first we switch to some other parent, call the set_rate*
>>>> op, and then switch the parent back if we're not already using
>>>> the parent that we should be using.
>>>
>>> While I'm not sure how much sophistication is warranted in the CCF, for
>>> our use case this backup timing has to be able to be a function of the
>>> timing we are leaving and preferably also the target timing. Also, as
>>> usual, the backup timings are (rate, parent) pairs, and just changing
>>> rate or just changing parent are both impossible.
>>>
>>>>
>>>> This sort of thing becomes important for things like per-clock
>>>> locking where we need to know how the clock tree is going to
>>>> change *before* we modify the clock tree. If we go back and forth
>>>> between the clock providers and the clock tree while we're in the
>>>> middle of making irreversible changes to the hardware, we may get
>>>> stuck in a situation where we need to lock more clocks and then
>>>> we may need to undo hardware changes.
>>>>
>>>
>>> Yeah, makes sense.
>>>
>>> Do you think you can still pull this patchset? There's other code in
>>> linux-next that depends on it and I'd prefer to have a working driver in
>>> the kernel; if/when the improvements to CCF materialize we could update
>>> the driver to use them.
>>
>> I'm not really sure what to do with this PR. This seems to fall into the
>> same category as the Exynos "cpu clocks" series: you have a complex
>> sequence that requires multiple clock nodes to be changes in a
>> coordinated fashion.
>
> I've decided to pull this in the interest of fairness. I'm taking the
> Exynos cpu clock patches, which will need to be updated in the future to
> use some new infrastructure for coordinating rate changes across
> multiple clock nodes. I'm merging the EMC stuff with the same
> expectation that it will need to migrate to the new infrastructure when
> it becomes available and we'll get rid of clk_hw_reparent.
>
> Sound good?

Sounds good! Please keep us informed and once the framework changes land 
we'll fix up this one.

>
> Regards,
> Mike
>

Thanks,
Mikko.

>>
>> I'm working on some core infrastructure to fix this. I'd like to get
>> that on the list asap and possibly merged for 4.3. I think it can
>> benefit your case and remove the need to export clk_hw_reparent, which
>> is pretty nasty.
>>
>> What exactly will break if this is not pulled? I appreciate your offer
>> to update this driver when the core changes are merged, but I would
>> prefer to do it the right way first, instead of fixing up something that
>> is already merged after the fact.
>>
>> Regards,
>> Mike
>>
>>>
>>> Thanks,
>>> Mikko.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

On 06/20/15 23:41, Michael Turquette wrote:
> Quoting Michael Turquette (2015-06-18 16:41:26)
>> Quoting Mikko Perttunen (2015-05-28 00:03:01)
>>> On 05/27/2015 10:50 PM, Stephen Boyd wrote:
>>>> On 05/21, Mikko Perttunen wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> the way the EMC clock rate is set in hardware is similar to other
>>>>> clocks, i.e. there's a register and you write the new divider and parent
>>>>> id to it. However, with EMC, you cannot just do this any time you want;
>>>>> writing to the register initiates a state machine in the clock hardware
>>>>> that changes a large number of other parameters regarding DRAM timings
>>>>> as well. These parameters need to be programmed into shadow registers
>>>>> before the rate change write is done. This means that both the new
>>>>> divisor and the parent must be written in the same register write.
>>>>>
>>>>> The CCF has a callback, set_rate_and_parent, which allows for both to be
>>>>> passed to the driver at the same time. However, it also requires
>>>>> set_rate and set_parent to be implemented, which the EMC driver cannot do.
>>>>
>>>> Ok so we should change the framework to allow drivers to only
>>>> implement set_rate_and_parent and use that in set_rate and
>>>> set_parent implementations if it's the only option available. Or
>>>> is there a problem if CCF allows clk_set_parent() on the EMC
>>>> clock by calling set_rate_and_parent() with the new parent and
>>>> whatever recalc_rate returns for the new parent's rate going into
>>>> the clock?
>>>
>>> There isn't really a problem, but the EMC driver cannot implement this
>>> operation sensibly so it would just always return an error if the (rate,
>>> parent) pair given to set_rate_and_parent() doesn't exactly match one of
>>> the entries specified in device tree.
>>>
>>>>
>>>>>
>>>>> Furthermore, the CCF cannot help with parent selection for the EMC clock
>>>>> at all. The parent for each rate is selected by the board designer.
>>>>
>>>> I'm not following this part. The CCF mostly asks clock providers
>>>> what parent should be used when clk_set_rate() is called.
>>>
>>> Yep, that much is fine; what I was alluding was the above (set_parent
>>> and set_rate_and_parent with an unlisted (rate, parent) pair are invalid)
>>>
>>>>
>>>>>
>>>>> There is also the issue that sometimes, the EMC driver cannot directly
>>>>> switch to the target (rate, parent) pair; instead it is necessary to
>>>>> switch first to another pair we call a backup timing. In this situation,
>>>>> we temporarily have a parent that is neither the one we had before the
>>>>> set_rate call or the one it will be after. Especially, if the switch to
>>>>> the backup timing succeeds but the following switch to the target timing
>>>>> fails, then without the reparent call the parent in hardware would be
>>>>> left inconsistent with the software state.
>>>>
>>>> Yes, I've sent a patch a while ago to support an idea of a "safe
>>>> parent" or a backup timing that can be used while a clock is
>>>> reprogrammed. Mike has also proposed the concept of "coordinated
>>>> clock rates" which would do something similar and allow clock
>>>> providers to control complicated rate transitions themselves. It
>>>> seems that we may be able to use the "safe parent" concept here,
>>>> where first we switch to some other parent, call the set_rate*
>>>> op, and then switch the parent back if we're not already using
>>>> the parent that we should be using.
>>>
>>> While I'm not sure how much sophistication is warranted in the CCF, for
>>> our use case this backup timing has to be able to be a function of the
>>> timing we are leaving and preferably also the target timing. Also, as
>>> usual, the backup timings are (rate, parent) pairs, and just changing
>>> rate or just changing parent are both impossible.
>>>
>>>>
>>>> This sort of thing becomes important for things like per-clock
>>>> locking where we need to know how the clock tree is going to
>>>> change *before* we modify the clock tree. If we go back and forth
>>>> between the clock providers and the clock tree while we're in the
>>>> middle of making irreversible changes to the hardware, we may get
>>>> stuck in a situation where we need to lock more clocks and then
>>>> we may need to undo hardware changes.
>>>>
>>>
>>> Yeah, makes sense.
>>>
>>> Do you think you can still pull this patchset? There's other code in
>>> linux-next that depends on it and I'd prefer to have a working driver in
>>> the kernel; if/when the improvements to CCF materialize we could update
>>> the driver to use them.
>>
>> I'm not really sure what to do with this PR. This seems to fall into the
>> same category as the Exynos "cpu clocks" series: you have a complex
>> sequence that requires multiple clock nodes to be changes in a
>> coordinated fashion.
>
> I've decided to pull this in the interest of fairness. I'm taking the
> Exynos cpu clock patches, which will need to be updated in the future to
> use some new infrastructure for coordinating rate changes across
> multiple clock nodes. I'm merging the EMC stuff with the same
> expectation that it will need to migrate to the new infrastructure when
> it becomes available and we'll get rid of clk_hw_reparent.
>
> Sound good?

Sounds good! Please keep us informed and once the framework changes land 
we'll fix up this one.

>
> Regards,
> Mike
>

Thanks,
Mikko.

>>
>> I'm working on some core infrastructure to fix this. I'd like to get
>> that on the list asap and possibly merged for 4.3. I think it can
>> benefit your case and remove the need to export clk_hw_reparent, which
>> is pretty nasty.
>>
>> What exactly will break if this is not pulled? I appreciate your offer
>> to update this driver when the core changes are merged, but I would
>> prefer to do it the right way first, instead of fixing up something that
>> is already merged after the fact.
>>
>> Regards,
>> Mike
>>
>>>
>>> Thanks,
>>> Mikko.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

Fixing Mike's mail address

On 06/22/15 09:59, Mikko Perttunen wrote:
> On 06/20/15 23:41, Michael Turquette wrote:
>> Quoting Michael Turquette (2015-06-18 16:41:26)
>> ...
>> I've decided to pull this in the interest of fairness. I'm taking the
>> Exynos cpu clock patches, which will need to be updated in the future to
>> use some new infrastructure for coordinating rate changes across
>> multiple clock nodes. I'm merging the EMC stuff with the same
>> expectation that it will need to migrate to the new infrastructure when
>> it becomes available and we'll get rid of clk_hw_reparent.
>>
>> Sound good?
>
> Sounds good! Please keep us informed and once the framework changes land
> we'll fix up this one.
>
>>
>> Regards,
>> Mike
>>
>
> Thanks,
> Mikko.
>
>>>
>>> I'm working on some core infrastructure to fix this. I'd like to get
>>> that on the list asap and possibly merged for 4.3. I think it can
>>> benefit your case and remove the need to export clk_hw_reparent, which
>>> is pretty nasty.
>>>
>>> What exactly will break if this is not pulled? I appreciate your offer
>>> to update this driver when the core changes are merged, but I would
>>> prefer to do it the right way first, instead of fixing up something that
>>> is already merged after the fact.
>>>
>>> Regards,
>>> Mike
>>>
>>>>
>>>> Thanks,
>>>> Mikko.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>>
>

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Mikko Perttunen]

Fixing Mike's mail address

On 06/22/15 09:59, Mikko Perttunen wrote:
> On 06/20/15 23:41, Michael Turquette wrote:
>> Quoting Michael Turquette (2015-06-18 16:41:26)
>> ...
>> I've decided to pull this in the interest of fairness. I'm taking the
>> Exynos cpu clock patches, which will need to be updated in the future to
>> use some new infrastructure for coordinating rate changes across
>> multiple clock nodes. I'm merging the EMC stuff with the same
>> expectation that it will need to migrate to the new infrastructure when
>> it becomes available and we'll get rid of clk_hw_reparent.
>>
>> Sound good?
>
> Sounds good! Please keep us informed and once the framework changes land
> we'll fix up this one.
>
>>
>> Regards,
>> Mike
>>
>
> Thanks,
> Mikko.
>
>>>
>>> I'm working on some core infrastructure to fix this. I'd like to get
>>> that on the list asap and possibly merged for 4.3. I think it can
>>> benefit your case and remove the need to export clk_hw_reparent, which
>>> is pretty nasty.
>>>
>>> What exactly will break if this is not pulled? I appreciate your offer
>>> to update this driver when the core changes are merged, but I would
>>> prefer to do it the right way first, instead of fixing up something that
>>> is already merged after the fact.
>>>
>>> Regards,
>>> Mike
>>>
>>>>
>>>> Thanks,
>>>> Mikko.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>>
>

Re: [GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Thierry Reding]

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

On Sat, Jun 20, 2015 at 01:41:04PM -0700, Michael Turquette wrote:
[...]
> I've decided to pull this in the interest of fairness. I'm taking the
> Exynos cpu clock patches, which will need to be updated in the future to
> use some new infrastructure for coordinating rate changes across
> multiple clock nodes. I'm merging the EMC stuff with the same
> expectation that it will need to migrate to the new infrastructure when
> it becomes available and we'll get rid of clk_hw_reparent.
> 
> Sound good?

Sounds good, thanks Mike. I'm sure we'll find someone to update this
when the framework changes are ready.

Thierry

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

[GIT PULL 4/8] clk: tegra: Changes for v4.2-rc1

[Thierry Reding]

On Sat, Jun 20, 2015 at 01:41:04PM -0700, Michael Turquette wrote:
[...]
> I've decided to pull this in the interest of fairness. I'm taking the
> Exynos cpu clock patches, which will need to be updated in the future to
> use some new infrastructure for coordinating rate changes across
> multiple clock nodes. I'm merging the EMC stuff with the same
> expectation that it will need to migrate to the new infrastructure when
> it becomes available and we'll get rid of clk_hw_reparent.
> 
> Sound good?

Sounds good, thanks Mike. I'm sure we'll find someone to update this
when the framework changes are ready.

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