Skip to contentSkip to conversation

tegra on 3.11

DISCUSSION Kyle McMartin 3 participants 8 messages Aug 20, 2013 – Dec 3, 2013 8 messages not in the archive Tegra architecture support

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 20130820150418.GI27560-nxOev/[email protected]

#2 lore raw
Quoted 5 lines · Kyle McMartin

Hey guys,

Just a quick note, I needed to pull in the patch from
http://marc.info/?l=linux-tegra&m=137404750420372&w=2 in order to get trimslice booting from its internal SATA when using dtb to boot.

Oh dear, I can reproduce this. It looks like I didn't notice this since I was probably testing linux-next with Mikko's patches applied on top in my local branch:-(

If that patch gets applied to v3.11, then it'll cause nasty merge conflicts with Mikko's other USB-related patches when v3.12 comes around. Plus, the patch is rather large for this late stage in the v3.11-rc series. I think the best way is to add regulator-always-on, regulator-boot-on properties to the relevant VBUS regulators. I'll try sending a patch for that...

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 11 lines · Stephen Warren
Quoted 5 lines · Kyle McMartin

Hey guys,

Just a quick note, I needed to pull in the patch from
http://marc.info/?l=linux-tegra&m=137404750420372&w=2 in order to get trimslice booting from its internal SATA when using dtb to boot.

Oh dear, I can reproduce this. It looks like I didn't notice this since I was probably testing linux-next with Mikko's patches applied on top in my local branch:-(

Quoted 6 lines

If that patch gets applied to v3.11, then it'll cause nasty merge conflicts with Mikko's other USB-related patches when v3.12 comes around. Plus, the patch is rather large for this late stage in the v3.11-rc series. I think the best way is to add regulator-always-on, regulator-boot-on properties to the relevant VBUS regulators. I'll try sending a patch for that...

Thanks, we've hit another issue in Fedora where that may or may not be the kernel (life on the bleeding edge, sigh.) but I'll re-build a known working kernel with your patch instead of the backport and let you know if it works for us.

regards, Kyle

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 5 lines
Quoted 5 lines
[   29.198018] PCI: enabling device 0000:01:00.0 (0140 -> 0143)
[   29.198180] Unhandled fault: imprecise external abort (0x406) at
0xb6f49000
[   29.205136] Internal error: : 406 [#1] SMP ARM
Quoted 7 lines
Quoted 3 lines

looks to be the first time we touch the HW in rtl_init_one.

Seen anything similar, or should I start debugging further?

PCIe isn't expected to work usefully until 3.12, unless you've manually merged in Thierry's Tegra PCIe driver rewrite. It's probably worth disabling it in your .config file.

fwiw, the problem was CONFIG_PCIEPORTBUS in our config, I've not had a chance to track down what the issue actually is, but that driver busted things in 3.11.

regards, Kyle

A message that is not in the archive (sent off-list or not yet received): 20130904183815.GC16338-nxOev/[email protected]

#10 lore raw
Quoted 9 lines · Kyle McMartin
Quoted 9 lines
Quoted 8 lines
[   29.198018] PCI: enabling device 0000:01:00.0 (0140 -> 0143)
[   29.198180] Unhandled fault: imprecise external abort (0x406) at
0xb6f49000
[   29.205136] Internal error: : 406 [#1] SMP ARM

looks to be the first time we touch the HW in rtl_init_one.

Seen anything similar, or should I start debugging further?

Quoted 7 lines
Quoted 3 lines

PCIe isn't expected to work usefully until 3.12, unless you've manually merged in Thierry's Tegra PCIe driver rewrite. It's probably worth disabling it in your .config file.

fwiw, the problem was CONFIG_PCIEPORTBUS in our config, I've not had a chance to track down what the issue actually is, but that driver busted things in 3.11.

Ah, I guess if you build the R8169 driver as a module, and disable CONFIG_CPU_IDLE, then it will work fine on TrimSlice in v3.11.

I have reproduced the issue you see with CONFIG_PCIEPORTBUS in v3.11. So, at least it isn't an isolated incident. That said, I don't intend to look into it since there's an easy workaround, and ...

The good news is that in v3.12 with the new PCIe driver,

(a) You don't need to build R8169 as a module; built-in will work fine.

(b) You don't need to disable CPUIDLE; the code disables the problematic idle state automatically iff a PCIe device is detected.

(c) CONFIG_PCIEPORTBUS is enabled in tegra_defconfig, and everything still works fine.

A message that is not in the archive (sent off-list or not yet received): [email protected]

#12 lore raw
Quoted 9 lines · Stephen Warren

Ah, I guess if you build the R8169 driver as a module, and disable CONFIG_CPU_IDLE, then it will work fine on TrimSlice in v3.11.

I have reproduced the issue you see with CONFIG_PCIEPORTBUS in v3.11. So, at least it isn't an isolated incident. That said, I don't intend to look into it since there's an easy workaround, and ...

The good news is that in v3.12 with the new PCIe driver,

Quoted 8 lines

(a) You don't need to build R8169 as a module; built-in will work fine.

(b) You don't need to disable CPUIDLE; the code disables the problematic idle state automatically iff a PCIe device is detected.

(c) CONFIG_PCIEPORTBUS is enabled in tegra_defconfig, and everything still works fine.

Awesome. Thanks very much Stephen, I'll make those changes to our 3.12 snapshots.

--Kyle

#13 lore raw
In reply to a message not in the archive
Quoted 9 lines · Kyle McMartin
Quoted 9 lines
Quoted 8 lines
[   29.198018] PCI: enabling device 0000:01:00.0 (0140 -> 0143)
[   29.198180] Unhandled fault: imprecise external abort (0x406) at
0xb6f49000
[   29.205136] Internal error: : 406 [#1] SMP ARM

looks to be the first time we touch the HW in rtl_init_one.

Seen anything similar, or should I start debugging further?

Quoted 7 lines
Quoted 3 lines

PCIe isn't expected to work usefully until 3.12, unless you've manually merged in Thierry's Tegra PCIe driver rewrite. It's probably worth disabling it in your .config file.

fwiw, the problem was CONFIG_PCIEPORTBUS in our config, I've not had a chance to track down what the issue actually is, but that driver busted things in 3.11.

I came across another occurrence of this only recently and now stumbled across this old email. Did you by any chance find out what the issue is with PCIEPORTBUS?

Thierry

A message that is not in the archive (sent off-list or not yet received): 20131203103043.GI21178-AwZRO8vwLAwmlAP/[email protected]

#15 lore raw
Quoted 14 lines · Thierry Reding
Quoted 13 lines · Kyle McMartin
Quoted 12 lines
Quoted 8 lines
[   29.198018] PCI: enabling device 0000:01:00.0 (0140 -> 0143)
[   29.198180] Unhandled fault: imprecise external abort (0x406) at
0xb6f49000
[   29.205136] Internal error: : 406 [#1] SMP ARM

looks to be the first time we touch the HW in rtl_init_one.

Seen anything similar, or should I start debugging further?

PCIe isn't expected to work usefully until 3.12, unless you've manually merged in Thierry's Tegra PCIe driver rewrite. It's probably worth disabling it in your .config file.

Quoted 8 lines
Quoted 3 lines

fwiw, the problem was CONFIG_PCIEPORTBUS in our config, I've not had a chance to track down what the issue actually is, but that driver busted things in 3.11.

I came across another occurrence of this only recently and now stumbled across this old email. Did you by any chance find out what the issue is with PCIEPORTBUS?

I think I did -- let me try to dig through my notes next time I'm in the office and I'll follow up later this week.

Thanks!
Kyle