| 01:15.28 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 02:51.08 | *** join/#openezx Dominus (i=unices@82-170-225-106.ip.telfort.nl) |
| 02:58.54 | *** join/#openezx flyhorse|linux (n=flyhorse@116.4.54.230) |
| 03:10.38 | *** join/#openezx arne_ (i=nobody@dslc-082-082-081-158.pools.arcor-ip.net) |
| 03:18.26 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 05:11.14 | *** join/#openezx dth (n=dth@p4FDEDDDA.dip.t-dialin.net) |
| 06:43.26 | *** join/#openezx SuN|2 (i=unices@82-170-225-106.ip.telfort.nl) |
| 06:43.53 | *** join/#openezx pleemans (n=toi@d51A49C45.access.telenet.be) |
| 07:09.05 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 07:14.07 | Hopscotch | good morning |
| 07:19.00 | *** join/#openezx l403 (n=l@85.132.159.239) |
| 07:42.30 | *** join/#openezx jamesmck (n=james@gimel.esc.cam.ac.uk) |
| 07:50.29 | *** join/#openezx WyrM1 (n=wyrm@20158130219.user.veloxzone.com.br) |
| 08:08.37 | *** join/#openezx Sleep_Walker (n=Sleep@nat/suse/x-e4f5b238baa40ef8) |
| 08:12.32 | *** join/#openezx marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 08:34.11 | *** part/#openezx dth (n=dth@p4FDEDDDA.dip.t-dialin.net) |
| 09:03.40 | ao2 | WyrM1, about the probe function issue in pcap subdevs, it gets indeed called if I use platform_driver_register() instead of platform_driver_probe() directly as I was doing in the init method, it's because the probe method can be called only _after_ pcap allocated and _added_ the subdevice, instead my module init method was being called before pcap-core one. Was that because of linking order? |
| 09:13.17 | *** join/#openezx flo_lap (n=fuchs@f048237057.adsl.alicedsl.de) |
| 09:13.54 | *** join/#openezx alain2210 (n=alain@AMontsouris-151-1-66-165.w82-123.abo.wanadoo.fr) |
| 10:02.31 | *** join/#openezx flo_lap (n=fuchs@f048237057.adsl.alicedsl.de) |
| 10:12.38 | WyrM1 | good morning. |
| 10:13.02 | *** join/#openezx gDD (n=gDD@unaffiliated/gdd) |
| 10:13.13 | WyrM | ao2: I don't think it was linking order. |
| 10:14.19 | WyrM | ao2: as we are using the spi subsystem, and pxa2xx_spi.c uses module_init(), its normal that pcap will not be probed very early. |
| 10:15.01 | WyrM | any reason that you need to use platform_driver_probe instead of register? |
| 10:18.13 | ao2 | I just read that non-hotplug drivers are supposed to use platform_driver_probe, and used it. No any other reason. |
| 10:19.50 | WyrM | altough its not hot-plug on ezx hardware, the software is hot pluggable. |
| 10:20.35 | WyrM | we could use platform_driver_probe, but then we would need to change pxa2xx_spi.c and ezx-pcap.c to init at subsys_initcall. |
| 10:20.59 | WyrM | we will probably do this on the future, because of cpufreq-pxa2xx.c |
| 10:22.01 | ao2 | well, platform_driver_register works for now, so, yes, we can leave that for later |
| 10:22.09 | WyrM | see the cpufreq: add vcc_core regulation thread on lakml. If the current approach by Robert Jarzmik gets merged, there will be no other way to use our regulator to change core voltage. |
| 10:43.37 | *** join/#openezx marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 11:17.13 | WyrM | I will submit pcap-core driver, any objections? :) |
| 11:18.42 | WyrM | http://git.pengutronix.de/?p=sha/linux-2.6.git;a=blob;f=drivers/input/touchscreen/mc13783_ts.c;h=f9653dab4e8f77252f406efff34cf2e8e60e88b8;hb=8fe6e7553d66e95266583fcb39b4f4d1abe4fbc2 |
| 11:18.53 | WyrM | ^ MC13873 Touch Screen driver. |
| 11:19.20 | WyrM | no adc abstraction (if the TS driver is used, no adc for everything else), and no pressure reading ;) |
| 11:38.11 | ao2 | go with pcap WyrM |
| 11:38.26 | WyrM | the driver is looking good. |
| 11:38.40 | WyrM | and really, we need to merge this before mc13783 driver. |
| 11:39.19 | WyrM | otherwise we risk to have to extend their driver to support our chip |
| 11:39.38 | ao2 | yes, agreed. |
| 11:41.13 | WyrM | we will have problems with irq with the ts driver. |
| 11:41.20 | WyrM | but we can fix these later ;) |
| 11:41.26 | ao2 | send it for review, and really, the little concerns I had about naming are not very important if we want to win :) |
| 11:44.57 | CIA-33 | OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r74f261730c 10openezx/drivers/mfd/ezx-pcap.c: cleanup headers |
| 11:50.55 | *** join/#openezx gmzhuo (n=gmzhuo@118.113.165.89) |
| 11:55.46 | WyrM | can somebody review the description? |
| 11:55.48 | WyrM | http://pastebin.ca/1427362 |
| 11:56.09 | WyrM | tmzt: ping |
| 11:58.25 | CIA-33 | OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r1b0bcc4df6 10openezx/.topmsg: update description |
| 12:04.33 | ao2 | looks, good, maybe Motorola with capital M, even if they don't deserve it? :) |
| 12:09.21 | gmzhuo | tipically?? |
| 12:09.32 | gmzhuo | or typically? |
| 12:13.48 | gDD | gmzhuo` i thinks capital M mean motorola black M logo:) |
| 12:18.46 | CIA-33 | OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * rae62457f09 10openezx/.topmsg: corrections |
| 12:43.28 | *** join/#openezx florian (n=fuchs@f048237057.adsl.alicedsl.de) |
| 13:01.44 | *** join/#openezx gDD (n=gDD@unaffiliated/gdd) |
| 13:24.43 | *** join/#openezx Dominus (i=unices@82-170-225-106.ip.telfort.nl) |
| 13:43.07 | WyrM | pcap sent. |
| 13:43.22 | WyrM | I hope we can get it in this time. :/ |
| 13:58.29 | gmzhuo | pcap sent to mainline? |
| 13:58.38 | WyrM | mail sent |
| 13:59.03 | WyrM | lets hope it gets accepted this time. |
| 13:59.21 | gmzhuo | :) |
| 14:01.40 | *** join/#openezx gDD (n=gDD@unaffiliated/gdd) |
| 14:22.04 | gmzhuo | How nice the DX900 is |
| 14:22.14 | WyrM | dx900? |
| 14:22.25 | gmzhuo | yes |
| 14:22.33 | WyrM | url? |
| 14:22.38 | gmzhuo | but is's WM |
| 14:22.54 | WyrM | well, then not so nice. ;) |
| 14:22.58 | gmzhuo | http://gnufiish.org/trac/wiki/DX900 |
| 14:23.14 | gmzhuo | I mean the hardware |
| 14:36.16 | gmzhuo | http://gnufiish.org/trac/attachment/wiki/DX900/haret-s3c64xx-dx900.patch |
| 14:36.24 | gmzhuo | C++ in kernel? |
| 14:42.55 | ao2 | gmzhuo, isn't that Haret rather than linux? |
| 14:46.06 | gmzhuo | don't know |
| 14:46.24 | WyrM | its haret |
| 14:49.37 | ao2 | WyrM, what problem were you referring to about pcap-ts? Nested interrupt handlers or something like that? |
| 14:50.21 | WyrM | masking the interrupt from inside the interrupt context. |
| 14:51.19 | WyrM | with the current code, if you call irq_disable() for a pcap interrupt from pcapd context it will not be disabled at the time. |
| 14:51.37 | WyrM | it will finish irq demultiplexing, and mask it only after. |
| 14:52.03 | WyrM | we avoid this race by disabling interrupts while running the demultiplexer. |
| 14:52.22 | WyrM | but this may cause an interrupt loss. |
| 14:52.33 | WyrM | I don't understand this fully yet. |
| 14:52.44 | WyrM | there are 2 issues, one is the masking above. |
| 14:53.05 | WyrM | the other is doing something that would cause another interrupt from inside the irq handler. |
| 14:53.21 | WyrM | we have both issues on the ts driver. :/ |
| 14:53.33 | ao2 | eh, I was doing a dirty test with ts and the old adc code, and if I disable_irq(PCAP_IRQ_TS) the irw handler doesn't get aclled anymore. If I leave it enabled with a dummy handler, then the interrupts are catched |
| 14:54.12 | ao2 | well, the test is independent from the adc code using the dummy handler |
| 14:54.19 | WyrM | in the ideal code, we would not need to disable the irq. ;) |
| 14:54.42 | WyrM | if it doesn't need to disable the irq, then better for us. LOL |
| 14:55.43 | WyrM | anyway, this is hard to get working right. SPI is too slow. And ADC is too fast. |
| 14:55.44 | WyrM | hehehehe |
| 14:56.03 | ao2 | and here comes a stupid question, isn't there any way to spot if the IRQ happened because of touch event or relese, is it? |
| 14:56.22 | WyrM | probably. |
| 14:56.33 | WyrM | check the PSTAT register. |
| 14:56.38 | WyrM | same bits as the ISR. |
| 14:56.52 | WyrM | it will be probably 1 for touch and 0 for release. |
| 14:57.21 | WyrM | hum, very good idea. |
| 14:57.32 | ao2 | eh, because the out of range test to detect release event dosn't fully conviced me, even if it works |
| 14:57.42 | WyrM | currently we consider invalid x/y as pen release. |
| 14:58.10 | WyrM | most ts drivers uses OOR to detect release. :) |
| 14:58.13 | ao2 | the state machine could be simplifies having press and release explicitly |
| 14:58.24 | ao2 | simlpified |
| 14:58.48 | WyrM | yeah, it's a very good idea. |
| 14:59.07 | WyrM | if we can determine touch/release with PSTAT, this will really beautify the code. |
| 14:59.37 | ao2 | and then we need NOT to disable the irq :) |
| 14:59.38 | WyrM | are you going to work on TS simultaneously with ADC? |
| 15:00.30 | ao2 | I think I'll submit something when a basic queuing structure is in place, and then we can go on together |
| 15:01.18 | ao2 | I'll steal some code from drivers/mfd/pcf50633-adc.c |
| 15:03.18 | WyrM | ao2: at first, I would support only instant requests. |
| 15:03.42 | WyrM | timed requests are a little bit harder, because you may get a instant request while waiting, etc.. |
| 15:04.09 | WyrM | let me take a look at pcf50633-adc |
| 15:05.08 | WyrM | yeah, seems good. |
| 15:05.29 | WyrM | but we also need a sync/blocking function. |
| 15:05.31 | ao2 | If you prefer I can commit the raw port of the old code and then improve that along with TS, and then we could think to queuing conversion requests from different sources |
| 15:06.10 | ao2 | I am quite slow you know |
| 15:06.12 | WyrM | ao2 anyway you prefer is good for me :) |
| 15:06.39 | WyrM | if you want me to help while you can't work, then it will be better if you commit it ;) |
| 15:07.15 | ao2 | a new topic branch on the go... :) |
| 15:11.07 | WyrM | thanks! :) |
| 15:16.36 | gmzhuo | WyrM,are you mean adc is faster than spi? |
| 15:17.03 | WyrM | gmzhuo: we can't exactly compare adc and spi. |
| 15:17.39 | WyrM | gmzhuo: but yes, the adc result is ready after ~5 spi I/O operations |
| 15:18.04 | WyrM | maybe even less. |
| 15:18.39 | WyrM | and this at 13Mhz. |
| 15:19.29 | gmzhuo | 5 times spi I/O or 5 bytes? |
| 15:19.46 | WyrM | 5 times. |
| 15:19.52 | WyrM | 32 bit I/O. |
| 15:20.31 | WyrM | total of 40bytes. |
| 15:20.38 | WyrM | 20 in, 20 out |
| 15:20.46 | WyrM | but I never measured this exaclty. |
| 15:20.59 | WyrM | just guessing from previous TS driver development. :) |
| 15:22.46 | ao2 | In Atlas ADC conversion start can be delayed to slow down the whole request/response cycle, not sure in pcap |
| 15:22.59 | WyrM | it can too. |
| 15:23.35 | WyrM | heh, its an alternative way to solve racing on the irq demultiplexer. ;) |
| 15:24.18 | *** join/#openezx LoneStar (n=xinzhen@114.92.181.228) |
| 15:24.39 | WyrM | or we can also use it instead of the sampling timer on the TS. |
| 15:24.50 | WyrM | depending on how much time it can delay, of course. |
| 15:25.30 | ao2 | requesting continuously with delayed start, also sounds good in theory :) |
| 15:26.02 | WyrM | yeah. |
| 15:26.17 | WyrM | but it would be 1 instant, 1 delayed. |
| 15:26.34 | WyrM | because we really want to read pressure and position "together". |
| 15:27.46 | ao2 | there's also a part of the TS spac which talks about a positio mode with TX1/TX2 and TY1/TY2, but I didn't understand if those can be used for "multi-touch" purposes |
| 15:27.53 | ao2 | s/spac/spec/ |
| 15:28.46 | WyrM | let me look at it. |
| 15:28.50 | WyrM | but I think no. |
| 15:30.54 | ao2 | WyrM, page 7-7 on Atlas GPL ref |
| 15:35.08 | WyrM | where? |
| 15:35.16 | WyrM | TSMOD? |
| 15:35.21 | ao2 | yes |
| 15:36.15 | WyrM | 000=off, 001=wait touch, 010=read pressure, 011=read pos. |
| 15:36.20 | WyrM | others are same as 000 |
| 15:36.44 | WyrM | or my version of the document is different than yours?? |
| 15:37.03 | ao2 | no, I just misunderstood the position mode completely |
| 15:39.37 | ao2 | the wording "coordinate pairs" along with the X1/X2 Y1/Y2 names mislead me. I read it as separate coordinate pairs, rather than sequential, sorry |
| 15:40.52 | WyrM | np. |
| 15:41.13 | WyrM | TS?1/TS?2 is probably because atlas supports 2 touch screen panels. |
| 15:41.51 | WyrM | I have no idea on how multi touch works. |
| 15:43.05 | WyrM | with ezx hardware, if you multi touch, the position read will be in the middle of the 2 points :) |
| 15:47.21 | *** join/#openezx agd5f (n=alex@c-69-143-4-28.hsd1.va.comcast.net) |
| 16:23.05 | *** join/#openezx johanbr (n=j@blk-7-129-240.eastlink.ca) |
| 16:39.20 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * rb7b540cfa5 10openezx/.topmsg: Remove the To: from .topmsg |
| 16:39.21 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * rdb0c45d393 10openezx/ (.topdeps .topmsg): Create ezx/pcap_adc branch |
| 16:39.22 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * r65d7ce5d55 10openezx/drivers/mfd/ (Kconfig Makefile ezx-pcap-adc.c): Split out old adc code in a pcap subdriver. |
| 16:39.23 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * r1b0fc81393 10openezx/.topdeps: Make ezx/mach/pcap depend on ezx/pcap_adc |
| 16:51.48 | *** join/#openezx gmzhuo (n=gmzhuo@118.113.165.89) |
| 17:54.59 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * rf93900877f 10openezx/arch/arm/configs/ezx_defconfig: Update ezx_defconfig, enable EZX_PCAP_ADC |
| 18:33.04 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 18:52.01 | *** join/#openezx florian (n=fuchs@f048237057.adsl.alicedsl.de) |
| 19:01.14 | *** join/#openezx marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 19:15.05 | *** join/#openezx darion76 (n=darion76@94-248-9-4.dynamic.peoplenet.ua) |
| 19:16.35 | *** join/#openezx ecloud_work (n=srutledg@gw.autoxray.com) |
| 19:19.38 | ecloud_work | test |
| 19:20.52 | *** join/#openezx ecloud_work (n=srutledg@gw.autoxray.com) |
| 19:25.09 | *** part/#openezx darion76 (n=darion76@94-248-9-4.dynamic.peoplenet.ua) |
| 19:28.07 | *** join/#openezx darion76 (n=darion76@94-248-9-4.dynamic.peoplenet.ua) |
| 20:01.17 | *** join/#openezx sabrod (n=sab@195.154.52.202) |
| 20:06.37 | *** join/#openezx sabro1 (n=sab@195.154.52.202) |
| 20:26.28 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 21:16.28 | *** join/#openezx johanbr (n=j@blk-7-129-240.eastlink.ca) |
| 22:27.31 | *** join/#openezx agd5f (n=alex@c-69-143-4-28.hsd1.va.comcast.net) |
| 23:30.56 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 23:41.53 | ao2 | WyrM, now TS is working, however I think I am abusing the timer in the interrupt handler. I wanted to have it working somehow to test future adc driver changes. |
| 23:42.26 | ao2 | I'll push as soon as tg update completes |
| 23:48.54 | CIA-33 | OpenEZX: 03Antonio Ospite <ospite@studenti.unina.it> 07ezx/current * r340fd5fa60 10openezx/drivers/input/touchscreen/pcap_ts.c: |
| 23:48.54 | CIA-33 | OpenEZX: Dirty fix for touchscreen. |
| 23:48.54 | CIA-33 | OpenEZX: Starting from a working touchscreen driver will ease adc driver overhaul. |
| 23:49.57 | tmzt | WyrM: other than tipically that looked fine, sorry I wasn't on screen :) |
| 23:50.50 | ao2 | see you tomorrow |