Skip to content

RFC Power(full) framework based on Driver Model

Tom Rini u-boot 1 version New

Get series with b4
b4 am 20141022153143.GE25506@bill-the-cat

Versions newest first

  1. v1 RFC Latest4 of 19 patches 0 repliesNew

4 of 19 patches are in this archive. The cover letter announces 19.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/19lib: errno: introduce errno_str(): returns errno related message+0 -03 replies
7/19dm: pmic: add max77686 pmic driver+0 -00 replies
8/19dm: regulator: add max77686 regulator driver+0 -00 replies
9/19dm: pmic: new commands: pmic and regulator+0 -00 replies

Reviews trailers per patch

2 of 4 patches have a Reviewed-by or Acked-by.

PatchTom Rini
1/19R-b
7/19R-b
8/19
9/19

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [U-Boot] [PATCH 00/19] [RFC] Power(full) framework based on Driver Model
Quoted 64 lines · Przemyslaw Marczak

Hello,
This piece of code was a base for prepare my presentation talk for the U-Boot Mini Summit, which taking place at ELCE2014 conference, 13-th October 2014 Dusseldorf, Germany.

The tittle of talk: "Power(full) framework based on Driver Model"

The presentation will be shared after the Summit.

This patchset introduces the new one PMIC framework for the U-Boot. It is still under the construction, but the basic functionality was achieved and tested. Please feel free to comment and share the opinion.

I think that each patch is described full enough, but for some more design details, please look into the documentation file. It includes some basic examples for the PMIC drivers.

Quick summary of:
Framework:
- The new approach - UCLASS_PMIC - simple and designed for device I/O only
- Add new uclass types: UCLASS_PMIC and UCLASS_PMIC_REGULATOR
- Two uclass drivers for above types
- A common regulator operations - will easy cover the real devices design

Drivers:
- Introduce new PMIC API for drivers - now everything base on "struct udevice"
- Introduce Regulator Voltage descriptors and Operation Mode descriptors which are usually taken from the device tree (board dependent data)
- Two uclass device drivers for MAX77686(PMIC+REGULATOR)

User Interface:
- command pmic, unchanged functionality and ported to the driver model
- command regulator(NEW) for safe regulator setup from commandline,
- now can check output Voltage and operation mode of the regulators,
- also can check the board Voltage limits and driver available modes

The future plans:
- Wait for the I2c Driver Model implementation
- Introduce a common way to bind pmic devices - now done by alias "pmic"
- Add additional uclass types: MUIC, CHARGER, BATTERY, MFD and maybe more.
- Introduce optimal operations for new uclasses
- Port all U-Boot drivers to the new Framework
- Remove the old drivers and the old PMIC Framework code

The assumptions of this work is:
- Add new code to independent files
- Keep two Frameworks as independent and without conflicts
- Don't mix OLD/NEW Framework code - for the readability
- Port all drivers using new API
- Remove the old Framework and the old drivers

A disadvantage:
- some parts of the present code is duplicated

Need help:
- After merge this, it is welcome to help with driver porting.
- Everything should be tested

The extra feature:
The first commit introduces errno_str() function.
It is a common function which I hope will be usefull for commands and not only. If any visible error says: -19 or some other magic number, then it means that this function should be used.

Quoted 5 lines

U-Boot Mini Summit members:
This code is maybe not as good as it could be, but the time was limited, and the conference is comming soon. I don't expects a code review of this now, but it would be nice if you take a look of this piece of code before our U-Boot Mini Summit. Of course it depends on you.

Per the mini-summit, please add a patch adding yourself as pmic custodian (so something to doc/git-mailrc, shoot me your patchwork username and Detlev an ssh key so we can get a repo setup). For this series, I'm going to review/ack and I want Simon to pick it up for the DM tree since I think that makes the most sense, yes? Thanks!

And for all the patches in the series I don't reply to, they seem fine but aren't for me to ack (being board specific stuff, that looked fine but I don't have the HW) or I just agree with Simon's comments.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141022/cdafd78a/attachment.pgp>