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
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:
1. 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.
2. 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
Hello Michael and Nikolaus!
First, thanks for all the hard work for Pyra and for other cool projects!
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
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
Hello everyone again!
Thanks for the idea :)
You are welcome!
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. :)
Okay, great to hear that there is already a way to catch the changes :>
Can I inquire a bit further? Are you using the -p or --property flag? For example: `sudo udevadm monitor --property` That seems to give a lot of additional info about the events, at least on my machine. But even with that it seems that not all initiators of events are obvious.
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.
For the daemon part, I would try the inotify to catch the change as it happens and then setup the script as a systemd-daemon so it starts / stays up. If inotify does not work, then maybe polling + sleeping could work?
And I agree, this should be solved by changing the event source, not hotfixing(...). I hope the real source is found so that can be done.
Thank you and good luck!
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
On Mo, 2020-12-21 at 09:33 +0100, H. Nikolaus Schaller wrote:
That directory doesn't exist on my system:
root@evild-pyra:/sys/kernel/debug/regmap# ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0008 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0048 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0049 drwxr-xr-x 2 root root 0 Jan 1 1970 0-004a drwxr-xr-x 2 root root 0 Jan 1 1970 0-004b drwxr-xr-x 2 root root 0 Dec 21 20:59 1-004f drwxr-xr-x 2 root root 0 Jan 1 1970 2-0029 drwxr-xr-x 2 root root 0 Jan 1 1970 2-0076 drwxr-xr-x 2 root root 0 Jan 1 1970 3-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0022 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-omap5_padconf_global@5a0 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-scm_conf@0
Could it be that it has a different name / ID
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
Do you have this path instead, which should be the same thing?
/sys/class/power_supply/bq24297/device/registers
(my Pyra is on a 5.10 kernel atm so it might not be identical, but iirc this path existed on 5.6 too)
On Mon, 2020-12-21 at 21:03 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 09:33 +0100, H. Nikolaus Schaller wrote:
That directory doesn't exist on my system:
root@evild-pyra:/sys/kernel/debug/regmap# ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0008 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0048 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0049 drwxr-xr-x 2 root root 0 Jan 1 1970 0-004a drwxr-xr-x 2 root root 0 Jan 1 1970 0-004b drwxr-xr-x 2 root root 0 Dec 21 20:59 1-004f drwxr-xr-x 2 root root 0 Jan 1 1970 2-0029 drwxr-xr-x 2 root root 0 Jan 1 1970 2-0076 drwxr-xr-x 2 root root 0 Jan 1 1970 3-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0022 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-omap5_padconf_global@5a0 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-scm_conf@0
Could it be that it has a different name / ID
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
On Mo, 2020-12-21 at 20:22 +0000, David Shah wrote:
Yes, and the result is 9c, so this is indeed what's resetting the value!
So it seems it's not disabled in the U-Boot version we're using.
Could someone update that? Thanks :D
Do you have this path instead, which should be the same thing?
/sys/class/power_supply/bq24297/device/registers
(my Pyra is on a 5.10 kernel atm so it might not be identical, but iirc this path existed on 5.6 too)
On Mon, 2020-12-21 at 21:03 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 09:33 +0100, H. Nikolaus Schaller wrote:
That directory doesn't exist on my system:
root@evild-pyra:/sys/kernel/debug/regmap# ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0008 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0048 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0049 drwxr-xr-x 2 root root 0 Jan 1 1970 0-004a drwxr-xr-x 2 root root 0 Jan 1 1970 0-004b drwxr-xr-x 2 root root 0 Dec 21 20:59 1-004f drwxr-xr-x 2 root root 0 Jan 1 1970 2-0029 drwxr-xr-x 2 root root 0 Jan 1 1970 2-0076 drwxr-xr-x 2 root root 0 Jan 1 1970 3-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0022 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-omap5_padconf_global@5a0 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-scm_conf@0
Could it be that it has a different name / ID
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Looks like the latest pyra u-boot implements this correctly:
https://dev.pyra-handheld.com/kernel/pyra-uboot/-/blob/pyra/board/dragonbox/...
Either the images need to be updated; or for some reason the watchdog gets enabled again after U-boot runs.
Best
David
On Mon, 2020-12-21 at 21:57 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 20:22 +0000, David Shah wrote:
Yes, and the result is 9c, so this is indeed what's resetting the value!
So it seems it's not disabled in the U-Boot version we're using.
Could someone update that? Thanks :D
Do you have this path instead, which should be the same thing?
/sys/class/power_supply/bq24297/device/registers
(my Pyra is on a 5.10 kernel atm so it might not be identical, but iirc this path existed on 5.6 too)
On Mon, 2020-12-21 at 21:03 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 09:33 +0100, H. Nikolaus Schaller wrote:
That directory doesn't exist on my system:
root@evild-pyra:/sys/kernel/debug/regmap# ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0008 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0048 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0049 drwxr-xr-x 2 root root 0 Jan 1 1970 0-004a drwxr-xr-x 2 root root 0 Jan 1 1970 0-004b drwxr-xr-x 2 root root 0 Dec 21 20:59 1-004f drwxr-xr-x 2 root root 0 Jan 1 1970 2-0029 drwxr-xr-x 2 root root 0 Jan 1 1970 2-0076 drwxr-xr-x 2 root root 0 Jan 1 1970 3-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0022 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-omap5_padconf_global@5a0 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-scm_conf@0
Could it be that it has a different name / ID
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am Montag, dem 21.12.2020 um 21:00 +0000 schrieb David Shah:
aTc tried to compile the latest version, but that doesn't even boot - so it seems to be in a half-finished state.
Looks like the latest pyra u-boot implements this correctly:
https://dev.pyra-handheld.com/kernel/pyra-uboot/-/blob/pyra/board/dragonbox/...
Either the images need to be updated; or for some reason the watchdog gets enabled again after U-boot runs.
Best
David
On Mon, 2020-12-21 at 21:57 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 20:22 +0000, David Shah wrote:
Yes, and the result is 9c, so this is indeed what's resetting the value!
So it seems it's not disabled in the U-Boot version we're using.
Could someone update that? Thanks :D
Do you have this path instead, which should be the same thing?
/sys/class/power_supply/bq24297/device/registers
(my Pyra is on a 5.10 kernel atm so it might not be identical, but iirc this path existed on 5.6 too)
On Mon, 2020-12-21 at 21:03 +0100, Michael Mrozek wrote:
On Mo, 2020-12-21 at 09:33 +0100, H. Nikolaus Schaller wrote:
That directory doesn't exist on my system:
root@evild-pyra:/sys/kernel/debug/regmap# ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0008 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0048 drwxr-xr-x 2 root root 0 Jan 1 1970 0-0049 drwxr-xr-x 2 root root 0 Jan 1 1970 0-004a drwxr-xr-x 2 root root 0 Jan 1 1970 0-004b drwxr-xr-x 2 root root 0 Dec 21 20:59 1-004f drwxr-xr-x 2 root root 0 Jan 1 1970 2-0029 drwxr-xr-x 2 root root 0 Jan 1 1970 2-0076 drwxr-xr-x 2 root root 0 Jan 1 1970 3-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0022 drwxr-xr-x 2 root root 0 Jan 1 1970 4-0064 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-omap5_padconf_global@5a0 drwxr-xr-x 2 root root 0 Jan 1 1970 dummy-scm_conf@0
Could it be that it has a different name / ID
Am 20.12.2020 um 21:54 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
So we need to find out what causes that reset. Is it the driver? What else could it be?
It could be the watchdog inside the bq24297. If that one expires it resets the chip and starts redetection of the power supply.
But I think we disable it in u-boot and the kernel driver.
Please check with
root@letux:~# fgrep 5: /sys/kernel/debug/regmap/1-006b/registers 5: 8a root@letux:~#
If you see 9x, ax, bx the watchdog timer is enabled for 40, 80, 120 seconds.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel