On Tue, Apr 29, 2014 at 11:15:27AM +0200, Sebastian Hesselbarth wrote: > On 04/28/2014 10:31 AM, Andrew Lunn wrote: >>> Russell, >>> >>> thanks for dropping those patches. I know you are packed with a bunch >>> of other patch sets, so if you agree, I can pick up your Dove related >>> patches and finish them. >>> >>> One thing that comes into my mind is, that we moved Dove DT to >>> mach-mvebu starting with v3.15-rc1 so we need to find a better place >>> for the driver than mach-dove. >> >> Create drivers/pmu ? > > Hmm, I see no other folder it could sit in. Maybe, yes. > >> The cpufreq driver also needs access to registers within the pmu >> range. Should it be part of pmu.c, or should we export a regmap which >> cpufreq can use? > > Not only cpufreq but also pinctrl as the first 16 mpps can have PMU > related functions mapped to them. Syscon should do the trick. The thing I don't like about regmap/syscon for this stuff is that it seems pretty easy to violate the statement in 8.6.2.4 when you lock individual register accesses. This statement states that the power-up/power-down sequence for VMeta and the GPU must be completed one at a time. In other words, you can't interleave the power control of these units (which is what could happen if you rely on the locking provided by regmap/syscon.) I'd prefer to take that a little further to avoid any unintended consequences (as indeed I have done in this patch) and ensure that these sequences are complete before any other system is controlled. As for DT, I should probably state that I'm far from happy with the DT situation on Dove. When I've tried it, I've encountered problems with the HDMI output - the picture spends more time blanked than displaying. I've no idea what is causing that, I've been through the SI5351 registers, the TDA998x registers, the LCD controller registers, and I can't find any reason for it. Yet, boot the same kernel without DT and it works fine. Boot back using DT, and it's unstable again. I can't detect any difference on the actual HDMI signals themselves either. The HDMI clock seems stable and of the correct frequency. There is definitely some difference between booting with DT and booting with legacy stuff that seems to upset HDMI. For me, the /only/ reliably working system is one where DT is not involved. This means I remain opposed to any solutions which can't be used in a non-DT environment - at least until the HDMI issue can be resolved. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
