IRC log for #openezx on 20090422

02:11.51*** join/#openezx WyrM1 (n=wyrm@20158153088.user.veloxzone.com.br)
03:09.28*** join/#openezx arne (i=nobody@dslc-082-082-081-152.pools.arcor-ip.net)
05:18.25*** join/#openezx flyhorse|linux (n=flyhorse@116.4.160.203)
05:50.11*** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be)
07:28.53*** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1)
07:34.37*** join/#openezx l403 (n=l@85.132.159.239)
07:51.40*** join/#openezx l403 (n=l@85.132.159.239)
07:55.29*** join/#openezx alain2210 (n=alain@AMontsouris-151-1-24-128.w82-123.abo.wanadoo.fr)
08:04.09*** join/#openezx WyrM (n=wyrm@20158128165.user.veloxzone.com.br)
08:12.10*** join/#openezx sabrod (n=sab@lns-bzn-45-82-65-166-213.adsl.proxad.net)
08:45.05*** join/#openezx gDD (n=gDD@125.116.10.100)
10:18.35*** join/#openezx purl (i=ibot@rikers.org)
10:18.36*** topic/#openezx is OpenEZX Developer Lounge -- http://www.openezx.org
10:43.57*** join/#openezx sabrod (n=sab@82.65.166.213)
11:42.50*** join/#openezx gDD (n=gDD@125.116.10.100)
11:52.49*** join/#openezx stefan_schmidt (n=stefan@f053152199.adsl.alicedsl.de)
12:23.37*** join/#openezx LoneStar (n=xinzhen@114.92.186.182)
12:31.15WyrMgood morning.
12:31.56WyrMI commited the fix for the pcap/bp IRQ to our git.
12:32.17WyrMand uploaded a zImage to my people.openezx dir.
12:32.31mickey|zzZZzzcool, is ezx/current the preferred kernel then again?
12:32.38mickey|zzZZzzshould i use this for more ts tests
12:36.38WyrMts should be working again.
12:37.34WyrMI will check the reported events now.
12:39.00*** join/#openezx gmzhuo (n=gmzhuo@222.210.146.80)
12:39.34gmzhuoWyrM:Hi
12:41.50*** join/#openezx univac (n=univac@148.81.191.193)
12:44.44WyrMhi gmzhuo
12:45.34WyrMmickey|zzZZzz: which phone were you experiencing problems with the TS?
12:45.37WyrMa780?
12:45.46mickey|zzZZzza780, yes
12:45.56mickey|zzZZzzdidn't have a chance to gen-blobify my a1200 yet
12:52.08*** join/#openezx gmzhuo- (n=gmzhuo@125.71.206.59)
12:52.25WyrMgmzhuo-: hi again :)
12:53.18WyrMmickey|zzZZzz: how bad is the TS on your tests.
12:53.46WyrMhere the only issue I can check atm is that in 1/5 of the single click events im getting 2 clicks.
12:54.05mickey|zzZZzzunusable
12:54.12mickey|zzZZzzlike i have written in the mail
12:54.15mickey|zzZZzzmajor jitter
12:54.19mickey|zzZZzzand halting to react for seconds
12:54.24WyrMI need to install ts_test here.
12:54.39WyrMim using just X to test.
12:54.55gmzhuo-On my phone ts report config faield
12:58.52*** join/#openezx gDD (n=gDD@125.116.10.100)
13:01.22WyrMwhere can I find tslib documentation?
13:02.17mickey|zzZZzzin the tarball
13:02.18mickey|zzZZzzhttp://tslib.berlios.de/
13:08.14*** join/#openezx Toma- (n=toma@enlightenment/developer/toma-)
13:16.34WyrMmodule pthres pmin=1 pmax=800
13:16.34WyrMmodule variance delta=20
13:16.34WyrMmodule dejitter delta=30
13:16.55WyrMmickey|zzZZzz: can you please check if these values improves the TS for you?
13:17.07WyrMalso, variance does not filter the release sample.
13:17.17WyrMthis seems to be the biggest issue now. :/
13:17.59WyrMsometimes on pen release an event with some weird position is reported.
13:19.32gmzhuo-how about modify SAMPLE_INTERVAL?
13:19.51WyrMto sample slower?
13:19.55gmzhuo-YES
13:20.25WyrMit shouldn't improve much.
13:20.52WyrMbecause it is meant only to wait between samples.
13:21.14WyrMit does not increase the ADC sampling time.
13:21.47WyrMwe could do more adc readings for the same sample.
13:21.56WyrMand report the average..
13:22.05WyrMbut this would be filtering on kernelspace.
13:22.13WyrMI don't know if we should do this.
13:26.03WyrMon which .ipk is ts_test/ts_calibrate?
13:27.20gmzhuo-dose pcap_ts_event_touch always be serivcied in time?
13:27.50WyrMwhat you mean?
13:28.20WyrMreading is done after the adc sends an interrupt
13:28.35WyrMand before the values are cleared from the pcap register.
13:30.11gmzhuoso there has no situation that we let pcap do ts adc after pen has released?
13:30.35WyrMyes, there is.
13:30.49WyrMwe do 2 adc readings for each sample.
13:30.59WyrMone for pressure, another for position.
13:31.33WyrMif the pen is relased before the pressure reading, we do position reading anyway.
13:32.13gmzhuowhich is the first?
13:32.13WyrMbut we mark it as a pen release event.
13:32.24WyrMIIRC pressure is first.
13:32.52gmzhuothen position maybe is incorrect?
13:33.26gmzhuowhy not position first,and if no pressure,we report release?
13:33.41WyrMbut when we see a release.
13:33.48WyrMwe don't report position.
13:33.54WyrMso it shouldn't make a difference.
13:34.38WyrMand pressure is not reliable at all.
13:34.48gmzhuorelease position is the pre position
13:37.21*** join/#openezx florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de)
13:44.45*** join/#openezx WyrM (n=wyrm@20158167051.user.veloxzone.com.br)
13:50.51*** join/#openezx florian (n=fuchs@port-217-146-132-69.static.qsc.de)
13:56.11alain2210Hello
13:57.27WyrMalain2210: hi.
13:57.37WyrMalain2210: im looking at the auto wake up issue now.
13:57.51alain2210WM: thanks.
13:58.01alain2210I have some questions.
13:58.04WyrMI think its because some pins are being driven low when we enter low power mode.
13:58.41*** part/#openezx Toma- (n=toma@enlightenment/developer/toma-)
13:58.47alain2210what are the files concerned ?
13:59.52alain2210I have several problems with poweroff/reboot/standby/suspend/resume.
13:59.59WyrMalain2210: http://pastebin.com/m1e839163
14:00.06WyrMPGSR* registers.
14:00.37WyrMwe need to set MFP_LPM_DRIVE_HIGH on gpio pins pointed by PGSR registers
14:05.37WyrMalain2210: heh, BP is being reset every time AP enters deep sleep mode.
14:05.38WyrM:)
14:05.44WyrMit couldn't work.
14:05.51alain2210yes...
14:06.05alain2210by the way : is it sleep or deep sleep ?
14:06.22alain2210I have read the pxa27x book.
14:06.51WyrMI think it is sleep.
14:06.57alain2210and seen that the standby of /sys/power/state is standby (the processor is not stop)
14:07.17alain2210and mem is for sleep or deep sleep.
14:07.33WyrMyes
14:07.35alain2210but reading the kernel source I have not seen deep sleep.
14:07.36WyrMstandby is easy
14:07.46alain2210yes standby is working.
14:08.24WyrMalain2210: try this:
14:08.29alain2210I have read the wakeup of ezx-bp and I not sure of the "good" value of bp_rdy.
14:08.34WyrMstatic unsigned long ezx_pin_config[] __initdata = {
14:08.43WyrM+       GPIO4_GPIO | MFP_LPM_DRIVE_HIGH,        /* WDI_AP */
14:08.46WyrM+       GPIO55_GPIO | MFP_LPM_DRIVE_HIGH,       /* SYS_RESTART */
14:08.55WyrMstatic unsigned long gen1_pin_config[] __initdata = {
14:09.00WyrM+       GPIO57_GPIO | MFP_LPM_DRIVE_HIGH,       /* AP_RDY */
14:09.35WyrM+       GPIO82_GPIO | MFP_LPM_DRIVE_HIGH,       /* RESET */
14:10.14WyrMwhat is happening is that when pxa enters sleep, it will drive gpio82 and gpio57 low.
14:10.21*** join/#openezx LoneStar (n=xinzhen@114.92.180.117)
14:10.27WyrMand this will reset bp.
14:10.51alain2210yes
14:11.16WyrMthen BP will toggle WDI, and wake AP. And because it was reset, it will no longer have USB working.
14:12.59alain2210in ezx-bp.c the wake up of BP is done when bp_rdy is low. But I have read the opposite in 2.6.25 kernel
14:14.20alain2210how do you have found this MFP_LPM_DRIVE_HIGH on 4 55 57 82 ?
14:14.35alain2210and is 82 : reset of what ?
14:16.51WyrMfrom svn code.
14:16.51WyrM+PGSR0 = 0x00000010;
14:16.51WyrM+PGSR1 = 0x02800000;
14:16.51WyrM+PGSR2 = 0x00040000;
14:17.06alain2210and how do you see the numbers of GPIO ?
14:17.15WyrMon the manual ;)
14:17.42WyrMPGSR0 = SS4;
14:18.10WyrMPGSR1 = SS55 | SS57;
14:20.00WyrMahh, and PGSR3 is setting GPIO99 as drive high too.
14:20.24alain2210understood.
14:29.32alain2210I have a lot of problem with my kernel now....
14:29.48WyrM?
14:30.02gmzhuohi,alain2210,which phone dose you have?
14:30.08alain2210e680
14:30.50*** join/#openezx l403 (n=l@85.132.159.239)
14:31.27alain22102 days ago, after sleep the BP was responding. now nothing: Maybe USB cable is bad.
14:32.01WyrMis it auto resuming after sleep?
14:32.08alain2210yes still.
14:32.21alain2210but I sure of nothing now.
14:32.21gmzhuoWyrM,would you let me update Power Management as 50% in project status?
14:32.31WyrMgmzhuo: sure.
14:33.12alain2210gmzhuo: in ezx-bp : wakeup bp
14:33.37alain2210why do you wake the bp if bp_rdy is low ?
14:33.54alain2210in 2.6.25 it was the opposite ?
14:34.09alain2210(I could make errors of course)
14:34.13WyrMif bp_rdy is low, bp is sleeping.
14:35.09*** join/#openezx l403 (n=l@85.132.159.239)
14:37.15gmzhuoin moto's code,revert ap_rdy will wakeup bp
14:37.30WyrMrevert?
14:37.44WyrMwhat wakes BP is the rising edge of ap_rdy
14:37.50alain2210but in 2.6.25 mux_cli.patch
14:38.03WyrMso, we need to make it low and then high again.
14:38.51alain2210the wake up is done if :
14:38.51alain2210if (GPIO_is_high(41))
14:39.03alain2210so it the opposite.
14:39.16gmzhuoyes,from high to low or low to high
14:39.38alain2210i'm speaking of 41 the is bp_rdy not ap_rdy
14:41.13alain2210s/the/that/
14:49.31WyrMalain2210: bp_rdy is gpio0
14:53.07alain2210right.
14:53.10WyrM<PROTECTED>
14:53.24alain2210so why if (GPIO_is_high(41)) becomes
14:53.46alain2210if (gpio_get_value(bp->bp_rdy)) (in that the opposite)
14:53.55alain2210s/in that/in fact/
14:54.03WyrM<PROTECTED>
14:54.30WyrMon the hardware that was sold, GPIO41 is ALWAYS LOW.
14:54.51WyrMso the block of code you are looking at is just a big NOP.
14:54.59alain2210yes ;-)
14:55.33alain2210so the BP is never wake up by the AP ?
14:56.03WyrMyes, it is.
14:56.07WyrMbut not via gpio.
14:56.23alain2210via what ?
14:56.28WyrMvia USB. :)
14:56.33alain2210and where in the kernel ?
14:56.49WyrMsame place you are looking.
14:56.55WyrMa few lines after. :)
14:56.59WyrMUHCRHPS3
14:57.03alain2210I'm completely confused.
14:59.00alain2210so the function ezx_wake_bp can be remove ?
14:59.06WyrMjust forget about this part of the code for now.
14:59.12WyrMfor gen1, yes.
14:59.18WyrMfor gen2, probably no.
14:59.46WyrMI think that on gen1 BP never sleeps.
14:59.57alain2210ok
15:00.02WyrMon gen2 it sleeps all the time.
15:00.17WyrMon my a1200 BP sleeps after 2 seconds.
15:00.35alain2210good for power
15:00.40WyrMon my a780 it is always ready.
15:02.35alain2210how can you see this ?
15:02.54WyrMbp_rdy
15:03.14alain2210you have put a printk ?
15:03.41WyrMyes.
15:03.56WyrMand changed the bp_rdy irq to both_edge
15:04.17WyrMI see it going low after 2 secs.
15:04.26WyrMbut I can't wake bp at all.
15:04.53WyrMafter it goes to sleep, it is dead.
15:05.11WyrMand it works on gmzhuo's E6, and ou muromec's a1200.
15:05.15alain2210I have the same problem on my e680 after sleep
15:05.25WyrMso it's a bp firmware version issue
15:05.29WyrMno.
15:05.39WyrMyou are confusing AP sleep with BP sleep.
15:05.49WyrMthose are 2 different things!
15:05.53alain2210no.
15:06.00alain2210yes
15:06.17WyrMyou have problems after AP sleep.
15:06.36alain2210I'm saying that when AP sleep, BP sleep also. and seems to not been able to wakeup.
15:06.44WyrMBP does not go to sleep when AP sleeps.
15:07.28WyrMyou can see this clearly, as BP is waking AP when it sleeps :)
15:07.33WyrMso, it is not sleeping.
15:07.49alain2210yes.
15:08.50alain2210but I see sometimes that wdi is set.
15:09.03WyrMI have to fix miniusb after resume.
15:09.20WyrMso I can debug bp code after ap resume.
15:09.43alain2210what is miniusb ?
15:09.56WyrMusb port 2, device
15:10.10WyrMthe one that we connect to the PC. :)
15:10.53alain2210in the same subject
15:11.07alain2210is the an easy way  ?
15:11.18alain2210when putting the phone in standby
15:11.30WyrMwhat do you mean?
15:11.32alain2210to make the usb connection down
15:11.55alain2210such that the pc reenumerate it automatically
15:12.07alain2210my HP 2210 PDA do this.
15:12.17alain2210By this the phone
15:12.32alain2210the connection in maintain even in standby.
15:12.40WyrMusb is put down on suspend. And up on resume.
15:12.47alain2210so I have to unplug/plug the usb cable.
15:12.51WyrMat least it should.
15:13.01WyrMcode is on ezx_udc_command
15:13.10WyrMand it is called by pxa27x-udc driver.
15:13.16WyrMon suspend and on resume.
15:14.23alain2210I have found it.
15:18.25WyrMI think that toggling PCAP_BUSCTRL_VUSB_EN with BUSCTRL_PU is enough to get it working after resume.
15:18.28WyrMtesting it now
15:21.14WyrMno, it is not.
15:21.16WyrM:(
15:21.45alain2210is it done with pcap ?
15:21.48WyrMit seems to be "yet another issue on the pxa27x-udc driver(tm)"
15:21.54alain2210no directly in pxa ?
15:22.02alain2210s/no/not/
15:22.14WyrMpcap is the usb transceiver.
15:23.01alain2210was it working with the svn kernel ?
15:23.15WyrMyes
15:23.25WyrMbut the svn kernel uses another udc driver.
15:23.36alain2210yes I have seen it.
15:23.46WyrMwhich worked much better than the pxa27x-udc driver from mainline.
15:23.59alain2210:(
15:33.07WyrMalain2210: comment out ezxbp_resume/ezxbp_suspend on ezx-bp.c
15:33.10WyrMthis is wrong.
15:33.35WyrMif ap_rdy is set as drive high, it should be set low by the suspend/resume functions.
15:34.42gmzhuobed time,bye all
15:35.16WyrMand it is commented on svn code, btw. :)
15:36.23alain2210yes it is commented.
15:37.27WyrMstill auto-resumes here :(
15:38.02alain2210but with standby, the phone use this and does not autoresume.
15:39.09WyrMwith standby LPM_DRIVE_HIGH is not used I think.
15:40.22WyrMwith lpm drive high, what happens on resume is:
15:40.22WyrMbp_suspend(ap_rdy=0), hardware_suspend(ap_rdy=1), hardware_resume(ap_rdy=0), bp_resume(ap_rdy=1).
15:41.18*** join/#openezx stefan_schmidt (n=stefan@p5B0352CB.dip.t-dialin.net)
15:42.36alain2210you say that the kernel put ap_rdy=0 using ezx-bp.c
15:42.59alain2210then pxa put ap_rdy=1 when getting in sleep mode
15:43.38alain2210but I have not read that resuming AP put ap_rdy=0.
15:49.16WyrMit does.
15:50.48WyrMwhen software resets PSSR(PH), the register for normal GPIO operation is used instead of PGSR.
15:51.59WyrMso, software was asking ap_rdy to be 0, then resume resets PSSR(PH) before calling bp_resume, so it will go low and then high again.
15:53.04alain2210yes but if ap_rdy=0 then ap_rdy=1 on suspend : what is the effect on bp ?
15:53.24WyrMI don't know the affect of anything on BP :)
15:53.35WyrMlol.
15:53.38WyrMnobody does.
15:53.46WyrMand it changes depending on firmware, etc..
15:54.03WyrMthe only thing I know for sure, is that its bp awaking pxa.
15:54.23WyrM"why?" are only guesses.
15:54.42alain2210thanks
16:13.20mickeylWyrM: changed parameters in ts.conf don't change a thing
16:13.37mickeyli will now strace to see whether anything comes in while the ts remains completely unresponsive
16:15.10mickeylok, interesting
16:15.26mickeyli can't reproduce the full hang for a couple of seconds with strace
16:15.34mickeyl[although the bogus release events are still there]
16:15.47mickeylwithout strace i regular see the full hang
16:15.54mickeylmight indicated something wrt. irq timing
16:16.05mickeyli'll leave the interpretation to the experts :)
16:17.59WyrMhum.
16:18.01WyrMweird.
16:18.13WyrMdo you see lockups with ts_test or ts_print_raw?
16:19.19mickeylboth
16:19.33mickeylit looks like it gets a bogus release event
16:19.40mickeyland then no irqs come from PCAP
16:19.48mickeyl(i tried watch cat /proc/interrupts)
16:19.51mickeylfor a while
16:20.03mickeylif you tap and release four to five times, it becomes reactive again
16:22.40WyrMI can't reproduce any of this here :(
16:22.48mickeylwah
16:22.49mickeylthat's sad
16:22.49*** join/#openezx darion76 (n=darion76@94-248-91-1.dynamic.peoplenet.ua)
16:22.55WyrMI mean..
16:23.05mickeylok, let me try one of your kernels to make sure it's nothing in the build system
16:23.05WyrMI can reproduce the bogus release.
16:23.09WyrMbut no lockups :(
16:23.17mickeylwhat do you do when you get the release?
16:23.24mickeyli mean do you continue drawing without releasing it really?
16:23.33mickeylbecause this is how you can see the lock best
16:23.36WyrMalso, please send me a log of ts_print_raw, and point me where it lockups.
16:27.30WyrMalain2210: even if I disable the bp_rdy wake up source, it still auto awakes.
16:27.50WyrMim testing if it auto awakes if run with bp in flash mode.
16:28.03mickeylWyrM: http://pastebin.ca/1399787
16:30.47WyrMalain2210: it doesn't. So I can only imagine that it is an usb-host interrupt waking it.
16:31.00WyrMmickeyl: all these 0 shouldn't happen :(
16:31.09WyrMs/0/0 0 0/
16:33.36*** join/#openezx pH5 (n=ph5@e178251091.adsl.alicedsl.de)
16:34.03alain2210WyrM: usb-host ? ohci-pxa ?
16:34.15WyrMalain2210: yeah, I think so.
16:34.24WyrMbit 28 of PWER.
16:34.30WyrMneeds to be off.
16:34.40alain2210how do you have diseable  bp_rdy wake up source
16:34.42alain2210?
16:34.44WyrMim grepping the source to see if something turns it on.
16:35.00WyrMremoving WAKE_ON_EDGE from the mfp table.
16:35.05alain2210ok.
16:35.21alain2210for the bit 28 of PWER, what to do ?
16:35.35WyrMdon't know yet.
16:41.07mickeylwrt. suspend/resume from BP I don't know how we should handle this
16:41.19mickeylit doesn't seem to be possible to turn unsolicited responses off
16:41.37mickeylso if we don't find a way, we will resume on every incoming msg
16:41.53mickeylwhich is bad
16:41.58WyrMno, bp decides itself when to go to sleep, ap has no control as it seems.
16:42.29mickeylthat's ok
16:42.37mickeylbut sometimes we want AP to be woken up
16:42.39mickeyland sometimes not
16:42.48WyrMon bp messages?
16:42.49WyrMwhy?
16:42.57mickeylincoming SMS -> wake up
16:43.01WyrMshouldn't we proccess all unsolicited messages?
16:43.02mickeylincoming signal strength -> keep slept
16:43.06mickeylno
16:43.13mickeylwe don't want to process signal strengh or registration updates
16:43.25mickeylthey're meaningless until we woke up again
16:43.58mickeyli wonder how the original firmware is doing that
16:44.01WyrMmaybe they are not sent if ap is sleeping?
16:44.15WyrMmaybe the original fw sends some at command before going to sleep.
16:44.17mickeylunlikely, but hey, it's MOTO
16:44.37mickeylyeah, perhaps there are proprietary commands to disable/enable certain kinds of unsolicited responses
16:45.01mickeylthere's a whole lot of 'em which we don't understand yet
16:45.09mickeyl[and probably never will, but that's another story...]
16:45.47mickeylok, back to the ts, is there anything else i can do to? should i retest with your latest kernel build?
16:46.09WyrMI changed nothing on ts code. so it shouldn't help. :(
16:46.14mickeylok
16:46.29WyrMI will debug it here and get rid of the spurious release events.
16:46.36mickeylthanks
16:46.43WyrMthen we see if it solves the lockup issue.
16:46.47mickeylokay
17:05.35*** join/#openezx stefan_schmidt_ (n=stefan@p5B034838.dip.t-dialin.net)
17:08.19mickey|dinnerooh
17:08.25mickey|dinnerneptune supports +CMER
17:08.30mickey|dinnerthat's _good_
17:08.36WyrMwhat is cmer?
17:08.51mickey|dinnerMobile Termination Event Reporting
17:09.01mickey|dinnerwith this you can disable +CIEV URCs
17:09.12mickey|dinnerso at least we can get rid of waking up due to signal strength changes
17:09.19mickey|dinners/can/could/
17:09.20WyrMgood! :)
17:10.35WyrMmy battery is empty :/
17:13.06mickey|dinnerwhy's taht?
17:13.09mickey|dinnerforgot +USBSTAT?
17:14.03WyrMI don't use it ;)
17:14.12WyrMI have a desktop charger and 4 batteries.
17:14.18mickey|dinneroh, even better
17:14.18WyrMfound another one with charge.
17:19.29alain2210WyrM: in old kernels there is
17:19.45alain2210<PROTECTED>
17:20.07alain2210I cannot find the equivalent in git kernel.
17:20.24alain2210PFER  = 0x0000f803;
17:20.34alain2210PRER  = 0x00001802;
17:20.39WyrMsame as the pastebin I said earlier.
17:20.58WyrMPWER = 0xc.......;
17:21.11WyrMis WERTC | WEP1;
17:21.19WyrMWEUSBH2 is off.
17:21.32WyrMand I think that this is our issue.
17:21.44WyrMyou can see that wake up is enabled on sysfs.
17:22.09WyrMcat /sys/devices/platform/pxa27x-ohci/usb1/power/wakeup
17:22.23WyrMI tried to echo disabled > ......
17:22.30WyrMbut it still auto resumes.
17:57.38alain2210WyrM: another observation :
17:58.27alain2210the phone was left 20 minutes.
17:59.51alain2210Using FSO, with no suspend.
18:00.15alain2210it get  BP Lowered WDI line. This is not good :(
18:00.37alain2210and 20 minutes after the bp_wake_up is called.
18:00.58alain2210but I get the MUX DLCI 7 Send DISC timeout!
18:01.41WyrMif wdi ever goes low, then you will have no communication with bp.
18:01.49WyrMbp is off when wdi goes low.
18:02.02WyrMit may panic for a number of reasons.
18:02.10WyrMit is hard to tell what happened.
18:02.23WyrMI dont know what userspace (fso) is doing.
18:02.38alain2210so. I will see more precisely the next time.
18:02.46WyrMthe most common cause of wdi going low is because BP wants to talk something, but AP is not listening.
18:03.09WyrMadd a #define DEBUG to ezx-bp.c
18:03.31alain2210And as usual, when I do /sbin/halt in this case, the phone does not stop but reboot.
18:03.32WyrMand check if you get a(or more than one) bp_rdy irq just before wdi goes low.
18:04.14WyrMahh, and check your battery
18:04.21WyrMif the battery level
18:04.35WyrMis not enough for bp to work, it will lower wdi and turn off.
18:05.00alain2210no problem with the battery : if have a patched version of fso that do the good usbstat.
18:05.08WyrMheh
18:05.16WyrMdon't test with this patch please.
18:05.25alain2210why ?
18:05.29WyrMif usbstat is on, then the bp will never allow ap to sleep.
18:06.01WyrMeven if everything was working as expected.
18:06.11alain2210I'm not using it everytime : I need to activated GSM in FSO.
18:06.34alain2210I'm not using it for tests.
18:06.36WyrMbut if you don't activate gsm on fso, will it open the mux lines?
18:06.53alain2210yes.
18:07.03WyrMremember that if bp wants to talk, and ap doesn't listen, it will lower wdi.
18:07.11alain2210the mux lines are opened by ezxd.
18:07.21WyrMif bp writes(), ap has to read().
18:07.26WyrMotherwise bp panics.
18:07.31alain2210and fso is reading.
18:07.44alain2210I have read the log of fso.
18:07.53WyrMgood.
18:07.56WyrMso its unrelated :)
18:07.57mickeylhmm, does that hold for _all_ lines? FSO by default only operates 4
18:08.10WyrMmickeyl: all at lines.
18:08.13mickeyldo we need to keep all mux lines opened?
18:08.15mickeyld'oh
18:08.35WyrMIIRC its 0-7
18:08.39mickeylthat's strange
18:08.42mickeylit works fine
18:08.46mickeylbut should bail out then
18:08.53mickeylsince it sends certain indicators on all lines
18:08.56alain2210but when fsp is sleeping : it does not read the bp !
18:08.57mickeylwhich we don't have open
18:09.15WyrMfso sleeping?
18:09.24WyrMyou mean AP sleeping?
18:09.33alain2210no.
18:09.49alain2210fso has some states called "dim" and others.
18:10.12WyrMmickeyl: I haven't tested this fully. But I know that only opening the mux is not enough.
18:10.24mickeylwe need to do some tests there
18:10.37mickeyllike what happens if we shutdown all lines and call the device
18:10.37WyrMprobably BP will lower wdi if the write buffer gets too big.
18:10.44mickeylah yes, that could be
18:12.07WyrM:( another empty battery
18:12.15WyrMI have to wait the other to charge.
18:16.20WyrMalain2210: I have no idea on what is waking ap.
18:17.04WyrMon pxa27x_cpu_pm_prepare I get PWER 00001003
18:17.05WyrMonly if PWER is changed after cpu_pm_prepare, which I think it isn't. :/
18:20.03alain2210WyrM: so if I understand, PWER is change but we don't know where ?
18:20.27WyrMheh, I have no idea on what's really happening.
18:20.30WyrM:)
18:20.47WyrMI can't read GEDR after resume, as I don't have usb after resume.
18:20.59WyrMso I don't know what is really resuming it.
18:21.12WyrMI know that it only resumes if bp is active.
18:21.22WyrMs/resumes/auto-resumes/
18:23.12alain2210I do not understand is this is related to the fact that when wdi is low, the do_hw_reset does not shutdonw the phone.
18:23.34*** join/#openezx shoragan (n=shoragan@debian/developer/shoragan)
18:23.37WyrMjust forget power off for now.
18:23.52alain2210no relation ?
18:23.56WyrMno
18:24.05WyrM2 different things
18:33.20WyrMPEDR = 1
18:34.05WyrMso, its waking up because of gpio0 = bp_rdy
18:42.26alain2210since I discover all theses things, I'm reading Documentation/arm/pxa/mfp.txt
18:43.10alain2210and it is written that pwer does not control the wakeup from gpio any more.
18:43.34WyrMwell, it does.
18:43.35WyrM:)
18:43.43WyrMsoftware can't change the hardware.
18:43.52alain2210yes ;-)
18:43.55WyrMits just that software abstracted PWER.
18:44.05WyrMwe no longer do PWER = xxxxxx;
18:44.22alain2210yes
18:44.23WyrMwe do | WAKE_ON .... on mfp.
18:44.34WyrMand set_irq_wake() or set_gpio_wake()
18:44.51WyrMbut this is not our problem.. wake up is working.
18:44.54WyrMworking too much.
18:44.56WyrM;)
18:45.24WyrMwe need to figure out what we are doing that is causing BP to send us interrupts on bp_rdy.
18:45.46WyrMits something with ap_rdy, or something on the usb port.
18:51.00WyrMit may also be gpio99.
19:04.56*** part/#openezx darion76 (n=darion76@94-248-91-1.dynamic.peoplenet.ua)
19:21.16*** join/#openezx pH5_ (n=ph5@e178231111.adsl.alicedsl.de)
19:28.11*** join/#openezx stefan_schmidt (n=stefan@p5B034838.dip.t-dialin.net)
19:35.40*** join/#openezx flo_lap (n=fuchs@f054218103.adsl.alicedsl.de)
19:55.55alain2210WyrM: If I put the phone in standby, on wake up with touchscreen PEDR=2.
19:56.04alain2210that is normal.
19:56.10WyrMsure.
19:56.17WyrMpedr=2 is pcap
19:56.34WyrMit means that it was not BP that wake it.
19:57.09alain2210exact.
19:57.23alain2210I have tried an old 2.6.21 kernel.
19:57.38alain2210it autoresume from standby.
19:57.57alain2210but I have not print the PEDR.
19:58.15alain2210the new kernel is better.
19:59.47WyrMit shouldn't autoresume with the old kernel.
20:00.01WyrMbut most tests I did on this were with the .16 kernel
20:02.03alain2210I never used a .16
20:10.13WyrMwith the "core" pm_test I can suspend/resume and still have bp comunication.
20:10.25WyrMso, it is really something wrong with the gpios.
20:10.38WyrMap_rdy, or gpio55 or gpio99
20:26.15*** join/#openezx pH5_ (n=ph5@e178235186.adsl.alicedsl.de)
20:40.21alain2210for e680, reading the moto kernel, it is not clear if gpio99 has a action here.
20:40.53WyrMgpio99 is a mistery. :)
20:41.14WyrMthere is code that says that its usb related, and connected to pcap.
20:41.28WyrMother code says it enables a clock on bp that is needed for camera.
20:41.43WyrMother says it is related to e680 keypad
20:41.52WyrMnobody knows what it really does. :)
20:42.15WyrMI exported all bp gpios to userspace.
20:42.25WyrMI will see what happens when I play with them.
20:42.42alain2210how do you do that ?
20:43.07WyrMif it is not used by the kernel with "echo <n> > /sys/class/gpio/export"
20:43.26WyrMif it is used (which is our case), with gpio_export() on kernel code.
20:43.52WyrMthen you control the gpio on /sys/class/gpio/gpio<n>/value
20:43.58WyrMand /direction
20:44.33WyrMits easier to "echo 0 > /sys/class/gpio/gpio4/value" to power off the phone.
20:44.37WyrMand it always works ;)
20:45.36alain2210I have to try that.
20:46.27WyrMnothing happens when I toggle gpio99
20:48.19alain2210I'm rebuilding my kernel after a make clean
20:48.33alain2210since the behaviour is stange.
20:48.52WyrMnothing happens with gpio55 either
20:49.06alain2210two days agos, the bp was working after standby. but not now.
20:49.35WyrMnothing with gpio57
20:49.57WyrM(ap_rdy)
20:50.04alain2210what can happen ?
20:50.11alain2210and how to see it ?
20:50.18WyrMwith ap_rdy I think that something should happen.
20:50.43WyrMI am monitoring the gpios with a printk() on the irq handler.
20:51.11alain2210ok.
20:54.06WyrMno activity by toggling any of the gpios :/
20:55.35WyrMbut sometime after toggling gpio82 to low, and high again, the phone turned off.
20:55.49WyrMlike if the handshake kicked in
20:58.13alain2210yes I remember having read on ezx ml, harald saying that if gpio4 is high, and if bp_reset is toggled
20:58.24WyrMnot gpio4
20:58.30alain2210the phone turn of.
20:58.34alain2210no gpio57
20:58.45WyrMyeah.
20:59.07WyrM57 is ap_rdy
20:59.08alain2210yes
20:59.19alain2210but I put this in ezx-bp : reset.
20:59.36alain2210but the phone does not shutdown....
21:01.10WyrM?
21:01.48alain2210this is in the poweroff.patch
21:05.34WyrMalain2210: are you testing suspend/resume with or without a SIM card?
21:05.44alain2210with sim card
21:05.53WyrMok
21:05.57WyrMim testing without.
21:06.16WyrMand I don't remember if I used or not a SIM before.
21:06.16WyrM:)
21:06.34alain2210I never test without.
21:10.05*** join/#openezx ph5 (n=ph5@e178216041.adsl.alicedsl.de)
21:40.46*** join/#openezx CIA-18 (n=CIA@208.69.182.149.simpli.biz)
21:42.11alain2210goodnight.
21:43.17mickey|bblg'night alain2210
21:43.45alain2210thanks
22:33.45WyrMhow do I workaround "Packages were found, but none compatible with the architectures configured" on opkg?
22:36.00WyrMor, can somebody send me ts_test/ts_print/ts_printraw?
22:37.30mickey|bblnever seen this message, but i can send you the packages you need
22:37.35mickey|bbllet me upload
22:37.40WyrMthanks!
22:37.50WyrMI downloaded the ipks from angstrom.
22:37.57WyrMbut they don't work on my rootfs.
22:39.32mickey|bbltry extracting http://linuxtogo.org/~mickeyl/misc/data.tar.gz
22:39.44mickey|bblif these don't work, then I'll boot my ezx device and upload those
22:40.08mickey|bbl(i have removed my a780 build tree in order to build from scratch)
22:41.17WyrMit works.
22:41.18WyrMthanks
22:41.28mickey|bblnp
22:44.28WyrMfunny
22:44.39WyrMts_test draws dashes.
22:44.41WyrMnot lines.
22:44.41WyrM:)
22:45.23mickey|bblgood!
22:45.35mickey|bblerr no
22:45.37mickey|bblnot good
22:45.43mickey|bbl(i read vice versa)
22:58.34WyrMall spurious up events are because a failure on pressure reading.
22:58.41WyrMposition is read ok.
22:59.06WyrMso, I will no longer use pressure to determine pen up events.
22:59.19WyrMis pressure is invalid, I will just report the last valid pressure.
22:59.28WyrMs/is p/if p/
23:04.02mickey|bblsounds good
23:11.03WyrMgood, I can draw lines again! :)
23:14.41mickey|bblyay :)
23:14.45mickey|bbllines good, lines important ,)
23:15.09WyrMthe driver is still reporting 2 release events.
23:18.43mickey|bblhmm, one too many
23:48.19WyrMlooks perfect now.
23:49.10mickey|bblawesome! i'd love to test that but i'm falling asleep... need to do that tomorrow ;)
23:49.22mickey|bblthanks and g'night!
23:49.27WyrMok, I will commit it to our git.
23:49.41WyrMgood night!
23:54.45WyrMdone.

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