On Fri, Jan 09, 2015 at 04:52:03PM +0800, wens Tsai wrote: > >> For now I've dropped that bit. The dependency is ELDOs are > >> powered from DCDC1, which is a fairly simple dependency. I think > >> we can get around it by registering the DCDC ones first. > > > > The thing is that this dependency is pretty much dependant on the > > board. We could really well have other combinations on different > > boards, that we wouldn't be able to solve. > > I doubt anyone sane would chain DCDC regulators or LDO regulators, > like DCDC1 -> DCDC2-in, or ALDO1 -> ELDO-in. It doesn't make sense > from an efficiency standpoint. And you'll likely be further limited > by how much current the parent regulator can drive. > > A more likely scenario would be DCDC -> some external regulator -> > xLDO. I don't think the regulator_set stuff solves this either.
Originally, I was thinking about something similar to what ASoC does, that would register sub-devices, one per regulator, that would really be treated as sub-devices and could solve cases like that with the regular deferred probe mechanism. But maybe you're right and we don't need it right now. > >> >> - sunxi (sun[457]i) cpufreq support, finished and testing (CB/CB2 > >> >> tested) > >> >> * Only added support for the boards I own. It's just a matter of > >> >> adding > >> >> the regulator nodes with the proper constraints > >> > > >> > Did you test individual OPPs or global ones (ie per-board or per-SoC)? > >> > Eventually, I'd like to have per-SoC OPPs. It doesn't seem that > >> > undoable from the spreadsheet I shared with you. > >> > >> I've tested per-SoC OPPs with the boards I have using the hardware > >> reliability > >> test on the wiki [1]. Doing per-board OPPs should be as simple as > >> overriding > >> the OPP table in the board dts. As I will state in the series cover letter, > >> for sun[457]i the OPPs are the same or very similar. > > > > Nice. > > > >> For sun6i it is somewhat harder. > > > > Yep, that version D thing is going to cause us a bit of trouble, but > > since we don't have any hardware available, I'd say we should ignore > > it for now. > > Sounds good. This becomes rather simple then. Just need to get the > AXP221 patches merged first. > > I hope that the voltage tolerance levels on the hypothetical version D > is high enough so that we don't ruin anyone's board though. >From what I saw, the rev D is always slightly under-volted (something around 50mV). It shouldn't really damage the CPU if we provide more power to it, and we're staying within the CPU operating range anyway, so we should be fine here. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
