IRC log for #openezx on 20080824

01:20.36*** join/#openezx markuman (n=markuman@dslb-084-063-184-042.pools.arcor-ip.net)
01:25.58*** part/#openezx markuman (n=markuman@dslb-084-063-184-042.pools.arcor-ip.net)
02:16.52*** join/#openezx WM (i=c93a9a76@gateway/web/ajax/mibbit.com/x-211ac17a3dc09db3)
02:46.49WMfound the source of the latency!
02:47.25WMyet another bug on pxa2xx_spi. It just ignores max_speed_hz, and sets the clk_div to 0xfff (very slow) ;)
02:48.40gmzhuothen the ts usable?
02:49.39WMtesting now.
02:51.30WMits a 150% improvement.
02:51.36WMbut still too much latency
02:52.24WMnow i get ~5 samples per second. Before it was ~2.
02:53.05WMwill test a non-interrupt-driven transfer change to pxa2xx_spi.
02:54.58WMstill slow :(
02:54.59gmzhuodose the latency is becaus of,if the mmc is translating one block data,and pcap interupt come,we must wait for the block data finsh,then can deal the interrupt?
02:55.08WMgmzhuo: no.
02:55.20WMgmzhuo: i am testing on a1200, no mmc on the spi bus
02:55.43gmzhuoSo the problem is schedul?
02:55.53WMthe problem is something on pxa2xx_spi.
02:56.07gmzhuonot wait for another i/o finish?
02:58.53WMeg, previously, with ssp.c, pcap_putget took less than 5us to finish. With the conversion to pxa2xx_spi, it takes 20ms. (now, with the clk_div fix it takes ~9ms).
02:59.10WMbut 9ms is still too slow.
03:01.06gmzhuo5us vs 9m :(
03:03.39WMdont take this numbers as exact, i am measuring 1000000 calls to pcap_putget on a looping. there may be some variation. :)
03:03.54WMbut the difference is still brutal.
03:21.28gmzhuothe flash card and wifi module use the same spi interface on a910?
03:22.25WMno.
03:22.38WMthe mmc card is connected to spi.
03:22.53WMthe wifi card is connected to the pxa mmc controller.
03:25.13WMand, to make the moto design even more stupid... there are 3 ssp ports on pxa, motorola uses 1 port shared for PCAP and MMC, and !2! ports for audio, with their pins shorted (SSP2 <-> SSP3 <-> Audio Codec)
03:25.19gmzhuoI don't know why the hardware designed as this,specialy for LCD controller,
03:26.37WMon a780 there are even more stupid things.. As bcm2035 is connected to a pcap voltage regulator that the PXA has no access.
03:26.57WMso, to turn bluetooth ON, the AP has to ask BP to power the bcm2035.
03:28.59WMgmzhuo: the lcd controller is not motorola fault at least.
03:29.05gmzhuoIn fact the LCD can be programed as 24bit/24depth ,the lcd connect to the high 6bits to r/b/b,the software can deal easy
03:29.08WMits stupidity from Intel :)
03:29.39gmzhuorealy?
03:29.53WMreally.
03:31.13gmzhuowe always need do more things for 18BPP,
03:32.33WMbut 18bpp in kernel seems to be handled right, the problem is "only" X.
03:33.33WMtime to get some sleep.
03:33.42gmzhuoI know this,I means it should be let software deal as 24BPP,but the hardware is 18BPP
03:33.56gmzhuothen need not morte bit operation
03:34.26gmzhuogood night!
03:34.43WMbye!
05:04.52*** join/#openezx dimichxp (n=dimichxp@89.108.88.71)
05:10.17dimichxphi. anybody worked with belcarra usb stack?
05:36.34gmzhuoWhat is belcarra usb stack?
05:37.58gmzhuoYou work with moto's 2.4?
05:38.52dimichxpthat's thing that moto uses to provide usb-gadget function. nope, 2.6
05:44.34gmzhuoHi,dimichxp,witch phone dose you have?
05:44.49dimichxpmoto e8
05:45.13gmzhuoDose it similar as e6?
05:45.27dimichxpno, it is magx phone
05:46.18gmzhuowhich cpu it is use?
05:46.29dimichxparm1136
06:06.51*** join/#openezx drath_ (i=vmaster@p5B07E894.dip.t-dialin.net)
08:36.36*** join/#openezx NiZoX_ (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68)
09:08.59*** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1)
09:10.28*** join/#openezx markuman (n=markuman@dslb-084-063-184-042.pools.arcor-ip.net)
10:14.34*** part/#openezx dimichxp (n=dimichxp@89.108.88.71)
10:47.57*** join/#openezx Zba_Phy (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68)
10:48.19*** part/#openezx markuman (n=markuman@dslb-084-063-184-042.pools.arcor-ip.net)
11:27.32gmzhuoDose the sd memory and sd wifi card can Coexistence in the same sd slot?
11:28.35gmzhuothere has a card identification process before data transfer mode
12:11.51*** join/#openezx Hopscotch (n=cd@touchdown.maintech.de)
12:13.37*** join/#openezx dimichxp (n=dimichxp@89.108.88.71)
12:37.12*** join/#openezx alphaone (n=alphaone@a064.apm.etc.tu-bs.de)
14:26.50*** join/#openezx flyhorse|linux (n=flyhorse@59.37.201.87)
14:55.53*** join/#openezx ilya_muromec (i=muromec@85-238-116-46.broadband.tenet.odessa.ua)
14:56.35ilya_muromechi all
14:59.11ilya_muromecWM: i`m trying to get red key working. please look at code: http://pastebin.com/m9ddb57b
15:05.43WMilya_muromec: hi
15:05.55WMilya_muromec: and is it working?
15:11.25ilya_muromecWM: compiling just now
15:11.33ilya_muromeci think it must
15:12.03WMilya_muromec: yes, me too.
15:13.05ilya_muromecis there any interface to access to ADC from userspace?
15:14.11WMilya_muromec: not yet. I was thinking in a sysfs interface, exporting some common pcap controls.
15:16.13ilya_muromeci alredy get qtopia running on 2.6 but there are some internal troubles and some trouble with ts
15:16.44WMilya_muromec: but as my last changes added much latency to pcap events, im working on fixing it.
15:17.32WMilya_muromec: use an older version, before the change to pxa2xx_spi and ts should work fine.
15:17.47ilya_muromecWM: yes i`m using old version
15:17.52WMor wait for the thing to settle down. :)
15:17.59ilya_muromecbefore irq -> pcap swithicng
15:42.58ilya_muromechmmm
15:43.12ilya_muromecWM: last kernel from not booting
15:43.59ilya_muromecsomething about irq
15:44.26ilya_muromeccant read it - text going to fast
15:46.45WMilya_muromec: latest kernel from git?
15:47.24WMilya_muromec: diff .config arch/arm/configs/ezx_defconfig may point you what is wrong.
15:48.17WMilya_muromec: or, it may be the udc bug, if you compiled in UDC support asser that you send it to gen-blob.
15:52.24ilya_muromecWM: spi_pxa was disabled
15:53.59WMhave to update the Kconfigs ;)
15:54.18ilya_muromecWM: thnx boots now
15:55.21ilya_muromecok some event comes from device
16:10.31WMilya_muromec: send patch to ML. i will be happy to incorporate it.
16:10.35WMilya_muromec: Thanks! :)
16:15.54ilya_muromecWM: first i`l fix it to send normal scancode and differentiate press/release
16:16.22ilya_muromec*i`l try :)
16:23.39WMilya_muromec: take a look on PCAP_REG_PSTAT, at (1 << PCAP_IRQ_ONOFFI). :)
16:24.12ilya_muromecPSTAT ?
16:24.59WMilya_muromec: PSTAT has the same bits as MSR/ISR/INT_SEL.
16:26.07WMbut it doesnt signal interrupts, it signals the interrupt source. eg, on each PSTAT change, the corresponding ISR bit is set, and if the MSR corresponding bit is set too an IRQ is generated
16:27.16WM(pstat & (1 << PCAP_IRQ_ONOFFI)) will be 1 on key pressed, and 0 on key released. (i think ;) )
16:28.20ilya_muromechm
16:37.40WMilya_muromec: sorry, PCAP_IRQ_* is already bit index, so (pstat & PCAP_IRQ_ONOFFI).
16:47.57*** join/#openezx Zba_Phy (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68)
16:53.09gmzhuoHi,WM,can sdio wifi card and sd memeroy Coexistence on one sd slot?
16:53.44gmzhuoeach card has his address?
16:54.16WMgmzhuo: yes, in theory yes.
16:54.32WMgmzhuo: but pxamci will only support it on SPI mode.
16:55.14WMgmzhuo: on the pxa manual it says that "mixed card types can only be supported with the MMC controller SPI mode"
16:55.35gmzhuolimit by hardware?
16:56.30WMgmzhuo: yes, i think it is a limit on the pxa mmc controller.
16:57.02WMi will stop reading TS pressure on each sample.
16:57.35WMi finally got the latency under control, and now the ADC spits out the pressure measurement when it should give the position measurement.
16:58.10WMrandomly. most times it sends the position, but sometimes it sends pressure instead.
17:01.01*** part/#openezx dimichxp (n=dimichxp@89.108.88.71)
17:04.45WMTS is smooth again :)
17:09.14gmzhuoSo can upload it now?
17:09.37ilya_muromecWM: like ezx_pcap_read ( (PCAP_REG_PSTAT & PCAP_IRQ_ONOFF ), &n ) ?
17:11.12gmzhuothere has a wifi module support compactflash too
17:11.30WMilya_muromec: no.
17:11.38gmzhuoWM-BG-MR-01-23
17:12.35WMilya_muromec: u32 pstat; ezx_pcap_read(PCAP_REG_PSTAT, &pstat); if (pstat & PCAP_IRQ_ONOFF) printk("down\n"); else printk("up\n");
17:15.18WMgmzhuo: not yet, still some stuff to solve on pcap_work. Its getting out of sync with ISR.
17:16.03gmzhuotime to sleep now,bye every one
17:16.42WMby gmzhuo!
17:21.14WMweird. after i remove my debug printks pressure reading became reliable again :)
17:50.15WMeven more weird. if i explicitly delay for some usecs after each spi transfer, the latency goes _down_ ???
17:50.48WMI think i found yet another bug on pxa2xx_spi.
17:51.08WMbasically we have to configure everything as a per-transfer basis.
17:51.25WMif i dont supply a .delay_usecs, it delays a _lot_.
17:51.49WMif i dont supply a .speed_hz it set-up a very slow speed.
17:54.56*** join/#openezx Zba_Phy (n=none@2a01:e35:8a13:a2b0:21c:c0ff:fe25:ff68)
18:25.21ilya_muromecWM: see ML
19:15.24*** join/#openezx ilya_muromec (i=muromec@85-238-116-46.broadband.tenet.odessa.ua)
19:30.34*** join/#openezx BadCluster (n=badclust@190.50.213.11)
20:28.57WMgreat, remaining bugs on the pcap event handler seem to be solved.
20:29.08WMTS is very smooth and stable.
20:37.31WMdefinitely smoother than 2.4 moto kernel.
21:01.13ao2hi WM, smoother even with pressure reading enabled?
21:03.59WMao2: yes, reading the pressure.
21:04.23ao2very good, compliments
21:04.44WMao2: it turned out that the deferred execution has minimum impact on latency.
21:04.55WMthe problem was pxa2xx_spi doing very slow transfers.
21:05.09WMonce this got solved, everything became easy
21:06.06ilya_muromecWM: slow mtd whas also because of it?
21:06.07ao2I read that on opnezx-devel. Do you plan to suggest upstream devs to use better default values for speed and delay?
21:06.12WManyway, i even did some optimizing on ts driver focusing lower latency. Then it turned out unnecessary, but it will stay, optimizing is always good ;)
21:06.30WMao2: Yes, it is not only a default issue.
21:06.51WMit sets the defaults, but somehow it gets lost when real activity happens.
21:07.03ao2so even a real bug was present, I see
21:07.43WMwill push the code in the next minutes, i am documenting the changes right now.
21:08.06WMilya_muromec: mtd has no relation to spi.
21:08.36WMilya_muromec: it may be because of cache invalidation problems, i havent researched it yet.
21:08.58ilya_muromecok
21:46.36*** join/#openezx acassis (n=acassis@201.82.15.235)
22:39.59*** part/#openezx BadCluster (n=badclust@190.50.213.11)
23:11.23*** join/#openezx BadCluster (n=badclust@190.50.213.11)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.