IRC log for #openezx on 20081123

00:02.30sn9Kensan: well, do you have any reason to suspect any uma uses any ike v1 in any way?
00:07.03Kensansn9: no, albeit wikipedia says "The first service launch was BT with BT Fusion in the autumn of 2005. The service is based on technology which is pre-3GPP GAN standard."
00:07.21Kensansn9: IKEv2 was standardized (became RFC) in 05.
00:08.12Kensansn9: so maybe...
00:09.05sn9that makes no sense; gan is defined only by 3gpp
00:13.20sn9in the auth packets in the ike exchange, the a910 identifies itself using the first-generation 3gpp notation, which differs slightly from 3gpp's second-generation notation
00:28.42*** join/#openezx gmzhuo (n=gmzhuo@125.69.10.89)
00:49.51sabrodsn9: intersting thing is t-mobile is not a dsl provider... UMA is sold by them, here in europe, that means basicaly there is no hotspots
00:50.01sabrodexept yours
00:50.38sabrodoops i forgot the <space> !  lol
01:02.12stefan_schmidtnight all
01:05.47tmztstefan_schmidt: atchannel in android ril seems to be able to handle the combined smd0
01:09.29tmztWyrM: how do you wnat that lm patch structured in topgit?
01:45.37*** join/#openezx sabrod_ (n=mac@lns-bzn-53-82-65-63-242.adsl.proxad.net)
01:53.01sn9sabrod_, p3t3r__, whoever else: look at section 5.2.1 on page 19 of http://kom.aau.dk/~ff/UMA/Stage3.pdf
01:53.28sn9that differs slightly from what the a910 does
02:33.08*** part/#openezx p3t3r__ (n=peter@134.245.164.105)
02:39.27sn9seems that is handled by libezxtapi.so
02:44.15*** join/#openezx johanbr (n=j@blk-7-128-3.eastlink.ca)
03:12.10*** join/#openezx SuN (i=unices@82-170-225-106.ip.telfort.nl)
03:29.58WyrMDavid Brownell give me work for one week on his review :/
05:41.40*** join/#openezx flyhorse|linux (n=flyhorse@116.4.83.158)
09:46.15*** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be)
09:56.40*** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1)
10:31.58*** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be)
10:54.52*** join/#openezx l403 (n=l@85.132.159.239)
11:41.28*** join/#openezx toi (n=pleemans@d5153128F.access.telenet.be)
13:47.11*** join/#openezx p3t3r__ (n=peter@134.245.164.105)
13:53.39*** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1)
14:05.10ao2hi
14:05.42ao2WyrM, I havw I/O error on a910 when accessing the MMC card, could it be due to some change in pcap?
14:05.57ao2s/havw/have/
15:18.00*** join/#openezx johanbr (n=j@blk-7-128-3.eastlink.ca)
15:39.48WyrMao2: hum. I think no.
15:40.21ao2WyrM, I'll try with another card
16:07.09CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r787b61460c 10openezx/drivers/mfd/ezx-pcap.c:
16:07.09CIA-29OpenEZX: David Brownell:
16:07.09CIA-29OpenEZX: Those show_regs/store_regs calls would IMO make more sense
16:07.09CIA-29OpenEZX: in debugfs than in sysfs.
16:07.09CIA-29OpenEZX: Removed.
16:07.19CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r585c045948 10openezx/drivers/mfd/ezx-pcap.c: move regs debug interface to local patch
16:26.22CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r8236ad4852 10openezx/drivers/mfd/ezx-pcap.c:
16:26.22CIA-29OpenEZX: David Brownell:
16:26.22CIA-29OpenEZX: For general paranoia, the probe() should abort if pcap.spi is
16:26.22CIA-29OpenEZX: already set ... and its cleanup path, plus remove(), should
16:26.22CIA-29OpenEZX: null that pointer.
16:26.31CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r953c0de257 10openezx/drivers/mfd/ezx-pcap.c:
16:26.31CIA-29OpenEZX: David Brownell:
16:26.31CIA-29OpenEZX: If you're going to mark the probe() as __devinit, then mark
16:26.32CIA-29OpenEZX: the remove() as __devexit and use __devexit_p() in the driver
16:26.34CIA-29OpenEZX: struct.
16:31.01CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * rf7b4da36c3 10openezx/drivers/mfd/ezx-pcap.c: copynpaste glitch
16:37.42ao2WyrM, same also with the other card, I noted I get "mmc_spi spi1.1: can't change chip-select polarity" on console
16:39.12WyrMao2: then something is wrong with my commits to ezx/mach/mci
16:39.37ao2I'll give a look at the history
16:39.46*** join/#openezx tombhadAC (n=tombhad@pD95DCF72.dip.t-dialin.net)
16:39.47WyrMif you have some time, check the commit that addresses Robert Jarzmik's comments
16:40.33WyrMI've had problems using XOR instead of (cond ? val1 : val2)
16:40.42WyrMahh.
16:41.04WyrMforget, for mmc cs im using NOT.
17:15.52CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * rca0fde9a13 10openezx/drivers/mfd/ezx-pcap.c: use NULL instead of 0
17:16.03CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r3bf801807e 10openezx/drivers/mfd/ezx-pcap.c:
17:16.03CIA-29OpenEZX: David Brownell:
17:16.03CIA-29OpenEZX: Unless it needs the full duplex capability of SPI, then
17:16.03CIA-29OpenEZX: you should be able to make write_then_read work ... on
17:16.03CIA-29OpenEZX: the other hand, if you do need full duplex, then you
17:16.05CIA-29OpenEZX: should address the DMA.
17:16.13WyrMao2: any clue about the mmc cs issue on a910?
17:17.05ao2compiling with the old a910_mmc_cs_control() to see if it works
17:20.54*** join/#openezx Kensan (n=ken@gw.ptr-80-238-186-16.customer.ch.netstream.com)
17:40.41ao2WyrM, still I/O errors
17:40.55ao2so it's not a910_mmc_cs_control()
17:41.07WyrMao2: then something changed upstream.
17:41.56ao2pxa2xx-spi or mmc_spi, let's check
17:42.15WyrMmore likely mmc_spi.
17:51.44ao2the only substantial change in the last mont is in pxa2xx-spi but eve reverting it does not help. I am now trying without DMA
17:52.21WyrMao2: have you added the patch to allow spi sharing to mmc_spi.c?
17:52.38ao2WyrM, yes
17:58.57ao2mmh, what about the mmc layer? The exact error I get is: "mmcblk0:error -22 sending read.write command" and then
17:59.36ao2"end_request: I/O error, dev mmcblk0, sector xxxx"
18:02.22ao2read/write instead of read.write
18:14.15*** join/#openezx johanbr (n=j@JBrannlund2.MathStat.Dal.Ca)
18:26.40*** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be)
18:41.04*** join/#openezx flyhorse|linux (n=flyhorse@116.4.83.158)
19:03.43*** join/#openezx sabrod (n=mac@lns-bzn-60-82-254-247-46.adsl.proxad.net)
19:14.50*** join/#openezx flo_lap (n=fuchs@f054166229.adsl.alicedsl.de)
19:20.10*** join/#openezx johanbr (n=j@JBrannlund2.MathStat.Dal.Ca)
19:24.20*** join/#openezx johanbr (n=j@JBrannlund2.MathStat.Dal.Ca)
19:51.22*** join/#openezx flo_lap (n=fuchs@f054166229.adsl.alicedsl.de)
20:08.22*** join/#openezx l403 (n=l@85.132.159.239)
20:31.36*** join/#openezx l403 (n=l@85.132.159.239)
20:50.54CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r8de7a80268 10openezx/drivers/mfd/ezx-pcap.c: David Brownell: (And byteswapping, either way.)
22:03.47*** join/#openezx agd5f (n=alex@c-68-49-28-208.hsd1.va.comcast.net)
23:16.49CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * rc294c5e0d5 10openezx/drivers/mfd/ezx-pcap.c:
23:16.49CIA-29OpenEZX: Remove byte swapping again.
23:16.49CIA-29OpenEZX: David Brownell:
23:16.49CIA-29OpenEZX: my apologies, I didn't notice
23:16.50CIA-29OpenEZX: the "bits_per_word = 32" line, you shouldn't need to
23:16.51CIA-29OpenEZX: do additional conversions
23:26.55CIA-29OpenEZX: 03Daniel Ribeiro <drwyrm@gmail.com> 07ezx/current * r3a8f41ad73 10openezx/drivers/mfd/ezx-pcap.c:
23:26.55CIA-29OpenEZX: David Brownell: (about bits_per_pixel)
23:26.55CIA-29OpenEZX: In any case, doing it as a per-transfer override for each
23:26.55CIA-29OpenEZX: transfer is odd; best you just do it during probe() by calling
23:26.55CIA-29OpenEZX: spi_setup(). That way you'll know *early* if you're
23:26.59CIA-29OpenEZX: running on a controller that doesn't handle 32-bit words.
23:27.11WyrMerr, s/pixel/word/ im thinking about 18bpp while working at pcap/spi :)
23:40.02*** part/#openezx p3t3r__ (n=peter@134.245.164.105)
23:44.40*** join/#openezx BadCluster (n=badclust@190.50.185.6)

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