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

raspberrypi: Make port_idle_until_interrupt work #7201

Merged
merged 2 commits into from
Nov 15, 2022

Conversation

jepler
Copy link
Member

@jepler jepler commented Nov 12, 2022

This needs thorough testing before it's merged, as we tried and reverted this once before (#5341 and #5356).

I think that besides checking for tinyusb having "something to do", the fact that port_interrupt_after_ticks and port_disable_tick weren't implemented that was causing a secondary problem.

I've tested this on a pico w over reboot-cycles and ctrl-c-cycles, with and without drive automounting, with and without serial repl open, and on a power-only connection.

I didn't notice the problem reported in #5356 after merely implementing port_idle_until_interrupt; but I did notice that sleeps in general would take over-long until "something" (like writing to the USB drive) happened; I think "something" was probably calling port_enable_tick(). When this problem was happening, sleeps would take a lot longer; for instance, sleep(.001) would take about 1/20s and sleep(.1) would take about 1/7s.

Closes: #5331

This needs thorough testing before it's merged, as we tried
and reverted this once before (adafruit#5341 and adafruit#5356).

I think that besides checking for tinyusb having "something to do",
the fact that `port_interrupt_after_ticks` and `port_disable_tick`
weren't implemented that was causing a secondary problem.

I've tested this on a pico w over reboot-cycles and ctrl-c-cycles,
with and without drive automounting, with and without serial repl open,
and on a power-only connection.

I didn't notice the problem reported in adafruit#5356 after merely implementing
port_idle_until_interrupt; but I did notice that sleeps in general would
take over-long until "something" (like writing to the USB drive) happened;
I think "something" was probably calling port_enable_tick(). When this
problem was happening, sleeps would take a lot longer; for instance,
`sleep(.001)` would take about 1/20s and `sleep(.1)` would take about 1/7s.
@jepler jepler marked this pull request as ready for review November 12, 2022 15:19
@jepler
Copy link
Member Author

jepler commented Nov 12, 2022

@Neradoc @microdev1 @urish if any of you have time & interest in testing out this branch it would be helpful!

@urish
Copy link

urish commented Nov 15, 2022

What kind of help do you need w/testing?

@jepler
Copy link
Member Author

jepler commented Nov 15, 2022

Just general testing, as the earlier occasion when we tried to enable WFI for light sleeping problems cropped up that the original submitter didn't find right away. I tried to test a number of scenarios that would "cover" normal usage but one always misses something...

@tannewt
Copy link
Member

tannewt commented Nov 15, 2022

This looks fine to me. I'm happy to test in main. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement CPU sleep (WFI) when idle on RP2040
3 participants