Hi! > > > I've been working on a driver for the charger found in most Snapdragon > > > 845 phones (the OnePlus 6, SHIFT6mq, PocoPhone F1, etc). I wanted to > > > include support for the POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT > > > property. > > > > > > My understanding is that it exposes the current limit as a cooling > > > device so that userspace (or frameworks like DTPM) can optimise for > > > performance in a thermally constrained device by limiting the input > > > current and thus reducing the heat generated by the charger circuitry, > > > a similar idea was applied on the Pixel C: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4496d52b3430cb3c4c16d03cdd5f4ee97ad1241 > > > > > > However, reading through the sysfs docs for cooling devices, and > > > looking at the implementation in power_supply_core.c, it seems like the > > > behavior here is wrong in a few ways: > > > 1. The values should scale from 0: no cooling to max_state: max > > > cooling, but the power_supply docs and the only existing implementation > > > (the smbb driver) just export the current_limit, such that increasing > > > cur_state would increase the current limit, not decrease it. > > > 2. (unsure?)The scale is completely different to most other cooling > > > devices, most cooling devices don't seem to have a max state much > > > beyond the double digits, but CHARGE_CONTROL_LIMIT is on the scale of > > > uA, so approaches like incrementing the cooling state by 1 don't really > > > work. > > > > Did this get solved somehow? > > Thanks for resurrecting the discussion. > > > Anyway, I am not sure mW will be useful here, as elsewhere it is mW > > thermal and here it is mW from charger. Most of that energy should be > > stored in battery, not converted to heat. > > I'm not sure to understand the comment. The question is about decreasing the > speed of the charge of the battery because the faster it charges the warmer > it gets. Doing a fast charge is ok, if the phone is for instance on a table > doing nothing. But if the environment is hot (a car, a pocket) or there are > other sources of heat on the phone like a game, the temperature of the > battery could be too high (or the skin temperature). In this case we have to > balance the heat contribution of the different components by reducing their > performances. The first knob to act on is to reduce the charge speed of the > battery by reducing the delivered power. Understood. > For that we need a connection between the thermal framework which monitors > the battery temperature and the power supply to reduce the charge speed when > it is too hot. This connection is the cooling device. > > The cooling devices have opaque values where the min and max cooling effect > vary depending on the implementation (eg. a fan 0/1, a LCD light 0/1023). Aha, ok. > Here the power supply has yet another unit (uA) to act on and difficult to > translate to a cooling device discrete numbers (that is my > understanding). Well, if you can accept 1000 steps like you do for LCD, all you really need is maximum current and then stepping in 1/100 of that. > With enough components in DTPM, it will be possible to create a generic > power cooling device using the unified unit uW with the powercap API. I was trying to point out trouble with uW: you don't know them in case of battery charging. You know phone is drawing 500mA @ close to 5V (-> 2.5W), but you don't really know how much is stored in battery, and how much is turned into heat. But I guess you could approximate that somehow. BR, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
