pinctrl pinprops work in 2011.12
Continue Support pin configuration of things like pull-up, pull-down, driving, schmitt-trigger input, slew rate, and other things about pins that software can control on the SoCs we know.
Blueprint information
- Status:
- Complete
- Approver:
- Deepak Saxena
- Priority:
- High
- Drafter:
- Linus Walleij
- Direction:
- Needs approval
- Assignee:
- Linus Walleij
- Definition:
- Approved
- Series goal:
- Accepted for devtrack
- Implementation:
-
Implemented
- Milestone target:
-
11.12
- Started by
- Linus Walleij
- Completed by
- Mounir Bsaibes
Related branches
Related bugs
Sprints
Whiteboard
Meta:
Headline: Support pin configuration that software can control on the SoCs
Acceptance: Pin control and pinmux for member platforms are fully managed using shared infrastructure in upstream code
Roadmap id: KWG2011-PIN-CONTROL
these WI were moved to: https:/
[triad] patch v1 for platform board config map infrastructure: TODO
[triad] Grue patch set (v7): TODO
[triad] Ask Torvalds to pull in pin control tip including this blueprint: TODO
Work Items
Work items:
[triad] Sort out the situation with GPIO ranges and: DONE
[triad] Sort out the problem with gpio_direction* vs pinmux GPIO cross-calls: DONE
[triad] Derek patch set (v4) refined with review comments: DONE
[triad] Make a copy of the pinmux map so multi-arch builds can discard their __initdata maps after boot: DONE
[triad] Make it possible to incrementally add multiple pinmux maps as needed for PXA: DONE
[triad] Implement example pin config for the U300 to use as reference: DONE
[triad] Eris patch set (v5) respond to community comments on v4, split off generic config in it optional (per Kconfig) file, refine group configuration: DONE
[triad] Felicia patch set (v6) respond to community feedback on v5 by switching to pin names for config lookups: DONE
[triad] Use supplied platform device as pin control device and do not create a new device: DONE
Dependency tree
* Blueprints in grey have been implemented.
