| 00:09:35 | | Join TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls) |
| 00:31:02 | fs-bluebot_ | Build Server message: New build round started. Revision 5e335f5, 280 builds, 7 clients. |
| 00:37:51 | *** | Saving seen data "./dancer.seen" |
| 00:45:03 | fs-bluebot_ | Build Server message: Build round completed after 842 seconds. |
| 00:45:05 | fs-bluebot_ | Build Server message: Revision 5e335f5 result: All green |
| 00:45:06 | fs-bluebot_ | Build Server message: New build round started. Revision 31a1a29, 280 builds, 7 clients. |
| 00:59:36 | fs-bluebot_ | Build Server message: Build round completed after 872 seconds. |
| 00:59:37 | fs-bluebot_ | Build Server message: Revision 31a1a29 result: All green |
| 01:00 |
| 01:01:35 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 01:02:17 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 02:00 |
| 02:37:53 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:10:12 | | Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de) |
| 03:18:43 | johnb2 | speachy : firmware/export/jz4740-codec.h -> The build (without any config.cfg) comes up with headphone volume @ 0dB. Can you please set this to a safe value like -25 or -30? |
| 03:21:01 | johnb2 | I just tested 31a1a29004: As soon as GUI BOOST kicks in, the crackling is back during mp3 playback |
| 03:24:30 | johnb2 | Volume, make it -30, please. |
| 04:00 |
| 04:37:54 | *** | No seen item changed, no save performed. |
| 05:00 |
| 05:09:06 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 06:00 |
| 06:27:51 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:37:57 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:35:30 | | Join lebellium [0] (~lebellium@aaubervilliers-653-1-153-110.w86-218.abo.wanadoo.fr) |
| 07:36:13 | | Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 07:42:45 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 07:45:17 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 07:48:23 | | Join MrZeus [0] (~MrZeus@05467834.skybroadband.com) |
| 08:00 |
| 08:19:32 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f8e7:d463:5890:b863) |
| 08:35:57 | | Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 08:37:59 | *** | Saving seen data "./dancer.seen" |
| 08:42:04 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 08:52:06 | fs-bluebot_ | Build Server message: New build round started. Revision 6296b22, 280 builds, 8 clients. |
| 08:53:51 | speachy | johnb2, the good news is that I think I'm able to recreate the "crackle" problem −− but the bad news is that I believe the underlying issue has nothing to do with CPU clocking. |
| 08:54:55 | speachy | default volume lowered, in this build. |
| 08:55:38 | __Bilgus | any thing change with cube and fire in your clocking tests? |
| 08:56:44 | speachy | I might have fixed those crashes −− or at least I was unable to make cube crash after more than a minute (as opposed to seconds prior) |
| 08:57:11 | speachy | BUT with those fixes audio artifacts are (nearly always) there |
| 08:58:12 | speachy | g#2709 |
| 08:58:13 | fs-bluebot_ | Gerrit review #2709 at http://gerrit.rockbox.org/r/2709 : mips: Heavily rework caching (WIP) by Solomon Peachy |
| 08:58:24 | __Bilgus | he said only mp3 exhibited the behavior so perhaps there is something about init |
| 08:58:59 | speachy | mp3 only makes no sense to me, unless it's purely a matter of relative system load. |
| 08:59:59 | __Bilgus | quite possible , if 2709 is more stable then it probably makes sense to work on the artifacts |
| 09:00 |
| 09:04:11 | speachy | I was going to disable the asm memcpy/memset next. |
| 09:04:57 | speachy | (the glitching I was hearing was clearly bad data in an audio buffer...) |
| 09:05:19 | fs-bluebot_ | Build Server message: Build round completed after 793 seconds. |
| 09:05:20 | fs-bluebot_ | Build Server message: Revision 6296b22 result: All green |
| 09:06:25 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 09:06:51 | __Bilgus | speachy I get some hanging running test_mem it almost acts like the audio buffer has the same or lower priority |
| 09:09:01 | speachy | that may very well be. I haven't looked at the DMA priority settings yet. |
| 09:09:26 | speachy | but the audio is only single-buffered too, which I find quite odd |
| 09:10:38 | speachy | it only seems to affect audio |
| 09:10:50 | speachy | (corruption I mean) |
| 09:11:06 | speachy | so it might be that there's been an audio problem here all along but it's been masked by other stuff |
| 09:14:48 | speachy | the caching stuff only affects DMA transfers (plus rolo and early boot where we want to drop everything) |
| 09:17:47 | | Quit sakax (Quit: Leaving) |
| 09:20:31 | speachy | I think this new cache code is buggy with respect to actions on buffers that aren't aligned with a cacheline. but trying to find the appropriate MIPS/xburst documentation has proven challenging. |
| 09:20:53 | | Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de) |
| 09:23:22 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 09:31:02 | | Quit __Bilgus (Remote host closed the connection) |
| 09:34:12 | | Join _Bilgus_ [0] (41ba23be@65.186.35.190) |
| 09:38:29 | pamaury | speachy: we usually make sure that DMA are aligned on cachelines |
| 09:46:40 | johnb2 | speachy: as for system load (on MP3 vs opus, flac), I just created a opus track with 480kBit/s and have and 8 band EQ active: no crackle, even if I increase the boost counter manually in debug. |
| 09:49:46 | _Bilgus_ | speachy Indeed it doesn't crash but the noise there during pb gets repolaced with the sound of the cube phases and once the screen turns off it gets quiet sometimes?? |
| 09:51:02 | _Bilgus_ | oh weird try this playback with 2709 its noisy , run cube do the greyscale high speed let screen turn off playback goes perfect |
| 09:51:50 | _Bilgus_ | press option to turn screen back on and switch to wireframe let screen turn off noise from boot returns |
| 09:52:15 | speachy | I wonder if we're having DMA stalls due to bus contention? |
| 09:52:43 | _Bilgus_ | go back to greyscale it makes that clicking, let scren turn off its perfect again |
| 09:53:39 | speachy | or maybe it's purely a function of high CPU load causing thread starvation? |
| 09:54:03 | speachy | 2079 is more stable though, correct? |
| 09:54:15 | _Bilgus_ | why does the greyscale loop clear it though |
| 09:54:36 | _Bilgus_ | oh no crash at all letting it thrash |
| 09:54:53 | _Bilgus_ | I want to try to boot with no screen and see if it helps |
| 09:55:30 | speachy | (I wonder if we have an IRQ delivery issue?) (Is something locking out interrupts?) |
| 09:56:58 | pamaury | speachy: if you are interested, I have some document regarding the xburst ISA but it's very incomplete. Mostly it contains info about the MXU instructions |
| 09:57:49 | speachy | pamaury: is it the one linked off the 4760b wiki page? |
| 09:58:44 | pamaury | speachy: ah yes, apparently I already uploaded it |
| 09:59:03 | speachy | _Bilgus_: could also be an IRQ hierarchy issue. bleh. I hate it when test results _expand_ the potential problem space. |
| 10:00 |
| 10:11:26 | pamaury | speachy: what is your problem with the cache ? |
| 10:24:54 | speachy | pamaury, trying to hunt down some stability problems. dragging your old cache rework patches into the present seems to have helped a lot, at the expense of audible audio crackling. |
| 10:26:08 | speachy | though the interaction with the display points at resource contention instead |
| 10:27:10 | _Bilgus_ | speachy when you get a chance could you rebase ontop of 2710? |
| 10:27:56 | speachy | _Bilgus_: commit it, I'll fix up my stuff later today. |
| 10:28:26 | fs-bluebot_ | Build Server message: New build round started. Revision 3867f0b, 280 builds, 8 clients. |
| 10:28:39 | pamaury | speachy: have you tried reverting memset and friends to put software versions? I am not sure the code in discard_dcache_range correctly handles edges not in cache lines |
| 10:28:47 | speachy | pamaury: that's also on my todo list. |
| 10:29:25 | speachy | pamaury: both are, actually. I have the latter in my working tree though I haven't loaded it up yet, and given that memset/memcpy have already proven to be (badly) broken in the past, I was going to disable them too |
| 10:29:32 | pamaury | and made sure all dma buffers are aligned? On imx233, I endedup introducing macros to check this because it bite me more times than I could count |
| 10:30:31 | speachy | in theory MIPS allows unaligned cache flushes. |
| 10:31:09 | speachy | there's no danger if you wb+invalidate too much, only if you only invalidate things |
| 10:31:38 | pamaury | speachy: yeah but memset for example invalidates, it could invaliate some bytes outside the range but in the cache line no ? |
| 10:32:00 | pamaury | I didn't know MIPS could do unaligned cache flushes. But I learned the hard way with JZ4760 that "MIPS" is some vague word that gives very little guarantees so I am quite paranoid |
| 10:32:21 | speachy | pamaury: fair enough. :) |
| 10:33:18 | speachy | I don't see any reference to the cache instruction in the memset code? |
| 10:33:47 | speachy | there's a memset_dma() C function but AFAICT nothing actually calls it.. |
| 10:33:52 | pamaury | I mean in the hardware based version on gerrit |
| 10:34:12 | pamaury | https://gerrit.rockbox.org/r/#/c/2709/1/firmware/target/mips/ingenic_jz47xx/dma_acc-jz4740.c |
| 10:35:22 | speachy | dma_acc-jz4740.c isn't present in SOURCES (or #include-d) anywhere |
| 10:35:38 | speachy | dma_acc-jz4760 is, but nothing actually calls the memset_dma/memcpy_dma functions it contains. |
| 10:36:11 | pamaury | ah ok, should nuke it then ^^ |
| 10:37:08 | speachy | _Bilgus_: is there a upper cap on display updates or is it pretty much "use all avaiable oomph" |
| 10:37:29 | pamaury | still something must be wrong with caches/dma if you have some audio crackling. On ARM I debugged those issues by the running the code without cache so see if it fixes issues (it's slow as hell). But on MIPS it's not necessarily easy to do so. |
| 10:38:03 | *** | Saving seen data "./dancer.seen" |
| 10:38:13 | _Bilgus_ | I don't think there is any limiting beyond what it can do |
| 10:38:16 | speachy | how large is the audio buffer typically passed to the dma engine? a few kb or larger? |
| 10:38:52 | _Bilgus_ | i mean most code has timeout or yield |
| 10:38:59 | pamaury | speachy: stupid question but are we 100% sure about the cache size ? And what if you replace all instances about commit/discard_range by just commit_discard_cache(), ie writeback the entire cache everytime instead of being smart ? |
| 10:39:23 | speachy | all of injenic's docs say it's a 16KB cache for I and D |
| 10:39:29 | pamaury | speachy: depends a lot on the codec, on imx233 the driver has to cut it in little piece to keep it manageable |
| 10:40:17 | speachy | and the cacheline is 32 bytes. so sayth the linux kernel too, btw |
| 10:40:48 | | Quit _Bilgus_ (Remote host closed the connection) |
| 10:41:21 | speachy | pamaury: I tried that last night, it didn't make the crackle go away. |
| 10:41:31 | speachy | (and no L2/L3 cache on these parts) |
| 10:41:43 | speachy | otherwise we'd have to flush the L2/L3 too...) |
| 10:41:47 | fs-bluebot_ | Build Server message: Build round completed after 800 seconds. |
| 10:41:49 | fs-bluebot_ | Build Server message: Revision 3867f0b result: All green |
| 10:42:26 | pamaury | speachy: does the AIC support pushing the audio data manual via a fifo register ? That way you can avoid DMA with audio and confirm that the problem indeed is the dma |
| 10:42:55 | speachy | the I2S controller uses a fifo, yeah. |
| 10:44:01 | speachy | I forget how deep it is.. but not very. |
| 10:46:24 | speachy | only seems to affect audio though. sd & usb are okay. |
| 10:47:05 | | Join __Bilgus [0] (41ba23be@65.186.35.190) |
| 10:47:49 | pamaury | speachy: apparently the FIFO is 32 entries deep (an entry is 24-bit so I assume just one channel). So at 48KHz you would need to to refill 3000 times a second, which is doable (for debug purpose) especially if you push the cpu clock high enough |
| 10:48:08 | speachy | huh, the 4760 doesn't like a 144MHz bus speed. |
| 10:48:10 | pamaury | I assume there is so IRQ mecanism for this |
| 10:50:34 | pamaury | more things you can try: create a smallish buffer (a few kb) in the audio driver, copy the data there in bursts and DMA'it (so you have full control of the buffer alignment and cache stuff) |
| 10:52:07 | speachy | huh... I lowered the clock to 528, upped the bus to 132 (from 96) and the crackle is gone. oh, with the guard test to make sure we don't invalidate unaligned cache lines |
| 10:52:54 | speachy | so we bounce between 528/132 and 192/96 now |
| 10:53:30 | speachy | might have genuinely been DMA contention due to the CPU clocking so high relative to the bus & memory. |
| 10:54:05 | speachy | aaaand cube makes it go kaboom. |
| 10:55:35 | __Bilgus | the fire plugin is even faster |
| 10:55:45 | __Bilgus | for crashes |
| 11:00 |
| 11:17:17 | | Quit __Bilgus (Remote host closed the connection) |
| 11:30:13 | speachy | __Bilgus: updated. there's a second patch there that tweaks the cpu freq too |
| 11:30:59 | | Join bilgus_ [0] (41ba23be@65.186.35.190) |
| 11:37:55 | | Quit MrZeus (Ping timeout: 240 seconds) |
| 11:41:19 | | Join sakax [0] (~r0b0t@unaffiliated/r0b0t) |
| 11:53:37 | | Quit ac_laptop (Ping timeout: 264 seconds) |
| 11:59:25 | | Quit johnb2 (Ping timeout: 240 seconds) |
| 12:00 |
| 12:38:04 | *** | Saving seen data "./dancer.seen" |
| 12:55:51 | speachy | now that's annoying. the vol-up button just broke. and taking it apart to figure out why, the vol-dn button followed. |
| 13:00 |
| 13:09:20 | bilgus_ | well luckily thats remapped as a menu item |
| 13:11:14 | | Join johnb4 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de) |
| 13:13:45 | johnb4 | speachy : as for the screen replacement, there were reports where people broke (sheared off) those volume buttons when trying to remove the pcb from the case. They found some easy to replace buttons. |
| 13:13:56 | speachy | that ebay link is no good now |
| 13:14:09 | johnb4 | That's somewhere in the head-fi thread. |
| 13:14:20 | speachy | trying to find something equivalent on mouser right now. |
| 13:14:45 | johnb4 | ah, I haven't checked myself. |
| 13:15:32 | johnb4 | I also ordered the Nintendo screen |
| 13:15:58 | speachy | in a strange coindidence, I have a brand new X3 supposed to be delivered within the hour. |
| 13:17:02 | speachy | vol up/dn isn't a big deal; I tend to use the line out anyway. it's the functions mapped onto those buttons that will be more challenging. |
| 13:18:31 | speachy | 3.5x2.9x1.3mm |
| 13:23:18 | speachy | https://www.mouser.com/ProductDetail/Panasonic/EVQ-P7A01P looks like it'll do |
| 13:34:51 | speachy | johnb4: one more for you. current git head with the dynamic clocking disabled. cpu is maxed out, unlike the older one I sent you. |
| 13:35:33 | speachy | http://www.shaftnet.org/~pizza/x3-test6.zip |
| 13:36:30 | johnb4 | will test it in 20min |
| 13:52:03 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 14:00 |
| 14:10:27 | | Quit johnb4 (Ping timeout: 258 seconds) |
| 14:11:44 | | Join johnb2 [0] (~johnb2@p5b3af8aa.dip0.t-ipconnect.de) |
| 14:13:04 | | Quit bilgus_ (Remote host closed the connection) |
| 14:17:36 | johnb2 | speachy The crackle doesn't cease (e.g. after 3s), but continues throughout the entire track (no matter whether display is on or off). |
| 14:17:45 | speachy | ok, that's what I actually expected |
| 14:18:20 | speachy | I wonder if you somehow have a different hardware variant. is your unit black or silver? |
| 14:19:35 | speachy | one more coming for ya. |
| 14:19:41 | johnb2 | black |
| 14:20:07 | speachy | there's now a test7 |
| 14:20:42 | speachy | dynamic clocking, but lower max speed (with a higher bus speed) |
| 14:21:18 | johnb2 | In the OF, it says VTX5 (so maybe I patched a Vortex version instead of original 1.1), but that shouldn't matter when in rockbox, right? |
| 14:22:52 | speachy | yeah. |
| 14:23:03 | speachy | http://www.shaftnet.org/~pizza/x3-test7.zip |
| 14:25:13 | johnb2 | That one works. |
| 14:25:48 | johnb2 | spoke too soon. |
| 14:26:02 | johnb2 | The notorious crackle is gone. |
| 14:27:01 | johnb2 | but there is a brief blob sound when resuming and then a few seconds later during playback |
| 14:27:30 | johnb2 | but the symptoms are completely different. |
| 14:28:22 | johnb2 | let me do more experiments |
| 14:28:23 | speachy | ok |
| 14:29:52 | johnb2 | turning down volume (1dB) causes the same (mostly just in one channel). |
| 14:30:16 | johnb2 | while playing |
| 14:31:00 | johnb2 | but again just in mp3, not flac |
| 14:35:46 | johnb2 | It is correlated to the frequency change: I monitore it in debug-> freq and buffering thread. |
| 14:36:21 | johnb2 | the volume change boosts to 534MHz, same for track change. |
| 14:37:01 | johnb2 | 524 |
| 14:37:18 | johnb2 | 528 |
| 14:37:20 | speachy | should be 528? |
| 14:37:26 | johnb2 | I need new glasses |
| 14:38:06 | *** | Saving seen data "./dancer.seen" |
| 14:38:29 | speachy | I can drop it down another notch (480) to see if that helps. |
| 14:38:32 | johnb2 | yeah, I think this is it. |
| 14:38:38 | johnb2 | ok |
| 14:39:27 | speachy | I still don't see why mp3 is special. :/ |
| 14:39:40 | speachy | http://www.shaftnet.org/~pizza/x3-test8.zip |
| 14:45:47 | johnb2 | It doesn't seem to make a difference. |
| 14:49:41 | johnb2 | playing with the vol keys I managed to freeze the player |
| 14:55:40 | speachy | one more: http://www.shaftnet.org/~pizza/x3-test9.zip |
| 14:57:11 | johnb2 | Froze once more (still with #8) |
| 15:00 |
| 15:01:39 | fs-bluebot_ | Build Server message: New build round started. Revision 3dc4f81, 280 builds, 8 clients. |
| 15:02:19 | speachy | the build running is equivalent to test9. I've disabled reclocking altogether. I still don't think the reclocking itself is the problem, but there's clearly something else going on that reclocking is exacerbating. |
| 15:02:49 | johnb2 | I don't notice any artefacts now with #9 running at 400MHz |
| 15:03:58 | johnb2 | wasn't #3 running @ 192 constantly? This sounded fine, too. |
| 15:04:18 | speachy | yeah, #3 was. sounded fine but would have problems with more intensive codecs. |
| 15:11:40 | johnb2 | Running cube while playing audio produces the original crackle, but at a lower rate. |
| 15:13:37 | | Join mutnai [0] (b2849e75@178.132.158.117) |
| 15:14:33 | fs-bluebot_ | Build Server message: Build round completed after 773 seconds. |
| 15:14:34 | fs-bluebot_ | Build Server message: Revision 3dc4f81 result: All green |
| 15:14:40 | johnb2 | and fire crashes it. |
| 15:15:10 | johnb2 | But solely doing audio playback is fine. |
| 15:15:11 | speachy | intensive display stuff destabilizes things, basically. |
| 15:15:55 | speachy | the display works by bitbanging things, so it's pretty cpu-intensive, especially for stuff like fire or cube that runs as fast as it can. |
| 15:22:25 | | Quit mutnai (Remote host closed the connection) |
| 15:24:07 | speachy | pamaury: do you have any idea where the irq vector list came from? it doesn't correspond with what's in the 4760's programming manual. |
| 15:25:19 | speachy | (as in, it's _very_ different..) |
| 15:28:31 | speachy | ugh, the vector table is a complete software construct that only loosely corresponds to the HW vector. |
| 15:29:18 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 15:57:28 | speachy | if I'm reading this correctly the IRQ handler treats the i2c as the highest priority.. |
| 15:58:16 | speachy | everything on the second bank (which includes the audio and SD controllers) is treated as lower priority than nearly everything else. |
| 16:00 |
| 16:15:04 | speachy | also might have a fix for the ROLO hang. |
| 16:16:46 | speachy | ...the code prioritized I2C, of all things. |
| 16:18:43 | | Quit mikroflops (Quit: <(^_^)>) |
| 16:29:16 | | Quit pamaury (Quit: this->disconnect()) |
| 16:29:37 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:30:36 | pamaury | speachy: no, I didn't pay attention to the existing jz4740 code to be honest, I am doing more of a rewrite from scratch |
| 16:31:05 | speachy | well, I've redone the interrupt priorization to be a little less insane. |
| 16:32:26 | speachy | no provision for IRQ preemption though |
| 16:33:55 | | Quit ac_laptop (Ping timeout: 240 seconds) |
| 16:34:18 | speachy | haven't crashed it yet with the cube plugin, which is progress. |
| 16:34:30 | speachy | though fire seems to introduce a bit of crackle (irony!) |
| 16:36:30 | speachy | I've really been spoiled with the NVIC on "newer" ARMs. |
| 16:37:23 | pamaury | I think I tried to implement nested IRQ on MIPS but I couldn't make it work |
| 16:38:07 | *** | Saving seen data "./dancer.seen" |
| 16:54:52 | speachy | I think I have basic nested irqs going, though there's no sense of priority other than the AIC is not preemptible. |
| 16:59:51 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 17:00 |
| 17:03:27 | speachy | I'm not sure what ingenic means by "enable the system interrupt to allow the interrupt masking" −− set ST0_IE? |
| 17:12:57 | | Quit lebellium (Quit: Leaving) |
| 17:26:53 | fs-bluebot_ | Build Server message: New build round started. Revision 733821b, 280 builds, 8 clients. |
| 17:39:42 | fs-bluebot_ | Build Server message: Build round completed after 770 seconds. |
| 17:39:44 | fs-bluebot_ | Build Server message: Revision 733821b result: All green |
| 18:00 |
| 18:11:37 | | Quit pamaury (Ping timeout: 264 seconds) |
| 18:23:21 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 18:38:10 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:04:48 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:17:00 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 19:18:57 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 19:27:39 | | Join fs-bluebot [0] (~fs-bluebo@55d4b614.access.ecotel.net) |
| 19:29:44 | | Quit fs-bluebot_ (Ping timeout: 240 seconds) |
| 19:30:22 | | Quit bluebrother^ (Ping timeout: 265 seconds) |
| 19:32:11 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:44:14 | | Quit ac_laptop (Quit: WeeChat 2.8) |
| 19:44:33 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 20:00 |
| 20:38:12 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:14:27 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 21:31:12 | | Quit cockroach (Quit: leaving) |
| 22:00 |
| 22:13:51 | | Quit sakax (Quit: Leaving) |
| 22:35:25 | | Quit ac_laptop (Ping timeout: 240 seconds) |
| 22:38:17 | *** | Saving seen data "./dancer.seen" |
| 22:40:37 | | Join _Bilgus_ [0] (41ba23be@65.186.35.190) |
| 22:47:29 | _Bilgus_ | speachy the audio priority makes sense |
| 22:47:38 | speachy | it does but I got it wrong. :D |
| 22:47:45 | _Bilgus_ | oh? |
| 22:48:07 | speachy | the AIC isn't actually used... all we actually care about is the DMA channel used to transfer audio |
| 22:48:17 | _Bilgus_ | before I left for the day I determined its not anything the cache rework did |
| 22:48:29 | speachy | yeah, the cache rework does change the timings around a bit though. |
| 22:48:37 | _Bilgus_ | there were a few things that were missing from the sources I found |
| 22:48:54 | _Bilgus_ | versus−− |
| 22:49:23 | speachy | the code I'm working on moves the SD DMA onto the second DMA controller, so only audio (and USB) is on the first. |
| 22:49:47 | _Bilgus_ | like ones was copying K0 to K1 and K1 to K0, the other was saving pagemask |
| 22:51:00 | _Bilgus_ | well usb will never be needed with audi so that sounds good |
| 22:52:19 | speachy | right now I'm trying to figure out how often the ADC (ie battery and button) is actually sampling |
| 22:55:06 | _Bilgus_ | do we have info on the adc? maybe a way to lower the sample time too |
| 22:55:15 | speachy | we do, but the docs are... lacking. |
| 22:55:24 | _Bilgus_ | heh |
| 22:56:33 | speachy | basically there are three dividers, the base clock speed (ie from the XTAL), and then two more to derive us and ms times, but no mention of what they actually do. the touchscreen port on the SADC can use DMA but the battery and aux can't. |
| 22:56:44 | speachy | so the thing runs as fast as it runs, interrupting the CPU each time |
| 22:57:51 | speachy | right now the base clock is 200KHz, aka the max the SADC supports. |
| 23:00 |
| 23:00:16 | speachy | or "us" and "ms" rather. still trying to figure out they mean. |
| 23:01:49 | speachy | so the "us" clock is ~100KHz, and "ms" clock is ~20KHz |
| 23:03:09 | speachy | (also means the keymaps that require two buttons being held down won't work, unless the other button is power!) |
| 23:06:00 | speachy | clk_us is "interval time between repeated sampling the same point" and clk_ms drives "the interval time among the different point" |
| 23:06:17 | _Bilgus_ | I found it in the manual, I think we can still do multiple buttons |
| 23:06:34 | _Bilgus_ | we just need to figure out the way they have it wired |
| 23:06:56 | speachy | I think the keymap is sane though I might have broken a few things inadvertantly. :) |
| 23:07:30 | _Bilgus_ | I can play with that I'm at least semi familar with adcs |
| 23:14:40 | speachy | the code does overdrive the SADC slightly, 203KHz nominal versus 200K max. |
| 23:15:56 | _Bilgus_ | is the clock shared with something else? |
| 23:16:08 | speachy | it's derived from the XTAL, so no. |
| 23:16:55 | speachy | the base divisor goes all the way to 255 ie a ~47KHz base clock |
| 23:17:20 | speachy | there's just no explanation of the other divisors. |
| 23:17:57 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 23:18:14 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 23:20:34 | speachy | wonder if it might just make more sense to only initiate the ADC query when button_read_device() is called. |
| 23:20:52 | speachy | and set up a timer to poll the battery oh, once a second. |
| 23:26:43 | speachy | docs appear to be wrong about the "ms" clock; it is supposed to key off the main sadc clock, not the us clock. |
| 23:26:58 | speachy | if I believe the linux kernel sources. :) |
| 23:30:44 | speachy | so, I infer that the ADC samples every ms for 10us. |
| 23:35:07 | speachy | the 4740 targets only poll the battery when the core requests it |
| 23:55:13 | _Bilgus_ | we could move the battery to tick task |
| 23:55:58 | speachy | ... no.. |
| 23:56:12 | speachy | I mis-read this. the aux and battery adc query is a oneshot |
| 23:56:18 | _Bilgus_ | I found a jz4760b UI programming manual on some chinese file sharing site |
| 23:56:26 | _Bilgus_ | I wonder if it applies to us |
| 23:56:41 | speachy | every time the button tick fires it triggers a bat+keypad read |
| 23:57:04 | speachy | but (here's the funny part) we don't actually _wait_ for it to finish. |
| 23:57:20 | _Bilgus_ | oh do we get an interrupt? |
| 23:57:21 | speachy | and there's nothing that prevents them from getting stacked on each other |
| 23:57:28 | _Bilgus_ | oh :/ |
| 23:57:47 | speachy | we get an interrupt and update the global state. so on a subsequent tick/call to button_read_device, the values are pulled. |
| 23:58:34 | _Bilgus_ | https://max.book118.com/html/2016/0309/37235681.shtm |
icon identifies that the person is a core developer (has commit access).