tristan-google
commented
2 years ago Happy to see this happening. Are there plans to add an implementation of this API for the Smart Battery standard?
Open aaronemassey opened 2 years ago
tristan-google
commented
2 years ago Happy to see this happening. Are there plans to add an implementation of this API for the Smart Battery standard?
aaronemassey
commented
2 years ago Happy to see this happening. Are there plans to add an implementation of this API for the Smart Battery standard?
That's a goal if the Zephyr community is interested!
aaronemassey
commented
1 year ago aaronemassey
commented
1 year ago Non-exhaustive list of TODO issues for incremental improvements from MVP
name: RFC / Proposal about: Submit an RFC / Proposal title: 'Dedicated Battery Fuel Gauge Device Driver API' labels: RFC assignees: 'aaronemassey'
Introduction
Add a kernel device driver API for battery fuel gauge control.
Problem description
A limited battery fuel gauge API exists in the increasingly large sensor_channel enum defined by the sensor API. ~However, fuel_gauges are also written to by drivers (e.g. SMBus writes); this falls outside the purview of the sensor API.~
Correction to above: The writing to drivers is absolutely within the purview of the sensor API. I'm not entirely sure why that text made it in here. It is the case that no fuel gauge ICs make use of the sensor API's writing, but that doesn't preclude such behavior to exist. Thank you to @trentp-igor for catching this error in the RFC.
The sensor API presuppose device drivers to do their own caching. Fuel gauges on severely memory strained systems should allow application code to decide what's important to cache (except for internal values that are necessary for the driver's operation).
Proposed change
Add a battery fuel gauge device driver API that provides reading and fuel gauge writing to (such as via smart battery SMBus) as a single device driver API. Eventually deprecating the sensor API battery fuel gauge APIs in favor of the dedicated battery driver API.
Detailed RFC
Proposed change (Detailed)
See the accompanying initial pull request for an initial MVP.
Followup changes will include a more full fledged SBS Gauge driver enabling SMBus and other writes via the API extended in future PRs.
Dependencies
In future PRs, clients of the battery fuel gauge channels in the sensor API will be migrated to leverage the new battery fuel gauge API. Eventually, the battery fuel gauge APIs implemented in the sensor API will be deprecated and removed.
Part of a Future/TBD Power Supply Subsystem Zephyr Ecosystem
In the initial pull request there were many comments indicating significant interest in the creation of an overarching power supply subsystem, likely drawing inspiration from the Linux Kernel's power supply subsystem. This would encompass working with fuel gauges and charger ICs from application code.
The creation of a fully fledged power supply subsystem is outside the scope of this specific RFC. This RFC is specific to battery fuel gauges. However, these comments were taken heavily into consideration and principally informed a redesign of the initial fuel gauge API to better fit as a module under such a future ecosystem. It's now intended to able to fit within the scope of a future power subsystem roughly described by the below diagram.
The exact details of ownership, RFCs, and future PRs of the future APIs described by this diagram are outside the scope of this RFC and should be largely discussed out in a separate RFC/issue.
Concerns and Unresolved Questions
Minimum Viable Product (MVP)
The initial pull request is intended to be an MVP. Notably, this PR does not include any way to expose writing to fuel-gauge registers, such as SBS extended registers. This will be designed and iterated upon in follow-up PRs.
Not an Expert
I am no expert on batteries nor Zephyr, so there may be cases I do not know to consider.
Alternatives
Status Quo
Pros
Cons
Keep Both
Instead of replacing the fuel gauge channels in the sensor API, just add the new battery fuel gauge device driver API.
Pros
Cons