RFC OMAP System Control Module
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest1 of 11 patches 0 repliesNew
1 of 11 patches is in this archive. The cover letter announces 11.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 7/11 | mfd: omap: control: usb-phy: introduce the ctrl-module usb driver | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [linux-pm] [RFC PATCH 00/11] OMAP System Control Module
Hi Eduardo,
Quoted 5 lines · Eduardo Valentin
Hello Paul and Tony,
This is a series of patches adding a basic support for system control module, on OMAP4+ context. It is a working in progress, but I wanted to share already to get your feedback.
This is a great start, thanks for working on this. We have been needing to do this for awhile now so I'm glad to see you working on it.
Quoted 11 lines
I've modeled the driver as an MFD. You will see in this series:
. A rework of the system control module header (patch from Santosh, picked from the list) . Device creation for control module core
. Early device creation for control module core
. The MFD core driver for system control module
. The MFD child for usb-phy pin control
. The MFD child for bandgap sensor
. Very early exposure of OMAP4 thermal zone
. All added drivers are only supporting DT probing
. The series is based on linux-omap master, as it has the hwmod entries for SCM.
Quoted 3 lines
The overall idea of this series is to put in place the infrastructure. It is not touching nor removing the existing APIs under
mach-omap2/control.cfor now. But the target is to have these APIs moved to the MFD core driver.
IMO, the best time to create the APIs is when the new MFD children are created.
The goal should be that none of these drivers should be doing direct read/writes to the control module.
Kevin