| 00:00:33 | | Quit wodz (Ping timeout: 240 seconds) |
| 00:00:56 | | Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) |
| 00:04:03 | | Quit petur (Quit: Leaving) |
| 00:04:18 | __builtin | user890104: I was hoping to get some way to output PCM through the piezo |
| 00:08:48 | __builtin | probably through pulse-width modulation |
| 00:20:29 | | Quit munch (Quit: Let's blast this shit and get naked) |
| 00:27:58 | | Quit alexweissman (Remote host closed the connection) |
| 00:29:44 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 00:36:08 | saratoga_ | what is the sampling rate you can drive it with? |
| 00:37:30 | | Quit wodz (Quit: Leaving) |
| 00:39:09 | | Join munch [0] (pls@gateway/shell/elitebnc/x-jkouwoqptxopphfn) |
| 00:56:29 | Bilgus | pamaury should I keep running the benchmark with autoslow off from earlier? |
| 00:57:08 | Bilgus | oh he went to bed nm |
| 01:00 |
| 01:06:18 | jhMikeS | This is embarrasing not to be able to answer: Which revision is 3.14 based off? |
| 01:06:39 | Bilgus | All of them? |
| 01:07:03 | * | jhMikeS slaps Bilgus |
| 01:07:40 | jhMikeS | It was branched from something |
| 01:07:52 | Bilgus | I changed that patch to check for else SYS_TIMEOUT it should be good, though is there any plans to ever put back the disk caching code? |
| 01:08:09 | jhMikeS | put back? |
| 01:08:44 | Bilgus | its commented out in the SYS_TIMEOUT routine |
| 01:09:47 | Bilgus | line 1673 /* TODO: This needs to be fixed to use the idle callback, disable it |
| 01:09:47 | Bilgus | * for simplicity until its done right */ |
| 01:10:19 | Bilgus | if thats is never going back the !filling timeout for the queue can probably be upped bu a bit |
| 01:11:54 | jhMikeS | oh, the fill on idle code? |
| 01:12:05 | Bilgus | yep |
| 01:13:36 | jhMikeS | could just remove it since it's probably not going any time soon. it's not like it can't be pulled out of the history if it's really wanted, or perhaps done better after whatever you're fixing. |
| 01:16:23 | Bilgus | i'd just as soon leave it be, it works and I doubt a few less comparisons a second are going to amount to too much |
| 01:19:15 | | Quit krabador (Quit: Leaving) |
| 01:19:45 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 01:19:57 | jhMikeS | it's disabled and probably doesn't quite work correctly |
| 01:20:33 | | Quit saratoga_ (Ping timeout: 260 seconds) |
| 01:20:33 | | Quit _meg (Ping timeout: 240 seconds) |
| 01:21:19 | Bilgus | oh I was saying leaving the timeout there at HZ/2 it checks watermark each time through |
| 01:21:58 | | Quit krabador (Remote host closed the connection) |
| 01:22:05 | jhMikeS | you quoted the TODO: so i thought you were talking about that disabled code |
| 01:23:34 | Bilgus | ah sorry no I was wondering if that would be added back in there if/when it came back |
| 01:24:33 | | Join _meg [0] (~notsure@211.25.203.45) |
| 01:26:43 | Bilgus | I'm pretty sure that code is the reason the !filling timeout is HZ/2 rather than HZ or more |
| 01:28:51 | | Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 01:28:51 | | Quit jhMikeS (Disconnected by services) |
| 01:28:52 | | Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 01:29:00 | jhMikeS | Not really. The watermarks are set in playback so the timeout better be shorter than the margin before the buffer goes empty. |
| 01:32:11 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 01:32:43 | jhMikeS | flash has a 1 second margin +0/-0.5 |
| 01:35:50 | Bilgus | oh see glad I asked |
| 01:37:01 | Bilgus | It seems to me though that this isn't the only place a call to rebuffer happens though so isn't it kinda redundant to have it checking in the thread and recieving calls from the codec? |
| 01:37:29 | Bilgus | or is it just a CYA kinda situation |
| 01:41:01 | jhMikeS | the codec is really concerned with the PCM buffer level more than anything |
| 01:42:22 | | Quit dys (Ping timeout: 248 seconds) |
| 01:44:20 | Bilgus | do you suppose that could cause the condition I was seeing in high demand during AAC-HE? basically if it wasn't boosted before it hit time to rebuffer it would never catch up even dropping calls for cpu_boost |
| 01:44:51 | jhMikeS | the audio thread stays (or is supposed to stay) boosted while adding handles which should keep buffering from getting ahead and unboosting anything just because it doesn't see anything |
| 01:45:17 | Bilgus | yeah that wasn't happening |
| 01:45:17 | __builtin | jhMikeS: 8817467 I think |
| 01:45:33 | jhMikeS | __builtin: 95% confidence interval? |
| 01:46:09 | __builtin | it's a mess actually |
| 01:46:11 | __builtin | lemme check |
| 01:47:09 | jhMikeS | was that before or after eefc7c7? |
| 01:47:59 | __builtin | after |
| 01:48:07 | __builtin | release was 1 May |
| 01:48:32 | *** | Saving seen data "./dancer.seen" |
| 01:48:40 | jhMikeS | hmmm |
| 01:50:55 | __builtin | yeah, it was the few commits around 8817467 |
| 01:51:18 | jhMikeS | Bilgus: was it getting overloaded and the thread not getting into buffer_handle on time (that's the only place where it boosts)? |
| 01:53:24 | jhMikeS | Bilgus: Is AAC HE particularly CPU intensive? |
| 01:53:34 | __builtin | saratoga: (re piezo) timer frequency on the 6G is 12MHz I think |
| 01:56:29 | jhMikeS | Bilgus: the codec could be going high priority and preventing the buffering thread from running if the target has trouble decoding that |
| 01:57:11 | jhMikeS | obviously if it doesn't get scheduled to run, then it can't boost itself |
| 01:57:42 | jhMikeS | then again, codec should be boosting itself too if that's the case |
| 01:58:42 | jhMikeS | maybe put the trigger before the open and lseek calls? |
| 01:59:55 | jhMikeS | it's not like those are lightweigh and don't make a thread block a lot |
| 01:59:58 | | Quit Rondom (Remote host closed the connection) |
| 02:00 |
| 02:00:49 | | Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) |
| 02:04:34 | __builtin | user890104: do you know any details about how the piezo is controlled beyond what's in piezo-6g.c? |
| 02:24:22 | | Quit CH23 (Quit: Page closed) |
| 02:59:41 | | Join deevious_ [0] (~Thunderbi@193.226.142.214) |
| 03:00 |
| 03:00:59 | | Quit deevious (Ping timeout: 240 seconds) |
| 03:00:59 | | Nick deevious_ is now known as deevious (~Thunderbi@193.226.142.214) |
| 03:34:39 | Bilgus | JhmikeS buffer_handle already has a cpu_boost call in it but its essentially ignored according to logging it gets 2 calls for boost and neither does anything |
| 03:35:49 | Bilgus | https://pastebin.com/B47yrQJw |
| 03:37:58 | Bilgus | sorry I have one that shows it better https://pastebin.com/kVhD8iua |
| 03:39:27 | Bilgus | it looses it at line 83. tick: 4493, boost_counter: 84. tick: 4495, boost_counter: 1 |
| 03:39:33 | Bilgus | loses* |
| 03:40:19 | Bilgus | each time boost_counter gets called it should increment or decrement the counter |
| 03:41:31 | Bilgus | and just after that you see count: (data_counters.remaining) go nuts |
| 03:48:34 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:10:16 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-vucnwziupcgmmsmp) |
| 04:27:17 | user890104 | __builtin: i'm afraid not, i only know that it's hardwired to a timer pin (E or F) on nano 2g (maybe 3g too?) |
| 04:37:19 | jhMikeS | Bilgus: how would it be ignored? |
| 04:37:46 | Bilgus | all I can figure is a race condition |
| 04:38:11 | Bilgus | I'm looking at the audio buffer and pcm buffer noww i'll post it shortly |
| 04:40:49 | jhMikeS | was it the same thread that did it in both? 82 looks like it did something |
| 04:44:17 | Bilgus | 82 is just the call to cpu_set freq |
| 04:44:34 | Bilgus | hen it returns it increments boost_count |
| 04:45:21 | jhMikeS | the way you have it logged it should always delta +1/-1, right? |
| 04:45:24 | Bilgus | ah you know what it is it got them out of order |
| 04:45:49 | Bilgus | yeah it either + or - 1 |
| 04:46:02 | Bilgus | but I think I might know whats happening |
| 04:46:17 | Bilgus | its calling for a unboost and a boost within the sma etick |
| 04:46:50 | jhMikeS | hmmm... |
| 04:47:00 | Bilgus | let me get this other log up |
| 04:47:09 | jhMikeS | which target is this? |
| 04:47:40 | jhMikeS | if the function allows reentrancy that's probably bad |
| 04:47:51 | jhMikeS | at least without a mutex |
| 04:48:06 | Bilgus | its the fuze+ |
| 04:49:34 | Bilgus | I see the boost code has if (!cpu_boost_lock()) |
| 04:50:57 | jhMikeS | which does nothing if it's not implemented (not needed on most atm) |
| 04:51:24 | jhMikeS | if set_cpu_frequency yields though, it better be serialized |
| 04:52:06 | Bilgus | yeah no define its always true ill check that next |
| 04:53:32 | Bilgus | no it doesn't have anything to enforce order |
| 04:54:07 | Bilgus | https://github.com/Rockbox/rockbox/blob/c7f897faa4276ade8fb26a3522ff5b3041b4cd56/firmware/target/arm/imx233/system-imx233.c#L319 |
| 04:55:25 | saratoga | what the heck did i do with my fuze+ |
| 04:59:17 | Bilgus | huh weird I didn't get any data in my log file for the file in question :/ |
| 04:59:37 | jhMikeS | imx233_power_set_regulator yields which could let threads pile in there and mess it up |
| 05:00 |
| 05:00:46 | jhMikeS | better implement the boost lock/unlock before moving on |
| 05:01:19 | Bilgus | I'm no low level kinda guy do i just set a mutex at the beginning and release at end? |
| 05:01:38 | Bilgus | or just enable cpu_boost_lock |
| 05:01:45 | Bilgus | well implement |
| 05:03:05 | jhMikeS | see system-as3525.c and its header |
| 05:03:28 | jhMikeS | set_cpu_frequency__lock/__unlock |
| 05:04:10 | Bilgus | k |
| 05:04:28 | jhMikeS | could probably just copy that stuff over |
| 05:10:39 | Bilgus | uh huh lol |
| 05:11:06 | Bilgus | all except for there being lots of targets but ill test it on the fuze= first |
| 05:11:11 | Bilgus | + |
| 05:26:16 | | Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) |
| 05:27:02 | jhMikeS | if they share the same code it's still the right setup |
| 05:27:12 | | Quit Aldem (Ping timeout: 255 seconds) |
| 05:27:15 | Bilgus | it worked |
| 05:27:48 | Bilgus | I have to do some more testing to say for 100% sure but It hasn't done it once in 3 runs |
| 05:28:08 | Bilgus | so priority inversion? |
| 05:28:21 | Bilgus | is that whats thats called? |
| 05:28:33 | jhMikeS | reentrancy but the function isn't reentrant |
| 05:28:42 | Bilgus | lol what that is called |
| 05:29:03 | jhMikeS | priority inversion is when a low priority thread keeps a higher one from executing |
| 05:29:17 | Bilgus | ah see thats what I thought it was |
| 05:29:28 | Bilgus | originally.. |
| 05:29:55 | jhMikeS | in that case, there's a thread yielding but another thread tries to change the frequency before one already doing it is finished |
| 05:30:02 | Bilgus | ok I'll get this all cleaned up spit out one more log and then abandon the other patch |
| 05:30:27 | Bilgus | yeah you have all the buffers and codecs fighting for the same space |
| 05:30:51 | Bilgus | well the same function |
| 05:31:11 | jhMikeS | so, a race condition is basically it |
| 05:33:22 | Bilgus | well thank you very much mike I learned something and you lead me to the real issue |
| 05:41:59 | | Quit almog1006 (Quit: Page closed) |
| 05:44:45 | jhMikeS | Bilgus: you're welcome. you said "race condition" early on which made me check the possibility. |
| 05:48:36 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:08:01 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 06:09:11 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:25:39 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 06:25:54 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 06:45:53 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 06:48:54 | Bilgus | Hey saratoga I just ran the test_codec after implementing cpu_boost_lock and there is now little to no difference on the decode speeds between with auto_slow and without it |
| 06:57:24 | | Quit alexweissman (Remote host closed the connection) |
| 06:57:59 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 06:59:45 | | Quit alexweissman (Remote host closed the connection) |
| 07:00 |
| 07:00:00 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 07:02:15 | Bilgus | no nevermind : |
| 07:14:25 | Bilgus | fuze+ NO auto slow boosted 095.87s 183.61% 247.66Mhz |
| 07:14:25 | Bilgus | boosted 148.49s 118.54% 383.61MHz |
| 07:14:25 | Bilgus | fuze+ No auto slow no boost 416.36s 042.27% 151.40Mhz |
| 07:14:25 | Bilgus | NO boost 568.89s 030.94% 206.85MHZ |
| 07:19:38 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 07:30:36 | | Quit alexweissman (Remote host closed the connection) |
| 07:48:38 | *** | Saving seen data "./dancer.seen" |
| 07:57:44 | Bilgus | pamaury when you get a chance can you look at http://gerrit.rockbox.org/r/#/c/1699/ and make sure I implemented it properly specifically mutex_init() |
| 08:00 |
| 08:11:34 | | Quit _meg (Ping timeout: 240 seconds) |
| 08:13:13 | | Join _meg [0] (~notsure@211.25.203.45) |
| 08:26:01 | | Quit deevious (Ping timeout: 260 seconds) |
| 08:46:54 | | Quit duo8 (Ping timeout: 248 seconds) |
| 08:47:35 | | Join almog1006 [0] (4d8bf186@gateway/web/freenode/ip.77.139.241.134) |
| 08:54:38 | | Quit sielicki (Read error: Connection reset by peer) |
| 08:55:31 | | Join sielicki [0] (~sielicki@unaffiliated/n1cky) |
| 09:00 |
| 09:03:16 | | Join deevious [0] (~Thunderbi@193.226.142.214) |
| 09:06:38 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 09:25:09 | | Quit mapache_ (Quit: Lost terminal) |
| 09:48:39 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:08:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:11:02 | almog1006 | pamaury: Hi.. Thank you very much! I'm done translating the entire firmware |
| 10:12:42 | | Quit TheEaterOfSouls (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) |
| 10:13:28 | | Join MrZeus [0] (~MrZeus@81.144.218.162) |
| 10:15:55 | pamaury | almog1006: I haven't made progress on repackin |
| 10:17:36 | pamaury | Bilgus: I see, indeed I thought the boost code was locking already, and my code is not reentrant |
| 10:17:45 | pamaury | did that solve the problem? The code looks good to me |
| 10:24:11 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 10:28:30 | almog1006 | pamaury: However thank you very much for your unpacking tools:) |
| 10:28:35 | almog1006 | Do you have an estimate when you write the repacking codes? |
| 10:29:04 | | Join PimpiN8 [0] (~textual@145.132.155.235) |
| 10:29:43 | wodz | pamaury: Have you got my email? |
| 10:30:33 | pamaury | wodz: yes thanks |
| 10:30:46 | wodz | great |
| 10:31:01 | pamaury | almog1006: no, I lost my reverse engineering work on the |
| 10:31:15 | pamaury | code from which I got the unpacker code |
| 10:31:24 | wodz | I have version 5.20 somewhere as well if you are interested. |
| 10:31:38 | pamaury | and there is something wrong with it I think, I will need to re-disassemble it |
| 10:33:00 | wodz | pamaury: any progress with amsv2 rom? |
| 10:33:18 | pamaury | wodz: a bit, but the code is so intricate I only mke baby steps at a time |
| 10:34:00 | almog1006 | pamaury: Does that mean I'm in a big problem? |
| 10:34:07 | | Join dys [0] (~dys@x5f71e881.dyn.telefonica.de) |
| 10:34:51 | wodz | almog1006: That means you need to stimulate pamaury's motivation |
| 10:37:08 | almog1006 | My luck is that he needs it anyway for Rockbox |
| 10:40:11 | wodz | almog1006: Not he. I need this tool for my work on atj213x |
| 10:42:09 | almog1006 | So we're in the same boat |
| 10:43:40 | wodz | almog1006: The difference is that I have tons of other work before I'll need repacking working. |
| 10:51:26 | | Quit pamaury (Ping timeout: 240 seconds) |
| 11:00 |
| 11:30:34 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 11:48:40 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:15:01 | | Join CH23 [0] (4dfa0218@gateway/web/freenode/ip.77.250.2.24) |
| 13:16:52 | CH23 | I have in my hands a sandisk cruzer blade 8gb with a NAND chip SDTNPNAHEM-008 |
| 13:18:04 | CH23 | homerun on first try |
| 13:23:53 | | Join smoke_fumus [0] (~smoke_fum@37.151.179.94) |
| 13:25:12 | CH23 | I also have a Sandisk cruzer Edge with same NAND |
| 13:28:48 | CH23 | and finally Sandisk Cruzer Micro with SDTNMNAHSM-004G |
| 13:33:53 | CH23 | man_in_shack: do you know how long it usually takes for something to ship from your location to mine> |
| 13:36:38 | wodz | CH23: Are you going to transplant nand chip from pendrive into clip/clip+/zip ? |
| 13:36:50 | CH23 | clip+ indeed |
| 13:37:10 | wodz | CH23: might be interesting to decap broken nand chip |
| 13:38:13 | CH23 | how would i do that |
| 13:41:37 | wodz | CH23: Its 'a bit' involved process http://zacsblog.aperturelabs.com/2013/02/decapping-integrated-circuits-using.html |
| 13:43:04 | CH23 | how about i mail it to you instead :P |
| 13:43:59 | wodz | CH23: Currently I have no longer access to lab currently :/ |
| 13:44:31 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:45:06 | CH23 | i'm doing all of this on a 9 year old laptop, and soldering stuff for stained glass soldering lol |
| 13:48:44 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:02:22 | CH23 | the cruzer blade has sandisk files on it dated 24th of august 2011, so this NAND was still used recently. |
| 14:05:13 | CH23 | cruzer edge is exactly the same |
| 14:24:49 | | Quit mmint (Ping timeout: 258 seconds) |
| 14:28:33 | | Join mmint [0] (~mmint@unaffiliated/mmint) |
| 14:35:10 | | Quit jhMikeS (Ping timeout: 248 seconds) |
| 14:36:55 | man_in_shack | CH23: no, but i haven't sent it yet. will send on monday. is friday 11:30pm here now |
| 14:45:50 | Bilgus | Pamaury it seems to have fixed the problem although I did get a hang at some point in testing but that could just be total coincidence as I couldn't reproduce again after. |
| 14:56:16 | Bilgus | Also FWIW the boost code is locking as far as boost_count only boosts on ++0 and unboosts on −−1 where as AFAICT the mutex holds the states per thread and doesn't let other threads unboost |
| 14:57:19 | Bilgus | so It might be more like the codec/buffer/audio code is really the issue and it needs to be reworked |
| 14:57:59 | Bilgus | but maybe we just need to implement boost lock across the code |
| 15:00 |
| 15:00:56 | | Quit man_in_shack (Ping timeout: 260 seconds) |
| 15:05:36 | Bilgus | I Imagine its still the case that under high load the other devices would probably exhibit the same behaviour |
| 15:08:24 | Bilgus | maybe it would be a better idea to force inline cpu_boost and have it carry a static bool |
| 15:24:45 | Bilgus | huh trigger_cpu_boost is already doing that ??? |
| 15:24:56 | | Quit wodz (Ping timeout: 264 seconds) |
| 15:26:54 | | Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
| 15:29:58 | | Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:e4d3:4538:2553:fd81) |
| 15:34:02 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 15:44:29 | pamaury | Bilgus: I'm not sure I'm following you |
| 15:45:04 | Bilgus | trigger_cpu_boost works on a per thread basis |
| 15:45:55 | pamaury | Bilgus: yes but the locking is done at the global level |
| 15:46:05 | Bilgus | but there are several places where cpu_boost is used in the codebase now its ok when it does a boost ##SOME ACTION## unboost |
| 15:46:33 | Bilgus | but for instance in the backlight fading code it has several calls to unboost |
| 15:47:09 | pamaury | basically at the thread level, you can't nest calls to {trigger,cance}_cpu_boost, the boosting is just a boolean. But then it calls cpu_boost which is global and counts boost/unboost calls and does the locking |
| 15:47:19 | Bilgus | I'm pretty sure it should only be taking one patch from boost to unboost but if it didn't then it would cause the same problem |
| 15:47:40 | Bilgus | sure when you actually use trigger_cpu_boost |
| 15:48:03 | Bilgus | but if you call cpu_boost directly there is no guarantee.. |
| 15:48:13 | pamaury | you can call cpu_boost directly, it still does the locking and the counting |
| 15:48:13 | | Quit petur (Remote host closed the connection) |
| 15:48:22 | Bilgus | no |
| 15:48:34 | pamaury | just look at the code, system.c |
| 15:48:37 | Bilgus | it does count but not lock |
| 15:48:46 | *** | Saving seen data "./dancer.seen" |
| 15:48:59 | pamaury | it does, locking is not done in thread.c, it's done in system.c |
| 15:49:15 | Bilgus | in as far as count+ or count- but it doesn't protect the code that has called trigger_cpu_boost |
| 15:49:30 | pamaury | protect from what? |
| 15:50:13 | Bilgus | ok ill give you a for instance |
| 15:51:13 | Bilgus | I'm in thread foo I call trigger_cpu_boost(true) ok boost_count+=1 ..BC now == 1 |
| 15:51:44 | Bilgus | i'm in thread BAR and I call cpu_boost ok BC ==2 |
| 15:52:18 | Bilgus | now I call cpu_boost(false) BC = 1 |
| 15:52:29 | Bilgus | I call it again BC == 0 |
| 15:52:42 | Bilgus | i go back to thread foo oh wait no cpu boost |
| 15:54:03 | Bilgus | now look at https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/backlight.c |
| 15:54:46 | pamaury | Bilgus: but that's broken code you are describing. If you call cpu_boost, you must call cpu_unboost. and if you call trigger_cpu_boost then you must call cancel_cpu_boost. |
| 15:55:04 | pamaury | I'm just pointing out that cpu_boost and trigger_cpu_boost are not the same, they do not do the same thing |
| 15:56:08 | Bilgus | well they do the same thing as in they both call cpu_boost and ++ or −− the counter |
| 15:56:35 | pamaury | no |
| 15:56:54 | pamaury | as I explained before, trigger_cpu_boost tracks per thread with a boolean |
| 15:57:17 | Bilgus | https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/firmware/kernel/thread.c#L1501 |
| 15:57:25 | pamaury | so if a thread does: |
| 15:57:25 | pamaury | trigger_cpu_boost -> BC=1 |
| 15:57:25 | pamaury | trigger_cpu_boost -> BC=1 (because thread was already boosting, it's ignored) |
| 15:57:25 | DBUG | Enqueued KICK pamaury |
| 15:57:25 | pamaury | cancel_cpu_boost -> BC=0 |
| 15:58:25 | pamaury | trigger_cpu_boost is per-thread and means "this thread needs to boost now" whereas cancel_cpu_boost means "this thread doesn't need to boost now" |
| 15:58:46 | Bilgus | sure but if you are boosted with trigger and I call cpu_boot(false) 2x you are no longer boosted |
| 15:59:00 | Bilgus | cpu_boost** |
| 15:59:12 | pamaury | yeah but you don't want to do that, that's the whole point |
| 15:59:23 | Bilgus | I know look at backlight.c |
| 15:59:47 | pamaury | I don't see a problem, backlight.c first calls cpu_boost(true) then cpu_boost(false). backlight is not per-thread |
| 15:59:51 | Bilgus | and search for cpu_boost |
| 16:00 |
| 16:00:12 | Bilgus | how many times can cpu_boost(flase) be called? |
| 16:00:16 | Bilgus | false |
| 16:01:02 | pamaury | counting the occurrences with grep is just wrong, you may have two code paths that call cpu_boost(false) and which are mutually exclusive |
| 16:01:15 | Bilgus | sur elook at the code though |
| 16:02:05 | pamaury | and? |
| 16:02:57 | pamaury | if you see a bug in backlight then fix it, I don't know enough about backlight.c to spot a bug |
| 16:04:33 | Bilgus | ok |
| 16:05:09 | pamaury | cpu_boost(true) is called when the timer is set. when the timer expies, cpu_boost(false) is called. The other cpu_boost(false) is called on BACKLIGHT_FADE_FINISH but when BACKLIGHT_FADE_FINISH is sent, the timer is unregistered |
| 16:05:17 | pamaury | thus there is no way cpu_boost(false) can be called twice imo |
| 16:05:43 | pamaury | at least no obvious way |
| 16:09:49 | Bilgus | well its the first that caught my eye esp since the fuze has backlight fading |
| 16:10:29 | Bilgus | the other is audio_path.c which doesn't apply atm and tag cache thats just a mess |
| 16:11:51 | | Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 16:12:43 | pamaury | I mean even if there was a problem with it, that could not cause a hang though, the boost counter would simply be wrong |
| 16:14:02 | Bilgus | which when you are trying to boost to decode a file would not be the best? |
| 16:16:41 | pamaury | yeah but have you encountered this bug? (after fixing locking) |
| 16:19:49 | Bilgus | no |
| 16:20:08 | Bilgus | but I just don't see how that could actually be it |
| 16:20:44 | Bilgus | I think it is just covering up (making impossible) the real problem |
| 16:20:48 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 16:21:20 | Bilgus | but if thats true then every device actually needs locking |
| 16:21:47 | Bilgus | and no the backlight one didn't do it |
| 16:25:00 | pamaury | Bilgus: the locking is done in cpu_boost, I don't see how backlight has anything to do with locking |
| 16:25:19 | pamaury | locking needs to be done when set_cpu_frequency is not reentrant |
| 16:25:28 | pamaury | imx233's code was not reentrant |
| 16:26:19 | | Join amayer [0] (~amayer@24.152.198.8.res-cmts.eph2.ptd.net) |
| 16:28:43 | Bilgus | well I'm sure you know more than I do but I just don't see how that could actually come into effect with trigger_cpu_boost working the way it does? |
| 16:29:45 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 16:46:13 | | Quit almog1006 (Quit: Page closed) |
| 16:54:15 | Bilgus | Ok I get it I had to think about it for awhile but I think I grasp what you mean |
| 16:56:53 | | Quit krabador (Remote host closed the connection) |
| 16:59:56 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-pobfgbgrzasazfzw) |
| 17:00 |
| 17:28:04 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 17:46:18 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:48:50 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:06:23 | | Quit pamaury (Ping timeout: 248 seconds) |
| 18:18:26 | | Quit krabador (Ping timeout: 240 seconds) |
| 18:34:47 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 18:41:56 | | Quit sparetire (Ping timeout: 240 seconds) |
| 18:44:52 | | Join sparetire [0] (~sparetire@unaffiliated/sparetire) |
| 19:00 |
| 19:15:46 | | Join detectiveaoi [0] (~detective@130.218.12.236) |
| 19:16:14 | | Quit detectiveaoi (Remote host closed the connection) |
| 19:18:59 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 19:38:54 | | Quit michaelni (Read error: Connection reset by peer) |
| 19:42:33 | | Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) |
| 19:48:54 | *** | Saving seen data "./dancer.seen" |
| 19:55:28 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 20:00 |
| 20:05:26 | | Quit dys (Ping timeout: 240 seconds) |
| 20:12:24 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 20:13:53 | | Join dys [0] (~dys@x5f71d060.dyn.telefonica.de) |
| 20:28:33 | | Quit dys (Ping timeout: 255 seconds) |
| 20:42:49 | | Quit bzed (Remote host closed the connection) |
| 20:43:04 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 20:51:38 | | Join p3tur [0] (~petur@78-23-23-252.access.telenet.be) |
| 20:51:38 | | Quit p3tur (Changing host) |
| 20:51:38 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 20:56:55 | | Join dys [0] (~dys@x5f72797e.dyn.telefonica.de) |
| 21:00 |
| 21:48:57 | *** | Saving seen data "./dancer.seen" |
| 22:00 |
| 22:20:57 | | Quit krabador (Quit: Leaving) |
| 22:36:23 | __builtin | user890104: ok, thanks! |
| 22:36:32 | __builtin | it's timer A on the 6G, it seems |
| 22:38:20 | __builtin | I think I should be able to control it directly, though |
| 22:39:10 | __builtin | the pin is P0_0, which supports GPIO |
| 22:39:30 | | Quit amayer (Quit: Leaving) |
| 22:41:44 | __builtin | this datasheet is nice :) |
| 23:00 |
| 23:02:09 | | Quit The_Prospector (Quit: when in doubt, kernel panic) |
| 23:05:12 | | Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) |
| 23:13:28 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 23:21:38 | __builtin | ah, figured it out |
| 23:48:58 | *** | Saving seen data "./dancer.seen" |
| 23:58:34 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) |
icon identifies that the person is a core developer (has commit access).