<arhuaco>
wpwrak: If you live alone, you can talk to someone when you get bored :-P
<arhuaco>
wpwrak: Talk to the cloud....
rejon has joined #qi-hardware
<wpwrak>
funny, a while ago I showed the clip to a friend and she said pretty much the same thing ;-)
Textmode has joined #qi-hardware
xiangfu has quit [Ping timeout: 245 seconds]
xiangfu has joined #qi-hardware
wolfspraul has joined #qi-hardware
<kyak>
"... and much more" - people volunteeraly equip their houses with spy equipment, how convenient :)
<kyak>
web camera/microphone in laptop? that's last generation
<kyak>
after several days "alexa, shut up and kill yourself already, you all-knowing, intruding bitch!" :)
<wpwrak>
the "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.
<wpwrak>
but i must say that the concept looks very attractive
<wpwrak>
of 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."
<kyak>
well, with almost everyone nowadays having smartphone with "ok google" feature, this tower looks unnecessary
<eintopf>
I want to say "computer" instead "ok google"
<eintopf>
kyak: for the matlab thing, I need to modelling a inverted pendelum control
<kyak>
this might be the most complete example of MBD
<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."
<eintopf>
(nxt lego) - yea we know these lego nxt things... but we have a real segway and other sensors for measurement some angles
<eintopf>
but okay, maybe I need to begin really to start the working on this project
<wpwrak>
hmm, "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 :)
<eintopf>
wpwrak: no there are other sensors
<eintopf>
for nxt lego they used the ultrasonic distance sensore and making pythagoras magic
<eintopf>
(ewee-pt) I have also the source code for the controller logic... this is visual basic code
<kyak>
oh god..
<eintopf>
but the device is hackable
<eintopf>
interesting is that there exist some visual basic compiler to generate avr code
<eintopf>
:D
<eintopf>
kyak: do you have also some skills for scilab?
<eintopf>
these open source matlab thing
<kyak>
nope
<eintopf>
ok
<eintopf>
my prof. put me in the theory mathematical group. He knows that I am more a practical guy.
<eintopf>
when I am done I will publish my results somewhere... open source for everyone
<kyak>
your aim is to develop segway controller that replaces one from ewee-pt?
<eintopf>
yes, but we not really replace the logic
<eintopf>
no time for that
<kyak>
then what do you do?
<eintopf>
put the logic in some physic engine
<eintopf>
with sensor parameter contstraints from ewee-pt
<kyak>
you mean, you only want to model the logic with physical plant model?
<kyak>
with the plant model representing the real ewee-pt device?
<eintopf>
we only don't replace the logic because stupid laws in germany and because we don't have time
<eintopf>
yea, something like that
<eintopf>
kyak: this sounds realistic?
<kyak>
of course!
<kyak>
in fact, Simulink is made just for this kind tasks.. dynamic systems and controls simulation
<eintopf>
has already a builtin physics engine?
<kyak>
i'm not sure what you mean by that. It has physical modeling tools
atommann has quit [Ping timeout: 265 seconds]
xiangfu has quit [Ping timeout: 255 seconds]
<eintopf>
ok
xiangfu has joined #qi-hardware
<larsc>
apelete: yes, good to hear from you. Already though you got lost on your way home
<apelete>
and that didn't worked with dma-jz4740 until I harcoded "request_channels(info, DMA_SLAVE);" in dmatest.c
<apelete>
larsc: is that normal ? what capabilities is dma-jz4740 compatible with exactly ?
<larsc>
I think it only test mem-to-mem
<wpwrak>
nice. 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.
<larsc>
anyway, 5 minutes are up, I have to go
<apelete>
larsc: 'kay, no problem, we'll talk later then
<apelete>
thanks for you time ;)
jluis has quit [Remote host closed the connection]
rejon has quit [Ping timeout: 240 seconds]
viric has quit [Read error: Connection reset by peer]
viric has joined #qi-hardware
pcercuei has joined #qi-hardware
jluis has joined #qi-hardware
<larsc>
I'm back now
<apelete>
<larsc> I think it only test mem-to-mem
<apelete>
at least it can be sued to know if the driver is working properly, right ?
<apelete>
s/sued/used/ :)
<qi-bot>
apelete meant: "at least it can be used to know if the driver is working properly, right ?"
<pcercuei>
sue him!
<apelete>
:D
<larsc>
if the driver implements mem-to-mem
<apelete>
oops, looks like dma-jz4740.c only implements mem-to-dev and dev-to-mem :(
<apelete>
so dmatest will ultimately be useless to test it
<apelete>
there are obviously a few things wrong with my changes (the number of channels declared in dma-jz4740.c is wrong for instance)
<apelete>
larsc: but if I get you right, then I'll be forced to test against the actual mmc driver it seems...
<apelete>
which I've been avoiding since I don't know to which extent I'm messing things up here :)
<larsc>
you can try read-only for now
<larsc>
that should be pretty save
<larsc>
safe
<apelete>
larsc: you mean putting the sd card in read only mode while booting ?
<larsc>
only use DMA for read operations
<larsc>
but not for write operations
<apelete>
ok
<pcercuei>
mmc-jz4740 already uses DMA, no?
<apelete>
yes it does, for read and write
<apelete>
but I wanted to get the dma driver right before testing against the mmc driver
<pcercuei>
ok; so it does not use the standard DMA API then?
<apelete>
on jz4740 it does
<pcercuei>
you're working on jz4770 now?
<apelete>
yes, porting the mmc driver from jz4740 to jz4770
<apelete>
and the mmc driver pulls in the dma driver
<pcercuei>
ok, great
<pcercuei>
so I guess you can use the old driver for the internal card, and your new driver for the external SD card
<pcercuei>
if that makes things easier to test, that is
<apelete>
didn't think about that, may be a good idea indeed
<pcercuei>
once you have something to test, I can use my proto
<pcercuei>
with the current driver, I reach ~250 KiB/s maximum
<pcercuei>
write speed
rejon has joined #qi-hardware
Textmode has quit [Quit: "It was one dev, naked in a room with a carton of cigarettes, a thermos full of coffee and bourbon, and all his summoned angels."]
<apelete>
'kay
kyak has quit [Ping timeout: 244 seconds]
kyak has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
atommann has quit [Ping timeout: 265 seconds]
rejon has quit [Ping timeout: 244 seconds]
<mth>
apelete, larsc: from the docs (section 4.4.1), it seems auto-request mode (8) can be used for memory-to-memory transfers
<mth>
so it might be an option to add that feature to the DMA engine driver
<mth>
to make it easier to test and perhaps to do useful work in the future
<larsc>
yes
<larsc>
the peripheral supports it, the driver does not
rejon has joined #qi-hardware
jluis has quit [Quit: Me'n vaig]
<apelete>
mth: good to know, added to the todo list just in case I get too much free time ;-)
<pcercuei>
does that ever happen?
<apelete>
loads and loads of free time during my sleep actually
<mth>
I 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 code
<apelete>
but then I wake up and it's all gone :-(
<pcercuei>
I usually debug when I sleep
<pcercuei>
happens quite often that I get ideas about my various projects, in my sleep
<apelete>
mth: that's what I thought too, don't know how long it would took to implement though
<apelete>
pcercuei: completely agree, debugging while sleeping seems to work really well
<mth>
dma_cap_set of DMA_MEMCPY and implement a device_prep_dma_memcpy handler, I think
<mth>
and jz4740_dma_slave_config would probably have to handle DMA_MEM_TO_DEV
<mth>
eh, DMA_MEM_TO_MEM
<viric>
:b1
<viric>
oops
<mth>
the memcpy interfact doesn't use sg lists, so it's probably a bit easier to set up then a slave transfer
<mth>
ah, there is also device_prep_dma_sg which has sg for both source and destination
<mth>
supporting 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 somehow
<mth>
the DMA test seems to check DMA_MEMCPY, DMA_XOR and DMA_PQ capabilties, so double sg is probably not needed for testing
<apelete>
mth: 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 ?
<mth>
device_prep_dma_memcpy is called explicitly by dmatest.c, so you certainly need that
<mth>
dma_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 indirectly
<mth>
or maybe that's only needed for sg-to-sg transfers then?
<mth>
I know very little about DMA engines, just had a quick look at the code
<qi-bot>
apelete meant: "the question is, would it be used to register a modified version of jz4740_dma_prep_slave_sg that can handle mem-to-mem transfer"
<apelete>
or to register a new jz4740_dma_prep_memcpy handler ?
<mth>
jz4740_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_memcpy
<mth>
since there is no sg input, it would have to build only a single entry descriptor list
<mth>
ah, jz4740_dma_start_transfer should support MEM_TO_MEM direction as well
<mth>
maybe instead of jz4740_dma_slave_config
<apelete>
'kay
<apelete>
maybe I'll look into that then. if it's quick enough to do it might be save testing time indeed
<apelete>
s/be//
<qi-bot>
apelete meant: "may I'll look into that then. if it's quick enough to do it might save testing time indeed"
<apelete>
(I love that qi-bot)
<mth>
eh, does dma-jz4740 use DMA descriptors at all?
<mth>
it seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ
<mth>
which works, but is not the most efficient approach if the sg list contains many small segments
<apelete>
<mth> it seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ
<apelete>
where in the code do you read that ?
<mth>
jz4740_dma_start_transfer and jz4740_dma_chan_irq
<mth>
in particular, the fact that chan->next_sg exists
<mth>
with chained DMA descriptors, the "next" would be a pointer in the descriptor itself
<mth>
anyway, 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 drivers
<mth>
and fb too
<apelete>
in jz4740_dma_start_transfer, it looks to me like it's just using an sg list
<apelete>
in fact, I don't know the difference between using an sg list and DMA descriptors
<apelete>
never used DMA descriptors this far, so sg is all I know
<mth>
sg list is the Linux side of things, DMA descriptors is what the hw uses
<mth>
they are similar in intent but not bitwise compatible
<mth>
I also don't know if addresses in sg lists are virtual or physical
<mth>
in hw descriptors they must be physical
<apelete>
do you have an example of DMA descriptors in use ?
<apelete>
just so that I can get a sense of what we're talking about :)
<mth>
the 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 DMAC
<apelete>
'kay, will look at that later, thanks
<mth>
in the 4740 docs, it speaks of descriptor or no-descriptor transfer
<mth>
and if I understand dma-jz4740.c correctly, it uses no-descriptor transfer at the moment
<mth>
probably because there are a lot less complications with that
<apelete>
yes, I read that part of 4740 docs, but didn't know how it would actually affect the code
<mth>
section 4.3.1 describes a descriptor transfer
<mth>
roughly: 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 it
<mth>
with descriptor transfer, a linked list of descriptors, one per sg item, is made in memory
<mth>
then the CPU starts the transfer by poking the start address of that list into thw hw regs
<mth>
so no interrupts are needed to go from one sg entry to the next
<mth>
I don't know though how many entries sg lists contain in practice
<mth>
if it's nearly always 1, there is no advantage to descriptor transfers
<apelete>
oh, I see... thanks for the translation ;-)