On 08/22/2012 01:07 PM, Mark Brown wrote: > On Mon, Aug 20, 2012 at 12:37:44PM -0600, Stephen Warren wrote: >> On 08/20/2012 12:14 PM, Mark Brown wrote: > >>> Why not just pull the patch in via the regulator tree? The >>> idea of merging the entire regulator drivers branch into the >>> Tegra tree doesn't seem awesome... > >> I think that'd end up causing some annoying conflicts with other >> changes that also touch arch/arm/match-tegra/board-dt-tegra20.c. >> Perhaps they're manageable; they probably aren't that bad, but >> it seems better to avoid them. > > Ugh, right. I guess I'd best rebase the commits out of the > drivers branch. Can you let me know what you depend on and I'll > build a mergable branch for you to pull in? I believe the only commit the Tegra tree might need is: b93fffb regulator: tps6586x: add support for SYS rail There is one other commit that touches this driver queued up for 3.7, but I've validated that the two commits can merge together without any conflicts, so I don't think we actually need this in the Tegra tree: 4c79c8d regulator: tps6586x: Convert to regulator_[enable|disable|is_enabled|get_voltage_sel]_regmap A few more notes on the overall situation: a) As background, regulators on the Harmony board are broken in v3.6-rc2, but fixed in v3.6-rc3. Specifically, commit 798bd59 "ARM: tegra: more regulator fixes for Harmony" is required. b) Even on top of v3.6-rc3, commit b93fffb "regulator: tps6586x: add support for SYS rail" introduces a regression on Harmony. I did give a Tested-by tag for this commit, but had tested it on a different board. To fix this, the commit needs to also edit arch/arm/mach-tegra/board-harmony-power.c and s/vdd_sys/REG-SYS/. c) I tested all of next-20120822, regulator's for-next, and Tegra's for-next. In all cases, if I fix the issues above, then merge Laxman's change to instantiate all Harmony's regulators from DT, without removing use of board-harmony-power.c, then all the regulator stuff does in fact work OK; I had previously thought it didn't, but I believe that was because of (a) and (b) above, not the .dts regulator patch. However, because the regulators are now registered from DT first, and the regulator names in the DT are different to the regulator names in board-harmony-power.c, Laxman's .dts regulator patch does break PCIe on Harmony, since it can't obtain the regulators it needs. Overall, I think the solution is as follows: 1) Remove b93fffb "regulator: tps6586x: add support for SYS rail" from the regulator tree entirely. 2) Fix that patch to s/vdd_sys/REG-SYS/ in board-harmony-power.c, and apply it to the Tegra tree. 3) Fix Laxman's regulator .dts patch to solve the PCIe problem, possibly also remove board-harmony-power.c while we're at it, and apply it to the Tegra tree. If it makes life easier, I'm quite happy to move 4c79c8d "regulator: tps6586x: Convert to regulator_[enable|disable|is_enabled|get_voltage_sel]_regmap" to the Tegra tree too. This might be useful; I know that Laxman has another patch for the TPS6586x driver queued up to move the regulator-specific DT parsing from the MFD driver into the regulator driver. I have no idea, but it seems quite likely that would conflict with this patch, and perhaps make everything easier to go through one tree? An alternative would be: 1) Remove b93fffb "regulator: tps6586x: add support for SYS rail" from the regulator tree since it causes a regression. 2) Fix that patch to s/vdd_sys/REG-SYS/ in board-harmony-power.c, and re-apply it to its own branch in the regulator tree. It would be nice to base this branch on v3.6-rc3 so Harmony regulators work before the patch, so the patch can be checked for regressions. 3) Merge that branch into both regulator and Tegra. 4) Apply all future TPS6586x patches to the regulator tree. 5) Apply Laxman's patch to add Harmony regulators to the device tree to the Tegra tree, after fixing the PCIe interaction issue. Let me know which way you want to go. Sorry this driver is causing pain. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
