ARM: tegra: Changes for v4.3-rc1

GIT PULL Applied Thierry Reding 10 participants 50 messages Aug 14, 2015 – Sep 17, 2015

Subsystems (5)

Arm (32-bit) GPIO Common clk Tegra architecture support +1 more subsystems

lore

Share & tools

lore

Thierry Reding

author

2015-08-14 14:48 UTC #0 lore raw

Hi ARM SoC maintainers, Mike, Stephen, Linus, Joerg,

Here's a set of pull requests with changes for v4.3-rc1. This is coming in rather late, but most of this is pretty trivial, so I hope it can still be merged for the v4.3 window.

Thanks,
Thierry

Thierry Reding

author

2015-08-14 14:48 UTC #1 lore raw

[GIT PULL 1/9] clk: tegra: Changes for v4.3-rc1

Hi Mike, Stephen,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 79cf95c763a11d4b365cd5a627fd1ab4dca67890:

clk: tegra: Add the DFLL as a possible parent of the cclk_g clock (2015-07-16 10:40:20 +0200)

Thanks,
Thierry

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

This contains the DFLL driver needed to implement CPU frequency scaling on Tegra.

----------------------------------------------------------------
Mikko Perttunen (1):
clk: tegra: Introduce ability for SoC-specific reset control callbacks

Paul Walmsley (1):
clk: tegra: Add DFLL DVCO reset control for Tegra124

Tuomas Tynkkynen (7):
clk: tegra: Add binding for the Tegra124 DFLL clocksource
clk: tegra: Add library for the DFLL clock source (open-loop mode)
clk: tegra: Add closed loop support for the DFLL
clk: tegra: Add functions for parsing CVB tables
clk: tegra: Add Tegra124 DFLL clocksource platform driver
clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend
clk: tegra: Add the DFLL as a possible parent of the cclk_g clock

 .../bindings/clock/nvidia,tegra124-dfll.txt        |   79 +
 arch/arm/mach-tegra/Kconfig                        |    1 +
 drivers/clk/tegra/Makefile                         |    3 +
 drivers/clk/tegra/clk-dfll.c                       | 1755 ++++++++++++++++++++
 drivers/clk/tegra/clk-dfll.h                       |   54 +
 drivers/clk/tegra/clk-tegra-super-gen4.c           |    4 +-
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c         |  166 ++
 drivers/clk/tegra/clk-tegra124.c                   |   82 +
 drivers/clk/tegra/clk.c                            |   39 +-
 drivers/clk/tegra/clk.h                            |    3 +
 drivers/clk/tegra/cvb.c                            |  140 ++
 drivers/clk/tegra/cvb.h                            |   67 +
 include/dt-bindings/reset/tegra124-car.h           |   12 +
 13 files changed, 2396 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h
 create mode 100644 include/dt-bindings/reset/tegra124-car.h

Stephen Boyd

2015-08-25 23:43 UTC #2 lore raw

[GIT PULL 1/9] clk: tegra: Changes for v4.3-rc1

Quoted 6 lines · Thierry Reding

Hi Mike, Stephen,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

Quoted 8 lines

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-clk
for you to fetch changes up to 79cf95c763a11d4b365cd5a627fd1ab4dca67890:
clk: tegra: Add the DFLL as a possible parent of the cclk_g clock (2015-07-16 10:40:20 +0200)

Pulled into clk-next. I had to apply this patch on top though. Please check and be more careful next time.

Also, I don't understand why __raw_{readl,writel} is used. You probably wanted the relaxed versions of the accessors, and not the ones that don't do any byte swapping.

Finally, please Cc linux-clk at vger.kernel.org next time.

Thanks!

----8<----
From: Stephen Boyd <[email protected]>
Subject: [PATCH] clk: tegra: Fix some static checker problems

The latest Tegra clk pull had some problems. Fix them.

drivers/clk/tegra/clk-tegra124.c:1450:6: warning: symbol 'tegra124_clock_assert_dfll_dvco_reset' was not declared. Should it be static? drivers/clk/tegra/clk-tegra124.c:1466:6: warning: symbol 'tegra124_clock_deassert_dfll_dvco_reset' was not declared. Should it be static? drivers/clk/tegra/clk-tegra124.c:1476:5: warning: symbol 'tegra124_reset_assert' was not declared. Should it be static? drivers/clk/tegra/clk-tegra124.c:1486:5: warning: symbol 'tegra124_reset_deassert' was not declared. Should it be static? drivers/clk/tegra/clk-dfll.c:590 dfll_load_i2c_lut() warn: inconsistent indenting
drivers/clk/tegra/clk-dfll.c:1448 dfll_build_i2c_lut() warn: unsigned 'td->i2c_lut[0]' is never less than zero.

Signed-off-by Stephen Boyd <[email protected]>

---
 drivers/clk/tegra/clk-dfll.c     | 8 +++++---
 drivers/clk/tegra/clk-tegra124.c | 8 ++++----
 2 files changed, 9 insertions(+), 7 deletions(-)

drivers/clk/tegra/clk-dfll.c +5 -3

index 109a79b95238..c2ff859ee0e8 100644
@@ -587,7 +587,7 @@ static void dfll_load_i2c_lut(struct tegra_dfll *td)
 		else
 			lut_index = i;
 
-		  val = regulator_list_hardware_vsel(td->vdd_reg,
+		val = regulator_list_hardware_vsel(td->vdd_reg,
 						     td->i2c_lut[lut_index]);
 		__raw_writel(val, td->lut_base + i * 4);
 	}

@@ -1432,6 +1432,7 @@ static int dfll_build_i2c_lut(struct tegra_dfll *td)
 	int selector;
 	unsigned long rate;
 	struct dev_pm_opp *opp;
+	int lut;
 
 	rcu_read_lock();

@@ -1444,9 +1445,10 @@ static int dfll_build_i2c_lut(struct tegra_dfll *td)
 	v_max = dev_pm_opp_get_voltage(opp);
 
 	v = td->soc->min_millivolts * 1000;
-	td->i2c_lut[0] = find_vdd_map_entry_exact(td, v);
-	if (td->i2c_lut[0] < 0)
+	lut = find_vdd_map_entry_exact(td, v);
+	if (lut < 0)
 		goto out;
+	td->i2c_lut[0] = lut;
 
 	for (j = 1, rate = 0; ; rate++) {
 		opp = dev_pm_opp_find_freq_ceil(td->soc->dev, &rate);

drivers/clk/tegra/clk-tegra124.c +4 -4

index a9e2b30737ec..824d75883d2b 100644
@@ -1447,7 +1447,7 @@ static void tegra124_car_barrier(void)
  *
  * Assert the reset line of the DFLL's DVCO.  No return value.
  */
-void tegra124_clock_assert_dfll_dvco_reset(void)
+static void tegra124_clock_assert_dfll_dvco_reset(void)
 {
 	u32 v;

@@ -1463,7 +1463,7 @@ void tegra124_clock_assert_dfll_dvco_reset(void)
  * Deassert the reset line of the DFLL's DVCO, allowing the DVCO to
  * operate.  No return value.
  */
-void tegra124_clock_deassert_dfll_dvco_reset(void)
+static void tegra124_clock_deassert_dfll_dvco_reset(void)
 {
 	u32 v;

@@ -1473,7 +1473,7 @@ void tegra124_clock_deassert_dfll_dvco_reset(void)
 	tegra124_car_barrier();
 }
 
-int tegra124_reset_assert(unsigned long id)
+static int tegra124_reset_assert(unsigned long id)
 {
 	if (id == TEGRA124_RST_DFLL_DVCO)
 		tegra124_clock_assert_dfll_dvco_reset();

@@ -1483,7 +1483,7 @@ int tegra124_reset_assert(unsigned long id)
 	return 0;
 }
 
-int tegra124_reset_deassert(unsigned long id)
+static int tegra124_reset_deassert(unsigned long id)
 {
 	if (id == TEGRA124_RST_DFLL_DVCO)
 		tegra124_clock_deassert_dfll_dvco_reset();

Signature · 2 lines

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

Thierry Reding

author

2015-08-14 14:48 UTC #3 lore raw

[GIT PULL 2/9] pinctrl: tegra: Changes for v4.3-rc1

In reply to Thierry Reding

Hi Linus,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-pinctrl

for you to fetch changes up to 9462510ce31e2b91156bdcc33e4c737e6768e5f8:

pinctrl: tegra: Only set the gpio range if needed (2015-08-13 16:24:33 +0200)

As mentioned before I've created this branch with Tomeu's change and based the for-4.3/dt branch onto that. Feel free to pull this into your tree if necessary. It will also go in through the ARM SoC tree via the device tree updates that depend upon it.

Thierry

----------------------------------------------------------------
pinctrl: tegra: Changes for v4.3-rc1

Contains a single patch from Tomeu to avoid setting up a duplicate GPIO range.

----------------------------------------------------------------
Tomeu Vizoso (1):
pinctrl: tegra: Only set the gpio range if needed

 drivers/pinctrl/pinctrl-tegra.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

Thierry Reding

author

2015-08-14 14:48 UTC #4 lore raw

[GIT PULL 3/9] ARM: tegra: Cleanup patches for v4.3-rc1

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 5cf4af3bebb718b72a23b7e80fddfe8b4e8b0620:

ALSA: hda/tegra: Order clock and reset names consistently (2015-07-16 09:42:05 +0200)

Thanks,
Thierry

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

Just a couple of trivial cleanups to make the HDA controller driver code match the device tree binding.

----------------------------------------------------------------
Marcel Ziswiler (1):
ALSA: hda/tegra - Fix hda2codec_2x clock and reset names

Thierry Reding (1):
ALSA: hda/tegra: Order clock and reset names consistently

 Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Olof Johansson

Applied

2015-08-21 01:42 UTC #5 lore raw

[GIT PULL 3/9] ARM: tegra: Cleanup patches for v4.3-rc1

Quoted 6 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

Quoted 7 lines

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-cleanup
for you to fetch changes up to 5cf4af3bebb718b72a23b7e80fddfe8b4e8b0620:
ALSA: hda/tegra: Order clock and reset names consistently (2015-07-16 09:42:05 +0200)

Merged, thanks!

-Olof

Thierry Reding

author

2015-08-14 14:48 UTC #6 lore raw

[GIT PULL 4/9] ARM: tegra: Core SoC changes for v4.3-rc1

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 1ec0e115f8604940491861d207cc1e1478db97b3:

ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze() (2015-08-13 16:53:38 +0200)

Thanks,
Thierry

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

This contains a bit more of Tegra210 support, which is shaping up pretty nicely. Other than that there are a couple of cleanup patches here, too.

----------------------------------------------------------------
Masahiro Yamada (1):

      soc: tegra: Remove redundant $(CONFIG_ARCH_TEGRA) in Makefile

Thierry Reding (15):
soc/tegra: Add Tegra132 support
soc/tegra: Add Tegra210 support
soc/tegra: pmc: Avoid usage of uninitialized variable soc/tegra: pmc: Restrict legacy code to 32-bit ARM soc/tegra: pmc: Add Tegra210 support soc/tegra: fuse: Restrict legacy code to 32-bit ARM soc/tegra: fuse: Unify Tegra20 and Tegra30 drivers soc/tegra: fuse: Add Tegra210 support soc/tegra: fuse: Rename core_* to soc_* soc/tegra: fuse: Add spare bit offset for Tegra114 soc/tegra: fuse: Add spare bit offset for Tegra124 soc/tegra: fuse: Add spare bit offset for Tegra210 soc/tegra: pmc: Remove unnecessary return statement soc/tegra: pmc: Use existing pclk reference
ARM: tegra: Disable cpuidle if PSCI is available

Tomeu Vizoso (1):
ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze()

 arch/arm/mach-tegra/cpuidle-tegra114.c   |  19 ++-
 arch/arm/mach-tegra/iomap.h              |   3 -
 drivers/soc/tegra/Makefile               |   6 +-
 drivers/soc/tegra/common.c               |   2 +
 drivers/soc/tegra/fuse/Makefile          |   2 +
 drivers/soc/tegra/fuse/fuse-tegra.c      | 257 ++++++++++++++++++++++++-------
 drivers/soc/tegra/fuse/fuse-tegra20.c    | 175 ++++++++-------------
 drivers/soc/tegra/fuse/fuse-tegra30.c    | 232 ++++++++++------------------
 drivers/soc/tegra/fuse/fuse.h            |  95 ++++++++----
 drivers/soc/tegra/fuse/speedo-tegra114.c |  22 +--
 drivers/soc/tegra/fuse/speedo-tegra124.c |  26 ++--
 drivers/soc/tegra/fuse/speedo-tegra20.c  |  28 ++--
 drivers/soc/tegra/fuse/speedo-tegra210.c | 184 ++++++++++++++++++++++
 drivers/soc/tegra/fuse/speedo-tegra30.c  |  48 +++---
 drivers/soc/tegra/fuse/tegra-apbmisc.c   |  76 +++++++--
 drivers/soc/tegra/pmc.c                  | 125 +++++++++++----
 include/soc/tegra/fuse.h                 |   6 +-
 include/soc/tegra/pmc.h                  |   5 +
 18 files changed, 853 insertions(+), 458 deletions(-)
 create mode 100644 drivers/soc/tegra/fuse/speedo-tegra210.c

Olof Johansson

Applied

2015-08-21 01:45 UTC #7 lore raw

[GIT PULL 4/9] ARM: tegra: Core SoC changes for v4.3-rc1

Quoted 14 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-soc
for you to fetch changes up to 1ec0e115f8604940491861d207cc1e1478db97b3:
ARM: tegra: cpuidle: implement cpuidle_state.enter_freeze() (2015-08-13 16:53:38 +0200)

Quoted 8 lines

Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Core SoC changes for v4.3-rc1
This contains a bit more of Tegra210 support, which is shaping up pretty nicely. Other than that there are a couple of cleanup patches here, too.

Merged into next/drivers. Thanks.

-Olof

Thierry Reding

author

2015-08-14 14:48 UTC #8 lore raw

[GIT PULL 5/9] ARM: tegra: CPU frequency scaling for v4.3-rc1

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-cpufreq

for you to fetch changes up to 9eb15dbbfa1a23b5e65efaf1d5d6c47798e7264b:

cpufreq: Add cpufreq driver for Tegra124 (2015-07-16 09:34:09 +0200)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: CPU frequency scaling for v4.3-rc1

This adds CPU frequency scaling support for Tegra124.

----------------------------------------------------------------
Tuomas Tynkkynen (3):
cpufreq: tegra124: Add device tree bindings
cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq
cpufreq: Add cpufreq driver for Tegra124

 .../bindings/cpufreq/tegra124-cpufreq.txt          |  44 +++++
 drivers/cpufreq/Kconfig.arm                        |  13 +-
 drivers/cpufreq/Makefile                           |   3 +-
 drivers/cpufreq/tegra124-cpufreq.c                 | 214 +++++++++++++++++++++
 .../cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} |   0
 5 files changed, 270 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
 create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
 rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

Olof Johansson

Applied

2015-08-21 01:47 UTC #9 lore raw

[GIT PULL 5/9] ARM: tegra: CPU frequency scaling for v4.3-rc1

Quoted 14 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-cpufreq
for you to fetch changes up to 9eb15dbbfa1a23b5e65efaf1d5d6c47798e7264b:
cpufreq: Add cpufreq driver for Tegra124 (2015-07-16 09:34:09 +0200)

Quoted 7 lines

Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: CPU frequency scaling for v4.3-rc1
This adds CPU frequency scaling support for Tegra124.

Merged, thanks.

-Olof

Thierry Reding

author

2015-08-14 14:48 UTC #10 lore raw

[GIT PULL 6/9] iommu/tegra-smmu: Changes for v4.3-rc1

In reply to Thierry Reding

Hi Joerg,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-iommu

for you to fetch changes up to 11cec15bf3fb498206ef63b1fa26c27689e02d0e:

iommu/tegra-smmu: Parameterize number of TLB lines (2015-08-13 17:05:28 +0200)

This is the pull request with Russell's updates. I've added a patch on top to unbreak Tegra30, which had been broken since the original rewrite of the SMMU driver.

Thanks,
Thierry

----------------------------------------------------------------
iommu/tegra-smmu: Changes for v4.3-rc1

A bunch of improvements by Russell King, along with a fix to restore display support when using the SMMU. This was due to the SMMU driver writing the wrong value of active TLB lines, effectively disabling the TLB and causing massive underflows on the display controller because of the latency introduced by the SMMU.

----------------------------------------------------------------
Russell King (15):
iommu/tegra-smmu: Fix iova_to_phys() method iommu/tegra-smmu: Fix unmap() method
iommu/tegra-smmu: Factor out common PTE setting iommu/tegra-smmu: Add iova_pd_index() and iova_pt_index() helpers iommu/tegra-smmu: Fix page table lookup in unmap/iova_to_phys methods iommu/tegra-smmu: Store struct page pointer for page tables iommu/tegra-smmu: Use kcalloc() to allocate counter array iommu/tegra-smmu: Move flush_dcache to tegra-smmu.c iommu/tegra-smmu: Split smmu_flush_ptc() iommu/tegra-smmu: smmu_flush_ptc() wants device addresses iommu/tegra-smmu: Convert to use DMA API iommu/tegra-smmu: Remove PageReserved manipulation iommu/tegra-smmu: Use __GFP_ZERO to allocate zeroed pages iommu/tegra-smmu: Extract tegra_smmu_pte_get_use() iommu/tegra-smmu: Factor out tegra_smmu_set_pde()

Thierry Reding (1):
iommu/tegra-smmu: Parameterize number of TLB lines

 drivers/iommu/tegra-smmu.c      | 306 ++++++++++++++++++++++++++--------------
 drivers/memory/tegra/tegra114.c |  18 +--
 drivers/memory/tegra/tegra124.c |  31 +---
 drivers/memory/tegra/tegra30.c  |  18 +--
 include/soc/tegra/mc.h          |   8 +-
 5 files changed, 202 insertions(+), 179 deletions(-)

Joerg Roedel

2015-08-17 12:40 UTC #11 lore raw

[GIT PULL 6/9] iommu/tegra-smmu: Changes for v4.3-rc1

Quoted 9 lines · Thierry Reding

Hi Joerg,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-iommu

Pulled, thanks.

Thierry Reding

author

2015-08-14 14:48 UTC #12 lore raw

[GIT PULL 7/9] ARM: tegra: Memory controller updates for v4.3-rc1

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 588c43a7bd5a53ae523b318e1db16bdd59963a3c:

memory: tegra: Add Tegra210 support (2015-08-13 16:07:52 +0200)

Thanks,
Thierry

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

Adds support for Tegra210, which allows the SMMU to be used on this new SoC generation.

----------------------------------------------------------------
Paul Walmsley (1):
memory: tegra: Add support for a variable-size client ID bitfield

Thierry Reding (2):
memory: tegra: Expose supported rates via debugfs
memory: tegra: Add Tegra210 support

 drivers/iommu/Kconfig                    |    2 +-
 drivers/memory/tegra/Makefile            |    1 +
 drivers/memory/tegra/mc.c                |    8 +-
 drivers/memory/tegra/mc.h                |    4 +
 drivers/memory/tegra/tegra114.c          |    1 +
 drivers/memory/tegra/tegra124-emc.c      |   42 +-
 drivers/memory/tegra/tegra124.c          |    2 +
 drivers/memory/tegra/tegra210.c          | 1080 ++++++++++++++++++++++++++++++
 drivers/memory/tegra/tegra30.c           |    1 +
 include/dt-bindings/memory/tegra210-mc.h |   36 +
 include/soc/tegra/mc.h                   |    2 +
 11 files changed, 1174 insertions(+), 5 deletions(-)
 create mode 100644 drivers/memory/tegra/tegra210.c
 create mode 100644 include/dt-bindings/memory/tegra210-mc.h

Olof Johansson

Applied

2015-08-21 01:57 UTC #13 lore raw

[GIT PULL 7/9] ARM: tegra: Memory controller updates for v4.3-rc1

Quoted 14 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-memory
for you to fetch changes up to 588c43a7bd5a53ae523b318e1db16bdd59963a3c:
memory: tegra: Add Tegra210 support (2015-08-13 16:07:52 +0200)

Quoted 8 lines

Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Memory controller updates for v4.3-rc1
Adds support for Tegra210, which allows the SMMU to be used on this new SoC generation.

Merged, thanks.

-Olof

Thierry Reding

author

2015-08-14 14:48 UTC #14 lore raw

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

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 6909c6632fdbea441b5077b4f882c0bf4b71997e:

ARM: tegra: Add gpio-ranges property (2015-08-13 16:31:53 +0200)

Thanks,
Thierry

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

Enables CPU frequency scaling on Jetson TK1 and enables the GK20A GPU on Venice2 and Jetson TK1. This also enables support for the PMU hardware found on Tegra124, which among other things, can be used for performance measurements.

----------------------------------------------------------------
Alexandre Courbot (2):
ARM: tegra: Add IOMMU node to GK20A
ARM: tegra: jetson-tk1: Add GK20A GPU DT node

Kyle Huey (1):
ARM: tegra: Add Tegra124 PMU support

Mikko Perttunen (1):
ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

Nicolas Chauvet (1):
ARM: tegra: Fix AHB base address on Tegra20, Tegra30 and Tegra114

Thierry Reding (2):
Merge branch 'for-4.3/pinctrl' into for-4.3/dt
ARM: tegra: venice2: Add GK20A GPU DT node

Tomeu Vizoso (2):
pinctrl: tegra: Only set the gpio range if needed
ARM: tegra: Add gpio-ranges property

Tuomas Tynkkynen (3):
ARM: tegra: Add the DFLL to Tegra124 device tree
ARM: tegra: Enable the DFLL on the Jetson TK1
ARM: tegra: Add entries for cpufreq on Tegra124

 arch/arm/boot/dts/tegra114.dtsi           |  5 ++--
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 25 ++++++++++++++--
 arch/arm/boot/dts/tegra124-venice2.dts    | 10 ++++++-
 arch/arm/boot/dts/tegra124.dtsi           | 50 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/tegra20.dtsi            |  5 ++--
 arch/arm/boot/dts/tegra30.dtsi            |  5 ++--
 drivers/pinctrl/pinctrl-tegra.c           | 19 +++++++++++-
 7 files changed, 109 insertions(+), 10 deletions(-)

Olof Johansson

Applied

2015-08-21 01:58 UTC #15 lore raw

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

Quoted 17 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-dt
for you to fetch changes up to 6909c6632fdbea441b5077b4f882c0bf4b71997e:
ARM: tegra: Add gpio-ranges property (2015-08-13 16:31:53 +0200)
Thanks,
Thierry

Quoted 7 lines

----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.3-rc1
Enables CPU frequency scaling on Jetson TK1 and enables the GK20A GPU on Venice2 and Jetson TK1. This also enables support for the PMU hardware found on Tegra124, which among other things, can be used for performance measurements.

Merged, thanks.

-Olof

Olof Johansson

2015-08-21 16:09 UTC #16 lore raw

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

Quoted 21 lines · Olof Johansson

Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-dt
for you to fetch changes up to 6909c6632fdbea441b5077b4f882c0bf4b71997e:
ARM: tegra: Add gpio-ranges property (2015-08-13 16:31:53 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.3-rc1

Quoted 6 lines

Quoted 4 lines
Enables CPU frequency scaling on Jetson TK1 and enables the GK20A GPU on Venice2 and Jetson TK1. This also enables support for the PMU hardware found on Tegra124, which among other things, can be used for performance measurements.
Merged, thanks.

This caused build failures due to missing tegra124-car.h:

http://arm-soc.lixom.net/buildlogs/arm-soc/v4.2-rc2-954-g5825349/buildall.arm.tegra_defconfig.log.failed

I've dropped this branch again.

-Olof

Jon Hunter

maintainer

2015-08-21 16:27 UTC #17 lore raw

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

Quoted 22 lines · Olof Johansson

Quoted 21 lines · Olof Johansson
Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-dt
for you to fetch changes up to 6909c6632fdbea441b5077b4f882c0bf4b71997e:
ARM: tegra: Add gpio-ranges property (2015-08-13 16:31:53 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.3-rc1

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Enables CPU frequency scaling on Jetson TK1 and enables the GK20A GPU on Venice2 and Jetson TK1. This also enables support for the PMU hardware found on Tegra124, which among other things, can be used for performance measurements.
Merged, thanks.
This caused build failures due to missing tegra124-car.h:

Should be included by Paul's patch, "clk: tegra: Add DFLL DVCO reset control for Tegra124", which is part of the clk series pull request [0].

Quoted 3 lines

http://arm-soc.lixom.net/buildlogs/arm-soc/v4.2-rc2-954-g5825349/buildall.arm.tegra_defconfig.log.failed
I've dropped this branch again.

It is building ok on linux-next today.

Cheers
Jon

[0] http://www.spinics.net/lists/arm-kernel/msg439463.html

Olof Johansson

2015-08-21 16:33 UTC #18 lore raw

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

Quoted 33 lines · Jon Hunter

Quoted 22 lines · Olof Johansson
Quoted 21 lines · Olof Johansson
Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-dt
for you to fetch changes up to 6909c6632fdbea441b5077b4f882c0bf4b71997e:
ARM: tegra: Add gpio-ranges property (2015-08-13 16:31:53 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Devicetree changes for v4.3-rc1
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Enables CPU frequency scaling on Jetson TK1 and enables the GK20A GPU on Venice2 and Jetson TK1. This also enables support for the PMU hardware found on Tegra124, which among other things, can be used for performance measurements.
Merged, thanks.
This caused build failures due to missing tegra124-car.h:

Quoted 8 lines

Should be included by Paul's patch, "clk: tegra: Add DFLL DVCO reset control for Tegra124", which is part of the clk series pull request [0].
Quoted 3 lines
http://arm-soc.lixom.net/buildlogs/arm-soc/v4.2-rc2-954-g5825349/buildall.arm.tegra_defconfig.log.failed
I've dropped this branch again.
It is building ok on linux-next today.

Yeah, it builds when the dependent changes from the clk tree are included, but this breaks bisectability potentially for quite a bit of code, and requires that we merge after the clk branch goes in or mainline will be busted.

As mentioned just now on IRC too, it might make most sense to rebase on top of the clk branch to avoid this breakage. Either that or drop the patch in question for 4.3.

-Olof

Thierry Reding

author

2015-08-21 16:52 UTC #19 lore raw

[GIT PULL 8/9] ARM: tegra: Devicetree changes for v4.3-rc1 (updated)

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 17cdddf0fb684f5456c1af3aa2c10aca3b68b8de:

ARM: tegra: Add gpio-ranges property (2015-08-21 18:44:28 +0200)

This updated version of the pull request includes the for-4.3/clk branch which is a build-time dependency for for-4.3/dt.

Thanks,
Thierry

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

----------------------------------------------------------------
Alexandre Courbot (2):
ARM: tegra: Add IOMMU node to GK20A
ARM: tegra: jetson-tk1: Add GK20A GPU DT node

Kyle Huey (1):
ARM: tegra: Add Tegra124 PMU support

Mikko Perttunen (2):
clk: tegra: Introduce ability for SoC-specific reset control callbacks
ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

Nicolas Chauvet (1):
ARM: tegra: Fix AHB base address on Tegra20, Tegra30 and Tegra114

Paul Walmsley (1):
clk: tegra: Add DFLL DVCO reset control for Tegra124

Thierry Reding (3):

      Merge branch 'for-4.3/pinctrl' into for-4.3/dt
      Merge branch 'for-4.3/clk' into for-4.3/dt
      ARM: tegra: venice2: Add GK20A GPU DT node

Tomeu Vizoso (2):
pinctrl: tegra: Only set the gpio range if needed
ARM: tegra: Add gpio-ranges property

Tuomas Tynkkynen (10):
clk: tegra: Add binding for the Tegra124 DFLL clocksource
clk: tegra: Add library for the DFLL clock source (open-loop mode)
clk: tegra: Add closed loop support for the DFLL
clk: tegra: Add functions for parsing CVB tables
clk: tegra: Add Tegra124 DFLL clocksource platform driver
clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend
clk: tegra: Add the DFLL as a possible parent of the cclk_g clock
ARM: tegra: Add the DFLL to Tegra124 device tree
ARM: tegra: Enable the DFLL on the Jetson TK1
ARM: tegra: Add entries for cpufreq on Tegra124

 .../bindings/clock/nvidia,tegra124-dfll.txt        |   79 +
 arch/arm/boot/dts/tegra114.dtsi                    |    5 +-
 arch/arm/boot/dts/tegra124-jetson-tk1.dts          |   25 +-
 arch/arm/boot/dts/tegra124-venice2.dts             |   10 +-
 arch/arm/boot/dts/tegra124.dtsi                    |   50 +
 arch/arm/boot/dts/tegra20.dtsi                     |    5 +-
 arch/arm/boot/dts/tegra30.dtsi                     |    5 +-
 arch/arm/mach-tegra/Kconfig                        |    1 +
 drivers/clk/tegra/Makefile                         |    3 +
 drivers/clk/tegra/clk-dfll.c                       | 1755 ++++++++++++++++++++
 drivers/clk/tegra/clk-dfll.h                       |   54 +
 drivers/clk/tegra/clk-tegra-super-gen4.c           |    4 +-
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c         |  166 ++
 drivers/clk/tegra/clk-tegra124.c                   |   82 +
 drivers/clk/tegra/clk.c                            |   39 +-
 drivers/clk/tegra/clk.h                            |    3 +
 drivers/clk/tegra/cvb.c                            |  140 ++
 drivers/clk/tegra/cvb.h                            |   67 +
 drivers/pinctrl/pinctrl-tegra.c                    |   19 +-
 include/dt-bindings/reset/tegra124-car.h           |   12 +
 20 files changed, 2505 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h
 create mode 100644 include/dt-bindings/reset/tegra124-car.h

Olof Johansson

Applied

2015-08-21 17:16 UTC #20 lore raw

[GIT PULL 8/9] ARM: tegra: Devicetree changes for v4.3-rc1 (updated)

Quoted 8 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:

Quoted 8 lines

git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-dt
for you to fetch changes up to 17cdddf0fb684f5456c1af3aa2c10aca3b68b8de:
ARM: tegra: Add gpio-ranges property (2015-08-21 18:44:28 +0200)
This updated version of the pull request includes the for-4.3/clk branch which is a build-time dependency for for-4.3/dt.

Merged, thanks.

-Olof

Thierry Reding

author

2015-08-14 14:48 UTC #21 lore raw

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

In reply to Thierry Reding

Hi ARM SoC maintainers,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:

ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)

Thanks,
Thierry

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

Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.

----------------------------------------------------------------
Thierry Reding (1):
ARM: tegra: Update multi_v7_defconfig

Tuomas Tynkkynen (1):
ARM: tegra: Update default configuration

 arch/arm/configs/multi_v7_defconfig | 9 +++++++++
 arch/arm/configs/tegra_defconfig    | 9 ++-------
 2 files changed, 11 insertions(+), 7 deletions(-)

Tyler Baker

2015-08-18 22:30 UTC #22 lore raw

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

Hi Theirry,

Quoted 20 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1

Quoted 6 lines

Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.
----------------------------------------------------------------
Thierry Reding (1):
ARM: tegra: Update multi_v7_defconfig

The kernelci.org bot recently reported jetson-tk1 boot failures[1][2] in next-20150818, only when booting the mult_v7_defconfig kernels. I bisected[3] these boot failure down to this commit, it didn't cleanly revert, so I manually removed that options this patch added, and my jetson-tk1 booted again. Digging a bit further, if I apply the patch below to next-20150818, my jetson-tk1 boots.

(quoted diff) +0 -0

b/arch/arm/configs/multi_v7_defconfig
index b2facab..a285afe 100644

arch/arm/configs/multi_v7_defconfig +0 -1

@@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=m
 CONFIG_SND=m
 CONFIG_SND_DYNAMIC_MINORS=y
-CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m

This isn't where the story ends unfortunately. The collabora lab also has a jetson-tk1, booted in the same manner, which boots next-20150818 fine[4]. The only differences I can spot in the two boot logs is that the collabora board is using an older version of u-boot, where as my board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad). I've also noticed some angry udev messages after the modules probe in userspace present in both boot logs that look suspicious.

[   70.469914] udevd[108]: worker [113] /devices/soc0/70030000.hda is
taking a long time
[   70.479849] udevd[108]: worker [115] /devices/soc0/70300000.ahub is
taking a long time
[   70.490769] udevd[108]: worker [117] /devices/soc0/sound is taking

a long time

FWIW, When I went searching for this patch, I couldn't find it on any of the mailing lists. The only reference to this patch was from this pull request, thus why I'm reporting the issue here. :)

Anyways, let me know if you can reproduce this issue, and/or can think of a reason this might may be causing trouble.

Cheers,

Tyler

[1] http://kernelci.org/boot/all/job/next/kernel/next-20150818/
[2] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-tbaker/boot-tegra124-jetson-tk1.html
[3] http://hastebin.com/bixofozaji.vhdl
[4] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-collabora/boot-tegra124-jetson-tk1.html

Thierry Reding

author

2015-08-19 09:14 UTC #23 lore raw

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

Quoted 30 lines · Tyler Baker

Hi Theirry,
Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1
Quoted 6 lines
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.
----------------------------------------------------------------
Thierry Reding (1):
ARM: tegra: Update multi_v7_defconfig

Quoted 6 lines

The kernelci.org bot recently reported jetson-tk1 boot failures[1][2] in next-20150818, only when booting the mult_v7_defconfig kernels. I bisected[3] these boot failure down to this commit, it didn't cleanly revert, so I manually removed that options this patch added, and my jetson-tk1 booted again. Digging a bit further, if I apply the patch below to next-20150818, my jetson-tk1 boots.

I'm not able to reproduce this here. Building next-20150818 with multi_v7_config and booting the resulting kernel works just fine.

arch/arm/configs/multi_v7_defconfig CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y · line 473

Quoted 13 lines

arch/arm/configs/multi_v7_defconfig +0 -1

index b2facab..a285afe 100644
@@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=m
 CONFIG_SND=m
 CONFIG_SND_DYNAMIC_MINORS=y
-CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m

lsmod output confirms that snd-hda-tegra.ko was loaded:

	# lsmod
	Module                  Size  Used by
	snd_soc_tegra30_i2s     5591  2 
	snd_soc_tegra_pcm       1184  1 snd_soc_tegra30_i2s
	snd_hda_tegra           4771  0 
	snd_soc_rt5640         56972  1 
	snd_soc_tegra_rt5640     3960  0 
	snd_hda_codec          76398  1 snd_hda_tegra
	snd_soc_rl6231          1897  1 snd_soc_rt5640
	snd_soc_tegra_utils     2825  1 snd_soc_tegra_rt5640
	snd_hda_core           26151  2 snd_hda_codec,snd_hda_tegra
	snd_soc_core          119213  4 snd_soc_tegra_pcm,snd_soc_rt5640,snd_soc_tegra_rt5640,snd_soc_tegra30_i2s
	snd_compress            7114  1 snd_soc_core
	snd_pcm_dmaengine       2943  1 snd_soc_core
	snd_pcm                67835  6 snd_soc_rt5640,snd_soc_core,snd_hda_codec,snd_hda_tegra,snd_pcm_dmaengine,snd_hda_core
	snd_timer              16881  1 snd_pcm
	snd                    41480  6 snd_soc_core,snd_timer,snd_pcm,snd_hda_codec,snd_hda_tegra,snd_compress
	soundcore                858  1 snd
	snd_soc_tegra30_ahub     8747  1 snd_soc_tegra30_i2s
	nouveau              1217903  0 
	tegra_devfreq           5389  0 
	ttm                    65073  1 nouveau

Quoted 6 lines

This isn't where the story ends unfortunately. The collabora lab also has a jetson-tk1, booted in the same manner, which boots next-20150818 fine[4]. The only differences I can spot in the two boot logs is that the collabora board is using an older version of u-boot, where as my board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).

I don't have either of those commits in any of the U-Boot trees I have. Perhaps whatever tree this comes from has local patches that cause the breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just to make sure I tried running latest origin/master, which identifies thusly:

	U-Boot 2015.10-rc2-00040-g0f9258228e2b

And that boots next-20150818 fine.

If you can point me at the source for the version that you use I may be able to find something that could cause this.

Quoted 10 lines

I've also noticed some
angry udev messages after the modules probe in userspace present in both boot logs that look suspicious.
[   70.469914] udevd[108]: worker [113] /devices/soc0/70030000.hda is
taking a long time
[   70.479849] udevd[108]: worker [115] /devices/soc0/70300000.ahub is
taking a long time
[   70.490769] udevd[108]: worker [117] /devices/soc0/sound is taking
a long time

These look suspicious indeed. Unfortunately I don't see those in the boot log on my setup either. Then again, you seem to be using Eudev 2.1.1, whereas I use the one shipped with systemd 219, so this could also be some sort of weird userspace issue.

Quoted 1 line

From the logs it further seems like you've configured the root to be

on NFS, but the logs never show NFS to be mounted. Perhaps that's because you're booting into a ramdisk rather than a full root file- system.

Quoted 3 lines

FWIW, When I went searching for this patch, I couldn't find it on any of the mailing lists. The only reference to this patch was from this pull request, thus why I'm reporting the issue here. :)

That's because it's merely sync'ing up the multi_v7_defconfig changes with tegra_defconfig that I forgot to submit for v4.2. I didn't think it necessary to send out a separate patch for that.

Quoted 2 lines

Anyways, let me know if you can reproduce this issue, and/or can think of a reason this might may be causing trouble.

Like I said, if you can point me at the U-Boot sources I can take a look if anything jumps out. I've also noticed that the initial ramdisks in both boot logs that you linked to have a slightly different size. But they use the same Eudev version, so I suspect that that's unrelated.

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

Sjoerd Simons

2015-08-19 09:48 UTC #24 lore raw

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

Quoted 4 lines · Thierry Reding

Quoted 3 lines · Tyler Baker
Hi Theirry,

Quoted 10 lines

Quoted 10 lines
This isn't where the story ends unfortunately. The collabora lab also
has a jetson-tk1, booted in the same manner, which boots next -20150818
fine[4]. The only differences I can spot in the two boot logs is that
the collabora board is using an older version of u-boot, where as my
board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).

Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot.

Fwiw:

$ git show 2015.01-00231-gab77f24
commit ab77f24119e80257de4ab017b877f92f96980562
Merge: d928664 fa58b10
Author: Tom Rini <[email protected]>
Date:   Thu Jan 15 14:05:31 2015 -0500

Merge branch 'master' of git://git.denx.de/u-boot-ti

Which is definately a commit you should hae in your upstream u-boot tree.

Quoted 10 lines

I don't have either of those commits in any of the U-Boot trees I have.
Perhaps whatever tree this comes from has local patches that cause the
breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just
to make sure I tried running latest origin/master, which identifies thusly:

Quoted 3 lines

	U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.

Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...

Signature · 2 lines

Sjoerd Simons <[email protected]>
Collabora Ltd.

Thierry Reding

author

2015-08-19 10:33 UTC #25 lore raw

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

Quoted 27 lines · Sjoerd Simons

Quoted 4 lines · Thierry Reding
Quoted 3 lines · Tyler Baker
Hi Theirry,
Quoted 10 lines
Quoted 10 lines
This isn't where the story ends unfortunately. The collabora lab also
has a jetson-tk1, booted in the same manner, which boots next -20150818
fine[4]. The only differences I can spot in the two boot logs is that
the collabora board is using an older version of u-boot, where as my
board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).
Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot.
Fwiw:
$ git show 2015.01-00231-gab77f24
commit ab77f24119e80257de4ab017b877f92f96980562
Merge: d928664 fa58b10
Author: Tom Rini <[email protected]>
Date:   Thu Jan 15 14:05:31 2015 -0500

Quoted 4 lines

Merge branch 'master' of git://git.denx.de/u-boot-ti
Which is definately a commit you should hae in your upstream u-boot tree.

Yeah, I suck. I was running:

	$ git show gab77f24

I didn't know git could parse the full output from git describe.

Quoted 10 lines

Quoted 10 lines
I don't have either of those commits in any of the U-Boot trees I have.
Perhaps whatever tree this comes from has local patches that cause the
breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just
to make sure I tried running latest origin/master, which identifies thusly:

Quoted 6 lines

Quoted 3 lines
	U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.
Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...

I've tried reconstructing the version that Tyler is running by checking out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix port information parsing") on top, but that also leaves me with a bootable system, so no way of reproducing. I agree that upgrading to a more recent U-Boot version sounds like the best way forward because it has already proven to work on at least two setups.

Tyler Baker

2015-08-19 16:48 UTC #26 lore raw

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

Quoted 56 lines · Thierry Reding

Quoted 27 lines · Sjoerd Simons
Quoted 4 lines · Thierry Reding
Quoted 3 lines · Tyler Baker
Hi Theirry,
Quoted 10 lines
Quoted 10 lines
This isn't where the story ends unfortunately. The collabora lab also
has a jetson-tk1, booted in the same manner, which boots next -20150818
fine[4]. The only differences I can spot in the two boot logs is that
the collabora board is using an older version of u-boot, where as my
board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).
Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot.
Fwiw:
$ git show 2015.01-00231-gab77f24
commit ab77f24119e80257de4ab017b877f92f96980562
Merge: d928664 fa58b10
Author: Tom Rini <[email protected]>
Date:   Thu Jan 15 14:05:31 2015 -0500
Quoted 4 lines
Merge branch 'master' of git://git.denx.de/u-boot-ti
Which is definately a commit you should hae in your upstream u-boot tree.
Yeah, I suck. I was running:
        $ git show gab77f24
I didn't know git could parse the full output from git describe.
Quoted 10 lines
Quoted 10 lines
I don't have either of those commits in any of the U-Boot trees I have.
Perhaps whatever tree this comes from has local patches that cause the
breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just
to make sure I tried running latest origin/master, which identifies thusly:
Quoted 6 lines
Quoted 3 lines
    U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.
Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...

Quoted 6 lines

I've tried reconstructing the version that Tyler is running by checking out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix port information parsing") on top, but that also leaves me with a bootable system, so no way of reproducing. I agree that upgrading to a more recent U-Boot version sounds like the best way forward because it has already proven to work on at least two setups.

Thanks for looking into this issue guys. I'll upgrade u-boot when I return from Plumbers this week and report back.

Cheers,

Tyler

Tyler Baker

2015-09-03 23:08 UTC #27 lore raw

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

In reply to Thierry Reding

Hi Thierry,

Quoted 56 lines · Thierry Reding

Quoted 27 lines · Sjoerd Simons
Quoted 4 lines · Thierry Reding
Quoted 3 lines · Tyler Baker
Hi Theirry,
Quoted 10 lines
Quoted 10 lines
This isn't where the story ends unfortunately. The collabora lab also
has a jetson-tk1, booted in the same manner, which boots next -20150818
fine[4]. The only differences I can spot in the two boot logs is that
the collabora board is using an older version of u-boot, where as my
board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).
Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot.
Fwiw:
$ git show 2015.01-00231-gab77f24
commit ab77f24119e80257de4ab017b877f92f96980562
Merge: d928664 fa58b10
Author: Tom Rini <[email protected]>
Date:   Thu Jan 15 14:05:31 2015 -0500
Quoted 4 lines
Merge branch 'master' of git://git.denx.de/u-boot-ti
Which is definately a commit you should hae in your upstream u-boot tree.
Yeah, I suck. I was running:
        $ git show gab77f24
I didn't know git could parse the full output from git describe.
Quoted 10 lines
Quoted 10 lines
I don't have either of those commits in any of the U-Boot trees I have.
Perhaps whatever tree this comes from has local patches that cause the
breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just
to make sure I tried running latest origin/master, which identifies thusly:
Quoted 6 lines
Quoted 3 lines
    U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.
Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...

Quoted 6 lines

I've tried reconstructing the version that Tyler is running by checking out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix port information parsing") on top, but that also leaves me with a bootable system, so no way of reproducing. I agree that upgrading to a more recent U-Boot version sounds like the best way forward because it has already proven to work on at least two setups.

Sorry for the delay. I've upgraded u-boot to U-Boot 2015.10-rc2-00439-g03d8714 using the tegra u-boot flashing scripts. FWIW, I did have to revert 620776d734e4 ("tftp: adjust settings to be suitable for 100Mbit ethernet") to get TFTP working again.

Anyways, it hangs at the exact same spot[1] with the newer version of u-boot. If remove the modules from the initrd or just disable CONFIG_SND_HDA_TEGRA it boots fine. This weekend I'll try to debug this module manually and see if I draw any conclusions.

Cheers,

Tyler

[1] http://lava.kernelci.org/scheduler/job/180894/log_file

Kevin Hilman

2015-09-10 21:29 UTC #28 lore raw

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

Quoted 71 lines · Tyler Baker

Hi Thierry,
Quoted 56 lines · Thierry Reding
Quoted 27 lines · Sjoerd Simons
Quoted 4 lines · Thierry Reding
Quoted 3 lines · Tyler Baker
Hi Theirry,
Quoted 10 lines
Quoted 10 lines
This isn't where the story ends unfortunately. The collabora lab also
has a jetson-tk1, booted in the same manner, which boots next -20150818
fine[4]. The only differences I can spot in the two boot logs is that
the collabora board is using an older version of u-boot, where as my
board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).
Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot.
Fwiw:
$ git show 2015.01-00231-gab77f24
commit ab77f24119e80257de4ab017b877f92f96980562
Merge: d928664 fa58b10
Author: Tom Rini <[email protected]>
Date:   Thu Jan 15 14:05:31 2015 -0500
Quoted 4 lines
Merge branch 'master' of git://git.denx.de/u-boot-ti
Which is definately a commit you should hae in your upstream u-boot tree.
Yeah, I suck. I was running:
        $ git show gab77f24
I didn't know git could parse the full output from git describe.
Quoted 10 lines
Quoted 10 lines
I don't have either of those commits in any of the U-Boot trees I have.
Perhaps whatever tree this comes from has local patches that cause the
breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just
to make sure I tried running latest origin/master, which identifies thusly:
Quoted 6 lines
Quoted 3 lines
    U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.
Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...
Quoted 6 lines
I've tried reconstructing the version that Tyler is running by checking out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix port information parsing") on top, but that also leaves me with a bootable system, so no way of reproducing. I agree that upgrading to a more recent U-Boot version sounds like the best way forward because it has already proven to work on at least two setups.
Sorry for the delay. I've upgraded u-boot to U-Boot 2015.10-rc2-00439-g03d8714 using the tegra u-boot flashing scripts. FWIW, I did have to revert 620776d734e4 ("tftp: adjust settings to be suitable for 100Mbit ethernet") to get TFTP working again.

Quoted 4 lines

Anyways, it hangs at the exact same spot[1] with the newer version of u-boot. If remove the modules from the initrd or just disable CONFIG_SND_HDA_TEGRA it boots fine. This weekend I'll try to debug this module manually and see if I draw any conclusions.

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.

Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

Kevin

[1] http://kernelci.org/boot/tegra124-jetson-tk1/?multi_v7_defconfig
[2]

(quoted diff) +0 -0

b/arch/arm/configs/multi_v7_defconfig
index b2facab..a285afe 100644

arch/arm/configs/multi_v7_defconfig +0 -1

@@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=m
 CONFIG_SND=m
 CONFIG_SND_DYNAMIC_MINORS=y
-CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m

Jon Hunter

maintainer

2015-09-11 10:39 UTC #29 lore raw

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

Hi Kevin,

On 10/09/15 22:29, Kevin Hilman wrote:

[snip]

Quoted 7 lines

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

So curiosity got the better of this cat, as to why we are not seeing this ;-)

The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).

So trying a quick modprobe of the hda-tegra driver I do see it hang ...

/ # modprobe snd-hda-tegra

[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)

Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...

/ # modprobe snd-hda-tegra

[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0

[hangs here]

However, if I do the following, this works ...

/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra

So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.

Thierry, any thoughts?

Jon

Jon Hunter

maintainer

2015-09-11 11:04 UTC #30 lore raw

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

Quoted 56 lines · Jon Hunter

Hi Kevin,

On 10/09/15 22:29, Kevin Hilman wrote:

[snip]

Quoted 7 lines

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

So curiosity got the better of this cat, as to why we are not seeing this ;-)

The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).

So trying a quick modprobe of the hda-tegra driver I do see it hang ...

/ # modprobe snd-hda-tegra

[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)

Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...

/ # modprobe snd-hda-tegra

Quoted 9 lines

[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0

Ftrace shows a similar thing ...

/ # cat /debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 8/8 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched

#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
        modprobe-110   [000] ....    46.095279: module_load: soundcore 
        modprobe-110   [000] .n..    46.096443: module_load: snd 
        modprobe-110   [000] .n..    46.097719: module_load: snd_timer 
        modprobe-110   [000] ....    46.099242: module_load: snd_pcm 
        modprobe-110   [000] ....    46.100231: module_load: snd_hda_core 
        modprobe-110   [000] ....    46.102418: module_load: snd_hda_codec 
        modprobe-110   [000] ....    46.102915: module_load: snd_hda_tegra 
        modprobe-122   [000] ....    46.341224: module_load: snd_hda_codec_hdmi

However, would imply that snd-hda-codec-hdmi is loaded ok and the hang occurs afterwards as the trace message is printed once the module has been loaded.

Jon

Thierry Reding

author

2015-09-11 12:38 UTC #31 lore raw

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

In reply to Jon Hunter

Quoted 68 lines · Jon Hunter

Hi Kevin,

On 10/09/15 22:29, Kevin Hilman wrote:

[snip]

Quoted 7 lines

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

So curiosity got the better of this cat, as to why we are not seeing this ;-)

The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).

So trying a quick modprobe of the hda-tegra driver I do see it hang ...

/ # modprobe snd-hda-tegra

[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)

Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...

/ # modprobe snd-hda-tegra

[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0

[hangs here]

Quoted 8 lines

However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?

I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.

What I do see is that after a little while network stops working. I noticed primarily because I boot with an NFS root, so the kernel started complaining about the NFS server not responding. Being on an NFS root could be one reason why this works for me, not sure what the kernelci labs are running. I don't see the network issues with tegra_defconfig. I've also tried a tegra_defconfig with all of sound support built as modules and that all works perfectly.

I'll investigate the multi_v7_defconfig network issues, perhaps that'll give me some clues, or perhaps even allow me to reproduce the original issue.

Jon Hunter

maintainer

2015-09-11 13:10 UTC #32 lore raw

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

Quoted 76 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 73 lines · Jon Hunter

Hi Kevin,

On 10/09/15 22:29, Kevin Hilman wrote:

[snip]

Quoted 7 lines

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

So curiosity got the better of this cat, as to why we are not seeing this ;-)

The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).

So trying a quick modprobe of the hda-tegra driver I do see it hang ...

/ # modprobe snd-hda-tegra

[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)

Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...

/ # modprobe snd-hda-tegra

[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0

[hangs here]

However, if I do the following, this works ...

/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra

Quoted 7 lines

Quoted 3 lines
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.

Did you try "modprobe snd-hda-tegra"? Fails for me 100% of the time.

Quoted 11 lines

What I do see is that after a little while network stops working. I noticed primarily because I boot with an NFS root, so the kernel started complaining about the NFS server not responding. Being on an NFS root could be one reason why this works for me, not sure what the kernelci labs are running. I don't see the network issues with tegra_defconfig. I've also tried a tegra_defconfig with all of sound support built as modules and that all works perfectly.
I'll investigate the multi_v7_defconfig network issues, perhaps that'll give me some clues, or perhaps even allow me to reproduce the original issue.

Well I am not using any networking and booting with a simple ramdisk so I don't think that is the right place to look.

Cheers
Jon

Thierry Reding

author

2015-09-11 13:25 UTC #33 lore raw

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

Quoted 80 lines · Jon Hunter

Quoted 78 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 75 lines · Jon Hunter
Hi Kevin,
On 10/09/15 22:29, Kevin Hilman wrote:
[snip]
Quoted 7 lines
Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.
So curiosity got the better of this cat, as to why we are not seeing this ;-)
The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).
So trying a quick modprobe of the hda-tegra driver I do see it hang ...
/ # modprobe snd-hda-tegra
[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)
Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...
/ # modprobe snd-hda-tegra
[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0
[hangs here]
However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.
Did you try "modprobe snd-hda-tegra"? Fails for me 100% of the time.

Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2

Quoted 8 lines

Quoted 8 lines
What I do see is that after a little while network stops working. I noticed primarily because I boot with an NFS root, so the kernel started complaining about the NFS server not responding. Being on an NFS root could be one reason why this works for me, not sure what the kernelci labs are running. I don't see the network issues with tegra_defconfig. I've also tried a tegra_defconfig with all of sound support built as modules and that all works perfectly.

Quoted 6 lines

Quoted 3 lines
I'll investigate the multi_v7_defconfig network issues, perhaps that'll give me some clues, or perhaps even allow me to reproduce the original issue.
Well I am not using any networking and booting with a simple ramdisk so I don't think that is the right place to look.

Looks like this might have been a transient issue with my networking setup. I can no longer reproduce the NFS hangs.

What sort of ramdisk do you use? Can you share the instructions you use to create it? Perhaps I can reproduce that way.

Jon Hunter

maintainer

2015-09-11 13:43 UTC #34 lore raw

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

Quoted 106 lines · Thierry Reding

* PGP Signed by an unknown key
Quoted 80 lines · Jon Hunter
Quoted 78 lines · Thierry Reding
Quoted 1 line
Old Signed by an unknown key
Quoted 75 lines · Jon Hunter
Hi Kevin,
On 10/09/15 22:29, Kevin Hilman wrote:
[snip]
Quoted 7 lines
Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.
So curiosity got the better of this cat, as to why we are not seeing this ;-)
The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).
So trying a quick modprobe of the hda-tegra driver I do see it hang ...
/ # modprobe snd-hda-tegra
[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)
Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...
/ # modprobe snd-hda-tegra
[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0
[hangs here]
However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.
Did you try "modprobe snd-hda-tegra"? Fails for me 100% of the time.
Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2
Quoted 12 lines
Quoted 11 lines
What I do see is that after a little while network stops working. I noticed primarily because I boot with an NFS root, so the kernel started complaining about the NFS server not responding. Being on an NFS root could be one reason why this works for me, not sure what the kernelci labs are running. I don't see the network issues with tegra_defconfig. I've also tried a tegra_defconfig with all of sound support built as modules and that all works perfectly.
I'll investigate the multi_v7_defconfig network issues, perhaps that'll give me some clues, or perhaps even allow me to reproduce the original issue.

Quoted 8 lines

Quoted 2 lines
Well I am not using any networking and booting with a simple ramdisk so I don't think that is the right place to look.
Looks like this might have been a transient issue with my networking setup. I can no longer reproduce the NFS hangs.
What sort of ramdisk do you use? Can you share the instructions you use to create it? Perhaps I can reproduce that way.

It is just a simple busybox based file-system. I can share it with you.

Cheers
Jon

Jon Hunter

maintainer

2015-09-11 15:51 UTC #35 lore raw

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

In reply to Thierry Reding

On 11/09/15 14:25, Thierry Reding wrote:

[snip]

Quoted 2 lines

Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2

Unfortunately, I am not sure it is whatever is in Paul's automation rig [0]. However, I have also reproduced this on a tegra124 nyan-big in the office.

Cheers
Jon

[0] http://nvtb.github.io/linux-next/

Thierry Reding

author

2015-09-11 15:59 UTC #36 lore raw

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

Quoted 11 lines · Jon Hunter

On 11/09/15 14:25, Thierry Reding wrote:
[snip]
Quoted 2 lines
Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2
Unfortunately, I am not sure it is whatever is in Paul's automation rig [0]. However, I have also reproduced this on a tegra124 nyan-big in the office.

I was able to reproduce this using a busybox initial ramdisk. Just to make sure I built a separate one from git and it exposes the same behaviour. I suspect that this is some sort of weird interaction between mdev and async probing and nobody's noticed so far because async probing isn't very common (at least in the ARM world).

I'll be off for the weekend soonish, but I'll try to find some more time next week to track this down.

Thierry Reding

author

2015-09-11 16:33 UTC #37 lore raw

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

Quoted 13 lines · Thierry Reding

Quoted 11 lines · Jon Hunter
On 11/09/15 14:25, Thierry Reding wrote:
[snip]
Quoted 2 lines
Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2
Unfortunately, I am not sure it is whatever is in Paul's automation rig [0]. However, I have also reproduced this on a tegra124 nyan-big in the office.

Quoted 8 lines

I was able to reproduce this using a busybox initial ramdisk. Just to make sure I built a separate one from git and it exposes the same behaviour. I suspect that this is some sort of weird interaction between mdev and async probing and nobody's noticed so far because async probing isn't very common (at least in the ARM world).
I'll be off for the weekend soonish, but I'll try to find some more time next week to track this down.

Before I head into the weekend, here are my findings: looks like this might be some sort of recursive locking problem. Here's the output with a lot of debug messages:

	/ # modprobe snd-hda-tegra
	[  298.765514] snd_hda_tegra: Unknown symbol snd_hdac_bus_enter_link_reset (err 0)
	[  298.773024] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
	[  298.779332] snd_hda_tegra: Unknown symbol snd_card_register (err 0)
	[  298.785834] snd_hda_tegra: Unknown symbol snd_card_free (err 0)
	[  298.792015] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
	[  298.798485] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
	[  298.805234] snd_hda_tegra: Unknown symbol snd_dma_free_pages (err 0)
	[  298.811816] snd_hda_tegra: Unknown symbol snd_hdac_bus_free_stream_pages (err 0)
	[  298.819413] snd_hda_tegra: Unknown symbol snd_hdac_bus_exit (err 0)
	[  298.825919] snd_hda_tegra: Unknown symbol snd_card_new (err 0)
	[  298.832003] snd_hda_tegra: Unknown symbol snd_pcm_lib_malloc_pages (err 0)
	[  298.839080] snd_hda_tegra: Unknown symbol snd_pcm_lib_free_pages (err 0)
	[  298.846033] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
	[  298.852070] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
	[  298.858475] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
	[  298.864626] snd_hda_tegra: Unknown symbol snd_device_new (err 0)
	[  298.870856] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
	[  298.877802] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
	[  298.883953] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
	[  298.890598] snd_hda_tegra: Unknown symbol snd_dma_alloc_pages (err 0)
	[  298.897274] snd_hda_tegra: Unknown symbol snd_hdac_bus_alloc_stream_pages (err 0)
	[  298.904975] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
	[  299.024167] device: 'timer': device_add
	[  299.031120] > driver_register(drv=bf06dd24)
	[  299.035294]   finding driver...
	[  299.038495]   adding driver...
	[  299.041605] > __driver_attach(dev=ed805810, data=bf06dd24)
	[  299.047115]   matching device...
	[  299.050352] > __driver_attach(dev=ed983e10, data=bf06dd24)
	[  299.055857]   matching device...
	[  299.059086] > __driver_attach(dev=ed9a2010, data=bf06dd24)
	[  299.064606]   matching device...
	[  299.067872] > __driver_attach(dev=ed9a2210, data=bf06dd24)
	[  299.073384]   matching device...
	[  299.076658] > __driver_attach(dev=ed9a2410, data=bf06dd24)
	[  299.082171]   matching device...
	[  299.085408] > __driver_attach(dev=ed9a2610, data=bf06dd24)
	[  299.090912]   matching device...
	[  299.094141] > __driver_attach(dev=ed9a2810, data=bf06dd24)
	[  299.099655]   matching device...
	[  299.102924] > __driver_attach(dev=ed9a2a10, data=bf06dd24)
	[  299.108435]   matching device...
	[  299.111710] > __driver_attach(dev=ed9a2c10, data=bf06dd24)
	[  299.117221]   matching device...
	[  299.120459] > __driver_attach(dev=ed9a2e10, data=bf06dd24)
	[  299.125963]   matching device...
	[  299.129192] > __driver_attach(dev=ed9a3010, data=bf06dd24)
	[  299.134706]   matching device...
	[  299.137976] > __driver_attach(dev=ed9a3210, data=bf06dd24)
	[  299.143487]   matching device...
	[  299.146762] > __driver_attach(dev=ed9a3410, data=bf06dd24)
	[  299.152273]   matching device...
	[  299.155511] > __driver_attach(dev=ed9a3610, data=bf06dd24)
	[  299.161015]   matching device...
	[  299.164253] > __driver_attach(dev=ed9a3810, data=bf06dd24)
	[  299.169752]   matching device...
	[  299.173016] > __driver_attach(dev=ed9a3a10, data=bf06dd24)
	[  299.178527]   matching device...
	[  299.181802] > __driver_attach(dev=ed9a3c10, data=bf06dd24)
	[  299.187325]   matching device...
	[  299.190560] > __driver_attach(dev=ed9a3e10, data=bf06dd24)
	[  299.196062]   matching device...
	[  299.199301] > __driver_attach(dev=ed9a4010, data=bf06dd24)
	[  299.204799]   matching device...
	[  299.208051] > __driver_attach(dev=ed9a4210, data=bf06dd24)
	[  299.213534]   matching device...
	[  299.216796] > __driver_attach(dev=ed9a4410, data=bf06dd24)
	[  299.222307]   matching device...
	[  299.225545] > __driver_attach(dev=ed9a4610, data=bf06dd24)
	[  299.231060]   matching device...
	[  299.234295] > __driver_attach(dev=ed9a4810, data=bf06dd24)
	[  299.239798]   matching device...
	[  299.243051] > __driver_attach(dev=ed9a4a10, data=bf06dd24)
	[  299.248534]   matching device...
	[  299.251799] > __driver_attach(dev=ed9a4c10, data=bf06dd24)
	[  299.257309]   matching device...
	[  299.260548] > __driver_attach(dev=ed9a4e10, data=bf06dd24)
	[  299.266064]   matching device...
	[  299.269298] > __driver_attach(dev=ed9a5010, data=bf06dd24)
	[  299.274801]   matching device...
	[  299.278054] > __driver_attach(dev=ed9a5210, data=bf06dd24)
	[  299.283537]   matching device...
	[  299.286799] > __driver_attach(dev=ed9a5410, data=bf06dd24)
	[  299.292311]   matching device...
	[  299.295549] > __driver_attach(dev=ed9a5610, data=bf06dd24)
	[  299.301064]   matching device...
	[  299.304296] > __driver_attach(dev=ed9a5810, data=bf06dd24)
	[  299.309800]   matching device...
	[  299.313054] > __driver_attach(dev=ed9a5a10, data=bf06dd24)
	[  299.318537]   matching device...
	[  299.321808]   done
	[  299.323821]   locking parent...
	[  299.326991]   done
	[  299.329007]   locking device...
	[  299.332191]   done
	[  299.334201]   probing device...
	[  299.337372] bus: 'platform': driver_probe_device: matched device 70030000.hda with driver tegra-hda
	[  299.346453] bus: 'platform': really_probe: probing driver tegra-hda with device 70030000.hda
	[  299.354990] devices_kset: Moving 70030000.hda to end of list
	[  299.510965] device: 'hdaudioC0D3': device_add
	[  299.590057] > __hda_codec_driver_register(drv=bf0795f0, name=snd_hda_codec_hdmi, owner=bf079680)
	[  299.598862] > driver_register(drv=bf0795f0)
	[  299.603054]   finding driver...
	[  299.606206]   adding driver...
	[  299.609265] > __driver_attach(dev=ede27c00, data=bf0795f0)
	[  299.614756]   matching device...
	[  299.617998] > hda_bus_match(dev=ede27c00, drv=bf0795f0)
	[  299.623240] > hda_codec_match(dev=ede27c00, drv=bf0795f0)
	[  299.628657] < hda_codec_match() match!
	[  299.632429]   done
	[  299.634443]   locking parent...

It hangs here, but interestingly I can interrupt it using Ctrl-C:

	^C[  329.774183] > __device_attach_driver(drv=bf0795f0, _data=ecbc3d08)
	[  329.780536]   matching device...
	[  329.783844] > hda_bus_match(dev=ede27c00, drv=bf0795f0)
	[  329.789198] > hda_codec_match(dev=ede27c00, drv=bf0795f0)
	[  329.794722] < hda_codec_match() match!
	[  329.798600]   async allowed: 0
	[  329.801790] bus: 'hdaudio': driver_probe_device: matched device hdaudioC0D3 with driver snd_hda_codec_hdmi
	[  329.811577] bus: 'hdaudio': really_probe: probing driver snd_hda_codec_hdmi with device hdaudioC0D3
	[  329.820913] devices_kset: Moving hdaudioC0D3 to end of list
	[  329.826618] > hda_codec_driver_probe(dev=ede27c00)
	[  329.831533]   device: hdaudioC0D3
	[  329.835152] > patch_tegra_hdmi(codec=ede27c00)
	[  329.916075] < patch_tegra_hdmi()
	[  329.920029] ALSA pcmC0D3p,0:HDMI 0: cannot preallocate for size 65536

	[  330.946327] < hda_codec_driver_probe()
	[  330.950122] driver: 'snd_hda_codec_hdmi': driver_bound: bound to device 'hdaudioC0D3'
	[  330.958115] bus: 'hdaudio': really_probe: bound device hdaudioC0D3 to driver snd_hda_codec_hdmi
	[  330.966903] < __device_attach_driver() = 1
	[  330.971179] device: 'card0': device_add
	[  330.975432] device: 'controlC0': device_add
	[  330.981325] device: 'pcmC0D3p': device_add
	[  330.987256] device: 'input1': device_add
	[  330.991997] input: tegra-hda HDMI/DP,pcm=3 as /devices/soc0/70030000.hda/sound/card0/input1
	[  331.000477] device: 'event1': device_add
	[  331.136299] driver: 'tegra-hda': driver_bound: bound to device '70030000.hda'
	[  331.143621] bus: 'platform': really_probe: bound device 70030000.hda to driver tegra-hda
	[  331.151804]   done
	[  331.153845]   unlocking device...
	[  331.157288]   done
	[  331.157473]   done
	[  331.157483]   locking device...
	[  331.157493]   done
	[  331.157501]   unlocking device...
	[  331.157508]   done
	[  331.157514]   unlocking parent...
	[  331.157522]   done
	[  331.157532] < __driver_attach()
	[  331.157714]   adding groups...
	[  331.157722]   sending KOBJ_ADD event...
	[  331.157772] < driver_register() = 0
	[  331.157784] < __hda_codec_driver_register() = 0
	[  331.196006]   unlocking parent...
	[  331.199354]   done
	[  331.201407] < __driver_attach()
	[  331.204551] > __driver_attach(dev=ed9a5c10, data=bf06dd24)
	[  331.210061]   matching device...
	[  331.213325] > __driver_attach(dev=ed9a5e10, data=bf06dd24)
	[  331.218826]   matching device...
	[  331.222091] > __driver_attach(dev=ed9a6010, data=bf06dd24)
	[  331.227593]   matching device...
	[  331.230837] > __driver_attach(dev=ed9a6210, data=bf06dd24)
	[  331.236341]   matching device...
	[  331.239578] > __driver_attach(dev=ed9a6410, data=bf06dd24)
	[  331.245079]   matching device...
	[  331.248351] > __driver_attach(dev=ed9a6610, data=bf06dd24)
	[  331.253854]   matching device...
	[  331.257119] > __driver_attach(dev=ed9a6810, data=bf06dd24)
	[  331.262623]   matching device...
	[  331.265901] > __driver_attach(dev=ed9a6a10, data=bf06dd24)
	[  331.271407]   matching device...
	[  331.274645] > __driver_attach(dev=ed9a6c10, data=bf06dd24)
	[  331.280146]   matching device...
	[  331.283411] > __driver_attach(dev=ed9a6e10, data=bf06dd24)
	[  331.288913]   matching device...
	[  331.292178] > __driver_attach(dev=ed9a7010, data=bf06dd24)
	[  331.297681]   matching device...
	[  331.300955] > __driver_attach(dev=ed9a7210, data=bf06dd24)
	[  331.306459]   matching device...
	[  331.309696] > __driver_attach(dev=ed9a7410, data=bf06dd24)
	[  331.315197]   matching device...
	[  331.318461] > __driver_attach(dev=ed9a7610, data=bf06dd24)
	[  331.323964]   matching device...
	[  331.327229] > __driver_attach(dev=ed9a7810, data=bf06dd24)
	[  331.332732]   matching device...
	[  331.335993] > __driver_attach(dev=ed9a7a10, data=bf06dd24)
	[  331.341497]   matching device...
	[  331.344734] > __driver_attach(dev=ed9a7c10, data=bf06dd24)
	[  331.350236]   matching device...
	[  331.353502] > __driver_attach(dev=ed9a7e10, data=bf06dd24)
	[  331.359005]   matching device...
	[  331.362269] > __driver_attach(dev=ed9b0010, data=bf06dd24)
	[  331.367772]   matching device...
	[  331.371032] > __driver_attach(dev=ed9b0210, data=bf06dd24)
	[  331.376533]   matching device...
	[  331.379771] > __driver_attach(dev=ed9b0410, data=bf06dd24)
	[  331.385272]   matching device...
	[  331.388536] > __driver_attach(dev=ed9b0610, data=bf06dd24)
	[  331.394039]   matching device...
	[  331.397312] > __driver_attach(dev=ed9b0810, data=bf06dd24)
	[  331.402816]   matching device...
	[  331.406068] > __driver_attach(dev=ed9b0a10, data=bf06dd24)
	[  331.411569]   matching device...
	[  331.414807] > __driver_attach(dev=ed9b0c10, data=bf06dd24)
	[  331.420307]   matching device...
	[  331.423572] > __driver_attach(dev=ed9b0e10, data=bf06dd24)
	[  331.429074]   matching device...
	[  331.432339] > __driver_attach(dev=ed9b1010, data=bf06dd24)
	[  331.437841]   matching device...
	[  331.441092] > __driver_attach(dev=ed9b1210, data=bf06dd24)
	[  331.446600]   matching device...
	[  331.449836] > __driver_attach(dev=ed9b1410, data=bf06dd24)
	[  331.455339]   matching device...
	[  331.458604] > __driver_attach(dev=edad2410, data=bf06dd24)
	[  331.464105]   matching device...
	[  331.467368] > __driver_attach(dev=edcbb810, data=bf06dd24)
	[  331.472870]   matching device...
	[  331.476120] > __driver_attach(dev=edde4a10, data=bf06dd24)
	[  331.481625]   matching device...
	[  331.484863] > __driver_attach(dev=edde5210, data=bf06dd24)
	[  331.490366]   matching device...
	[  331.493630] > __driver_attach(dev=edde5410, data=bf06dd24)
	[  331.499133]   matching device...
	[  331.502384] > __driver_attach(dev=edde5610, data=bf06dd24)
	[  331.507879]   matching device...
	[  331.511129] > __driver_attach(dev=edde5810, data=bf06dd24)
	[  331.516623]   matching device...
	[  331.519855] > __driver_attach(dev=edde5a10, data=bf06dd24)
	[  331.525348]   matching device...
	[  331.528598] > __driver_attach(dev=ede78810, data=bf06dd24)
	[  331.534092]   matching device...
	[  331.537341] > __driver_attach(dev=edeb5e10, data=bf06dd24)
	[  331.542838]   matching device...
	[  331.546133]   adding groups...
	[  331.549184]   sending KOBJ_ADD event...
	[  331.553043] < driver_register() = 0

Kevin Hilman

2015-09-11 17:08 UTC #38 lore raw

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

Quoted 20 lines · Thierry Reding

Quoted 19 lines · Thierry Reding
Quoted 11 lines · Jon Hunter
On 11/09/15 14:25, Thierry Reding wrote:
[snip]
Quoted 2 lines
Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2
Unfortunately, I am not sure it is whatever is in Paul's automation rig [0]. However, I have also reproduced this on a tegra124 nyan-big in the office.
I was able to reproduce this using a busybox initial ramdisk. Just to make sure I built a separate one from git and it exposes the same behaviour. I suspect that this is some sort of weird interaction between mdev and async probing and nobody's noticed so far because async probing isn't very common (at least in the ARM world).

Quoted 6 lines

Quoted 2 lines
I'll be off for the weekend soonish, but I'll try to find some more time next week to track this down.
Before I head into the weekend, here are my findings: looks like this might be some sort of recursive locking problem. Here's the output with a lot of debug messages:

FWIW, in kernelci we use a buildroot initramfs[1] with eudev enabled for module loading. Before booting, modules are injected into the ramdisk so they are loaded during boot by eudev.

The source is on github[2] and can be rebuilt using './configs/frags/build armel'

Kevin

[1] http://storage.kernelci.org/images/rootfs/buildroot/armel/
[2] https://github.com/kernelci/buildroot/tree/kernelci/2015.02

Thierry Reding

author

2015-09-17 10:26 UTC #39 lore raw

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

Quoted 29 lines · Kevin Hilman

Quoted 20 lines · Thierry Reding
Quoted 19 lines · Thierry Reding
Quoted 11 lines · Jon Hunter
On 11/09/15 14:25, Thierry Reding wrote:
[snip]
Quoted 2 lines
Works for me 100% of the time. Unloading and reloading isn't a problem either. What revision of the Jetson TK1 do you have? Mine is a C.2
Unfortunately, I am not sure it is whatever is in Paul's automation rig [0]. However, I have also reproduced this on a tegra124 nyan-big in the office.
I was able to reproduce this using a busybox initial ramdisk. Just to make sure I built a separate one from git and it exposes the same behaviour. I suspect that this is some sort of weird interaction between mdev and async probing and nobody's noticed so far because async probing isn't very common (at least in the ARM world).
Quoted 6 lines
Quoted 2 lines
I'll be off for the weekend soonish, but I'll try to find some more time next week to track this down.
Before I head into the weekend, here are my findings: looks like this might be some sort of recursive locking problem. Here's the output with a lot of debug messages:

Quoted 5 lines

FWIW, in kernelci we use a buildroot initramfs[1] with eudev enabled for module loading. Before booting, modules are injected into the ramdisk so they are loaded during boot by eudev.
The source is on github[2] and can be rebuilt using './configs/frags/build armel'

This turned out to be rather interesting. The reason why I wasn't seeing this on my setup was because request_module() ends up directly calling the /sbin/modprobe userspace helper. On my setup I had these files installed in /usr/bin (because that's the default installation path that kmod uses) and I was missing a symlink from /sbin to /usr/bin, therefore causing request_module() to return with -ENOENT. Unfortunately the HDA core code completely ignores errors from request_module() so didn't give any indication at all. Thanks to Jon Hunter who put me on that trail.

After fixing the root filesystem I was seeing the deadlocks as well. But the root cause of this was now clearly the request_module(). It turns out that this causes the driver for the HDA codec to be bound to the HDA codec device immediately, from within the HDA controller's ->probe() callback, hence leading to the deadlock.

That's a known problem in HDA land and for Intel this has been worked around rather creatively by deferring HDA codec probing to a work queue that runs asynchronously to the controller's probe. To be fair there seem to be other reasons why this is necessary on Intel (the HDA codec and i915 display drivers interact weirdly). It's possible that a work- around isn't necessary on Intel anymore either because the recursive locking of HDA controller vs. HDA codec is gone and the i915 device should be relatively far removed to not cause any deadlocks. I haven't invested any time in fixing this because I don't have a setup where I could test this.

The solution I came up with, and I've sent patches earlier with a couple of people from this thread Cc'ed, is to get rid of the explicit calls to the request_module() function and use existing infrastructure instead. I implemented a uevent callback in the HDA bus that reports the MODALIAS information to the userspace helper, which can then use it to auto-load the proper module. That gets rid of the recursive locking because both devices are now probed from different contexts.

This should work just fine with any relatively modern distribution. Both systemd and eudev implementations of udev should support loading modules when they see a MODALIAS environment variable. For busybox this doesn't work out of the box, but you can enable it by adding the following line to /etc/mdev.conf:

	# support module loading on hotplug
	$MODALIAS=.*    root:root 660 @modprobe "$MODALIAS"

Make sure you have /etc/passwd and /etc/group entries for root, or else mdev will fail to parse this file. mdev still doesn't automatically load modules on boot (mdev -s isn't quite the same as udevadm trigger), but that's only a minor inconvenience and maybe even expected when you use mdev.

Given that the patches are somewhat invasive and probably need more testing on Intel, I'm not sure if they'll make it into v4.3. If not I suggest we go ahead and remove the problematic Kconfig option for now (or make it built-in) and enable it again when the fixes have landed (if not for v4.3 then hopefully for v4.4). Perhaps give it a week or so to give the sound tree maintainers a chance to look at the patches and evaluate whether or not they should go into v4.3.

Does that sound reasonable?

Jon Hunter

maintainer

2015-09-11 13:15 UTC #40 lore raw

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

In reply to Thierry Reding

Quoted 76 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 73 lines · Jon Hunter

Hi Kevin,

On 10/09/15 22:29, Kevin Hilman wrote:

[snip]

Quoted 7 lines

Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.

So curiosity got the better of this cat, as to why we are not seeing this ;-)

The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).

So trying a quick modprobe of the hda-tegra driver I do see it hang ...

/ # modprobe snd-hda-tegra

[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)

Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...

/ # modprobe snd-hda-tegra

[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0

[hangs here]

However, if I do the following, this works ...

/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra

Quoted 7 lines

Quoted 3 lines
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.

To be clear, booting multi_v7_defconfig works just fine for me too and has been working fine for months. However, the reason I am not seeing the issue Kevin and Tyler are reporting is because I never attempt to "modprobe snd-hda-tegra" after boot. If I do then I see a hang. So I believe the only reason we don't see this is because their setup is loading modules.

Cheers
Jon

Thierry Reding

author

2015-09-11 13:21 UTC #41 lore raw

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

Quoted 86 lines · Jon Hunter

Quoted 76 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 73 lines · Jon Hunter
Hi Kevin,
On 10/09/15 22:29, Kevin Hilman wrote:
[snip]
Quoted 7 lines
Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.
So curiosity got the better of this cat, as to why we are not seeing this ;-)
The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).
So trying a quick modprobe of the hda-tegra driver I do see it hang ...
/ # modprobe snd-hda-tegra
[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)
Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...
/ # modprobe snd-hda-tegra
[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0
[hangs here]
However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
Quoted 7 lines
Quoted 3 lines
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.

Quoted 6 lines

To be clear, booting multi_v7_defconfig works just fine for me too and has been working fine for months. However, the reason I am not seeing the issue Kevin and Tyler are reporting is because I never attempt to "modprobe snd-hda-tegra" after boot. If I do then I see a hang. So I believe the only reason we don't see this is because their setup is loading modules.

snd-hda-tegra is auto-loaded on boot for me as well and I don't see any hangs either. I can also unload and reload the module just fine. I've tested this on next-20150911.

Jon Hunter

maintainer

2015-09-11 13:39 UTC #42 lore raw

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

Quoted 96 lines · Thierry Reding

* PGP Signed by an unknown key
Quoted 86 lines · Jon Hunter
Quoted 76 lines · Thierry Reding
Quoted 1 line
Old Signed by an unknown key
Quoted 73 lines · Jon Hunter
Hi Kevin,
On 10/09/15 22:29, Kevin Hilman wrote:
[snip]
Quoted 7 lines
Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.
So curiosity got the better of this cat, as to why we are not seeing this ;-)
The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).
So trying a quick modprobe of the hda-tegra driver I do see it hang ...
/ # modprobe snd-hda-tegra
[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)
Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...
/ # modprobe snd-hda-tegra
[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0
[hangs here]
However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
Quoted 7 lines
Quoted 3 lines
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.
Quoted 6 lines
To be clear, booting multi_v7_defconfig works just fine for me too and has been working fine for months. However, the reason I am not seeing the issue Kevin and Tyler are reporting is because I never attempt to "modprobe snd-hda-tegra" after boot. If I do then I see a hang. So I believe the only reason we don't see this is because their setup is loading modules.

Quoted 3 lines

snd-hda-tegra is auto-loaded on boot for me as well and I don't see any hangs either. I can also unload and reload the module just fine. I've tested this on next-20150911.

What else are you auto-loading? For my testing there appears to be a sensitivity to order outside of the depmod order.

Can you try unloading all the sound modules and then do a "modprobe snd-hda-tegra"?

Cheers
Jon

Thierry Reding

author

2015-09-11 13:57 UTC #43 lore raw

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

Quoted 102 lines · Jon Hunter

Quoted 96 lines · Thierry Reding
* PGP Signed by an unknown key
Quoted 86 lines · Jon Hunter
Quoted 76 lines · Thierry Reding
Quoted 1 line
Old Signed by an unknown key
Quoted 73 lines · Jon Hunter
Hi Kevin,
On 10/09/15 22:29, Kevin Hilman wrote:
[snip]
Quoted 7 lines
Since there is no movement on this, and jetson hasn't been boot for multi_v7_defconfig for a while[1], I think it's time to undo the option causing this problem[2] so that v4.3 will actually boot on the jetson.
Unless I hear a good reason otherwise, I'll be posting a patch to disable the HDA related options in multi_v7_defconfig.
So curiosity got the better of this cat, as to why we are not seeing this ;-)
The main difference I see between the tegra_defconfig and multi_v7_defconfig is all the sound drivers are modules (including this one).
So trying a quick modprobe of the hda-tegra driver I do see it hang ...
/ # modprobe snd-hda-tegra
[  625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0)
[  625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0)
[  625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0)
[  625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0)
[  625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0)
[  625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0)
[  625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0)
[  625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0)
[  625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0)
[  625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0)
[  840.117528] INFO: task modprobe:137 blocked for more than 120 seconds.
[  840.124192]       Not tainted 4.2.0-next-20150909-40826-gb799053 #1
[  840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  840.138540] modprobe        D c09ac3a4     0   137     82 0x00000000
[  840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98)
[  840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10)
[  840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150)
[  840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50)
[  840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90)
[  840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88)
[  840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0)
[  840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4)
[  840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0)
[  840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354)
[  840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c)
[  840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138)
[  840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c)
Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show the order in which modules are being loaded) ...
/ # modprobe snd-hda-tegra
[   22.450276] snd_hda_tegra: err = -2
[   22.484535] soundcore: err = 0
[   22.488964] snd: err = 0
[   22.493242] snd_timer: err = 0
[   22.498380] snd_pcm: err = 0
[   22.502479] snd_hda_core: err = 0
[   22.508337] snd_hda_codec: err = 0
[   22.513386] snd_hda_tegra: err = 0
[   22.740216] snd_hda_codec_hdmi: err = 0
[hangs here]
However, if I do the following, this works ...
/ # modprobe snd-hda-codec-hdmi
/ # modprobe snd-hda-tegra
Quoted 7 lines
Quoted 3 lines
So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs.
Thierry, any thoughts?
I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs.
Quoted 6 lines
To be clear, booting multi_v7_defconfig works just fine for me too and has been working fine for months. However, the reason I am not seeing the issue Kevin and Tyler are reporting is because I never attempt to "modprobe snd-hda-tegra" after boot. If I do then I see a hang. So I believe the only reason we don't see this is because their setup is loading modules.
Quoted 3 lines
snd-hda-tegra is auto-loaded on boot for me as well and I don't see any hangs either. I can also unload and reload the module just fine. I've tested this on next-20150911.

Quoted 5 lines

What else are you auto-loading? For my testing there appears to be a sensitivity to order outside of the depmod order.
Can you try unloading all the sound modules and then do a "modprobe snd-hda-tegra"?

Here's the list of loaded modules right after boot:

	-sh-4.3# lsmod
	Module                  Size  Used by
	snd_hda_tegra           4764  0 
	snd_hda_codec_hdmi     35010  1 
	snd_soc_tegra30_i2s     5380  2 
	snd_soc_tegra_pcm       1184  1 snd_soc_tegra30_i2s
	snd_soc_tegra_rt5640     3960  0 
	snd_soc_rt5640         56972  1 
	snd_soc_tegra_utils     2825  1 snd_soc_tegra_rt5640
	snd_soc_rl6231          1897  1 snd_soc_rt5640
	snd_soc_core          107271  4
	snd_soc_tegra_pcm,snd_soc_rt5640,snd_soc_tegra_rt5640,snd_soc_tegra30_i2s
	snd_hda_codec          75955  2 snd_hda_codec_hdmi,snd_hda_tegra
	snd_compress            7363  1 snd_soc_core
	snd_hda_core           26603  3
	snd_hda_codec_hdmi,snd_hda_codec,snd_hda_tegra
	snd_pcm_dmaengine       2943  1 snd_soc_core
	snd_pcm                69108  7
	snd_soc_rt5640,snd_soc_core,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_tegra,snd_pcm_dmaengine,snd_hda_core
	snd_timer              17264  1 snd_pcm
	snd_soc_tegra30_ahub     8299  1 snd_soc_tegra30_i2s
	snd                    42248  7
	snd_soc_core,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_tegra,snd_compress
	nouveau              1302185  0 
	soundcore                858  1 snd
	tegra_devfreq           5375  0 
	ttm                    65238  1 nouveau

Then I went and unloaded a couple of modules until I was left with this:

-sh-4.3# lsmod
Module Size Used by
nouveau 1302185 0
tegra_devfreq 5375 0
ttm 65238 1 nouveau

Then I did the following:

-sh-4.3# modprobe snd-hda-tegra
[ 2243.786143] hdaudio hdaudioC0D3: Unable to bind the codec
-sh-4.3# lsmod
Module Size Used by
snd_hda_tegra 4764 0
snd_hda_codec 75955 1 snd_hda_tegra
snd_hda_core 26603 2 snd_hda_codec,snd_hda_tegra
snd_pcm 69108 3 snd_hda_codec,snd_hda_tegra,snd_hda_core
snd_timer 17264 1 snd_pcm
snd 42248 4 snd_timer,snd_pcm,snd_hda_codec,snd_hda_tegra
soundcore 858 1 snd
nouveau 1302185 0
tegra_devfreq 5375 0
ttm 65238 1 nouveau
-sh-4.3# modprobe snd-hda-codec-hdmi
-sh-4.3# modprobe -r snd-hda-tegra
-sh-4.3# modprobe snd-hda-tegra
[ 2263.934328] input: tegra-hda HDMI/DP,pcm=3 as /devices/soc0/70030000.hda/sound/card0/input4

So all worked just fine.

Jon Hunter

maintainer

2015-09-11 14:08 UTC #44 lore raw

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

On 11/09/15 14:57, Thierry Reding wrote:

[snip]

Quoted 21 lines

Then I did the following:
-sh-4.3# modprobe snd-hda-tegra
[ 2243.786143] hdaudio hdaudioC0D3: Unable to bind the codec
-sh-4.3# lsmod
Module Size Used by
snd_hda_tegra 4764 0
snd_hda_codec 75955 1 snd_hda_tegra
snd_hda_core 26603 2 snd_hda_codec,snd_hda_tegra
snd_pcm 69108 3 snd_hda_codec,snd_hda_tegra,snd_hda_core
snd_timer 17264 1 snd_pcm
snd 42248 4 snd_timer,snd_pcm,snd_hda_codec,snd_hda_tegra
soundcore 858 1 snd
nouveau 1302185 0
tegra_devfreq 5375 0
ttm 65238 1 nouveau
-sh-4.3# modprobe snd-hda-codec-hdmi
-sh-4.3# modprobe -r snd-hda-tegra
-sh-4.3# modprobe snd-hda-tegra
[ 2263.934328] input: tegra-hda HDMI/DP,pcm=3 as /devices/soc0/70030000.hda/sound/card0/input4

Quoted 1 line

So all worked just fine.

That's interesting. For me (as per my earlier email), I did not see the "unable to bind the codec" and modprobe attempted to load snd-hda-codec-hdmi after snd-hda-tega. Puzzled.

Jon

Olof Johansson

2015-08-19 20:36 UTC #45 lore raw

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

In reply to Thierry Reding

Quoted 94 lines · Thierry Reding

Quoted 30 lines · Tyler Baker
Hi Theirry,
Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1
Quoted 6 lines
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.
----------------------------------------------------------------
Thierry Reding (1):
ARM: tegra: Update multi_v7_defconfig
Quoted 6 lines
The kernelci.org bot recently reported jetson-tk1 boot failures[1][2] in next-20150818, only when booting the mult_v7_defconfig kernels. I bisected[3] these boot failure down to this commit, it didn't cleanly revert, so I manually removed that options this patch added, and my jetson-tk1 booted again. Digging a bit further, if I apply the patch below to next-20150818, my jetson-tk1 boots.
I'm not able to reproduce this here. Building next-20150818 with multi_v7_config and booting the resulting kernel works just fine.
arch/arm/configs/multi_v7_defconfig CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y · line 473
Quoted 13 lines
arch/arm/configs/multi_v7_defconfig +0 -1
index b2facab..a285afe 100644
@@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=m
 CONFIG_SND=m
 CONFIG_SND_DYNAMIC_MINORS=y
-CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m
lsmod output confirms that snd-hda-tegra.ko was loaded:
        # lsmod
        Module                  Size  Used by
        snd_soc_tegra30_i2s     5591  2
        snd_soc_tegra_pcm       1184  1 snd_soc_tegra30_i2s
        snd_hda_tegra           4771  0
        snd_soc_rt5640         56972  1
        snd_soc_tegra_rt5640     3960  0
        snd_hda_codec          76398  1 snd_hda_tegra
        snd_soc_rl6231          1897  1 snd_soc_rt5640
        snd_soc_tegra_utils     2825  1 snd_soc_tegra_rt5640
        snd_hda_core           26151  2 snd_hda_codec,snd_hda_tegra
        snd_soc_core          119213  4 snd_soc_tegra_pcm,snd_soc_rt5640,snd_soc_tegra_rt5640,snd_soc_tegra30_i2s
        snd_compress            7114  1 snd_soc_core
        snd_pcm_dmaengine       2943  1 snd_soc_core
        snd_pcm                67835  6 snd_soc_rt5640,snd_soc_core,snd_hda_codec,snd_hda_tegra,snd_pcm_dmaengine,snd_hda_core
        snd_timer              16881  1 snd_pcm
        snd                    41480  6 snd_soc_core,snd_timer,snd_pcm,snd_hda_codec,snd_hda_tegra,snd_compress
        soundcore                858  1 snd
        snd_soc_tegra30_ahub     8747  1 snd_soc_tegra30_i2s
        nouveau              1217903  0
        tegra_devfreq           5389  0
        ttm                    65073  1 nouveau
Quoted 6 lines
This isn't where the story ends unfortunately. The collabora lab also has a jetson-tk1, booted in the same manner, which boots next-20150818 fine[4]. The only differences I can spot in the two boot logs is that the collabora board is using an older version of u-boot, where as my board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad).
I don't have either of those commits in any of the U-Boot trees I have. Perhaps whatever tree this comes from has local patches that cause the breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just to make sure I tried running latest origin/master, which identifies thusly:

Quoted 6 lines

        U-Boot 2015.10-rc2-00040-g0f9258228e2b
And that boots next-20150818 fine.
If you can point me at the source for the version that you use I may be able to find something that could cause this.

FWIW, my jetson has been booting fine as well, with U-Boot 2014.07-rc1-00095-gd7782d0 and Debian userspace.

(Glad to confirm that it's a good thing we've got variety in how systems are configured and setup so we get more coverage).

-Olof

Mikko Perttunen

2015-08-19 11:15 UTC #46 lore raw

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

In reply to Tyler Baker

Please try disabling TEGRA124_EMC and seeing if that makes any difference.

Mikko

Quoted 87 lines · Tyler Baker

Hi Theirry,
Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1
Quoted 6 lines
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.
----------------------------------------------------------------
Thierry Reding (1):
ARM: tegra: Update multi_v7_defconfig
The kernelci.org bot recently reported jetson-tk1 boot failures[1][2] in next-20150818, only when booting the mult_v7_defconfig kernels. I bisected[3] these boot failure down to this commit, it didn't cleanly revert, so I manually removed that options this patch added, and my jetson-tk1 booted again. Digging a bit further, if I apply the patch below to next-20150818, my jetson-tk1 boots.
arch/arm/configs/multi_v7_defconfig +0 -1
index b2facab..a285afe 100644
@@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=m
 CONFIG_SND=m
 CONFIG_SND_DYNAMIC_MINORS=y
-CONFIG_SND_HDA_TEGRA=m
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m
This isn't where the story ends unfortunately. The collabora lab also has a jetson-tk1, booted in the same manner, which boots next-20150818 fine[4]. The only differences I can spot in the two boot logs is that the collabora board is using an older version of u-boot, where as my board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad). I've also noticed some angry udev messages after the modules probe in userspace present in both boot logs that look suspicious.
[   70.469914] udevd[108]: worker [113] /devices/soc0/70030000.hda is
taking a long time
[   70.479849] udevd[108]: worker [115] /devices/soc0/70300000.ahub is
taking a long time
[   70.490769] udevd[108]: worker [117] /devices/soc0/sound is taking
a long time
FWIW, When I went searching for this patch, I couldn't find it on any of the mailing lists. The only reference to this patch was from this pull request, thus why I'm reporting the issue here. :)
Anyways, let me know if you can reproduce this issue, and/or can think of a reason this might may be causing trouble.
Cheers,
Tyler
[1] http://kernelci.org/boot/all/job/next/kernel/next-20150818/
[2] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-tbaker/boot-tegra124-jetson-tk1.html
[3] http://hastebin.com/bixofozaji.vhdl
[4] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-collabora/boot-tegra124-jetson-tk1.html
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Tyler Baker

2015-08-19 16:50 UTC #47 lore raw

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

Hi Mikko,

Quoted 1 line · Mikko Perttunen

Please try disabling TEGRA124_EMC and seeing if that makes any difference.

I disabled CONFIG_TEGRA124_EMC and the problem on my end still exists. Thanks for the suggestion.

Cheers,

Tyler

Olof Johansson

2015-08-21 02:00 UTC #48 lore raw

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

In reply to Thierry Reding

Quoted 14 lines · Thierry Reding

Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)

Quoted 8 lines

Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.

I know there are issues surfaced by these changes, but the bug is unrelated to the defconfig update per se.

I've chosen to merge this, with the hope that the root cause will be found and fixed quickly. If needed, we can revert the options that are causing problems.

-Olof

Tyler Baker

2015-08-21 02:39 UTC #49 lore raw

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

Quoted 21 lines · Olof Johansson

Quoted 20 lines · Thierry Reding
Hi ARM SoC maintainers,
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig
for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480:
ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200)
Thanks,
Thierry
----------------------------------------------------------------
ARM: tegra: Default configuration updates for v4.3-rc1

Quoted 8 lines

Quoted 2 lines
Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling on Tegra124.
I know there are issues surfaced by these changes, but the bug is unrelated to the defconfig update per se.
I've chosen to merge this, with the hope that the root cause will be found and fixed quickly. If needed, we can revert the options that are causing problems.

Fine with me, as the issue seem to be local to my board.