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?

> 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.

> 
> >>     - 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.

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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: Digital signature

Reply via email to