--- Log for 29.06.111 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 6 days and 21 hours ago 00.03.15 Quit domonoky (Read error: Connection reset by peer) 00.06.33 Quit ender` (Quit: If at first you don't succeed, skydiving is not for you.) 00.07.18 Quit krazykit (Ping timeout: 258 seconds) 00.10.40 Join ender` [0] (krneki@foo.eternallybored.org) 00.13.02 Quit alexbobp (Read error: Connection reset by peer) 00.13.10 # woohoo. git repository containing absolutely everything in the svn repository, including ancient branches, themesite, etc: 137MB 00.13.18 # Notably smaller than one copy of our source. :) 00.13.56 Join alexbobp [0] (~alex@209.135.10.128) 00.14.34 # cool 00.15.23 # it's not very friendly to look at at the moment though because that is 133 branch heads 00.15.32 # since svn tags are also treated as branches 00.15.45 # and, er, a bunch of virtual branches for where we have done weird shit with svn is also treated as branches. :) 00.16.04 # clean-upable? 00.16.08 # Yes 00.16.16 # those are all under refs/remotes 00.16.27 # we will discard all those refs once we stop needing to update from svn 00.16.37 # so now i need to make proper git branch heads and tags for the ones we care about 00.16.39 Quit Rob2222 (Quit: Rob2222) 00.16.51 # which I'm going to decide arbitrarily is "everything with any content in, even if it's ancient" 00.16.54 # because it's *tiny* 00.17.02 # but quite a lot of these branches have no content 00.17.15 # and i can always put the old ones somewhere that clone won't bother cloning them by default 00.20.29 *** Saving seen data "./dancer.seen" 00.20.41 Quit robin0800 (Ping timeout: 240 seconds) 00.21.44 Join krazykit [0] (~krazykit@206.183.185.8) 00.25.41 Quit esperegu (Remote host closed the connection) 00.25.49 Join robin0800 [0] (~robin0800@149.254.60.171) 00.33.45 Quit sideral (Quit: Leaving.) 00.37.30 Quit Stephen___ (Ping timeout: 240 seconds) 00.40.25 Quit pamaury (Remote host closed the connection) 00.41.34 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 00.44.43 Quit ender` (Quit: It always takes longer than you expect, even when you take Hofstadter's Law into account. -- Hofstadter's Law) 00.46.17 Quit mudd1 (Quit: Ex-Chat) 00.49.59 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 00.52.51 Quit dantje (Quit: Ex-Chat) 00.54.34 Quit bertrik (Quit: :tiuQ) 00.55.29 Nick kramer3d is now known as d3remark (~kramer@unaffiliated/kramer3d) 01.00.15 Quit TheLemonMan (Quit: Ex-Chat) 01.10.18 Quit hobby16 (Ping timeout: 240 seconds) 01.10.30 Join Rob2222 [0] (~Miranda@p5DE4B0F9.dip.t-dialin.net) 01.10.45 Join BHSPitMonkey_ [0] (~stephen@68-185-203-185.dhcp.dntn.tx.charter.com) 01.11.06 Quit bzed (Remote host closed the connection) 01.11.14 Join bzed [0] (~bzed@devel.recluse.de) 01.19.45 Quit BHSPitMonkey_ (Remote host closed the connection) 01.29.52 Quit Xerion (Ping timeout: 255 seconds) 01.45.06 Quit powell14ski_ (Ping timeout: 264 seconds) 01.46.45 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 01.53.30 Quit powell14ski_ (Ping timeout: 264 seconds) 01.56.32 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 02.08.15 Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.18.43 Quit mikroflops (Ping timeout: 260 seconds) 02.19.39 Quit GeekShadow (Quit: The cake is a lie !) 02.20.31 *** Saving seen data "./dancer.seen" 02.23.54 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 02.33.23 Join mikroflops [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 02.36.13 Quit Thra11 (Ping timeout: 260 seconds) 02.57.00 Join ReimuHakurei [0] (~reimu@74.112.212.15) 03.03.16 Quit liar (Quit: hallowed are the ori!) 03.07.41 Quit robin0800 (Read error: Connection timed out) 03.08.39 Join robin0800 [0] (~robin0800@149.254.61.208) 03.09.29 Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) 03.09.35 Quit Judas_PhD (Quit: This is a quitting message) 03.15.23 Quit Rob2222 (Read error: Connection reset by peer) 03.36.44 Quit Zarggg (Quit: Rebooting client...) 03.44.12 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 04.05.07 Quit [7] (Disconnected by services) 04.05.18 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.20.32 *** Saving seen data "./dancer.seen" 04.24.39 Quit evilnick (Read error: Connection reset by peer) 04.44.19 Nick d3remark is now known as kramer3d (~kramer@unaffiliated/kramer3d) 04.50.01 Quit amiconn (Disconnected by services) 04.50.02 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.50.15 Quit pixelma (Disconnected by services) 04.50.17 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.50.19 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.50.19 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.59.54 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 05.21.20 Quit kramer3d (Ping timeout: 240 seconds) 05.22.29 Quit patheticbliss (Ping timeout: 260 seconds) 05.23.26 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.34.47 # gevaerts: dammit... more thai spam not in that ip range 05.38.46 # though... if all the bans between mum_maisusa and the ip ban on the 27th are from that one i say WIN 05.42.32 Quit Horscht (Quit: Verlassend) 05.46.20 Quit CaptainKewl (Ping timeout: 276 seconds) 05.50.30 Quit Topy44 (Read error: Connection reset by peer) 05.52.24 Quit Strife89 (Quit: Sleep) 06.06.10 Join legendarymidget [0] (~7cb593dd@giant.haxx.se) 06.09.13 Quit factor (Read error: Connection reset by peer) 06.09.30 Quit legendarymidget (Client Quit) 06.14.25 Quit Scromple (Ping timeout: 240 seconds) 06.20.34 *** Saving seen data "./dancer.seen" 06.25.14 Quit robin0800 (Read error: Connection timed out) 06.26.21 Join robin0800 [0] (~robin0800@149.254.61.208) 06.26.42 Join factor [0] (~factor@74.197.205.204) 06.28.13 Join icarusfactor [0] (~factor@74.197.205.204) 06.28.57 Quit factor (Disconnected by services) 06.29.03 Nick icarusfactor is now known as factor (~factor@74.197.205.204) 06.38.50 Quit robin0800 (Quit: Leaving) 06.47.27 Join sideral [0] (~sideral@rockbox/developer/sideral) 06.51.55 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 06.54.36 Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 06.55.33 Quit sideral (Quit: Leaving.) 07.09.34 Quit CIA-27 (*.net *.split) 07.10.26 Join CIA-14 [0] (~CIA@cia.atheme.org) 07.28.03 Join Thra11 [0] (~thrall@220.171.pn.adsl.brightview.com) 07.30.46 Join hobby16 [0] (~ubuntu@157.186.193.77.rev.sfr.net) 07.48.48 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 07.51.44 Quit factor (Read error: Connection reset by peer) 08.00.12 Join factor [0] (~factor@74.197.205.204) 08.10.58 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 08.18.57 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.20.37 *** Saving seen data "./dancer.seen" 08.21.27 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 08.37.07 # New commit by 03jethead71 (r30097): Commit FS#12150 - Fully-functional audio mixer - and finally whip old limitations about playback of voice and other sounds when paused. Channels are ... 08.38.37 # woohoo 08.39.23 # yeehaa 08.41.20 # yippie 08.41.56 # ooh, 1 1/2 mins overdue, that's usually not a good sign for build errors :D 08.42.06 # r30097 build result: 82 errors, 5342 warnings (jethead71 committed) 08.42.10 # nice call 08.42.42 # uh oh 08.42.46 # IRAM full 08.43.05 Join ender` [0] (krneki@foo.eternallybored.org) 08.43.19 Quit Scromple (Ping timeout: 264 seconds) 08.43.20 # also forgot to filter in some places for SWCODEC :\ 08.43.21 # have fun with that :D 08.43.59 # by 24 bytes? 08.51.42 # one by one I suppose 08.53.24 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 08.54.15 # jhMikeS: Are there any constraints for the size param in pcm_play_dma_start()? 08.54.52 Join pondlife [0] (~Steve@rockbox/developer/pondlife) 08.55.36 # rk27xx hardware have 16bit reg for dma size expressed in transfer units (32bits) so I am wondering if I have to provide some logic to extend this to full 32bit size 08.55.44 # * pondlife pops in to thank/congratulate jhMikeS 08.56.33 # and one more - do I assume correctly that size param in pcm_play_dma_start() is expressed in bytes? 08.56.35 # wodz: multiples of four bytes 08.56.43 # pondlife: thank you 08.56.54 # wodz: it is, yes 08.57.19 # hmm - the build has a broken in it? 08.57.21 # wodz: the layer above rounds it though 08.57.31 # jhMikeS: what about size limit? 08.57.45 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 08.58.06 # jhMikeS: \o/ 08.58.07 # a 16-bit reg for word count should be enough 08.59.40 # ams pcm driver has logic to split dma transaction but there the limit is much lower (10 or 11bits of word count) 08.59.53 Join esperegu [0] (~quassel@145.116.15.244) 09.01.26 # android is giving trouble with including pcm-mixer-armv5.c 09.03.15 # hmmm...thing thing actually didn't add as much binsize as I seem to remember eariler on 09.03.21 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.03.22 Quit bertrik (Changing host) 09.03.22 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.05.27 Quit pondlife (Read error: Connection reset by peer) 09.06.11 # New commit by 03jethead71 (r30098): Knock out at least some red/yellow from r30097. 09.09.38 # wodz: imx31 has been getting away with a limit of 64KB just fine without resorting to splitting it up, though it easily could 09.10.20 # r30098 build result: 19 errors, 0 warnings (jethead71 committed) 09.11.14 # jhMikeS: cool - this simplifies pcm driver :-) 09.14.22 # hmm interesting that m5 has iram full while other coldfires not 09.15.05 # the other ones had some left over 09.18.56 # Am I right that I can't use register values representation for SOUND_VOLUME and have to use tenth of dB? 09.19.31 # correct 09.19.42 # shit 09.20.26 # dammnit, I have no andoid build stuff installed 09.22.05 # I wonder who invented this #@%@# gain setup pattern in rk27xx codec. That is insane. 09.23.51 # our code seems to assume that gain steps are distributed evenly 09.24.02 Join Rob2222 [0] (~Miranda@p4FFF388B.dip.t-dialin.net) 09.24.40 Join Topy44 [0] (~Topy44@f049108161.adsl.alicedsl.de) 09.27.35 # wodz: seems like a reasonable assumption to me :-) 09.29.01 Quit utanapischti (Quit: WeeChat 0.3.2) 09.29.04 # yeh - tell this to engineers from Dolphin :-) 09.29.27 Join utanapischti [0] (~username@p4FF2D8E2.dip.t-dialin.net) 09.29.55 # it's craziness like that that made me an index-based advocate 09.30.50 Join petur [0] (~petur@rockbox/developer/petur) 09.31.54 # jhMikeS: android uses the Target tree under hosted 09.32.09 # it cannot easily see stuff under ARM 09.32.39 # it will see it under /firmware? 09.33.00 # yes 09.33.39 # could also do an empty c in the android Target tree that includes via hardcoded path 09.34.44 # <[Saint]> Just, whatever you do...do it soon. I want to see if it magically fixes keyclick and track skip bep on my phone ;) 09.34.48 # <[Saint]> *beep too 09.35.17 # or have an extra dir for arch specific things that are native/hosted dependant 09.35.19 # <[Saint]> (audio playback cuts out something wicked during keyclick for some reason) 09.35.40 # keyclick should be vibrate on android :) 09.36.34 # [Saint]: kugelp checked it afaik, don't know if he checked those other bits. I also don't know if it needs to be implemented like the SDL version to really work perfectly. 09.36.34 # are *not 09.37.36 # oh heck, what would that path be to include it properly? 09.37.58 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 09.38.00 # <[Saint]> JdGordon: I'd thought about adding a menu entry for keyclick for haptic feedback as well, so as to have one, the other, or both enabled...but I couldn't find out how to tie into haptic feedback properly. 09.42.15 # or...for now, I can skip the optimized include for non-native targets and let someone able to build that actually sort it out rather than maybe committing the wrong thing :) 09.43.13 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 09.44.47 # <[Saint]> Bah! Where's the sense of adventure in that? ;) 09.45.01 # <[Saint]> Build errors are part of learning! 09.45.31 # I've got other crap to sort out, like IRAM being ful on a few things, which is bad enough 09.47.36 # New commit by 03jethead71 (r30099): Get android to build. Forgo optimized mixing code for app builds for the moment; work it out later. 09.51.17 # what the heck is the IRAM suck on m5 that doesn't disturb h100 series? 09.51.23 # r30099 build result: 16 errors, 0 warnings (jethead71 committed) 10.02.57 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 10.07.54 Quit boghog (Ping timeout: 260 seconds) 10.09.43 Join n1s [0] (~quassel@rockbox/developer/n1s) 10.10.35 # I see. the remote stuff sucks up the IRAM on m5 but not on H100 10.10.52 # how about an arch for in firmware as a place for arch-specific stuff that isn't native/hosted dependant? 10.15.13 # arch dir* 10.15.13 # could work. should it be limited to firmware? dsp has some optimized routines but they're all right in /apps along with dsp.c 10.15.57 Quit Llorean (Read error: Connection reset by peer) 10.17.07 # do MIPS have good caches? 10.18.50 Quit mc2739 (Read error: Connection reset by peer) 10.20.09 # MIPS hasn't been profiled extensively I guess 10.20.39 *** Saving seen data "./dancer.seen" 10.21.42 Join TheLemonMan [0] (~lem0n@ppp-197-58.26-151.libero.it) 10.22.35 # TheLemonMan: you seem to know something about MIPS archs 10.23.23 # yep, but i know less than zero about ffts heh 10.23.24 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.24.37 Quit Judas_PhD (Quit: This is a quitting message) 10.24.43 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.24.50 # TheLemonMan: do you know how cache is performing on ingenics? 10.25.50 # IRAM is quite tight there. If I use it at all, what is more important, code or data? 10.26.17 # of course, data is big, code is small and loopy in this case 10.26.34 Quit ack (Remote host closed the connection) 10.26.36 # jhMikeS: could have the same thing in apps 10.27.58 Join ack [0] (~ack@mingbai.org) 10.28.04 # the pcm stuff is in firmware now 10.28.07 # On MIPS, it's 0x1f0 over the limit 10.28.51 # jhMikeS: congrat for your patch, hope it will work flawlessly :) 10.29.31 # I don't think it would be good to split dsp just to have optimization in firmware 10.29.53 # pamaury: thank you. and I share the latter sentiment as well :) 10.30.13 # pamaury: can you point me out how usb drivers in rb works? 10.30.40 # is there any documentation how to write usb driver? 10.31.05 # The Code 10.31.11 # wodz: sure, not really 10.31.37 # there are two different matters, both are very important: 1) usb detection 2) usb driver itself 10.32.05 # usb detection is easy - the core sets the flag when usb connect occures 10.33.12 # I think there's also a separation in high-level more-or-less-generic "USB" code (e.g. the USB HID and MSC) and driver level USB code (to drive a specific USB controller) 10.33.14 # wodz, what do you mean with how cache performs ? 10.33.37 # see jhMikeS question 10.34.04 # of, the tricky part with usb detection is to make the whole machine work, it's a bit messy; for the usb driver 10.34.12 # you need to implement these functions: 10.34.30 # usb_drv_init -> one time init (once per connection); so basically enable the usb core 10.34.45 # (and boost if needed, very important on some !) 10.34.53 # usb_drv_exit -> the oppositze 10.35.28 # usb_drv_port_speed -> return the port speed, I don't remember the value but basically it's 0=full speed, 1=high speed or the converse 10.35.42 # oh, usually the best combination is code in IRAM along with the most frequently used data 10.36.20 # usb_drv_request_endpoint -> reserve a endpoint; have a look at how other drivers to it; usually this is some administrative stuff + bit stuffing in the usb controller to set the type and max packet size 10.36.24 # TheLemonMan: thats obvious the question is whats more important on ingenics as Iram is tight 10.36.38 # usb_drv_release_endpoint -> converse 10.37.17 # pamaury: we reserve Control endpoint bulkin, bulkout 10.37.23 # pamaury, something else? 10.37.33 # we don't reserve control 10.37.35 # I can get it to build if I take the mixer callback out of IRAM. all the loops are fairly small. there's probably junk in pcmbuf.c that is pointless to have in IRAM anyway as well. 10.37.37 # it's EP0, always 10.37.57 # it is never reserved, so don't alloc it to other drivers ;) 10.38.09 # we reserve bulk in/out, int in 10.38.58 # usb_drv_cancel_all_transfers -> kill all transfers; usually you need to set a bit for each endpoint and flush fifos. You should also call the completion handler with error status for everything 10.39.17 # usb_drv_recv -> setup a receive transfer; *non blocking* 10.39.35 # usb_drv_send setup a send transfer, *blocking* 10.39.45 # usb_drv_send_nonblocking -> "", *non blocking* 10.40.12 # usb_drv_set_test_mode -> set test mode, you can forget that for now, usually it's sufficient to bit copy the argument into some register of the controller 10.41.41 # usb_drv_set_address -> set the address (usually it's in a register); there is a problem here: some controller want the address to be set between control out and ack and some want to wait for the end of the transaction. In the first case, you need to write some code special code when getting setup packets and ignore this function (have a look at other drives) 10.41.44 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 10.41.56 # usb_drv_stall -> stall a endpoint; usually set a flag in the controller 10.42.04 # usb_drv_stalled -> ... 10.42.12 # and you are done ! 10.42.14 Join max131 [0] (~c3cf0579@giant.haxx.se) 10.42.14 # :) 10.42.17 # pamaury: does test mode actually work on any of our targets? 10.42.25 # easy :-) 10.42.59 # gevaerts: it's implemented :) 10.43.06 # Yes, I know that! :) 10.43.08 # I don't know if it actually works ;) 10.43.21 Join [Saint] [0] (~Saint]@119.224.72.2) 10.43.24 # I know I didn't get it to actually work on portalplayer 10.43.24 # pamaury: which driver would you recommend as a support? 10.43.28 # obiviously code would take more benefits by staying in iram 10.45.26 # wodz: target/arm/{usb-arc.c, usb-s3c6400x.c} and perhaps target/arm/as3525/usb-drv-as3525(v2).c 10.45.38 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 10.46.31 # Has the AMSv2 USB code been merged in rockbox already? I've got a patched version running r29857 now on my FuzeV2, and i was wondering if i still need to do patching on the current code base. 10.46.32 # TheLemonMan: it has no I-cache? the code execution is far more coherent because of small loops than the data 10.47.16 # jhMikeS: google says it has 16kB I-cache and 16kB d-cache 10.47.29 # it has separate D/I-cache so coherency isn't assured 10.47.37 # the amsv2 code doesn't work reliably 10.48.12 # max131: which patch ? 10.50.51 # if i remember well i applied both as3525v2-enable-usb.diff and as3525v2-usb.diff 10.51.49 # never tried the usb-pio.diff though 10.52.02 # TheLemonMan: I meant that the cached code is used over and over in a loop while the data would miss more often since it's way larger than 16KB. The ARM targets with separate I/D cache don't need much or any IRAM assistance with mixing. 10.53.37 # the as3525v2-usb.diff is perhaps not necessary (it's a hacky workaround), the other one is needed to enable usb 10.53.56 Quit wodz (Quit: Leaving) 10.55.57 # if all the data is used into the looping code then it's a problem 10.56.03 # @pamaury, when you say the amsv2 code doesn't work reliably, do you mean the stock rockbox code, without any patch applied? 10.56.31 # max131: the patch just enables the usb code already in svn 10.56.41 # the stock have it disable but with the patches it's unreliable; it works for some, doesn't work for others 10.56.44 # it doesn't work reliably on all players 10.57.09 # ok, happy to hear that code is checked in in svn 10.57.10 # but if just a small part is accessed really often it's better to cache that to avoid frequent misses 10.57.13 # meh, there's no room on MIPS to be picky anyway 10.58.00 # and it seems i'm a lucky guy because USB is pretty stable on my FuzeV2 10.58.28 # max131: me too :) 10.59.17 # so is it in autoconf.h that i have to enable USB for the FuzeV2? 11.00.00 # no, the enable-usb.diff patch is the right way to enable usb 11.00.21 # sideral: ping 11.02.45 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.03.17 # does enable-usb.diff apply cleanly onto r30099? I remember i had to try a couple of times when i did that on r29857, and still suffered from some failed hunks ... 11.03.53 Quit einhirn (Client Quit) 11.03.56 # don't know, but it's a couple of lines so it's easy to apply it by hand 11.04.21 # (you only need to change the file related to your device) 11.04.46 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.05.03 # alright, thanks for this info. If i find some time i'm gonna try that out this evening, as i'm not my dev-environment right now 11.05.52 # pamaury, i wrote some code that hopefully will make the screen work, but when i send it the player discards the last packet 11.06.05 # i tried padding the size to 0x40 and stuff like that but had no luck 11.06.23 # is there something special i have to do with the elf ? 11.07.47 # not to my knowledge 11.07.56 # how to you it discards the last packet ? 11.07.59 # *do you 11.10.23 # *know 11.12.50 # my tool hangs when sending the last one 11.13.17 # but works well when sending the original nand loader 11.15.32 # if you don't find, try sending them to me, I'll have a look; I don't have an idea right now 11.18.15 Quit max131 (Quit: CGI:IRC) 11.20.43 # * [Saint] declares that voice is *horrible* with svn head on Android... 11.21.18 # libusb returns -7 :| 11.21.40 # Hi pamaury! 11.22.52 # [Saint]: Meaning what exactly? 11.24.30 # I'd expect it could be acting much like the sim did initially 11.24.37 # <[Saint]> it's very choppy. 11.24.50 # <[Saint]> like it's cutting in/out many, many times a second 11.25.25 # sound like the same problem because it's not actually mixing at a steady rate 11.25.31 # <[Saint]> and that's not even with audio playing 11.26.55 # yep, that won't change it. it needs to be paced out in the main pcm callback 11.29.00 # voice decoding buffer latency is only about .06 seconds 11.33.06 # obviously whatever kugel uses has small buffers since he reported no negative issues to me with voice 11.34.08 # sideral: hi, are you still willing to send me your clip+ ? I forgot mine at my mother's home and won't have the opportunity to get it back before one month... 11.34.24 # that's now or never ! :) 11.35.17 # TheLemonMan: what is the error code associated with -7 ? 11.37.46 # timeout error 11.39.15 # New commit by 03jethead71 (r30100): Do some adjustments to alleviate IRAM congestion on some targets from r30097. Include removing pointless IRAM declarations in pcmbuf.c because that ... 11.39.49 # TheLemonMan: did you try to send it with the windows tool ? 11.40.12 # don't have a windows box 11.40.31 Quit antil33t () 11.42.52 # and a VM ? 11.43.29 # r30100 build result: 3 errors, 0 warnings (jethead71 committed) 11.43.43 # i havent had much luck with wms 11.45.11 # weird delta, like IRAM wasn't being measured right in the size table :\ 11.45.51 # TheLemonMan: so your code is never run ? 11.46.01 # it doesnt even reach the player 11.46.01 # pamaury: Yes, I'm still willing to do that. But will you be able to debug this with multiple hosts? 11.46.36 # jhMikeS: why did you remove icode for so many targets? 11.47.33 # Yes, I will have the opportunity to temporary steal the computers of my housemate ;) 11.47.50 Quit FOAD (Read error: Connection reset by peer) 11.48.24 Join FOAD [0] (~dok@83.161.135.61) 11.48.56 # kugel: in pcmbuf.c I killed a bunch of it for everything. it's rather a waste. 11.49.21 Quit FOAD (Read error: Connection reset by peer) 11.49.31 # jhMikeS: I mean MIXER_CALLBACK_ICODE 11.49.33 Join FOAD [0] (~dok@83.161.135.61) 11.49.40 # pamaury: OK. I'll back it up hopefully tonight, so it could be in the mail tomorrow 11.52.38 # kugel: If the caching is good, I'd rather not waste it on that 11.57.51 # might have to take a hike from IRAM on m5 as well 11.58.56 # sideral: ok, thanks 11.58.57 # unless something else can get out of the way 11.59.59 # jhMikeS: IRAM is excluded from the delta table. It's only dram and code (with the latter contributing to the former, as we're not delta-ing rom builds) 12.01.56 # TheLemonMan: well, all your code except the last packet reaches the player :) 12.02.56 # amiconn: why is m5 so overfull? 12.03.44 Quit bertrik (Read error: Connection timed out) 12.03.58 # Because you added too much? 12.04.17 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 12.04.18 Quit bertrik (Changing host) 12.04.18 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 12.04.34 # the greyscale cf's have (both) framebuffers in iram iirc 12.05.03 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 12.05.56 # n1s: well, so does H100, but apparently, it's much larger on iAudio models. 12.05.56 # TheLemonMan: how do you procude the sb file ? 12.06.12 # i used the freescale tool 12.06.16 # had it to spare on H100 12.06.30 # jhMikeS: M5 has greyscale main lcd (same resolution as H1x0) *and* greyscale remote (unlike the irivers) 12.07.34 # *produce 12.08.21 # TheLemonMan: perhaps try the one I wrote for rockbox ? It might be that the freescale one make some assumption... 12.08.46 # does it take the same database format as the official one ? 12.08.56 # a subset of it 12.09.03 # and there's 2k of pcm frames now 12.09.30 # TheLemonMan: but you successfully sent custom code to your player, didn't you ? 12.10.01 # not really, i never had working code on that 12.10.58 # and if you only send the init stage you extracted from the OF ? 12.12.07 # nothing happens 12.12.37 # but it successfully send the code... 12.13.16 # jhMikeS: Btw, main lcd framebuffer is exactly the same size on both (0x140c bytes) 12.16.00 # TheLemonMan: does your custom code uses the ocram ? 12.16.30 # yep 12.16.42 # I think the ROM has a limitation: it uses the upper part of the ocram for itself and leaves the lower part for the custom code 12.17.30 # the official nand booter is rebased at 0 too so dont think it's a space limitation 12.18.38 # I mean, the ocram is 32kb (confirm ?), and the bootloader uses the higher 16kb so you shouldn't load more than 16kb to ocram at address 0 with the sb file 12.18.56 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.19.06 # just trying to help :) 12.19.53 # yep, 32kb and mirrored at 0x8000 12.20.41 *** Saving seen data "./dancer.seen" 12.23.11 # I don't see what else could be wrong 12.24.34 # argh, where the heck could it come from. taking mixdown buffers out of IRAM would be about the worst thing to do there (shortening them is kinda bad too) 12.30.43 Quit hobby16 (Ping timeout: 264 seconds) 12.38.46 Quit Keripo (Quit: Leaving.) 12.43.16 # jhMikeS: how much did your patch increase the iram usage? 12.49.15 # amiconn: in lcd-m5.c:lcd_blit_mono is there a reason the buffers can't be on the stack? 13.00.11 # n1s: the principle increase is 2k for the mixdown double buffer, which can have a smaller size at the expense of more interrupts 13.01.53 # there seems to be a *lot* of lcd code in iram i wonder how much that actually gains 13.03.46 # looks like ~4.8k for all the lcd_* functions in icode 13.12.24 # test_fps ought to say 13.13.18 # data's definitely the killer there 13.14.26 # * Torne ponders what to actually do with this git repo with 7 roots and 134 heads now he's *got* it. :) 13.15.11 # I remember way back not gaining much with dsp code that just did small loops using icode 13.16.33 # 134 heads? 13.16.53 # GodEater: Yup! Many of them are tags, though 13.17.00 # ah thank goodness 13.17.15 # well okay there are still 33 non-tag heads. 13.17.21 # the 7 roots is more interesting :) 13.17.32 Join dfkt|n [0] (dfktn@unaffiliated/dfkt) 13.18.03 # what on earth have we done to manage that? 13.18.13 # well, themes and translate are entirely seperate histories 13.18.21 # so there's going to be at least three. 13.18.27 # www? 13.18.33 # www is actually branched from inside trunk 13.18.39 # since it used to be a subdirectory 13.18.46 # jhMikeS: yeah, i think only pixelma has an m5 though 13.18.48 # this means the root there is trunk/www, not www 13.18.57 # and that history includes duplicate copies of all commits that touched trunk/www before the split. 13.19.01 # which is fun. 13.19.11 # as it means therea re multiple git commits with the same svn revision number :) 13.19.24 # likewise for songdbj 13.19.43 # and then the same thing happens a couple more times possibly by accident where people have sometimes branched only subtrees of trunk for rbutil/bootloaders/etc 13.20.05 # some of this will go away when i push stuff to seperate repos, but the bootloaders/rbutil subtree branches are.. interesting. 13.25.02 # n1s: ok, then who cares if it works any more :P 13.25.20 # i bet she does :) 13.26.19 # exactly 13.29.44 # of course I can only test what I have and infer from that if there's an impact 13.32.35 # n1s: If you can make sure that all plugins use it from the main thread *only*, they could be on stack. Otherwise they wouldn't be in iram 13.33.17 # amiconn: ah, didn't think of plugins 13.33.23 # Oh, and you can't 13.33.42 # Greylib uses it, meaning that the isr uses whatever stack is currently active 13.34.16 # n1s: lcd_blit_* are specifically for plugin use. They're not used in the core at all 13.34.41 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 13.34.55 # hmm 13.35.05 Quit pamaury (Read error: Operation timed out) 13.35.07 # Hmm, actually greylib doesn't use it 13.35.31 # test_scanrate does though, also in an isr 13.35.55 Join AlexandrosSchill [0] (~9bf52b4c@giant.haxx.se) 13.36.12 # chip8 and lua use it too (also video.rock but that's archos only) 13.36.34 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.37.10 # amiconn: do you know what kind of impact moving some of the lcd code to dram would have? 13.37.43 # Hi! I just registered in the wiki and I was wondering if I could be added to the WikiUsersGroup? 13.43.11 Join max131 [0] (~c3cf0579@giant.haxx.se) 13.43.25 # <[Saint]> AlexandrosSchill: Assuming your real name is Alexandros Schill, it's done. 13.43.35 # <[Saint]> You can edit the wiki (don't break it) as you please. 13.43.39 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 13.43.41 # <[Saint]> ;) 13.45.24 Quit n1s (Remote host closed the connection) 13.46.24 # sorry, it is AlexandrosSchillings 13.46.32 # irc truncated the name 13.47.31 # Torne: I wonder why svn tags don't translate to git tags? 13.47.42 # kugel: because svn tags are normal commits and thus can contain diffs 13.47.52 # And quite a few of our old ones *do* contain diffs :) 13.48.07 # Don't worry I won't mess around. I'll fix a few missing links that I found when I was researching putting rockbox on my fuzev2 13.48.22 # some because people were "naughty" and some because the git conversion handles tagging only a subdirectory interestingly 13.48.27 # Torne: oh, that sucks balls 13.48.36 # kugel: I'm going to do magic to fix it where possible. 13.48.44 # The actual release tags for 3.0+ are fine 13.48.46 # they can become real git tags. 13.49.10 Quit max131 (Quit: CGI:IRC) 13.49.20 # Torne: can we drop all tags except releases and bootloader tags? or do those contain tags too? 13.49.23 # diffs* 13.49.29 # Some of them 13.49.35 # Different things were done differently. 13.49.39 # it's not a problem, seriously. 13.49.53 # The things that have diffs can also become git tags, the branch is not required 13.50.03 # the existence of the tag keeps the commit reachable even if no branch head points to it 13.50.16 # it just looks slightly odd in a history graph, but only if youa ctually bother to look back that far. 13.51.12 # I'm probably going to keep all the old tags and branches just for historical reference but will put them in refs/oldheads or similar 13.51.26 # which will mean git clone won't bother to fetch them by default and thus you won't see them unless you explicitly pull them 13.51.47 # (like gerrit's review branches and so on) 13.51.57 # <[Saint]> AlexandrosSchill: Ok, AlexandrosSchillings added, sorry for the confusion. 13.52.03 # even with all that history included the repo is only 140MB so screw it. 13.52.10 # <[Saint]> I was joking about breaking the wiki, by the way. Welcome aboard. 13.52.12 # git delta compression is excellent ;) 13.52.32 # I only worry about a too large git branch tab completion :) 13.52.50 # kugel: Yeah, that's reasonable 13.53.56 # the default refspec for a fresh clone fetches refs/heads/* to refs/remotes/origin/* so anything outside heads won't appear in your tab completion as your local repo won't know about it 13.54.58 # Nah, my bad. I should have noticed 13.55.29 # Works fine. Thanks! 13.55.39 # <[Saint]> No worries, happy to help. 13.56.12 # Torne: can stuff be moved to oldrefs afterwads? 13.56.23 # kugel: yup. 13.56.26 # i.e. move v3_0 to oldrefs in a few years? 13.56.48 # it won't actually disappear in people's existing copies unless they git fetch --prune 13.56.53 # but it won't appear in new copies 13.57.01 # that's cool 13.57.11 # git remote show shows prunable refs 14.15.13 Quit knittl (Ping timeout: 240 seconds) 14.15.33 Quit Farthen (Ping timeout: 250 seconds) 14.16.11 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 14.16.38 Join crwll [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 14.16.59 # lol...I actually measure a small speed increase if I take bitmap routines out of iram on h120 14.17.27 Quit AlexandrosSchill (Quit: CGI:IRC) 14.18.09 Quit crwl (Ping timeout: 250 seconds) 14.20.41 # jhMikeS, n1s: Since coldfire has icache, having code in iram isn't that important. It can still be useful for code that is used a lot 14.20.46 *** Saving seen data "./dancer.seen" 14.21.45 # The icache is somewhat nasty. Because it's direct mapped,relative location of functions in dram matters. This is probably what you're seeing 14.22.58 # It's only about 11 fps (4621/4611), just substituting regular lcd_bitmap functions for the greylib calls 14.23.46 # s/4611/4610/ 14.41.59 # If those bmp functions are moved to dram, then there's some iram to spare without much to worry about for speed. I just wonder, is it really critical in that sense on any other target to have them as icode? 14.46.17 # Substituting what, where? 14.47.41 # calling rb->lcd_bitmap instead of grey_ub_gray_bitmap since test_fps doesn't do the framebuffer functions by default 14.48.19 # Use test_gfx 14.49.10 # heh...forgot about that one 14.49.11 # Hmm, that one doesn't do native bitmaps though 14.49.25 # oh 14.49.27 # But it does text, i.e. mono bitmaps 14.50.52 # test_fps() is probably a bad example, because it uses large bitmaps, where most time is spent in lowlevel stuff like memcpy() 14.54.23 # what do you mean? I just see small loops calling grey_ub_gray_bitmap 15.00.04 # The bitmaps are large though (fullscreen and 1/4 screen) 15.02.39 Quit esperegu (Remote host closed the connection) 15.04.51 Join Thra11_ [0] (~thrall@87.115.145.253) 15.07.13 Quit Thra11 (Ping timeout: 240 seconds) 15.11.17 # I guess for the font rendering it does help 15.11.38 # Do we want git tags to be v3_0 like the svn ones, or would it be nicer to call them v3.0 since git doesn't care what characters are in them? 15.11.48 # using the dot would make git describe output look nicer ;) 15.11.50 Quit krazykit (Ping timeout: 244 seconds) 15.12.27 # jhMikeS: test_gfx checks font rendering 15.12.33 # and other lcd_* functions 15.13.49 # that's why I was using it...to judge the impact, which on h100 is about -18% if moving to dram 15.17.07 Quit bertrik (Read error: Connection timed out) 15.17.36 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 15.17.36 Quit bertrik (Changing host) 15.17.36 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 15.22.36 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 15.25.58 Quit Thra11_ (Ping timeout: 255 seconds) 15.29.28 # this went on longer than I though. I'll just get the red off the table for the moment. I've got a couple really important things to take care of in RL. 15.32.10 # 97 branch heads, getting somewhere :) 15.34.42 # Torne: what to do about the branches which are clearly not branches? dast,Rockbox, ...? 15.34.49 # kugel: I've blown them away, they have no content 15.35.07 # good :) 15.35.15 # they are an artifact of cvs branching/tagging that was copied over by cvs2svn 15.35.34 # i'm keeping anything with an actual diff in it, but not things which just have file removals because of partial tree cvs branch/tags 15.42.20 Join Thra11_ [0] (~thrall@87.115.145.253) 15.43.34 Join promyloph [0] (~foo@unaffiliated/promyloph) 15.43.49 # New commit by 03jethead71 (r30101): Get M5 building again by moving the downmix buffer out of IRAM for now. Everything should still work. It doesn't have any apparently measurable effect ... 15.44.05 # jhMikeS: What about changing the iram split for MCF5250 back to what it used to be? 15.44.22 # (provided codecs don't actually use up everything) 15.46.36 # I could explore that later. m5 is mc5249 though 15.47.32 # unless that's wrong with IRAM size only being 0xc000 15.47.52 # wait, erm 15.47.54 # r30101 build result: All green 15.48.06 # x5 also lists as that 15.48.35 Join MethoS- [0] (~clemens@134.102.106.250) 15.48.58 # ok, yeah, lcd_framebuffer is in COMMON 15.51.51 # Both X5 and M5 are MCF5250. M3 and the irivers are MCF5249 15.52.54 # The former has 128KB IRAM, the latter only has 96KB. Atm we're splitting it 48/80 for MCF5250; it used to be 64/64 15.53.43 # And of course the X5 framebuffer isn't in iram - it's way larger than the M5 (and H1x0) framebuffer 15.54.30 # the mixer buffer *must* be DMA compatible though and as I remember the second bank isn't 15.55.53 # Correct, but not a problem 15.56.30 # The first (== dma capable) block is 64KB for both MCF5249 and MCF5250 16.01.19 Quit Thra11_ (Ping timeout: 264 seconds) 16.07.06 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 16.17.06 Quit Judas_PhD (Quit: This is a quitting message) 16.20.49 *** Saving seen data "./dancer.seen" 16.24.36 Join elcan [0] (user36@pr0.us) 16.28.24 # I had a couple minute to check it out while getting ready: if I move the boundary by 2k, all is well. If I move it by 4k, cook.codec fails. 16.29.52 # 47 branch heads, and now i need to do some work :) 16.36.11 Join krazykit [0] (~krazykit@206.183.182.189) 16.36.54 # too bad the remainder after the core build can't just get fed over to the codec/plugin portion :) 16.38.05 # what could cause a eMMC (or SD) card to NOT work at high speed ? (but the switch itself workà 16.41.40 # kugel: what was the reason to use dot and dotdot instead of direct "." and ".."? 16.42.28 Join evilnick [0] (~evilnick@ool-18bee3a9.dyn.optonline.net) 16.42.28 Quit evilnick (Changing host) 16.42.28 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 16.43.57 # kugel: now you have to call everywhere generate_dot_d_names() and make code harder to read for no apparent reason 16.43.59 Quit elcan (Quit: Changing server) 16.45.36 Join patheticbliss [0] (~calvin@75-134-134-13.dhcp.roch.mn.charter.com) 16.47.23 # urg, that's weird, you can't change the timings without affecting the timeout on the imx ssp, that explains *lots* of things 16.55.03 # Slasheri: "." and ".." are string literals and not in the dircache allocated memory 16.55.42 # it's simpler to put them into the allocation than to add lots of complexity into the relocation code 16.55.51 # I thought I added comments about this? 17.02.28 # ah, yes. That's a problem when loading dircache dump indeed 17.02.47 # i am just trying to fix the re-building issue with dircache 17.03.39 # kugel: I can have a look later, but first I'm going to set up my new shiny ssd :) 17.07.08 Quit factor (Ping timeout: 260 seconds) 17.15.03 # gevaerts: what might make the arc controller don't work with packets >32 bytes ? My fuze+ is already running at top speed (cpu + ahb) so I can't see anything 17.17.04 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 17.22.37 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 17.31.06 Quit bertrik (Read error: Connection timed out) 17.31.48 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 17.31.49 Quit bertrik (Changing host) 17.31.49 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.32.53 Quit mikroflops (Ping timeout: 244 seconds) 17.34.45 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 17.45.27 Quit [Saint] (Ping timeout: 252 seconds) 17.55.12 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 17.56.33 Quit petur (Remote host closed the connection) 17.59.23 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.13.12 Quit sideral (Quit: Leaving.) 18.16.42 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.20.53 *** Saving seen data "./dancer.seen" 18.28.01 Join [Saint] [0] (~st.lasciv@119.224.72.2) 18.29.16 Quit [Saint] (Client Quit) 18.30.25 # "Writes must be DWORD writes" but the OF does BYTE writes... 18.30.29 Join [Saint] [0] (~st.lasciv@119.224.72.2) 18.30.59 Quit [Saint] (Disconnected by services) 18.30.59 Join S_a_i_n_t [0] (~st.lasciv@119.224.72.2) 18.31.02 Quit S_a_i_n_t (Remote host closed the connection) 18.31.12 Join [Saint] [0] (~st.lasciv@119.224.72.2) 18.31.23 Nick [Saint] is now known as S_a_i_n_t (~st.lasciv@119.224.72.2) 18.31.28 Nick S_a_i_n_t is now known as [Saint] (~st.lasciv@119.224.72.2) 18.31.46 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 18.31.49 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 18.53.39 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 18.59.27 Quit bertrik (Read error: Connection timed out) 18.59.54 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.59.55 Quit bertrik (Changing host) 18.59.55 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.00.24 Quit TheLemonMan (Quit: Ex-Chat) 19.01.42 Quit bluebrother (Disconnected by services) 19.01.43 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 19.04.08 Quit fs-bluebot (Ping timeout: 250 seconds) 19.05.18 Join fs-bluebot [0] (~fs-bluebo@g224238179.adsl.alicedsl.de) 19.06.12 Quit promyloph (Quit: WeeChat 0.3.5) 19.06.55 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 19.10.47 # what is the typical read speed of the internal flash in our various players ? 19.21.08 Quit liar (Ping timeout: 258 seconds) 19.22.39 Join sideral [0] (~sideral@rockbox/developer/sideral) 19.23.24 Quit sideral (Remote host closed the connection) 19.25.07 Join sideral [0] (~sideral@rockbox/developer/sideral) 19.26.17 Join Thra11_ [0] (~thrall@87.115.145.253) 19.28.10 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 19.31.33 Join Horscht [0] (~Horscht@p5DD5741B.dip.t-dialin.net) 19.31.34 Quit Horscht (Changing host) 19.31.34 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.33.14 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 19.33.39 Quit sideral (Remote host closed the connection) 19.34.13 Join sideral [0] (~sideral@rockbox/developer/sideral) 19.34.38 # pamaury: http://www.rockbox.org/wiki/DiskSpeed has a few entries for flash targets 19.39.06 Quit bertrik (Read error: Connection timed out) 19.39.47 Quit thomasjfox (Remote host closed the connection) 19.39.59 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.39.59 Quit bertrik (Changing host) 19.39.59 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.43.54 Quit sideral (Remote host closed the connection) 19.44.07 Quit GeekShadow (Quit: The cake is a lie !) 19.45.37 Join sideral [0] (~sideral@rockbox/developer/sideral) 19.46.08 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 19.47.35 # pamaury, AMSv2 (clip+) is quite slow, 3MB/s or so IIRC 19.47.40 Part Transformer 19.48.05 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.57.04 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 19.57.27 Quit tchan (Disconnected by services) 19.57.34 Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 19.57.45 Quit tchan (Changing host) 19.57.45 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 19.59.02 # the fuze+ seems to sustain 21.5Mib/s through usb with custom code 20.02.02 Join Jerom [0] (~jerome@79.132.36.219) 20.20.55 *** Saving seen data "./dancer.seen" 20.21.15 Quit Jerom (Quit: Leaving.) 20.21.58 Join smk [0] (~smk@49.203.175.83) 20.23.31 Part smk 20.23.35 Join Jerom [0] (~jerome@79.132.36.219) 20.23.49 # pamaury: I am trying to understand usb_drv_request_endpoint() and I can't. I mean does one setup particular endpoint to act as IN/OUT BULK/INT/CONTROL ? 20.24.52 # each driver calls usb_drv_requesr_endpoint to configure a endpoint; it is the driver responsability to try to find one free which can handle this particular type/direction 20.25.57 Quit Jerom (Client Quit) 20.26.04 Quit ReimuHakurei (Quit: If I use this, I will disappear, and Shana-tan will remain...) 20.26.17 Join ReimuHakurei [0] (~reimu@74.112.212.15) 20.27.10 # so basicaly I have to map requested type|dir to physical endpoint? 20.28.09 # there can be several request with the same parameters 20.28.15 # to request several endpoints 20.31.01 # hmm I am slowly starting to understand 20.31.37 # let's take an example: you device has 3 endpoint, each endpoint can handle any type and is bidirectional 20.31.58 # mine has 16 endpoints 20.32.02 # is someone request a bulk ep IN, you will configure EP1IN as bulk 20.32.19 # then if someone request a int ep OUT, you will configure EP2OUT as int 20.32.38 # ha here is the trick - rk27xx has predefined endpoints 20.32.42 # finally, if someone request a bulk ep OUT, you can configure EP1OUT as bulk because EP1 is bidirectional 20.33.06 # wait, I'll have a look a the rk27xx datasheet 20.33.12 # I can't switch BULK1 into something else 20.34.29 # indeed, in your case you have unidirectional endpoints 20.36.47 # EP1=bulk out,EP2=bulk in,EP3=int in, EP4=bulk out,EP5=bulk in,EP6=int in, ... 20.37.46 # so you only need to keep a map of boolean saying for each endpoint if it used or not. when requested for a endpoint, you look for the first endpoint of that type which is free and select it 20.39.05 # * amiconn should probably try to cut down the coldfire memcpy/memmove asm once more 20.39.17 # It's a monster... 20.39.59 # There is an idea that might work... just last time I tried to implement it I couldn't get my head around it 20.41.05 Join mikroflops [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 20.41.36 # amiconn: can't we use spare DMA channel for larger transfers? 20.41.50 # nope 20.41.59 # why? 20.42.15 # DMA with auto-align is broken, and without it it's slower than using the cpu 20.42.39 # broken i which way? 20.43.06 # I recall we set aa mode in pcm driver 20.43.29 # It transfers garbage if enabled 20.44.06 # so why we use this in pcm transfers? 20.44.19 # Auto-align? 20.44.22 # Afaik we don't 20.44.32 # hmm pcm transfers are 4byte aligned I guess 20.44.51 # DCR0 = DMA_INT | DMA_EEXT | DMA_CS | DMA_AA | DMA_SINC | DMA_SSIZE(DMA_SIZE_LINE) | DMA_START; 20.44.58 # so I guess we use AA 20.45.07 # There are further restrictions. (1) memcpy/memmove might be called in an isr, potentially interrupting another memcpy/memmove. We'd have to protect from this and resort to using the cpu if it happens -> more complexity 20.45.32 # Hi. http://www.rockbox.org/wiki/MajorChanges still lists changes since 3.8 (SVN), maybe this could get updated. Thanks for the new release. 20.45.41 # (2) Iirc DMA can only copy forward -> it can't be used for memove if the kind of overlap demands backwards copying 20.45.59 # (3) There are memory blocks (namely the second iram bank) which aren't dma capable 20.46.53 # wodz: It may be that auto-align works in (dma capable) iram, but when I tried it with dram (for H300 lcd) it didn't work 20.48.12 # the fact that pcm samples are 4bytes alligned may be the reason it just work 20.49.06 # It would only be useful if dma would actually be faster, because we'd have to busy-poll for completion 20.49.50 # Usually we'd set up an isr for signalling completion and then yield(), but we can't do those things in stuff as low-level as memcpy 20.50.10 # It might be called before the threading system is set up, or with interrupts disabled etc... 20.51.13 # At least in my tests on mpios dma was faster than somehow optimized writes to lcd. But other problems with DMA are predominant here 20.51.41 # anyway memcpy/memmove *are* the monsters :-) 20.51.44 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 20.53.47 Quit bertrik (Read error: Connection timed out) 20.54.03 # On H300 dma is also faster for the lcd, but the frramebuffer is suitably aligned 20.54.13 # memcpy has to cope with any alignment 20.54.38 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.54.38 Quit bertrik (Changing host) 20.54.38 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.56.24 # interrupt ep is always in? 20.56.44 # no 20.57.01 # Most uses probably are though 20.57.15 # hmm so looks like rk27xx has no out interrupt endpoint 20.58.05 # In fact, I can't really think of anything more or less common that actually uses interrupt out 20.58.51 Join benedikt93_ [0] (~benedikt9@p5B0C524A.dip.t-dialin.net) 20.59.47 Nick benedikt93_ is now known as benedikt93 (~benedikt9@p5B0C524A.dip.t-dialin.net) 21.00.03 Quit benedikt93 (Changing host) 21.00.03 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 21.02.41 # Is there possibly an objection to IRAM splits between core and codec that are smaller grained than 0x1000? 21.05.43 # Not from me. Just keep in mind that you need to bum the codec and plugin api versions (including minimum version) when changing iram split 21.06.19 # oh, definitely. they won't link at the correct address. 21.06.36 # or currently be linked rather 21.06.36 # Actually this isn't necessary when moving the boundary down, but it definitely is when moving it up 21.07.10 # Well, I plan so far to move it up by 0x800 21.07.12 # The codecs and plugins would load and run, but they would overwrite part of core iram 21.07.25 # which is bad? :) 21.07.42 # You might wait whether we can free some iram elsewhere 21.07.49 # *might want to 21.08.37 # Sure, np. It still works anyway for what it has to do right now. Though, from where would it come? 21.08.55 # icode, probably 21.09.16 # E.g. the monster I mentioned ~half an hour ago 21.09.27 # ah, the memcpy/move monster 21.13.15 # it'll sure get used alot now unless I implement a cut-down specialty version like I did for arm, but for arm it's simple 21.26.25 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 21.31.42 Quit dfkt|n () 21.31.46 # gevaerts: an interrupt out would be really similar to a control out no ? 21.32.01 # (class specific, interface) 21.32.24 # * jhMikeS wonders why some of his files are missing props when he has svn-auto-props on 21.32.58 # pamaury: I can't remember the timing constraints for control right now 21.33.29 # it seems like they were files that were in one place but got "svn mv"ed before committing 21.35.11 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) 21.35.11 Quit dfkt|n (Changing host) 21.35.12 Join dfkt|n [0] (dfktn@unaffiliated/dfkt) 21.35.23 # jhMikeS: well fortunately props will go away soonish ;) 21.37.44 # pamaury: should usb_drv_request_endpoint() enable interrupt from requested endpoint or such configuration is in other place? 21.39.17 # it should enable it 21.39.20 # iirc 21.39.31 # Torne: whee...props then! :) 21.40.16 # jhMikeS: well technically git still tracks the executable bit, so people might screw that up 21.40.23 # jhMikeS: but that's the only metadata you can break ;) 21.41.19 # wodz: the important bit is that you get the interrupts :) I don't think it matters much whether you enable them from usb_drv_request_endpoint() or the controller init 21.41.32 # it's happened with SVN plenty of times already 21.42.38 Quit bertrik (Read error: Connection timed out) 21.43.12 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 21.43.13 Quit bertrik (Changing host) 21.43.13 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 21.44.51 # jhMikeS: git also has the cunning trick of detecting when it's on a crappy filesystem that doesn't have that kind of thing and then ignoring changes to the bit, though 21.45.11 Quit dfkt|n () 21.45.28 # jhMikeS: people on unixlike systems rarely make things executable by accident :) 21.47.05 # Torne: I never did it, I don't know how they got that way, but I know some non-executables were set as such. There were commits fixing that here and there. 21.47.15 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) 21.47.15 Quit dfkt|n (Changing host) 21.47.15 Join dfkt|n [0] (dfktn@unaffiliated/dfkt) 21.48.39 # jhMikeS: I recently fixed them all in svn :) 21.48.59 # and it generally happens because people use windows for some/all of their workflow. 21.49.07 # hmm interesting - address bits are marked as read only in datasheet 21.49.30 # oh, recent ones? I'd seen it some time way back. 21.50.13 # i was searching the repo for all our usage of svn properties, so i spotted all the svn:executables that didn't belong :) 21.51.28 # wodz: either it's wrong or the device automatically set it on set address 21.57.12 # pamaury: looks like the letter - OF doesn't write to this bits 21.58.54 # you will soon see if it the case or not :) 22.01.58 Quit dfkt|n () 22.03.25 Join dfkt|n [0] (~dfkt@unaffiliated/dfkt) 22.04.42 Quit evilnick (Quit: Leaving) 22.05.21 # kugel: btw, i think i have locally fixed the dircache issue but now debugging a possible tagcache problem 22.06.30 # did I introduce that also? 22.06.38 # pamaury: how are control transfers treated? 22.07.07 # kugel: i have no idea yet 22.07.13 Join T44 [0] (Topy44@f049145005.adsl.alicedsl.de) 22.07.19 Join factor [0] (~factor@74.197.205.204) 22.07.33 # wodz: just like other transfers 22.07.35 # with ep=0 22.07.43 # (for both direction) 22.08.51 # but _request_endpoint() is not called prior to this right? 22.09.18 # no 22.09.29 # EP0 is special and can't be requested 22.10.57 Quit Topy44 (Ping timeout: 255 seconds) 22.18.19 Join Thra11__ [0] (~thrall@87.112.167.192) 22.20.56 *** Saving seen data "./dancer.seen" 22.21.27 Quit Thra11_ (Ping timeout: 276 seconds) 22.25.24 Quit dfkt|n () 22.29.45 Join domonoky1 [0] (~Domonoky@agsb-5d871776.pool.mediaWays.net) 22.30.00 Join dfkt [0] (dfkt@unaffiliated/dfkt) 22.31.12 Quit domonoky (Ping timeout: 255 seconds) 22.48.36 Quit ender` (Quit: My computer NEVER cras) 22.50.01 # what's the most proper way to sleep a thread for a certain number of milliseconds on android that will always work? 22.50.55 # pthread_delay_np? 22.52.55 Quit Thra11__ (Read error: Operation timed out) 22.54.42 # anything suffixed _np I'd guess means "nonportable" (if I get the pattern) 22.54.57 # hmm 22.56.30 Join TheLemonMan [0] (~lem0n@ppp-197-58.26-151.libero.it) 23.07.54 Join Thra11__ [0] (~thrall@46.208.29.214) 23.12.25 Join Thra11_ [0] (~thrall@24.60.125.91.rb3.adsl.brightview.com) 23.14.18 # the partition tables in the fuze+ make no fucking sense :( 23.14.41 # it's just...wrong, nothing matches 23.16.03 Quit Thra11__ (Ping timeout: 276 seconds) 23.18.02 # it seems the real fat partition uses 2048 sector size but how the hell can you figure that out before find it !! 23.18.09 # and 2048 sector size is a mess :( 23.21.04 # does our fat code handles physical sector size != logical size or not ? 23.21.28 # good question 23.21.30 # I suspect not 23.22.01 # I suspect the same 23.22.23 # but on the other hand, 2048 sector size is wrong on this device, mmc at high speed has 512 sector size 23.22.46 # Maybe a pass-through translation storage driver? 23.22.48 # and 2048 sector size doesn't seem to match the main partition table 23.23.31 Join Thra11__ [0] (~thrall@87.112.139.71) 23.23.54 Nick Thra11__ is now known as Thra11 (~thrall@87.112.139.71) 23.24.20 # actual the situation is this: 23.24.20 # 1) main partition table has 4 entry: 2 are strange partition, 1 is a boot partition, 1 looks like an logical one (but not reported as this) => 2048 sector size don't match LBA !! 23.24.20 # 2) the logical one has one entry which point to this fat partition => 2048 sector size don't match LBA !! 23.24.36 Quit Thra11_ (Disconnected by services) 23.27.47 # Can you read real data from this eMMC? Maybe there is some other abstract layer - something like FTL? 23.28.10 # ... or data are crypted 23.28.20 # * jhMikeS will just wait for someone more informed in android domain to come up with a way to clock the pcm callbacks at a steady pace :) 23.28.47 # no, it's eMMC so there is no FTL (it's hidden) and it's not crypted either and the ROM is able to boot from it through the MBR !! 23.30.13 # that doesn't mean that this MBR is not mangled somehow 23.30.42 # it's fully documented in the imx doc :-/ 23.31.36 # data layout is documented in imx doc? 23.32.26 # the mbr indeed contains a sigmatel boot entry but the lba doesn't point to the actually bootloader, there is a 0x880 offset ot it 23.32.49 # mostly zero except for last part which contains a few 0xff so it's unused 23.33.19 # I must be missing something :D 23.33.36 Join evilnick [0] (~evilnick@ool-18bee3a9.dyn.optonline.net) 23.33.36 Quit evilnick (Changing host) 23.33.36 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 23.34.17 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.37.52 # wow, if I turn off usb clock and read udc register I get Data abort 23.39.54 Quit stripwax (Quit: http://miranda-im.org) 23.40.33 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.44.51 # Which target's Rockbox keymap is considered the most generic one (with the fewest deviations from the "Rockbox standard")? 23.45.21 # hum, several READ_SINGLE_BLOCK doesn't yield the same result as READ_MULTIPLE_BLOCK 23.45.56 # sideral: non 23.46.55 # wodz: Interesting :) I remember people saying the intra-Rockbox keymap consistency is valued higher than adhering to any other standard, such as the OF's 23.48.50 # sideral: Go figure yourself :-) Basic things are rather consistent but every keymap I studied had some quirks 23.49.46 # :) That's what I'm running into right now, switching from a Clip+ to a Fuze. 23.49.56 Quit domonoky1 (Read error: Connection reset by peer) 23.50.10 # I guess I'll have to make them all adhere to the sideral standard 23.50.35 # many targets have weird constraints which combos are allowed 23.52.07 # and keymap syntax is not that easy to follow AND you cannot test it reliably in simulator 23.53.54 # And the last - almost every plugin has its distinct keymap. This is real pain to get this all consistent. I failed with MPIOs. 23.55.52 Quit Thra11 (Ping timeout: 240 seconds) 23.55.59 Quit evilnick (Quit: Leaving) 23.57.10 # thanks for your comments, wodz. Strangely, this eases my task at hand, allowing me to not care ;) 23.58.33 # did I mentioned that keymap changes in more popular targets leads usually to hot discussions? :-)