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. :)
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.
--
Sampsa
On 12/21/20 12:53 AM, Michael Mrozek wrote:
> 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:
>>>
>>> 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
>>>>
>>>
>> _______________________________________________
>> Kernel mailing list
>> Kernel@pyra-handheld.com
>>
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
>