#qi-hardware IRC log for Friday, 2014-11-07

arhuacowpwrak: If you live alone, you can talk to someone when you get bored :-P02:46
arhuacowpwrak: Talk to the cloud....02:46
wpwrakfunny, a while ago I showed the clip to a friend and she said pretty much the same thing ;-)03:19
kyak"... and much more" - people volunteeraly equip their houses with spy equipment, how convenient :)06:10
kyakweb camera/microphone in laptop? that's last generation06:11
kyakafter several days "alexa, shut up and kill yourself already, you all-knowing, intruding bitch!" :)06:13
wpwrakthe "permanent" listening is indeed a not so likeable feature there. i also wonder whether the cloud is really necessary for the pattern matching that happens when recognizing sentences.06:34
wpwrakbut i must say that the concept looks very attractive06:34
wpwrakof course, with something that star trek-ish, one has to wonder whether it can also handle this: "alexa, self-destruct, authorization alpha-alpha-three-zero-five."06:45
kyakwell, with almost everyone nowadays having smartphone with "ok google" feature, this tower looks unnecessary06:54
eintopfI want to say "computer" instead "ok google"06:54
eintopfkyak: for the matlab thing, I need to modelling a inverted pendelum control06:55
eintopfhttp://www.iforce2d.net/blog/2014-04-22 - something like this. This guy programmed a PID controller inside a physic engine06:56
kyakeintopf: that's been done many times, search pendulum control on FEX06:58
kyakthere are several interesting submissions, including Lego Segway examples06:59
kyakhttp://www.mathworks.com/matlabcentral/fileexchange/19147-nxtway-gs--self-balancing-two-wheeled-robot--controller-design07:00
kyakthis might be the most complete example of MBD07:01
wpwrak("computer") exactly ! that's the whole point. "computer ! put milk on the shopping list. how many fathoms in a parsec ? and, um, eject the warp core."07:01
eintopf(nxt lego) - yea we know these lego nxt things... but we have a real segway and other sensors for measurement some angles07:03
eintopfbut okay, maybe I need to begin really to start the working on this project07:04
kyakhttp://www.mathworks.com/company/user_stories/segway-llc-delivers-innovative-transporter.html07:04
kyakhow's this for a real segway? :)07:05
eintopfno we have some from china07:05
eintopfhttp://www.ewee-pt.com/07:05
wpwrakhmm, "we have a segway for measuring angles". i suppose google should hurry and get a few sr-71 for better google maps pictures, or you'll easily out-overkill 'em :)07:06
eintopfwpwrak: no there are other sensors07:06
eintopffor nxt lego they used the ultrasonic distance sensore and making pythagoras magic07:06
eintopf(ewee-pt) I have also the source code for the controller logic... this is visual basic code07:07
kyakoh god..07:07
eintopfbut the device is hackable07:07
eintopfinteresting is that there exist some visual basic compiler to generate avr code07:08
eintopf:D07:09
eintopfkyak: do you have also some skills for scilab?07:10
eintopfthese open source matlab thing07:10
kyaknope07:14
eintopfok07:14
eintopfmy prof. put me in the theory mathematical group. He knows that I am more a practical guy.07:15
eintopfwhen I am done I will publish my results somewhere... open source for everyone07:16
kyakyour aim is to develop segway controller that replaces one from ewee-pt?07:17
eintopfyes, but we not really replace the logic07:18
eintopfno time for that07:18
kyakthen what do you do?07:19
eintopfput the logic in some physic engine07:19
eintopfwith sensor parameter contstraints from ewee-pt07:19
kyakyou mean, you only want to model the logic with physical plant model?07:20
kyakwith the plant model representing the real ewee-pt device?07:20
eintopfwe only don't replace the logic because stupid laws in germany and because we don't have time07:20
eintopfyea, something like that07:20
eintopfkyak: this sounds realistic?07:22
kyakof course! 07:22
kyakin fact, Simulink is made just for this kind tasks.. dynamic systems and controls simulation07:23
eintopfhas already a builtin physics engine?07:26
kyaki'm not sure what you mean by that. It has physical modeling tools07:34
eintopfok07:55
larscapelete: yes, good to hear from you. Already though you got lost on your way home07:56
arhuacowpwrak: This is how the "echo" concept will probably evolve. https://www.kickstarter.com/projects/keecker/keecker-the-worlds-first-homepod/ Imagine this one with good speech recognition / IA.08:07
eintopf(keecker) this looks like a driving toilet08:09
eintopfmhhh, would be a great feature08:09
apeletelarsc: been silently busy indeed, but I'm fine :)08:10
apeletegot a minute or are you busy with work right now ?08:10
larsc5 minutes even08:11
apelete'kay08:15
apeletelarsc: I resumed porting dma-jz4740.c to jz477008:15
apeletetesting with the dmatest driver currently08:15
apeleteI noticed that dmatest does not request slave channels from dma: http://lxr.free-electrons.com/source/drivers/dma/dmatest.c#L87708:16
apeleteand that didn't worked with dma-jz4740 until I harcoded "request_channels(info, DMA_SLAVE);" in dmatest.c08:17
apeletelarsc: is that normal ? what capabilities is dma-jz4740 compatible with exactly ?08:18
larscI think it only test mem-to-mem08:18
wpwraknice. and i also like their realistic reward structure: all "mainstream" options that actually require them to make something are capped. so they're not at risk of waking up one morning with 10 MUSD on their account and the obligation to scale by 100x within weeks.08:18
larscanyway, 5 minutes are up, I have to go08:18
apeletelarsc: 'kay, no problem, we'll talk later then08:19
apeletethanks for you time ;)08:19
larscI'm back now08:49
apelete<larsc> I think it only test mem-to-mem08:53
apeleteat least it can be sued to know if the driver is working properly, right ?08:53
apeletes/sued/used/ :)08:53
pcercueisue him!08:53
apelete:D08:54
larscif the driver implements mem-to-mem08:55
apeleteoops, looks like dma-jz4740.c only implements mem-to-dev and dev-to-mem :(08:58
apeleteso dmatest will ultimately be useless to test it08:59
apeletelarsc: yesterday I was wondering why it didn't started any transfer at all -> http://paste.debian.net/130647/09:01
apelete(lines 154 and 226)09:01
apeletethere are obviously a few things wrong with my changes (the number of channels declared in dma-jz4740.c is wrong for instance)09:03
apeletelarsc: but if I get you right, then I'll be forced to test against the actual mmc driver it seems...09:04
apeletewhich I've been avoiding since I don't know to which extent I'm messing things up here :)09:05
larscyou can try read-only for now09:05
larscthat should be pretty save09:05
larscsafe09:06
apeletelarsc: you mean putting the sd card in read only mode while booting ?09:06
larsconly use DMA for read operations09:07
larscbut not for write operations09:07
apeleteok09:07
pcercueimmc-jz4740 already uses DMA, no?09:07
apeleteyes it does, for read and write09:08
apeletebut I wanted to get the dma driver right before testing against the mmc driver09:09
pcercueiok; so it does not use the standard DMA API then?09:09
apeleteon jz4740 it does09:11
pcercueiyou're working on jz4770 now?09:16
apeleteyes, porting the mmc driver from jz4740 to jz477009:24
apeleteand the mmc driver pulls in the dma driver09:24
pcercueiok, great09:26
pcercueiso I guess you can use the old driver for the internal card, and your new driver for the external SD card09:26
pcercueiif that makes things easier to test, that is09:26
apeletedidn't think about that, may be a good idea indeed09:29
pcercueionce you have something to test, I can use my proto09:32
pcercueiwith the current driver, I reach ~250 KiB/s maximum09:32
pcercueiwrite speed09:32
apelete'kay09:56
mthapelete, larsc: from the docs (section 4.4.1), it seems auto-request mode (8) can be used for memory-to-memory transfers11:55
mthso it might be an option to add that feature to the DMA engine driver11:55
mthto make it easier to test and perhaps to do useful work in the future11:55
larscyes11:56
larscthe peripheral supports it, the driver does not11:57
apeletemth: good to know, added to the todo list just in case I get too much free time ;-)14:22
pcercueidoes that ever happen?14:23
apeleteloads and loads of free time during my sleep actually14:27
mthI was thinking of it not just as a nice-to-have feature, but a way to save time on testing, since if you have mem-to-mem transfers, I think you can use the existing test code14:27
apeletebut then I wake up and it's all gone :-(14:27
pcercueiI usually debug when I sleep14:28
pcercueihappens quite often that I get ideas about my various projects, in my sleep14:29
apeletemth: that's what I thought too, don't know how long it would took to implement though14:29
apeletepcercuei: completely agree, debugging while sleeping seems to work really well 14:31
mthdma_cap_set of DMA_MEMCPY and implement a device_prep_dma_memcpy handler, I think14:33
mthand jz4740_dma_slave_config would probably have to handle DMA_MEM_TO_DEV14:37
mtheh, DMA_MEM_TO_MEM14:37
viric:b114:39
viricoops14:39
mththe memcpy interfact doesn't use sg lists, so it's probably a bit easier to set up then a slave transfer14:39
mthah, there is also device_prep_dma_sg which has sg for both source and destination14:42
mthsupporting that would be a bit tricky, since the hw has DMA descriptors which contain both source and dest, so you'd have to weave the two sg lists together somehow14:43
mththe DMA test seems to check DMA_MEMCPY, DMA_XOR and DMA_PQ capabilties, so double sg is probably not needed for testing14:47
apeletemth: it's either implement a new device_prep_dma_memcpy handler from scratch OR modify jz4740_dma_slave_config to handle DMA_MEM_TO_MEM, but not both right ?14:55
mthdevice_prep_dma_memcpy is called explicitly by dmatest.c, so you certainly need that15:01
mthdma_slave_config is not called explicitly, but a DMA_MEM_TO_MEM direction does exist, so I don't know if it might be called indirectly15:02
mthor maybe that's only needed for sg-to-sg transfers then?15:03
mthI know very little about DMA engines, just had a quick look at the code15:03
apeletemth: in dma-jz4740.c device_prep_dma_* are callbacks to be registered -> http://lxr.free-electrons.com/source/drivers/dma/dma-jz4740.c#L56215:04
apeleteso I guess device_prep_dma_memcpy would be added there15:04
apeletethe question is, would it be used to register a modified version of jz4740_dma_slave_config that can handle mem-to-mem transfer15:05
apeletes/jz4740_dma_slave_config/jz4740_dma_prep_slave_sg/15:06
apeleteor to register a new jz4740_dma_prep_memcpy handler ?15:07
mthjz4740_dma_prep_slave_sg and jz4740_dma_prep_dma_cyclic are mostly the same, so I think a modified variant of those can be used as jz4740_dma_prep_memcpy15:08
mthsince there is no sg input, it would have to build only a single entry descriptor list15:09
mthah, jz4740_dma_start_transfer should support MEM_TO_MEM direction as well15:10
mthmaybe instead of jz4740_dma_slave_config15:10
apelete'kay15:11
apeletemaybe I'll look into that then. if it's quick enough to do it might be save testing time indeed15:12
apeletes/be//15:12
apelete(I love that qi-bot)15:13
mtheh, does dma-jz4740 use DMA descriptors at all?15:13
mthit seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ15:14
mthwhich works, but is not the most efficient approach if the sg list contains many small segments15:15
apelete<mth> it seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ15:15
apeletewhere in the code do you read that ?15:15
mthjz4740_dma_start_transfer and jz4740_dma_chan_irq15:16
mthin particular, the fact that chan->next_sg exists15:16
mthwith chained DMA descriptors, the "next" would be a pointer in the descriptor itself15:17
mthanyway, that's a possible optimization for later; for now being able to use a DMA engine at all is already an improvement over separate DMA implementations in the MMC and audio drivers15:18
mthand fb too15:18
apeletein jz4740_dma_start_transfer, it looks to me like it's just using an sg list15:19
apeletein fact, I don't know the difference between using an sg list and DMA descriptors15:20
apeletenever used DMA descriptors this far, so sg is all I know15:20
mthsg list is the Linux side of things, DMA descriptors is what the hw uses15:21
mththey are similar in intent but not bitwise compatible15:21
mthI also don't know if addresses in sg lists are virtual or physical15:21
mthin hw descriptors they must be physical15:22
apeletedo you have an example of DMA descriptors in use ?15:22
apeletejust so that I can get a sense of what we're talking about :)15:22
mththe jz4770 fb driver uses them, but that's a dedicated DMA controller for the LCDC iirc, it might not be exactly the same as the generic DMAC15:23
apelete'kay, will look at that later, thanks15:23
mthin the 4740 docs, it speaks of descriptor or no-descriptor transfer15:23
mthand if I understand dma-jz4740.c correctly, it uses no-descriptor transfer at the moment15:24
mthprobably because there are a lot less complications with that15:24
apeleteyes, I read that part of 4740 docs, but didn't know how it would actually affect the code15:25
mthsection 4.3.1 describes a descriptor transfer15:25
mthroughly: with no-descriptor transfer, each sg item gets poked into the hw regs one at a time: the completion of item N is a trigger for the CPU to poke item N+1 and then start it15:27
mthwith descriptor transfer, a linked list of descriptors, one per sg item, is made in memory15:28
mththen the CPU starts the transfer by poking the start address of that list into thw hw regs15:28
mthso no interrupts are needed to go from one sg entry to the next15:28
mthI don't know though how many entries sg lists contain in practice15:29
mthif it's nearly always 1, there is no advantage to descriptor transfers15:29
apeleteoh, I see... thanks for the translation ;-)15:30
--- Sat Nov 8 201400:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!