--- Log for 17.09.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 19 days and 9 hours ago 00.04.43 Join Huntereb [0] (~Huntereb@174.226.7.215) 00.24.18 Quit ac_laptop (Ping timeout: 260 seconds) 00.47.23 *** Saving seen data "./dancer.seen" 02.09.55 Quit kirvesAxe (Ping timeout: 246 seconds) 02.10.07 Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) 02.12.26 Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-xgiyfmccvirdnaiu) 02.23.39 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 02.47.24 *** Saving seen data "./dancer.seen" 03.02.00 Quit johnb5 (Ping timeout: 265 seconds) 03.22.11 Join petur [0] (~petur@rockbox/developer/petur) 04.02.29 Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:4c99:ab72:beeb:908d) 04.47.27 *** Saving seen data "./dancer.seen" 05.03.10 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 05.09.59 Quit johnb5 (Ping timeout: 258 seconds) 05.34.33 Join ungali [0] (~ungali@50.93.0.42) 05.34.34 Quit ungali (Changing host) 05.34.34 Join ungali [0] (~ungali@unaffiliated/ungali) 05.43.55 Quit MrZeus__ (Ping timeout: 272 seconds) 06.24.51 Quit ungali (Quit: ungali) 06.32.35 Quit koniu (Remote host closed the connection) 06.33.20 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 06.47.30 *** Saving seen data "./dancer.seen" 06.56.06 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 07.10.54 Quit ac_laptop (Ping timeout: 260 seconds) 07.14.28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.34.11 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 08.34.59 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 08.47.32 *** Saving seen data "./dancer.seen" 08.58.48 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 08.59.06 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 09.18.58 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 09.19.31 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 09.21.24 Quit pamaury (Ping timeout: 240 seconds) 09.26.44 Join Moarc_ [0] (~chujko@a105.net128.okay.pl) 09.37.44 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.42.29 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 09.43.17 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 09.46.36 Quit St3ak (Client Quit) 09.47.12 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 09.56.18 Quit Moarc_ (Read error: Connection reset by peer) 09.57.18 Join Moarc [0] (~chujko@a105.net128.okay.pl) 10.01.27 # <_bilgus_> speachy #FS 13237 LO still doesn't work reliably, gonna try and see what the frontend is doing withit, failing that I'll probably set it up as an interrupt 10.02.26 # I think I'm responsible for the LO code in the core. 10.02.47 Quit tchan (Read error: Connection reset by peer) 10.03.24 # it doesn't have a lot of the complexities that the HP code does; namely unplugging LO doesn't necessarily trigger things. 10.03.32 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 10.15.10 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 10.15.49 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 10.18.44 Quit lemon_jesus (Ping timeout: 240 seconds) 10.25.01 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) 10.33.25 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 10.34.44 Quit lemon_jesus (Ping timeout: 272 seconds) 10.34.46 Join lemon_jesus4 [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) 10.37.18 Quit Moarc (Read error: Connection reset by peer) 10.37.31 Join Moarc [0] (~chujko@a105.net128.okay.pl) 10.38.49 Quit lemon_jesus4 (Ping timeout: 246 seconds) 10.39.01 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:84ca:64ee:b1e1:e0f) 10.39.55 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 10.40.46 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) 10.47.36 *** Saving seen data "./dancer.seen" 11.01.14 Quit massiveH (Quit: Leaving) 11.06.42 # <_bilgus_> judging by the debug output I think you are correct, it is catching the insertion/removal perfectly 11.25.11 # Build Server message: New build round started. Revision a66b908, 280 builds, 7 clients. 11.30.27 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.36.36 Quit petur (Read error: Connection reset by peer) 11.40.37 # Build Server message: Build round completed after 925 seconds. 11.40.39 # Build Server message: Revision a66b908 result: All green 11.41.21 # I'd like to commit the current state of the USB rework 11.49.49 # <_bilgus_> It works, and you can ifdef it out so why not 12.01.11 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 12.01.42 # I think I'll leave the lock switch bypass in permanently 12.02.02 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 12.06.16 # <_bilgus_> maybe eventually it could be used to disable the USB and turn it charge only or something 12.06.56 # <_bilgus_> OH speaking of that line out stuff as I'm going through adding the extra defines for LO detection 12.07.40 # <_bilgus_> the thought occurs to me that maybe its current behavior is better if you want to plug a hp && lineout at the same time 12.07.52 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 12.08.08 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 12.08.58 # it supports it but I can't really think of a situation where you'd want to do that. 12.09.21 # since you can't control the volume indepdently, and LO needs the volume maxed out. 12.09.57 # <_bilgus_> ah so so LO affects HP as well? 12.11.22 # the cs4358 (?) only has one audio output, and it's connected to two different output amps. 12.14.49 # we only want to max the volume (ie bypass the user selection) if the HP is *not* plugged. The output amps are enabled by their respective plug detect switches. 12.16.38 # Build Server message: New build round started. Revision ec413f7, 280 builds, 7 clients. 12.17.08 # <_bilgus_> ok then I shall continue 12.17.42 # as long as that max vol interlock remains 12.20.29 # I'm going to merge your sysbench script too 12.20.54 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 12.21.18 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 12.22.56 # <_bilgus_> go for it 12.25.08 Quit St3ak (Client Quit) 12.25.32 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 12.33.38 # Build Server message: Build round completed after 1018 seconds. 12.33.39 # Build Server message: Revision ec413f7 result: All green 12.33.40 # Build Server message: New build round started. Revision 4fa945d, 280 builds, 7 clients. 12.43.38 Quit lemon_jesus (Quit: Ping timeout (120 seconds)) 12.44.02 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.il.comcast.net) 12.47.40 *** Saving seen data "./dancer.seen" 12.48.27 # Build Server message: Build round completed after 889 seconds. 12.48.29 # Build Server message: Revision 4fa945d result: All green 12.49.12 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 12.55.49 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 12.59.08 Quit johnb5 (Ping timeout: 272 seconds) 13.06.41 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) 13.08.04 Join Moarc [0] (~chujko@a105.net128.okay.pl) 13.12.25 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 13.13.03 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 13.13.32 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 13.21.08 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 13.27.44 Quit johnb5 (Ping timeout: 240 seconds) 13.38.18 Quit ZincAlloy (Quit: Leaving.) 13.41.38 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 13.43.53 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 13.46.05 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.47.14 Quit St3ak (Client Quit) 13.47.37 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 13.50.59 Quit pamaury (Ping timeout: 240 seconds) 13.52.17 Quit St3ak (Client Quit) 13.53.45 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 13.59.46 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 14.03.38 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 14.04.12 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.04.44 Quit St3ak (Client Quit) 14.05.38 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.14.08 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 14.14.47 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.16.16 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 14.16.46 Quit St3ak (Client Quit) 14.17.26 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.19.47 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:a567:5fb:db4:f552) 14.19.51 Quit St3ak (Client Quit) 14.20.41 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.26.06 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 14.26.54 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.29.26 Quit St3ak (Client Quit) 14.29.58 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.31.08 Quit St3ak (Client Quit) 14.31.50 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.33.22 Quit St3ak (Remote host closed the connection) 14.33.50 Join St3ak` [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.39.58 Quit St3ak` (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 14.40.29 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 14.47.44 *** Saving seen data "./dancer.seen" 14.54.24 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 14.54.57 Quit johnb5 (Ping timeout: 258 seconds) 14.55.11 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 15.02.31 # <_bilgus_> ok g#2749 is up I havent had any spurious detections with either port so far after enabling the pullup on lo. 15.03.25 # <_bilgus_> I had to switch the headphone caused pause boolean in order to get the lo to stay playing on startup 15.04.10 # <_bilgus_> It does seem to glitch the wps now on plug/unplug but it very well may have done that before 15.05.15 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 15.05.36 # so does it behave properly if you have both plugged in and unplug one? 15.05.54 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 15.06.29 # <_bilgus_> lol IDK i'll have to get a second set oh headphones 15.07.00 # <_bilgus_> it should being that I didn't change the lockout on the backend 15.07.21 Quit St3ak (Remote host closed the connection) 15.08.10 # and that logic in audio_enable_speaker is a little odd. if mode gets set to 1, will that logic ever fire again? 15.08.20 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 15.11.00 # no, I don't mean the lockout -- I mean if you have that pause-on-unplug, with both plugged in, and you unplug one, it'lll pause. 15.11.27 # even though the other is still plugged in. 15.12.22 # <_bilgus_> yes it'd still pause 15.12.32 # <_bilgus_> thats what I was referring to earlier 15.12.43 # * speachy nods. 15.12.51 # <_bilgus_> uh the enable speaker one is not right I have that logic backwards 15.13.24 # <_bilgus_> doesn't affect this target but I figured i'd add the functionality there too 15.13.25 # that's probably okay. I consider simultaneous hp/lo usage to be user error.. 15.22.02 # <_bilgus_> eh I'll have to think about the speaker one for a bit gtg 15.28.17 Join johnb5 [0] (~johnb2@p5b3afc93.dip0.t-ipconnect.de) 15.38.35 Join petur [0] (~petur@rockbox/developer/petur) 15.50.05 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 15.50.43 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 15.55.10 Quit St3ak (Client Quit) 15.55.12 Quit johnb5 (Ping timeout: 272 seconds) 15.55.40 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 15.56.46 Quit ecs (Remote host closed the connection) 16.05.10 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 16.05.38 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.07.48 Join ecs [0] (esawady@d2evs.net) 16.12.56 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 16.13.39 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.18.57 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 16.21.03 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.22.29 Quit St3ak (Remote host closed the connection) 16.22.52 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.23.33 Join Topy44 [0] (I7FyMx2JcP@bellatrix.uberspace.de) 16.32.29 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 16.34.16 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.35.03 Quit St3ak (Remote host closed the connection) 16.35.54 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 16.36.32 Quit St3ak (Client Quit) 16.47.49 *** Saving seen data "./dancer.seen" 17.07.03 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 17.31.09 Quit ZincAlloy (Quit: Leaving.) 17.39.41 Quit lebellium (Quit: Leaving) 17.54.47 Quit pamaury (Ping timeout: 272 seconds) 18.13.46 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 18.14.11 Join advcomp2019__ [0] (~advcomp20@65-131-168-14.sxct.qwest.net) 18.14.11 Quit advcomp2019__ (Changing host) 18.14.11 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 18.17.39 Quit advcomp2019_ (Ping timeout: 260 seconds) 18.47.51 *** Saving seen data "./dancer.seen" 19.01.36 # <_bilgus_> speachy with both ports at the same time it does not act right gonna make them mutually exclusive 19.05.08 Join advcomp2019_ [0] (~advcomp20@65-131-168-14.sxct.qwest.net) 19.05.08 Quit advcomp2019_ (Changing host) 19.05.08 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 19.06.27 Quit petur (Remote host closed the connection) 19.08.23 Quit advcomp2019__ (Ping timeout: 260 seconds) 19.13.19 Quit MrZeus (Ping timeout: 272 seconds) 19.15.13 Quit ac_laptop (Ping timeout: 272 seconds) 19.18.06 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 19.24.12 # okeydokey 19.34.51 Quit ac_laptop (Ping timeout: 272 seconds) 19.50.31 # speachy: is there a reason why rockbox has never supported MTP? 19.51.52 # braewoods: the code won't write itself... 19.51.58 # oh, i see. 19.52.06 # i thought there was some reason. 19.52.37 # there's Linux support for MTP and such so I thought it would be a nice option. 19.52.45 # i thought maybe there were technical reasons why. 19.53.41 # at some point I'll see if there's an viable MTP implementations that can be ported. 19.54.51 # there's a partial implementation here: https://github.com/pamaury/rockbox/commits/mtp-new 19.56.42 Quit bluebrother (Disconnected by services) 19.56.47 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.57.10 Join fs-bluebot_ [0] (~fs-bluebo@55d4730a.access.ecotel.net) 19.59.21 # i see. 20.00.11 Quit fs-bluebot (Ping timeout: 272 seconds) 20.00.16 # Hm. Seems there's a Linux port. 20.00.37 # Maybe I can tie that into the rockbox USB stack. 20.02.15 # TBH you're better off starting with that mtp-new branch and forward-porting it to current master. 20.02.53 # the actual mtp-specific stuff is self-contained but there's a lot of support code around it. 20.03.03 # I see. 20.03.28 # another possibility is to start with one of the hosted targets and use a native linux OTG MTP implementation. 20.03.55 # I'll figure something out. I want to research options first. 20.04.07 # I do know I don't want to write the MTP code from scratch. 20.04.48 # i expect most of the MTP clients are going to be using libusb with some MTP library. 20.04.56 # but we want an MTP server of sorts. 20.08.09 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.22.54 # Build Server message: New build round started. Revision 2df3a5b, 280 builds, 7 clients. 20.32.36 Join scorche [0] (~scorche@rockbox/administrator/scorche) 20.35.19 Quit scorche` (Ping timeout: 260 seconds) 20.37.18 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 20.39.11 # Build Server message: Build round completed after 978 seconds. 20.39.13 # Build Server message: Revision 2df3a5b result: All green 20.40.24 Quit St3ak (Client Quit) 20.40.50 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 20.47.53 *** Saving seen data "./dancer.seen" 20.57.51 # _bilgus_: still getting occasional ROLO hangs. 21.00.37 # oh, just noticed the date/time in the debug menu is ... quite janky 21.00.41 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 21.01.16 # well, time is good, date is showing '17/08/0120' 21.01.25 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 21.02.00 # <_bilgus_> someone isn't adding 1900 apparently 21.03.08 # <_bilgus_> well ingenic told me to FO 21.03.34 # <_bilgus_> Sorry .We don't support JZ4760B anymore.Thank you. 21.03.35 # <_bilgus_> Best Regards, support 21.03.51 # what were you asking for? (anything?) 21.04.05 # <_bilgus_> maybe someone who visits the forum will have access to wechat 21.04.40 # <_bilgus_> that second manual the one that has the DMA SADC and few other things I'd really like to read about 21.05.02 # oh, that "UI" manual 21.05.33 # their SDK sources might have useful bits in there. 21.05.55 # <_bilgus_> oh and the CODEC part! 21.06.17 # <_bilgus_> I managed to get all their sources from their ftp took like 2 days 21.06.57 # I have a complete mirror of that too 21.07.18 # <_bilgus_> yeah it's clearly not gonna be there forever 21.10.17 # oh, I managed to find a copy of the upstream MUSBHDRC documentatio 21.12.42 # not sure if it matches the core revision that the jz4760 uses but it's much more useful than the ingenic docs. 21.15.02 Quit ufdm (Read error: Connection reset by peer) 21.19.05 Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 21.22.53 # <_bilgus_> https://forums.rockbox.org/index.php/topic,53576.0.html 21.23.49 # <_bilgus_> I'm not overly impressed by anything dealing with ingenic tbh 21.25.20 # <_bilgus_> hehe I asked in #mips-lab and they guy told me to use google and linked me to our own document lol 21.25.42 # <_bilgus_> s/ they / a 21.25.56 # heh 21.27.15 # <_bilgus_> the heaphone / lo stuff should be good now I left the FS open to hear back from the OP but its set to close in a week 21.27.51 # <_bilgus_> if you plug both it pauses if headphone is plugged it takes priority 21.28.08 # <_bilgus_> unplug l/o while hp is playing no change 21.28.51 # <_bilgus_> plug both unplug hp goes to lo 21.35.56 # <_bilgus_> So at this point I assume you are confident that it is possible to make RX work given enough time? 21.36.54 # <_bilgus_> I guess I should try a disk speed test on the OF that might tell 21.40.43 Quit ufdm_ (Quit: Leaving) 21.40.55 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 21.41.08 # definitely. I've restructured the RX flow, and now I've finished about 2/3rds of the DMA plumbing for it 21.46.09 # <_bilgus_> judging by the seq write speed they are not using dma 21.53.02 # I agree 21.53.56 Quit amiconn (Ping timeout: 244 seconds) 21.53.56 Quit pixelma (Ping timeout: 244 seconds) 21.54.09 Join pixelma [0] (marianne@rockbox/staff/pixelma) 21.54.25 Join amiconn [0] (jens@rockbox/developer/amiconn) 21.59.26 # code complete. 22.01.09 # <_bilgus_> damn 22.01.32 # okay, didn't break things with RX DMA compiled out 22.01.36 # <_bilgus_> hmm the sequential read says they are using dma 22.02.22 # device RX is the complex case 22.02.59 # <_bilgus_> SW: 2.65 RndRW 0.69/0.45 SR: 10.06 mbps 22.03.38 # DMA compiled in, but disabled, still works.. 22.05.03 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 22.05.24 # and small-transfer RX DMA is ... busted. 22.05.51 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 22.15.52 # DMA went thrrough ok but for some reaon the logic thought there was another 900-odd-bytes remaining...? 22.27.25 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 22.27.50 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 22.28.36 Quit St3ak (Client Quit) 22.28.52 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 22.29.16 Quit St3ak (Client Quit) 22.33.54 Quit ac_laptop (Ping timeout: 260 seconds) 22.37.31 # <_bilgus_> errant bit? 22.38.17 # convoluted logic; I'm getting the DMA complete interrupt but not the endpoint complete interrupt. 22.38.32 # I cleared the DMA state too early so latter code didn't do it properly 22.39.02 # but that doesn't explain the wonky FIFO; there's no way the FIFO should report having that much crap in it. 22.39.15 # got past that but now the whole thing is stalling 22.46.27 # found an inverted, um, inversion. 22.47.56 *** Saving seen data "./dancer.seen" 22.49.17 # sweet, it's working for short transfers now. 22.50.36 # <_bilgus_> nice! 22.52.49 # aaaand broken for larger transfers. I'm probably going to trash my SD card doing this. :/ 22.53.29 # <_bilgus_> throw a cheapie in there 22.53.55 # two slots, fortunately 22.54.05 # don't want to corrupt my data 22.58.15 # ok, first block transferred, things go wonky after that. DMA/RX quirks rearing their ugly head, basically. 22.59.30 # <_bilgus_> does this dma have a shift mechinism like stride for the display stuff 23.00.11 # no 23.06.07 # this is the auto-rx stuff breaking. or rather, my logic isn't quite right yet. I'm getting a spurious interrupt that makes me think we got a 0 length transfer. 23.06.20 # prematurely terminating the flow. 23.06.30 Join pablocastellanos [0] (~emergency@li79-248.members.linode.com) 23.08.04 Quit beencubed (Quit: Leaving) 23.12.24 Join beencubed [0] (~beencubed@209.131.238.248) 23.14.30 # I think the issue is that we're getting a DMA interrupt _and_ a EP interrupt for the same transfer. 23.15.31 # and that's breaking the accounting 23.19.26 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 23.55.25 Quit TheSeven (Ping timeout: 240 seconds) 23.55.51 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)