Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Charging Subsystem #56666

Merged
merged 3 commits into from Sep 7, 2023
Merged

Conversation

rriveramcrus
Copy link
Contributor

@rriveramcrus rriveramcrus commented Apr 7, 2023

Introduce a Battery Charging API #56635

include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
drivers/Kconfig Show resolved Hide resolved
drivers/charger/Kconfig Show resolved Hide resolved
drivers/charger/sbs_charger/emul_sbs_charger.c Outdated Show resolved Hide resolved
drivers/charger/sbs_charger/sbs_charger.c Outdated Show resolved Hide resolved
drivers/charger/sbs_charger/sbs_charger.c Outdated Show resolved Hide resolved
tests/drivers/charger/sbs_charger/testcase.yaml Outdated Show resolved Hide resolved
dts/bindings/charger/charger.yaml Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
@@ -0,0 +1,8 @@
# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add tests into a separate commit to ease review

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, I can split it into two commits:

  • Introduces the driver
  • Adds tests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#56666 (comment)
I don't want to mess up the existing comments by splitting up the commits. I'll split it up once this comment is resolved.

tests/drivers/charger/sbs_charger/src/test_sbs_charger.c Outdated Show resolved Hide resolved
tests/drivers/charger/sbs_charger/testcase.yaml Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
include/zephyr/drivers/charger.h Outdated Show resolved Hide resolved
@rriveramcrus rriveramcrus force-pushed the charger branch 4 times, most recently from 7ea3e77 to 1484160 Compare April 20, 2023 18:01
teburd
teburd previously approved these changes Apr 27, 2023
Copy link
Collaborator

@teburd teburd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs compliance fixes but I like it

@teburd
Copy link
Collaborator

teburd commented Apr 27, 2023

I mean to add... just like the fuel gauge API... this could use with a notification mechanism for status changes. I believe many of the fuel gauge and charger ICs have a gpio line that can be hooked on to for catching interrupts to trigger event handling for things like charger status changes, fuel gauge level sets and such.

That can be done in subsequent work but it would be great to see a plan for it done soon for both of these APIs.

@carlescufi
Copy link
Member

carlescufi commented Aug 22, 2023

Many of the initial discussed changes have been dropped (why?)

You should've been at the dev-review meeting. Towards the end @aaronemassey made his case for this runtime architecture and frankly I agree. Additionally, there was a Nordic Semi representative that was asked about his thoughts on the runtime properties and he did not speak up against it.

Perhaps I wasn't clear enough when I spoke during the meeting @rriveramcrus, my mistake. I have not followed the development of this PR nor I know charging in general, so if I gave the impression of giving my acquiescence then it was the wrong impression. I just don't have an opinion one way or the other due to lack of knowledge in the area.

, and I still fail to see some additional implementations (BQ24190?) that prove this API is good enough for multiple devices.
This was also addressed at the dev-review meeting. As a compromise I did add a settable property to sbs_charger.

As it is today, the API can get and it can set. If you would like to see more properties or devices added, your contributions are welcome and encouraged.

As for BQ24190, it's not happening until after this PR has closed and that is my final decision.

It is however common practice to implement a driver from at least two different vendors to ensure that we cover the hardware diversity as best as possible.
EDIT: I actually got confused, we usually require those to transition an API from experimental to stable

Copy link
Member

@fabiobaltieri fabiobaltieri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the followup, one leftover file and one comment still open about the parameter handling, repeating here: I think that comment is relevant, though it also applies to the fuel gauge APIs so I see why you did it like that, I'll work with @aaronemassey separately on having that one fixed, I don't think it should stay in the current form.

include/zephyr/drivers/charger/charger_sbs_charger.h Outdated Show resolved Hide resolved
Comment on lines 139 to 165
static inline int z_impl_charger_get_prop(const struct device *dev,
struct charger_get_property *prop)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey I think this is still an open point and I agree with Gerard that this should take a (dev, prop, &val) as an argument, having the property embedding the value is very weird, looks like an ioctl or something. I see that this mimics the fuel gauge APIs though so I understnad the motivation, I'll talk with @aaronemassey about reviewing that one as well as I think it should get the same modifications.

Apologies for throwing you off track, but in the end this is a good chance to review both APIs and get them cleaned and coherent.

@fabiobaltieri
Copy link
Member

Thanks @rriveramcrus, I think my last concern is with how the get/set arguments are defined, basically @gmarull comment at 1afad57#r1205212874. I had a good chat with @aaronemassey since that's in the fuel gauge api as well and if anything the two should be aligned.

@rriveramcrus
Copy link
Contributor Author

rriveramcrus commented Aug 24, 2023

I had a good chat with @aaronemassey since that's in the fuel gauge api as well and if anything the two should be aligned.

Likewise chatted with Aaron yesterday. The recommended changes work for me, ack.

Copy link
Member

@fabiobaltieri fabiobaltieri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, few more comments but I like how the get/set are organized now, @gmarull can you take a look at how the subsystem API is defined now?

drivers/charger/charger_handlers.c Outdated Show resolved Hide resolved
drivers/charger/charger_handlers.c Outdated Show resolved Hide resolved
drivers/charger/charger_handlers.c Outdated Show resolved Hide resolved
drivers/charger/sbs_charger.c Show resolved Hide resolved
Add initial charger driver API with the most basic of native_posix
driver tests.

Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Adds a sample sbs charger driver and basics tests.

Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Adds a short stub doc as a placeholder for future documentation in the
charger API.

Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
@rriveramcrus
Copy link
Contributor Author

@gmarull bump, it's been a week since the get/set changes were pushed up.

@henrikbrixandersen henrikbrixandersen dismissed their stale review September 7, 2023 07:27

I have lost track of this extremely lengthy discussion going back and forward between suggested solutions.

@gmarull gmarull dismissed their stale review September 7, 2023 11:51

main concerns have been addressed

@nashif nashif merged commit a627035 into zephyrproject-rtos:main Sep 7, 2023
18 checks passed
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rriveramcrus!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!

To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.

Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁

@rriveramcrus rriveramcrus deleted the charger branch September 7, 2023 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Devicetree Binding PR modifies or adds a Device Tree binding area: Documentation
Projects
Status: v3.5
Development

Successfully merging this pull request may close these issues.

None yet