On Mo, 2020-12-21 at 00:48 +0200, Sampsa Laapotti wrote:
Hi,
Thanks for the idea :) I can already check when that happens using udevadm monitor, as it's being logged via udev.. but that doesn't really help to find out WHY that happen. :)
The script I'm working on (for thermal management) is currently being called via crontab once a minute (unless someone knows a better way to implement that stuff), so it changes the value back to what we need it to be... but that's still something that shouldn't happen, so I'd like to find the culprit in the long run.
I was thinking about how could this kind of issue be quickpatched or debugged in GNU/Linux, specifically I a was wondering if the change of the /dev/usb_max_current could be caught with inotify-event?
This would work by running for example inotifywait (https://linux.die.net/man/1/inotifywait) and catching the modify -event. eg:
# From link above, edited a bit #!/bin/sh while inotifywait -e modify /dev/usb_max_current; do echo "max current got changed!" cat /dev/usb_max_current done
This should fire when the file gets modified. That should at least help a bit to locate when changes happen.
It might also be possible to use it to quickpatch the issue. Eg. just change the value to '2000000' when it is being modified and the value being set is not '2000000'.
My 2 cents, I hope I did not intrude or disturb.
ps. I might be completely wrong about this, depending on how the /dev/usb_max_current is setup, as according to wikipedia(https://en.wikipedia.org/wiki/Inotify), sysfs and procfs don't support inotify events for all files. But might still be worth trying.
Happy holidays and have an awesome Solstice!
Sampsa Laapotti
On 12/20/20 10:54 PM, Michael Mrozek wrote:
On Mi, 2020-11-18 at 11:43 +0100, H. Nikolaus Schaller wrote:
Hi,
I'd like to pick this up again. I will start to ship Pyras to end customers this week, so it would be nice if we could at least get charging to work to some degree.
As mentioned in the other message, I'm working on the temperature- limit script that should prevent the system and battery to overheat.
I'm running into a few issues here though, which might be connected to the charging driver.
Here's what's happening:
- The USB OTG port successfully recognizes the connected power
supply and sets the limit accordingly. On my power supply, the limit (linked to /dev/usb_max_current) is being set to 3000000 (3A). On aTcs power supply, it's being set to 2000000 (2A). So far so good.
- The USB FTDI port is always being set to 500000 (500mA), as it
can't recognize the charger. Increasing /dev/usb_max_current manually works and you can charge at a faster rate.
However, here's the issue: Something resets that limit regularly. So if I want to limit the 3A input to 1A, it works - but 30 - 60 seconds later, there's a KERNEL UDEV event reported - and it's back to 3A.
It's the same for the USB FTDI port as well. I can increase the limit - but it's being reset.
The problem is: Charging the battery with 3A causes it to heat up really fast - so it stops charging after a few minutes until the battery has cooled off again. With 2A, this doesn't seem to happen (tested on aTcs unit), but I can't limit it to 2A.
So we need to find out what causes that reset. Is it the driver? What else could it be?
Does that happen on Letux OS as well? Or only on our OS?
Thanks for your help :)
Hi Nick, please reply to all.
Am 17.11.2020 um 21:41 schrieb Nick Elsmore < nicholaselsmore@gmail.com>:
If I remember correctly the driver only starts charging if USB becomes plugged in but not if it *is* plugged in.
But what happens if USB remains plugged in and the charger stops charging after the battery is fully charged.
Or what happens if USB is already connected while boot? Is this detected as a "plug in" event?
I think there is no code that looks and decides when to trigger charging a second or third time to keep the battery full (which may drain during operation).
Can someone review the code for this?
I don't understand why we need to use the watchdog timer on the charger. The hardware state machine in the charger can handle all that is required to safely charge the battery without runtime interaction from the host CPU.
That is what I assumed the past years until the Pyra prototype convinced me of the opposite.
The host should just configure the required settings at startup and leave the thing alone. In this case, the watchdog should simply be disabled. I have read some drivers for similar charger chips which behave this way as well.
Yes, that is how we do it.
However, one feature of the bq24 I am not particularly familiar with is the OTG support, perhaps this affects this behavior (I need to read up more on how this works in the bq24).
OTG wasn't used or enabled and involved in my tests so it is unlikely to be a factor. It does not automatically enable and can be enabled only if the battery is not charging and not too cold/hot.
If the driver is not trying to handle the USB detection and control the bq24 manually, the bq24 will properly detect a valid supply on VBUS and enter the appropriate charge mode (precharge, fast, termination) depending on the battery voltage.
Maybe exactly this is the problem. It may choose an input current limit based on the USB charger detection protocol which is too low to run the Pyra and charge in parallel. For example 500mA. Then, the battery must drain...
So to increase the input current limit to a non-standard value the host must detect USB events and increase input_current_limit.
I see no reason to duplicate behavior which already exists in hardware.
IMHO we need more behaviour than already exists in hardware because the OMAP draws so much energy. Or am I wrong?
In fact, I think this is the cause for a lot of the existing issues in the driver.
So what would be your hypothesis of the bq24297 being in a state where you have to remove the battery for a moment before it automatically starts charging again?
BR and thanks, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel