**** BEGIN LOGGING AT Wed Jan 30 02:59:59 2013 Jan 30 05:21:43 Russ: so you know the TI Tutorial Track is exactly? Jan 30 05:39:17 mranostay, ? Jan 30 05:39:44 Russ: at ELC Jan 30 05:39:49 that wasn't there before Jan 30 05:39:56 was it? Jan 30 05:40:02 yeah that is why i mentioned it Jan 30 05:40:08 magically appeared i think Jan 30 05:40:30 I haven't heard anything, I'm sure prpplauge is on top of it Jan 30 05:42:30 are rar files some europeans thing? Jan 30 05:42:49 i swear i only see them from .eu'ians in emails Jan 30 05:43:01 well that and pirates Jan 30 05:43:39 * dm8tbr sends mranostay some arj files Jan 30 05:44:16 mranostay: yes, since they predate the contitution.... Jan 30 05:55:49 got some stuff workign today Jan 30 05:55:58 anybody else have any sucess? Jan 30 06:02:14 meh Jan 30 06:12:41 no. Jan 30 06:13:43 got some work stuffing today Jan 30 06:14:02 * mranostay backs away Jan 30 06:34:34 lol. Jan 30 06:49:23 * mranostay revises slides Jan 30 06:49:57 av500: need to get one of those for the intel booth Jan 30 06:50:40 ? Jan 30 06:53:04 av500: yocto plunger :) Jan 30 06:53:59 ah Jan 30 06:57:53 * koen yawns Jan 30 07:00:17 oh noes Jan 30 07:01:38 * mranostay thinks up his PRU function generator project Jan 30 07:05:29 how is koen today? Jan 30 07:05:59 email is working against, catching up on backlog Jan 30 07:06:24 from customers who know how to google, so I'll need coffee first Jan 30 07:11:27 hey, i got an xM with 3.2.24-x14 kernel, i'm trying to change the pinmux so that i can use UART2 on the expansion header, but i cant seem to find the files specified in all the tutorials Jan 30 07:12:53 cant seem to find anything similar to this: "arch/arm/mach-omap2/mux.c" Jan 30 07:13:57 ubuntu.. Jan 30 07:14:22 i'd like to mux in the kernel Jan 30 07:14:27 have you tried linux? Jan 30 07:15:21 what do you mean? Jan 30 07:15:47 inside joke Jan 30 07:16:07 that is an old kernel Jan 30 07:16:10 probably funny :) Jan 30 07:16:14 er Jan 30 07:16:29 on a xM? hmm Jan 30 07:16:33 yes Jan 30 07:16:46 using a MAX232 chip? Jan 30 07:17:20 no, expansion header Jan 30 07:17:23 P9 Jan 30 07:17:30 th e28 pin one Jan 30 07:17:34 *the Jan 30 07:17:58 well yeah i'm sure you need a transceiver chip :) Jan 30 07:18:43 no, its hooked up to an atmega128 Jan 30 07:18:51 not to a computer Jan 30 07:20:07 ah Jan 30 07:20:24 don't you need to logic level shift? Jan 30 07:20:35 yes, all that is handled, i need the pinmux Jan 30 07:20:53 l Jan 30 07:21:01 k Jan 30 07:21:24 ds2: random letter time? Jan 30 07:21:47 competing with geiger counters for entropy Jan 30 07:22:10 "/lib/modules/3.2.24-x14/kernel/arch/arm/mach-omap2/" exists Jan 30 07:22:41 but does only contain mailbox:mach.ko Jan 30 07:23:01 #entropy channel? :) Jan 30 07:28:56 (salut|howdy) Jan 30 07:29:26 yee haw! Jan 30 07:45:13 0: nodejs-0.8.18-r0 do_compile (pid 26522) Jan 30 07:45:18 bad ass rockstar tech Jan 30 07:47:34 heh Jan 30 07:51:12 koen: blame mranostay Jan 30 07:51:59 i dont even know what rev of the bb i got Jan 30 07:52:48 the order from farnell says b, but it does not have the sd card on the top, so it cant be Jan 30 08:16:03 so it seems that i got rev c1, DM/AM3730 cpu. figured that its probably easiest to change the pinmux in u-boot Jan 30 08:16:42 looking at the beagle.h file now, but i cant make the names and gpio numbers match Jan 30 08:16:57 MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/\ MUX_VAL(CP(UART2_RX), (IDIS | PTU | EN | M4)) /*GPIO_147*/ Jan 30 08:17:10 that didnt work Jan 30 08:17:51 MUX_VAL(CP(UART2_RX), (IDIS | PTU | EN | M4)) /*GPIO_147*/ Jan 30 08:18:48 morning Jan 30 08:18:50 while it says here: http://elinux.org/BeagleBoardPinMux#UART2 that it should be gpio 143 Jan 30 08:18:55 morning Jan 30 08:19:22 "143" is not found at all in that file Jan 30 08:20:58 good morning under the bridge perso^Wcreatures Jan 30 08:22:33 HI Jan 30 08:23:04 LO Jan 30 08:23:46 How to enable uart5 on beaglebone? Jan 30 08:23:47 > __ Jan 30 08:23:53 >HI/LO Jan 30 08:24:14 every info out there seems to be about the omap versions, i got dm/am3730, guessing "make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config" will not work for me? Jan 30 08:24:21 I had do something , but can't echo RX Jan 30 08:24:33 mux options? Jan 30 08:24:44 yes i did it Jan 30 08:25:00 follow the BB guide Jan 30 08:25:11 echo 4 > /sys/kernel/debug/omap_mux/lcd_data8 echo 24 > /sys/kernel/debug/omap_mux/lcd_data9 Jan 30 08:25:12 sabesto: omap=am=dm Jan 30 08:25:16 its all the same Jan 30 08:25:21 ok, thanks Jan 30 08:26:52 seems like the mux settings are set properly for uart 2 in this u-boot source i downloaded Jan 30 08:27:18 uart2? Jan 30 08:28:30 yes? Jan 30 09:33:29 koen, I have pulled the latest beagle kernel Jan 30 09:33:29 and I keep getting: error: arch/arm/boot/dts/am33xx.dtsi: patch does not apply Jan 30 09:33:29 Patch failed at 0001 ARM: dts: Add SHAM data and documentation for AM33XX Jan 30 09:33:29 I performed git reset HEAD --hard on the kernel tree before I pulled and started patching again, so it was fresh iteration Jan 30 09:35:59 jackmitchell: fixed Jan 30 09:36:18 jackmitchell: I forgot I had git-rerere enabled, so git-am didn't fail here Jan 30 09:37:04 * panto tries to be a nice person, but alas, people piss me off Jan 30 09:38:33 cheers koen Jan 30 09:40:32 * NishanthMenon pats panto and thinks of getting him a beer :P Jan 30 09:41:23 it's too early in the morning! Jan 30 09:41:28 nm, offer accepted Jan 30 09:41:34 it never too early for a beer Jan 30 09:41:35 ;) Jan 30 09:41:52 +1 Jan 30 09:42:01 or a bear :P Jan 30 09:42:09 NishanthMenon: its really late or you are not in TX? Jan 30 09:42:33 insomnia, av500 ;) could not sleep, so came back to office and started reviewing patches :D Jan 30 09:43:07 * NishanthMenon laments that reviewing patches is not helping put him to sleep either.. just making him agitated :( Jan 30 09:45:03 * jackmitchell admires the dedication Jan 30 09:45:10 * jackmitchell or the madness.... Jan 30 09:45:26 * NishanthMenon checks for other options.. Jan 30 09:46:21 * panto offer a pony option Jan 30 09:46:44 * NishanthMenon wonders if he should offer gerrit to the list ;) Jan 30 09:57:52 I know I've said this before, but I really dislike how Nautilus (the file manager) now uses solely dbus to find and show files in the view window Jan 30 09:58:20 the latencies involved and difference in time between all the files popping up is really disconcerting Jan 30 10:23:36 koen, I'm sure you're aware but just in case you're not the kernel throws up this traceback during boot: http://pastebin.com/umPiSVRF Jan 30 10:23:47 jackmitchell: dbus wtf? Jan 30 10:25:04 jackmitchell, working on it Jan 30 10:26:38 av500: I know right Jan 30 10:26:50 av500: I think it works in a client<->server model Jan 30 10:27:16 where the 'file manage daemon' is always running, and the window is the client and queies for everything over dbus Jan 30 10:28:21 lol Jan 30 10:28:59 also, would enabling DYNAMIC_DEBUG pump up idle cpu usage? Jan 30 10:29:27 if not, this recent kernel is doing a lot more work than usual Jan 30 10:29:47 jackmitchell: yeah, we've switched back to the pure TI "quality" driver to tscadc, instead of the one panto worked on Jan 30 10:30:08 jackmitchell: needless to say those TI PSP people only compile test their code Jan 30 10:30:31 bonus points for noticing that the tscadc code only works if you use platform data in a boardfile Jan 30 10:30:47 and guess what am335x doesn't have in mainline Jan 30 10:40:39 there, a concise mail sent as response to the tscadc patch series Jan 30 10:40:57 no doubt offended any non-western european reader with the directness Jan 30 10:41:30 koen, thick skin required in this business Jan 30 10:52:14 what is the impedance of a beagleboard's GPIO? Jan 30 10:52:38 african or european? Jan 30 10:52:47 eu Jan 30 10:53:18 no idea, what does the datasheet say? Jan 30 11:03:09 with DYANMIC_DEBUG enabled, and pr_debug being used in my module, no info is being spat out to dmesg, do I need anything else enabled? reading the control file correctly finds my debug statements Jan 30 11:04:27 jackmitchell, are you booting with the kernel command line enabling the debug log level? Jan 30 11:05:10 panto: no Jan 30 11:05:22 put a 'debug' there Jan 30 11:05:55 or write the kernel log level property on runtime Jan 30 11:06:08 yep, google just found me this: echo 7 > /proc/sys/kernel/printk Jan 30 11:06:29 that enables all log levels? Jan 30 11:06:35 yeah Jan 30 11:11:27 dmesg -7 Jan 30 11:15:32 hmm, ok if I have a module, which prints debug on load, how I can enable the debug printouts for that module before it is loaded? Jan 30 11:16:41 or is there a method to 'reload' a module in place, so that the dynamic_debug doesn't lose the enabled pr_debug lines when I unload then reload Jan 30 11:18:28 cant you set the module debug on load? via parameters? Jan 30 11:21:09 from within the module? Jan 30 11:21:31 or when loading with insmod Jan 30 11:22:13 insmod Jan 30 11:22:16 modprobe Jan 30 11:24:31 module_param(debug, int, 0); Jan 30 11:25:00 modprobe foo debug=1 Jan 30 11:25:18 my bad, RTFM Jan 30 11:27:48 http://www.tldp.org/LDP/lkmpg/2.6/html/x323.html Jan 30 11:28:36 av500: insmod fpgaSPI.ko dyndbg Jan 30 11:28:40 did the trick, thanks Jan 30 11:29:44 * jackmitchell shall become a mildly competent kernel programmer Jan 30 11:30:22 yes Jan 30 11:35:26 jackmitchell: so, you already know the ldd3 by heart? Jan 30 11:38:59 KotH: unfortunately not, take heed of the 'shall' in the previous comment ;) Jan 30 11:49:23 does anyone here have acrobat and can look at a pdf? Jan 30 11:49:28 I think I have a rendering error Jan 30 11:49:44 http://datasheets.maximintegrated.com/en/ds/MAX6643-MAX6645.pdf Jan 30 11:49:56 renders fine here Jan 30 11:49:58 page 14, fullspd polarity column Jan 30 11:50:09 are both MAX6643 variants the same? Jan 30 11:50:16 or does one have a bar over FULLSPD Jan 30 11:50:25 no Jan 30 11:50:35 6644 has "-" Jan 30 11:50:40 and 6645 Jan 30 11:50:45 well yes, I see that Jan 30 11:50:56 but they have two MAX6643 variants, but they look identical Jan 30 11:51:20 no Jan 30 11:51:28 one is 40, the other 30 Jan 30 11:51:29 In the picture above, the have a (FULLSPD) with a bar over it, and in the note '() ARE FOR MAX6643_A ONLY.' Jan 30 11:51:36 ah, right Jan 30 11:51:40 missed that Jan 30 11:51:52 unless that is a rendering error here Jan 30 11:51:55 :) Jan 30 11:52:07 but the mystical variant with an active low FULLSPD Jan 30 11:52:27 I'm not even sure which one of those two variants MAX6643_A would be Jan 30 11:52:33 hmm Jan 30 11:54:06 I think the part doesn't exist anymore, but whoever edited it out of the datasheet did a crappy job Jan 30 11:54:30 the demo schematic shows it active low Jan 30 11:54:42 which makes sense since OT is active low Jan 30 11:55:00 I sent an email to them Jan 30 11:55:08 we'lll see what I get in the morning Jan 30 11:56:32 porridge Jan 30 12:33:48 would someone be able to have a very quick look at this simple module, I can't see a reason why the interrupt irq routine isn;t firing Jan 30 12:33:50 http://pastebin.com/DMN2U0ae Jan 30 12:34:22 there is an interrupt occurring on that gpio, to be clear ;) Jan 30 12:34:45 and you see the init debugs? Jan 30 12:35:00 jackmitchell, did you muxed the pin to gpio input mode properly? Jan 30 12:35:49 panto: very good question Jan 30 12:36:00 av500: yes, i get just the first init debug line Jan 30 12:37:16 and yes, check your pinmux Jan 30 12:41:39 jackmitchell: so, you are going to pospone learning the thing you need until you retire... by which time linux will be either obsolete or you'll have completely forgotten what you wanted to do Jan 30 12:42:51 jackmitchell: and please stop the camelCasing :) Jan 30 12:44:27 av500: do you prefere DromedarCasing? Jan 30 12:44:49 lpswStudlyCasing Jan 30 12:45:08 or lcpswStudlyCasing Jan 30 12:46:44 Hi, I'm trying to use PWM-backlight on an omap3 device using this patch: https://patchwork.kernel.org/patch/1881981/ on a 3.7.x kernel. Now I've got it working but the polarity is wrong, how do I change the polarity of the PWM signal from the board-*.c file? (I tried a lot, but don't find the right way, is there just something missing from the omap-pwm.h added by the patch) Jan 30 12:47:08 tsjsieb: short answer: you can't Jan 30 12:47:33 koen: that's not the answer I wanted to hear ;) (but thanks) Jan 30 12:47:52 what to look for, for the long answer? Jan 30 12:48:31 polarity support was added post 3.7 iirc Jan 30 12:48:49 so get a 3.8rc kernel and use the third bit in the DT field Jan 30 12:48:51 so just hard code it Jan 30 12:49:00 e.g. pwms = <&pwm 0 5000000 1>; Jan 30 12:49:04 better yet bitbang it Jan 30 12:49:08 the '1' there is for inverse polarity Jan 30 12:49:12 (just kidding, don't do it) Jan 30 12:49:48 tsjsieb: have a look at Documentation/devicetree/bindings/pwm/pwm.txt Jan 30 12:50:18 Thnx, I've got some reading and comparing to do :) Jan 30 12:50:58 so just hard code it Jan 30 12:52:50 av500: you mean to change the patch added code? that might be an easier (but maybe quick and dirty) option Jan 30 12:54:03 hmm Jan 30 12:54:13 in the patch there is a set_polarity call, no? Jan 30 12:55:06 so where is the problem? Jan 30 12:56:02 the problem I ran into was that the pwm subsys exposed the polarity knob Jan 30 12:56:13 but if you used pwm-backlight you couldn't turn it Jan 30 12:56:52 since pwm-backlight didn't allow you to config the pwm itself Jan 30 12:56:53 omap->polarity = PWM_POLARITY_NORMAL; Jan 30 12:56:59 there a line to edit :) Jan 30 12:57:18 with DT you can override the pwm node if you need to Jan 30 12:57:44 you mean DT is better than /dev/mem? Jan 30 12:57:57 /dev/DT Jan 30 12:59:44 /dev/mem is the preferred samsung interface for high speed devices Jan 30 12:59:58 ofcourse /dev/mem is better Jan 30 13:00:18 /dev/null for highspeed output Jan 30 13:00:19 ln -s /dev/mem /dev/highspeed_bus Jan 30 13:01:36 ln -s /dev/mem /dev/null Jan 30 13:01:59 av500, that is evil Jan 30 13:02:01 I like it Jan 30 13:02:15 submit a patch Jan 30 13:02:53 I will give that too people that complain that ubuntu is too slow Jan 30 13:03:42 *g* Jan 30 13:05:10 but my ubuntu is too slow... Jan 30 13:05:16 (or maybe my pc...) Jan 30 13:06:22 tsjsieb: I can fix that, try this: ln -s /dev/mem /dev/null Jan 30 13:07:02 I wonder if it's possible to loop mount /tmp to /dev/mem Jan 30 13:07:10 KotH: I refer the ldd3 but it's particularly dated in places now. I usually start there to get a feel for the flow then research the modern technique, book learning is for passing exams... Jan 30 13:07:12 thnx, much better now Jan 30 13:10:20 av500: it doesn't matter that I had to use sudo and some extra -f for that command, does it? Jan 30 13:10:40 jackmitchell: ldd3 might be dated, but 90% of it still applies Jan 30 13:10:55 jackmitchell: and if you think of books only worthy for exams, then you are very mistaken Jan 30 13:11:11 KotH: I think learning them by heart is only for exams Jan 30 13:11:12 jackmitchell: beside, there is the list of changes keept by corbet Jan 30 13:12:17 jackmitchell: your sarcasm detector needs adjustment Jan 30 13:13:23 KotH: I'll crank it to 11 ;) Jan 30 13:13:50 lunch Jan 30 13:13:57 jackmitchell: for 2000 i build you one that goes to 12 Jan 30 13:14:43 in the world of the almighty DT, is it acceptable to be doing pin muxing in modules, or should it be done be in the DT and that's the end of it? Jan 30 13:14:45 panto: en guete Jan 30 13:15:09 jackmitchell: you want it in DT Jan 30 13:15:15 or is this the not-cape-bus saga again? Jan 30 13:15:25 KotH: ok, thanks Jan 30 13:16:46 jackmitchell: make your driver pinctrl aware and then add the muxing the DT Jan 30 13:17:00 jackmitchell: once your driver gets probed the pins will be muxed Jan 30 13:17:29 koen: ok, thanks - will go searching for a good example Jan 30 13:18:29 jackmitchell: https://patchwork.kernel.org/patch/1672271/ Jan 30 13:18:54 ignore the dev_info, that's leftover debugging Jan 30 13:19:34 koen: ok, thanks Jan 30 13:34:52 back Jan 30 13:42:30 jo pantos Jan 30 13:46:08 jackmitchell: be aware that there's two examples of how to do muxing in the kernel...the right way and the wrong way Jan 30 13:46:50 jackmitchell: try to ignore any of the upstream examples that don't have the default pingroup inside the device node Jan 30 13:46:58 beagleboard/kernel tree has it correct Jan 30 13:47:07 mdp: ok, I'm attempting to setup my driver to be devicetree compatable Jan 30 13:47:26 then i'll work on the dt pinctrl Jan 30 13:50:07 jackmitchell: if you see an example like this: http://hastebin.com/facokajuga.xml don't follow it in your dts files. Each of those defaults belongs in the respective device node Jan 30 13:50:11 sounds good Jan 30 13:59:07 damn Jan 30 13:59:12 wifi sucks on pio-musb Jan 30 13:59:22 isn't it obvious? Jan 30 13:59:28 "but we have patches from 3.2 to fix that!" <- TI person Jan 30 14:01:32 musb Jan 30 14:01:36 there it is Jan 30 14:06:41 koen, there's something about the relationship between trying to use am335x musb and the definition of insanity Jan 30 14:06:48 koen, I want you to think carefully about that. Jan 30 14:21:35 piowhat? Jan 30 14:21:53 pope GPIO X Jan 30 14:23:50 generation GPIO X Jan 30 14:24:47 * mdp says "musb" just to take another drink. Jan 30 14:24:59 so another good cases solved today Jan 30 14:25:13 and I will come home now Jan 30 14:50:31 mdp, I ported my code to dmaegine, addr_width seems to be ACNT, maxburst seems to be BCNT, however I'm having a hard time finding how to have bidx of 0, is that possible through dmaengine? Jan 30 15:07:29 oh, perhaps I'm supposed to use interleaved template Jan 30 15:08:18 argh Jan 30 15:18:49 jsabeaudry: yes, except the edma dmaengine driver doesn't have interleaved transfer support Jan 30 15:19:04 bitbang it Jan 30 15:19:06 um Jan 30 15:19:46 jsabeaudry, you are transferring from a h/w fifo but not to a memory buffer? Jan 30 15:21:02 My main use case is as you describe, I have another use case in which I throw away the data so i used to write over the same memory location, perhaps I can allocate a bigger buffer Jan 30 15:21:44 I have 2 cases, 1: hw fifo -> kfifo and 2: hw fifo -> sink Jan 30 15:22:14 hw-accelerated /dev/null? Jan 30 15:22:26 +1 Jan 30 15:22:27 mru, exactly :) Jan 30 15:22:27 mru, +1 I was thinking the same thing Jan 30 15:22:31 lol Jan 30 15:23:40 jsabeaudry: a dummy buffer is your best bet, yes Jan 30 15:24:33 mdp, but how to I configure for the hw fifo, is it by putting maxburst to 1 ? Jan 30 15:24:44 and tinker a bit with the buffer size Jan 30 15:24:46 jsabeaudry: that's btw, what spi drivers do since spi is inherently full duplex...the dma driven ones are also filling a dummy buffer in the opposite direction with garbage Jan 30 15:25:05 looping over a buffer larger than the transfer size can be faster Jan 30 15:25:13 depends on burst modes and such Jan 30 15:25:51 mdp, (the spi driver seems to have maxburst = 1) Jan 30 15:26:19 jsabeaudry: maxburst of 1 means no burst, of course... Jan 30 15:26:25 I'm talking about your sink Jan 30 15:26:37 heh, RIM just renamed themselves Blackberry Jan 30 15:26:39 jsabeaudry: if you are talking about spi-davinci.c then yes, spi-davinci IP is a POS Jan 30 15:27:17 it has no fifo..just a shift-register that you dma each in and get one dma event for each word Jan 30 15:28:11 I need to always read from the same address and from what I can understand dma_slave_config does not seem to allow that Jan 30 15:28:18 jsabeaudry: if you have a hw _fifo_ then typically you set your maxburst (in units of address_width) to something like half the fifo width...though that's hw dependent for performance Jan 30 15:28:54 if you're writing to a dummy buffer in memory to discard data, it can be faster to loop over a buffer of 32 bytes or so than writing repeatedly to the same 32-bit location Jan 30 15:29:15 jsabeaudry: dma slave transfers allow exact that..they are specifically designed for peripheral transfers like you describe with a static transfer location Jan 30 15:30:12 jsabeaudry: look at spi-davinci.c again. the dma_rx_conf definition... Jan 30 15:31:02 mdp, that where they put maxburst = 1, is that what prevents it from incrementing address? Jan 30 15:31:36 basically what I do not understand is where I choose incrementing addresses vs static Jan 30 15:31:53 DMA_DEV_TO_MEM (hw 'port" to memory), src_addr is the spi shift register address, src_addr_width is the configure spi word width for that shift register, and max_burst 1 means that only one src_addr_width sized transfer is done per event Jan 30 15:32:01 jsabeaudry: you don't Jan 30 15:32:11 for a fixed address, you simply set the increment to zero Jan 30 15:32:15 jsabeaudry: when you choose a dma slave transfer, that is chosen implicitly for you Jan 30 15:32:42 jsabeaudry: from a dmaengine api POV is what I'm explaining Jan 30 15:34:15 jsabeaudry: dmaengine_prep_slave_sg() says "I want to do a slave sg transfer and this is my direction Jan 30 15:34:42 and I'm talking about the hw Jan 30 15:34:51 mdp, oh! Great, thanks. Then I'll just allocate a bigger sink and that will be the end of it. Jan 30 15:34:54 by api definition, a DMA_DEV_TO_MEM slave sg transfer is always non-incrementing at the source and incrementing at the destination Jan 30 15:35:05 mru, right, also important to understand Jan 30 15:35:05 wmat: RIMberry for me Jan 30 15:35:25 I just wanted to be sure he understands the highlevel api when using it Jan 30 15:35:29 av500: heh Jan 30 15:35:33 Ok, DEV = non-inc and MEM = inc ? Jan 30 15:35:57 I prefer understanding the hw first, then figuring out how to make the api do what I want Jan 30 15:36:07 jsabeaudry: yes Jan 30 15:36:40 mru, unfortunately, changing stuff in the kernel is easier said than done...at least upstream Jan 30 15:37:09 hopefully there's already a way to program the hw the way you want Jan 30 15:37:14 really unfortunately, dmaengine api needs more work to abstract some other things Jan 30 15:37:44 mru, yeah, in fact, there's the bare metal-ish private edma api where he could program the transfer you describe Jan 30 15:37:46 you don't want to ask the api to do something the hw doesn't support and end up emulating it in some inefficient way Jan 30 15:38:20 right...atm though, the limitation there is not a serious performance concern Jan 30 15:38:26 however, it is suboptimal Jan 30 15:38:41 it can be fixed by implementing interleaved transfer support Jan 30 15:39:08 but that's been low priority as all in-kernel users to slave sg transfers Jan 30 15:39:14 s/to/use/ Jan 30 15:39:47 meanwhile, the clever user can continue to use the private api to do more interesting cases like you describe Jan 30 15:39:49 for the discarding sink, I'd program the dma engine for a "2D" block transfer with stride = -width Jan 30 15:40:26 I mean, there the ability to do dma driven byte swapping here, but no generic transfer type to encapsulate that Jan 30 15:40:46 I have a real use case for that one even..just haven't had time to justify it upstream Jan 30 15:41:42 mru, right Jan 30 15:42:10 with the width equal to the max burst size Jan 30 15:42:53 fwiw, http://lxr.free-electrons.com/source/include/linux/dmaengine.h#L96 is the transfer type abstraction for that type of thing Jan 30 15:43:24 where you can control src/dst inc, stride, etc. Jan 30 15:43:50 I was playing with some pci hw once that had a 32-bit wide fifo replicated over a larger address window so it could take advantage of pci burst transfers Jan 30 15:44:37 a graphics card, to be precise Jan 30 15:44:42 and it really made a difference Jan 30 16:08:38 urgh, DT && kernel programming is melting my brian :( Jan 30 16:09:15 LOL: http://appworld.blackberry.com/webstore/content/137637/?countrycode=US Jan 30 16:09:54 av500, this one goes to 11? Jan 30 16:10:10 mru, yeah, that's critical on PCI..smart design Jan 30 16:10:32 it was an old 3dlabs card fwiw Jan 30 16:12:34 jackmitchell, its melting my Br*ai*n. Jan 30 16:12:50 * ka6sox-away dunnos who Brian is. Jan 30 16:13:03 ka6sox-away, it's D.T. Brian Jan 30 16:13:06 I'm Brian Jan 30 16:13:12 and me wife is Brian too Jan 30 16:13:30 wewease wodewick! Jan 30 16:13:35 av500, and together you have a Life? Jan 30 16:13:42 so far yes Jan 30 16:14:38 mdp: how's the uboot work going? Jan 30 16:15:53 ka6sox-away: exactly my point, I'm now even incapable of correct spelling Jan 30 16:16:26 jackmitchell, good to hear I'm not the only one who's brain has melted Jan 30 16:16:34 Jacmet: good, had to tend to some edma things of priority 1 Jan 30 16:16:42 repeat after me: it's a capital D and a capital T Jan 30 16:17:01 Jacmet: I'm refactoring the ddr stuff to use the omap-common/emif-common.c Jan 30 16:17:17 http://en.wikipedia.org/wiki/The_Incredible_Melting_Man now powered by DT Jan 30 16:17:24 since that version pretty much 1:1 matches the ti81xx emif setup..whereas the am335x one is "different" Jan 30 16:18:04 mdp: yes, I saw your v6 series Jan 30 16:18:16 Jacmet: I am booting a 2.6.37 vendor kernel from RBL->spl mmc->u-boot mmc->kernel Jan 30 16:18:17 mdp, we are the 'burned ones' Jan 30 16:18:20 av500: tD? Jan 30 16:18:32 mdp: nice! Jan 30 16:19:20 Jacmet: on a current mainline u-boot working tree..so it's going well. Jan 30 16:19:20 hopefully finish cleanup by tomorrow Jan 30 16:19:54 mdp: great, I'll look into 816x support once you post it Jan 30 16:21:33 cool Jan 30 16:31:40 jo re Jan 30 16:35:14 gotta love the tax return Jan 30 16:35:24 "Were you party to one or more tax avoidance schemes?" Jan 30 16:36:06 you men the be greatful we didn't take it all return? Jan 30 16:37:33 mru: were you? Jan 30 16:37:42 would I tell them? Jan 30 16:37:48 mru: its like answering if you want to kill the president when entering the US Jan 30 16:38:02 if you do, they get your for lying Jan 30 16:38:25 and double the sentence Jan 30 16:38:25 mru, ever seen the questionnaire for a visa to the us? Jan 30 16:38:32 av500: is that like asking if you're a witch? Jan 30 16:38:38 yes Jan 30 16:38:41 panto: no Jan 30 16:38:52 "have you ever been a member of a terrorist organization?" Jan 30 16:39:04 av500: you are wise in the ways of science Jan 30 16:41:30 panto yes its known since nine eleven Jan 30 16:42:05 have they caught a lot of terrorists that way? Jan 30 16:42:28 sure Jan 30 16:43:46 I mean of the non-retarded type Jan 30 16:45:09 panto, does #beagle count? Jan 30 16:45:41 as terrorism? Jan 30 16:45:45 yeah Jan 30 16:45:55 all you foreigners.... Jan 30 16:45:58