On Fri, Jan 9, 2015 at 4:30 PM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Tue, Jan 06, 2015 at 12:56:37AM +0800, wens Tsai wrote: >> Hi, >> >> On Tue, Jan 6, 2015 at 12:15 AM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > Hi Chen-Yu, >> > >> > On Wed, Dec 24, 2014 at 11:29:26PM +0800, wens Tsai wrote: >> >> Hi everyone, >> >> >> >> As some of you might have noticed, I've sent out patches for A80 MMC >> >> and AXP20x. In addition, I've picked up Boris' AXP221 patches to >> >> resend after the AXP patches are merged. >> > >> > Thanks for your amazing work. >> > >> >> The following is a list of things I'm working on or waiting to >> >> submit: >> >> >> >> - AXP20x (PEK and docs) series, originally by Carlo, posted v8 >> >> - AXP20x regulator driver cleanup, finished and tested >> > >> > What is left to be posted, besides the DT bits? >> >> This is actually getting rid of the DT parsing code in the regulator >> driver, and using common code in the regulator core added in 3.19-rc1. >> So this is new. > > Oh, cool. > >> >> - AXP221 support, originally by Boris, finished and tested >> >> * Also enables WiFi on the Hummingbird A31 >> > >> > There was some discussion since for some board (maybe the APP4) we had >> > some circular dependency between the regulators exposed by the >> > PMIC. Has that been taken care of? >> >> The work Boris has done on that doesn't mesh well with the previous >> item. > > What previous items? The DT parsing code removal?
Yes. >> 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. >> >> >> - 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. ChenYu -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
