irclog2html for #htc-linux on 20070218

00:01.10psokolovsky_pH5, well, I'd say that we exactly not duplicate, but generalize all that stuff which already appears many-many times in kernel
00:01.39psokolovsky_we indeed could go for yet another adhoc function pointer indirection case,
00:02.06psokolovsky_but I'd like to put it exactly as defining OOP interfacing and implementing them via virtual methods
00:02.37pH5psokolovsky_: I'm not saying duplicating it is a bad thing, just that we might check whether upstream had any issues with the isa method and if not, we might try to follow its form.
00:04.01*** join/#htc-linux ellisway (n=ellis@host-87-74-241-174.bulldogdsl.com)
00:04.37psokolovsky_pH5, yes, actually, it's good "prior art" case, of course. as you see, what I propose is just put those func pointers into separate structure, before embedding in pdata.
00:05.06psokolovsky_that would allow for better separation and potentially implementing multiple interfaces by the same device
00:05.16psokolovsky_otherwise, it's indeed the same
00:08.18*** join/#htc-linux jjazz__ (n=jjazz@cpe-24-90-14-159.nyc.res.rr.com)
00:10.10pH5psokolovsky_: why would you want multiple interfaces?
00:11.46psokolovsky_pH5, who knows ;-) I don't say it's required, I say it's extra feature. but I indeed would like to separate device's interface from device's config data. vtable struct does just that.
00:12.09psokolovsky_pH5, otherwise, I can make up not too far-fetched example:
00:13.20psokolovsky_suppose there're 2 types of gpio chips: "dumb" (gpio get/set) and "pic'ed" (ability to get interrupt from gpio line, and thus need to convert gpio# to irq#)
00:19.27pH5I thought we are talking about adc drivers here.
00:19.40pH5Is this kind of separation done anywhere else in the kernel?
00:20.45pH5I'd try to pioneer new ideas where it actually makes sense (i.e. the gpio example sounds sensible).
00:21.23psokolovsky_pH5, I'd say, for such separation to be in place, you need to have paradigm in place. otherwise, it is done in adhoc way (just stick func pointer into pdata/any other structure).
00:21.45psokolovsky_pH5, so yes, we now have two real usecases for it:
00:21.57psokolovsky_1. General GPIO access
00:22.10psokolovsky_2. polymorphic ADC drivers
00:22.17*** join/#htc-linux cyrill62 (n=cyrill62@142.233.146.195.dynamic.adsl.abo.nordnet.fr)
00:22.24pH5what are polymorphic adc drivers?
00:22.26psokolovsky_more may come
00:22.48pH5maybe I'm missing some background on adc drivers.
00:23.28psokolovsky_pH5, that's when TS driver doesn't care which ADC driver it uses. we have that already. except that machine init code still have to know too much about ADC driver to configure that
00:24.02pH5but for that multiple interfaces are not needed.
00:24.25psokolovsky_pH5, we now have 2 TS drivers for generic ADC api: one which assumes hardware debouncing, another does sw debouncing
00:24.53psokolovsky_those 2 driver should be enough to handle *any* TS. all you need to do is write ADC driver.
00:25.11pH5still, shouldn't we introduce vtable separation in gpio drivers first, where it actually has an advantage over the ad-hoc way?
00:25.17psokolovsky_pH5, again, I didn't tell mult.interfaces *needed* ;-)
00:25.28pH5for adc you just need an adc_driver platform_data with a sample function pointer.
00:25.56psokolovsky_pH5, well, that'd be pretty serious change. we should test it on ADC drivers, which are new thing on their own.
00:26.15psokolovsky_pH5, yeah, ADC's interface is that simple ;-)
00:26.19pH5But I wouldn't like to add another layer of abstraction just for the sake of it if it could make upstream adoption harder.
00:27.20psokolovsky_pH5, there's really thin layer of abstraction (extra enclosed structure). and that's actually to separate stuff properly, i.e make it simpler, not harder essentially
00:30.24*** join/#htc-linux jjazz (n=jjazz@cpe-24-90-14-159.nyc.res.rr.com)
00:31.24pH5psokolovsky_: so let's try it this way and see if we can sneak this by the upstream guys?
00:32.11pH5I don't like the 'convenience' macro though.
00:32.33psokolovsky_pH5, yes, I'd propose to implement it on ADC, commit, test, and write RFC for that to lkml.
00:33.02psokolovsky_pH5, what do you propose instead? you want to do 80-char long typecasts?
00:34.51pH5wow, I'm not constructive right now, all I ever say is 'I don't like' :)
00:35.33pH5how about adc_driver adc; adc.methods->sense()?
00:36.25psokolovsky_pH5, that's all open to discussion and search, of course. but such paradigms only fly if you can have sane syntax for them.
00:36.53psokolovsky_pH5, well, that requires whole statement to get adc_driver first ;-)
00:37.10pH5psokolovsky_: exactly, but sane syntax is something we could disagree upon :)
00:37.31pH5psokolovsky_: you are already getting platform_data anyway in most functions
00:37.52psokolovsky_for adc that's ok, but think gpios - if to flip bit you need to write 2 statements instead of one function call...
00:38.08pH5I guess we should just commit, test and then discuss changes.
00:38.46pH5psokolovsky_: right. gpios are not trivial.
00:39.06psokolovsky_pH5, well, I wouldn't argue on that. my idea was to show that with moving from CPU's gpio API to GPIO interface, you still can set gpio with "one call".
00:39.13psokolovsky_ok!
00:42.11*** join/#htc-linux jjazz_ (n=jjazz@cpe-24-90-14-159.nyc.res.rr.com)
00:43.51pH5psokolovsky_: common gpio api for static/dynamic off-cpu gpios needs some more infrastructure though. if you need to supply a device every time you want to flip a gpio, it's not convenient anymore.
00:44.39fluffspH5: the gpio api sucks
00:44.40psokolovsky_pH5, well, instead of just gpio#, you need to suply pair <master_device, gpio#>. it's not that bad, after all.
00:44.46pH5I'm curious how the current irq discussion will turn out.
00:44.50pH5fluffs: agreed
00:45.11psokolovsky_anyway, thanks for discussion! let's give it more thought.
00:45.22psokolovsky_I'm off for today.
00:45.27psokolovsky_Good night!
00:46.41pH5psokolovsky_: good night
00:59.53*** join/#htc-linux tudenbart (n=willi@xdsl-213-196-220-28.netcologne.de)
01:03.19*** join/#htc-linux shido6 (n=shido6@d221-68-200.commercial.cgocable.net)
01:28.23*** join/#htc-linux cyrill62 (n=cyrill62@142.233.146.195.dynamic.adsl.abo.nordnet.fr)
01:47.38*** join/#htc-linux Hawk||- (n=Hawk@p57A524D8.dip0.t-ipconnect.de)
02:02.11*** join/#htc-linux pH5_ (n=ph5@p5485DC67.dip.t-dialin.net)
02:14.44*** join/#htc-linux shido6 (n=shido6@d221-68-200.commercial.cgocable.net)
02:41.51*** join/#htc-linux Ralith (n=ralith@soggy202.drizzle.com) [NETSPLIT VICTIM]
02:41.51*** join/#htc-linux tgnard (n=tgnard@boi78-3-82-246-26-13.fbx.proxad.net) [NETSPLIT VICTIM]
02:41.51*** join/#htc-linux lkcl (n=lkcl@53541584.cable.casema.nl) [NETSPLIT VICTIM]
05:36.22*** join/#htc-linux shido6 (n=shido6@d221-68-200.commercial.cgocable.net)
06:37.51*** join/#htc-linux goxboxlive (n=goxboxli@206.80-202-161.nextgentel.com)
06:38.00*** join/#htc-linux rmoravcik (n=rmoravci@icm3-orange.orange.sk)
07:35.53goxboxliveanyone awake?
07:39.17*** join/#htc-linux RoEn_PC (n=roen@p54A64932.dip.t-dialin.net)
08:13.20*** join/#htc-linux asylumed (n=insanity@vc-196-207-41-253.3g.vodacom.co.za)
08:43.15*** join/#htc-linux rob_w (n=bob@p85.212.175.228.tisdip.tiscali.de)
08:43.26*** join/#htc-linux psokolovsky_ (n=psokolov@82.193.98.2)
08:50.41goxboxlivehttp://www.i-mate.no/e107_files/downloads/Produktark/7150.jpg
08:55.42*** join/#htc-linux ellisway (n=ellis@host-87-74-241-174.bulldogdsl.com)
09:01.01goxboxliveit lacks gps.
09:02.16goxboxliveBut it is suplied with 128MB ram
09:02.29*** join/#htc-linux pH5 (n=ph5@p5485DC67.dip.t-dialin.net)
09:31.14*** join/#htc-linux pwr (n=pwr@86.121.234.119)
10:05.06*** join/#htc-linux rmoravcik (n=rmoravci@icm3-orange.orange.sk)
10:05.36*** join/#htc-linux alt__ (n=alt@V3612.v.pppool.de)
10:28.31*** join/#htc-linux WizMaui (n=WizMaui@62.112.90.231)
11:27.45goxboxlivecr2: Are you awake?
11:40.22cr2yes.
11:54.17*** join/#htc-linux dullard (n=jim@adsl-static-1-30.uklinux.net)
11:55.47goxboxlivecan you translate this for me: optisch gibt es minimale Abnutzungserscheinungen die aber keineswegs stören.
11:57.18goxboxliveor any other german people here.
12:01.12goxboxlivecr2: Still awake?
12:03.48goxboxlivecr2: Why dont we try out the new generic touchscreen driver? Maybe it is more power friendly than the one we are using. It drains battery AFAIK.
12:11.46pH5goxboxlive: there are minimal visible signs of wear, but the seller thinks they are insignificant ('not disturbing at all').
12:12.05goxboxlivepH5 i c thank you very much.
12:12.19pH5np
12:12.57goxboxliveYou se some of the online translaters said both: NOT in a good tecn..... and In a good techn... so i got confused :-)
12:17.24pH5yeah, online translaters often produce interesting results :)
12:17.30goxboxlive:-)
12:30.34lkclpsokolovsky: just read the thingies about GPIO.  imagine a scenario where you have multiple CPUs in a SoC... you might want to bear that one in mind
12:30.50psokolovsky_Hi!
12:31.24psokolovsky_lkcl, sure, that scheme works for everything. Or can you show example when it wouldn't?
12:35.27lkclallo dude :)
12:35.54lkcloh - ok - so, you have a tuple <gpio_on_cpu_1>, <pin 5>
12:36.38lkclright.  i'm going to stare at kid's crap dutch tv and eat breakfast :)
12:36.54lkclnot understanding a woooord that's being said is my speciality ha ha
12:39.38cr2hi lkcl
12:40.16cr2psokolovsky_: what was the reason c++ was considered harmful in the kernel ?
12:40.19lkclallo cr2, how are ya?
12:40.39lkcltoo much implicit stuff behind it, cr2
12:40.49cr2lkcl: thanks, still trying to boot the kernel on hermes.
12:41.09lkclque?? weird...
12:41.26lkclhermes, hermes... ohbollocks, yeh.
12:42.12lkclbut dang that's going to be a weird one.  oh - you looked at the serial ports n everything, right?
12:42.19cr2i have also logged lots of GL data. waiting for the moko people.
12:42.30cr2on hermes ? yes.
12:42.49cr2i've identified the bt/phone/ir.
12:43.02psokolovsky_cr2, well, kernel is written in C, that's enough reason not to use C++. note that what I propose has nothing to do with C++ ;-). C++ and what I propose are siblings of the OOP idea. So, it's not the case that I wnat to drag C++ into kernel, I propose to use paradigm which has proven its soundness with many other implementations.
12:43.05cr2and decoded the nand params.
12:43.10*** join/#htc-linux WizMaui (n=WizMaui@62.112.90.231)
12:44.24cr2psokolovsky_: i see.
12:49.00cr2lkcl: it seems that i'll get a hima with the broken lcd backlight soon.
12:50.40*** join/#htc-linux WizMaui (n=WizMaui@62.112.90.231)
12:51.25lkclcool.  well, that's no hardship
13:04.42goxboxlivelkcl: You dont have to think about selling me the A780 anymore. I bought one from ebay now. Thanks anyway.
13:04.49lkclyaay!  well done dude
13:05.10*** join/#htc-linux pleemans (n=peter@d51A5E76A.access.telenet.be)
13:05.14goxboxlive:-) well lets hope i dont be scammed. :-)
13:08.34lkcl*snort*...
13:09.05lkclbtw does anyone have a device running a javascript-capable web browser, with a screen only 320 pixels wide?
13:16.31lkcli got a web page that needs viewing :)
13:21.43cr2lkcl: wget :)
13:22.15lkcl*snort*.  i just rewrote it with pyjamas.pyworks.org which is google-web-kit ported to python.
13:22.50lkcland i built in a detection of screen width, and reconfigure the site based on that.  and i wanna know if it goes down to 300 pixels wide on other browsers
13:24.54cr2start X with a respective modeline.
13:27.14lkclyehh i knowww.  or run firefox with a different wiiidth.  that works fine.
13:29.43*** join/#htc-linux Alendit (n=alt@V3612.v.pppool.de)
13:57.02*** join/#htc-linux tudenbart (n=willi@xdsl-213-196-251-226.netcologne.de)
14:07.13*** part/#htc-linux Alendit (n=alt@V3612.v.pppool.de)
14:07.24*** join/#htc-linux alt_ (n=alt@V3612.v.pppool.de)
14:11.26*** join/#htc-linux pleemans (n=peter@d51A5E76A.access.telenet.be)
14:13.14alt_hi
14:13.53alt_is there a way to install opie on magician?
14:21.34alt_hi, is there a way to install opie on magician?
14:26.18cr2alt_: use the archive for universal, and modify the serial ports, bt and so on.
14:27.21alt_how can i modify serial ports?
15:01.25*** join/#htc-linux pleemans (n=peter@d51A5E76A.access.telenet.be)
15:23.26*** join/#htc-linux rob_w (n=bob@p85.212.175.61.tisdip.tiscali.de)
16:15.19*** part/#htc-linux rmoravcik (n=rmoravci@icm3-orange.orange.sk)
17:19.25*** join/#htc-linux WizMaui (n=WizMaui@62.112.90.231)
17:19.52*** join/#htc-linux snerfu (n=brian@ip68-229-242-231.ok.ok.cox.net)
17:26.59*** join/#htc-linux alt_ (n=chatzill@V3612.v.pppool.de)
17:30.35Alenditdoes anybody knows if there vibration alarm support on magician?
17:32.20*** part/#htc-linux snerfu (n=brian@ip68-229-242-231.ok.ok.cox.net)
17:39.50pH5Alendit: there is (it's a userspace issue. you can switch the vibrator via the led sysfs api)
18:19.04*** join/#htc-linux goxboxlive (n=goxboxli@206.80-202-161.nextgentel.com)
18:46.23*** join/#htc-linux goxboxlive (n=goxboxli@206.80-202-161.nextgentel.com)
19:45.24cr2goxboxlive: nokia maps work on my universal.
19:52.53*** join/#htc-linux rob__w (n=bob@p85.212.171.218.tisdip.tiscali.de)
20:19.23*** join/#htc-linux shido6 (n=shido6@d221-68-200.commercial.cgocable.net)
20:54.07*** join/#htc-linux cyrill62 (n=cyrill62@ble59-5-82-233-205-36.fbx.proxad.net)
21:10.38*** join/#htc-linux rmoravcik (n=rmoravci@pc-3s0zt5w2e4y0vzmhnrzq3a21zqajzfw.users.student.utc.sk)
21:22.21*** join/#htc-linux Tjikkun (n=tjikkun@82-204-54-115.dsl.bbeyond.nl)
21:23.00*** join/#htc-linux psokolovsky_ (n=psokolov@82.193.98.2)
21:30.21*** part/#htc-linux WizMaui (n=WizMaui@62.112.90.231)
22:25.56*** join/#htc-linux g3gg0_ (n=g3gg0@ppp-62-245-209-124.dynamic.mnet-online.de)
22:48.58*** join/#htc-linux cyrill62 (n=cyrill62@ble59-5-82-233-205-36.fbx.proxad.net)
22:56.48*** join/#htc-linux Malek_ (n=chatzill@pool-72-78-2-146.phlapa.east.verizon.net)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.