**** BEGIN LOGGING AT Thu Dec 30 02:59:58 2010
Dec 30 13:16:30 <tim_abell> http://www.theregister.co.uk/2010/12/30/rogue_sms_danger/
Dec 30 13:17:59 <tim_abell> http://www.theregister.co.uk/2010/12/29/standard_charger/
Dec 30 13:18:08 <tim_abell> all interesting stuff for the neo and its distros
Dec 30 13:26:09 <lindi-> tim_abell: that doesn't have much details yet though
Dec 30 13:27:36 <tim_abell> i've been meaning to make an adaptor to make my neo automatically draw 1A from the car charger
Dec 30 13:27:42 <tim_abell> haven't got round to it yet
Dec 30 13:29:55 <lindi-> tim_abell: do you really need an adaptor? you can just manually enable charging?
Dec 30 13:30:05 <tim_abell> yeah, but it's a pain
Dec 30 13:30:11 <tim_abell> and that only gives you 500ma
Dec 30 13:30:23 <tim_abell> i think my motorolla usb charger can deliver the whole 1000mA
Dec 30 13:30:38 <gena2x> tim_abell: .34 kernel seem like to set 1000mA even for usb
Dec 30 13:30:49 <tim_abell> oh right
Dec 30 13:30:58 <tim_abell> i thought it had to ask nicely to get 1000
Dec 30 13:31:09 <tim_abell> to avoid upsetting computers
Dec 30 13:31:17 <lindi-> tim_abell: only gives 500 mA?
Dec 30 13:31:34 <lindi-> tim_abell: surely you can force it to draw 1000 mA
Dec 30 13:31:46 <tim_abell> the little slider in the power options in my build of shr defaults to 100mA, and i can slide it to 500mA
Dec 30 13:32:13 <gena2x> tim_abell: shr protects your device from you? :)
Dec 30 13:32:13 <tim_abell> you might be able to with dbus calls but that's more than i want to do when setting off in the car
Dec 30 13:32:22 <tim_abell> apparently :)
Dec 30 13:32:44 <gena2x> lindi-: is it possible to force charger to 1A with omhacks?
Dec 30 13:33:45 <lindi-> gena2x: I think so
Dec 30 13:34:05 <gena2x> hm... SMS of death
Dec 30 13:34:17 <lindi-> sms of death is like http://achtbaan.nikhef.nl/27c3-stream/releases/mkv/%5b4060%5d%20SMS-o-Death/20101227-170003.wmv.mkv
Dec 30 13:34:49 <gena2x> FR is in forward of all that phones - it has GSM modem which can die without SMS :)
Dec 30 13:35:02 <tim_abell> lol
Dec 30 13:35:45 <tim_abell> is there a utube of that?
Dec 30 13:35:55 <lindi-> utube?
Dec 30 13:35:59 <tim_abell> youtube
Dec 30 13:36:12 <tim_abell> that's quite a big download :)
Dec 30 13:36:14 <lindi-> tim_abell: isn't that like non-free softwarE?
Dec 30 13:36:30 <tim_abell> and my windoze box declines to play that vid as it downloads it
Dec 30 13:36:46 <tim_abell> sadly i'm stuck in the land of the non-free at the moment :(
Dec 30 13:37:06 <tim_abell> asp.net + visual studio = windows
Dec 30 13:37:11 <gena2x> tim_abell: then move windoze box to trash bin :)
Dec 30 13:37:13 <SpeedEvil> FR can even do the attack also mentioned in that conference - in principle.
Dec 30 13:37:14 <tim_abell> man's gotta eat
Dec 30 13:37:22 <SpeedEvil> To decrypt phone-calls.
Dec 30 13:37:27 <tim_abell> gena2x:  I wish
Dec 30 13:37:46 <SpeedEvil> Though it would need a beefy PC to do the actual decrypt
Dec 30 13:37:59 <tim_abell> the first time i called my mate's iphone from my fr his iphone crashed. most amusing
Dec 30 13:38:08 <gena2x> hehe
Dec 30 13:38:28 <gena2x> damn. i keep laughing.
Dec 30 13:57:18 <[Rui]> tim_abell: lOLOLOL
Dec 30 13:57:31 <tim_abell> :)
Dec 30 13:57:39 <tim_abell> iLOL'd too
Dec 30 14:01:12 * [Rui] rolls on the floor laughing
Dec 30 14:39:15 <gena2x> lindi-: thanks for link. not really impressing, just few funny bugs. i were involved in development of GSM hardware, so somwhow i am not surprised
Dec 30 14:42:00 <gena2x> lindi-: i think it may be more funny to attack GSM switch
Dec 30 18:10:36 <PBeck> hi
Dec 30 19:13:49 <PBeck> ahoi
Dec 30 19:18:31 <PragmaticAnarchy> hi yall
Dec 30 19:20:02 <PragmaticAnarchy> whats the easyest way to partition a sd card from linux?
Dec 30 19:21:41 <gena2x> PragmaticAnarchy: it depends on you, partition table type
Dec 30 19:22:35 <gena2x> PragmaticAnarchy: for me easiest is fdisk for DOS table, gdisk for GPT
Dec 30 19:22:55 <gena2x> PragmaticAnarchy: for you this may be some kind of graphical tool
Dec 30 19:24:00 <gena2x> PragmaticAnarchy: in general you partition sd card just like hdd - no diff at all
Dec 30 19:24:18 <PragmaticAnarchy> i guess fdisk will do the trik i need ext3 and fat partitions
Dec 30 19:25:40 <PragmaticAnarchy> ill try a tutorial from openmoko wiki.. i dont have the same device but i think that if i use the kernel from mines will work
Dec 30 19:26:16 <gena2x> you may partition it on PC
Dec 30 19:26:29 <gena2x> and fdisk will do job
Dec 30 19:26:52 <PragmaticAnarchy> one more thing
Dec 30 19:27:08 <PragmaticAnarchy> does openmoko have any kind of package manager?
Dec 30 19:27:47 <PragmaticAnarchy> in case i want to install plasma mobile
Dec 30 19:32:56 <PBeck> PragmaticAnarchy: opkg
Dec 30 19:33:03 <PBeck> PragmaticAnarchy: the same as ipkg
Dec 30 19:42:19 <gena2x> PragmaticAnarchy: where is no 'openmoko' now. only community supported distros. shr based on opkg and qtmoko based on debian
Dec 30 19:43:07 <lindi-> gena2x: opkg?
Dec 30 19:43:24 <lindi-> gena2x: OE maybe?
Dec 30 19:43:38 <gena2x> lindi-: sure, opkg is name of tool
Dec 30 19:44:34 <gena2x> lindi-: i forgot details, you can provide more preciese information if you feel that is needed
Dec 30 19:44:58 <lindi-> gena2x: I was just bit confused, I thought you were listing distros and wondered if there was some opkg distro at some point :)
Dec 30 19:45:53 <gena2x> lindi-: question were about packages managers in 'openmoko'
Dec 30 19:46:13 <lindi-> ah sorry didn't read anything else :)
Dec 30 19:46:38 <gena2x> lindi-: damn cpufreq still now working. i think i wrote my version, but debugging now :)
Dec 30 20:02:20 <gena2x> lindi-: look like it even working :)
Dec 30 20:03:22 <gena2x> lindi-: lets test suspend/resume...
Dec 30 20:04:01 <gena2x> lindi-: serials...
Dec 30 20:04:51 <gena2x> lindi-: serials look fine
Dec 30 20:06:01 <gena2x> lindi-: so... want to test working cpufreq?
Dec 30 20:06:18 <gena2x> lindi-: so far without voltage regulation
Dec 30 20:06:18 <lindi-> gena2x: I can put it to my test queue yes
Dec 30 20:06:27 <lindi-> gena2x: let's move one step at a time :P
Dec 30 20:06:30 <gena2x> lindi-: but works. 
Dec 30 20:06:50 <lindi-> still haven't tested your u-boot.. I guess I could now
Dec 30 20:07:42 * lindi- fires up the backup phone with "remote_power nokia_charger on"
Dec 30 20:09:13 <gena2x> lindi-: 'backup phone' sounds a bit fearful
Dec 30 20:11:57 <lindi-> well otherwise this scheduled downtime will count as real downtime :)
Dec 30 20:12:42 <gena2x> ah, damn. something with usb. need investigation.
Dec 30 20:14:50 <lindi-> gena2x: does that occur if you enable cpufreq or do you need to also switch frequencies for it to occur?
Dec 30 20:15:17 <gena2x> lindi-: wait, wait. may be this not realed at all
Dec 30 20:19:53 <gena2x> usb clocks are completely separate, should it should just work
Dec 30 23:08:04 <DocScrutinizer> gena2x: volt reg for cpufreq? check latest Nokia patches (if that'S for OMAP N900 at all). There have been instabilities
Dec 30 23:09:37 <gena2x> DocScrutinizer: no way to see except experiment :)
Dec 30 23:10:05 <gena2x> DocScrutinizer: and of course i am about gta02
Dec 30 23:10:24 <DocScrutinizer> gena2x: hmm, hw instabilities are hard to squish
Dec 30 23:11:05 <DocScrutinizer> err, wasn't cpufreq for gta02 quite stable some time ago?
Dec 30 23:11:28 <DocScrutinizer> and no, on 2442 all clocks are related
Dec 30 23:11:43 <gena2x> DocScrutinizer: some aspects were not working
Dec 30 23:11:58 <DocScrutinizer> that's the main poblem with 2442 cpufreq
Dec 30 23:12:41 <DocScrutinizer> you can't switch clock on the fly while tty or usb or anything with a timing is still active
Dec 30 23:13:34 <gena2x> DocScrutinizer: it's possible to set particular freqences like 400:100:50 300:100:50 200:100:50 100:100:50, so memory bus, peripherial bus and so remain stable
Dec 30 23:14:11 <DocScrutinizer> athis doesn't apply to UARTs though afaik
Dec 30 23:14:49 <gena2x> UART's clock source is peripherial bus
Dec 30 23:15:15 <DocScrutinizer> hmm, so maybe my info is obsolete or even my memory is wrong
Dec 30 23:15:57 <DocScrutinizer> tbj I'm not exactly nterested in braindamaged samsung cpu design anymore
Dec 30 23:16:15 <gena2x> it's it just arm core ;)
Dec 30 23:16:27 <gena2x> s/it's/isn't/
Dec 30 23:16:27 <apt> gena2x meant: isn't it just arm core ;)
Dec 30 23:16:28 <DocScrutinizer> lol, 
Dec 30 23:16:48 <gena2x> ok, i am not hw engineer
Dec 30 23:16:56 <DocScrutinizer> SoC is as different as ... nevermind
Dec 30 23:16:56 <gena2x> of course peripherial is not core
Dec 30 23:18:31 <gena2x> DocScrutinizer: the clock source for UART's may be selected from FCLK, PCLK or UEXTCLK. and IMO author need to be sligly braindamaged to select FCLK
Dec 30 23:37:42 <DocScrutinizer> IIRC UEXTCLK is NC on GTA02, a pity
Dec 30 23:38:45 <DocScrutinizer> but honestly this is way too long ago
Dec 30 23:39:53 <DocScrutinizer> we considered having a trace from UEXTCLK to some nice clocksource on same SoC some 3 pins away, for GTA02A6 iirc. Think it never made it to MP though
Dec 30 23:40:05 <DocScrutinizer> too risky :-S
Dec 30 23:44:01 <gena2x> :( but let's hope it will work. in the final end only dividers are changing, so hope it will not take too much time to interfere with serials
Dec 30 23:44:30 <gena2x> cause we have slight moment then PCLK is slower than expected
Dec 31 00:32:51 <DocScrutinizer> this will be enough to introduce errors into an ongoing data transmission
Dec 31 00:33:24 <DocScrutinizer> and that's something you don't like to see ever.
Dec 31 00:33:28 <SpeedEvil> Only inbound though
Dec 31 00:34:19 <DocScrutinizer> that's what I meant: you need to stop and newly set up all UARTs
Dec 31 00:34:31 <DocScrutinizer> for each CPUCLK change
Dec 31 00:34:36 <SpeedEvil> yeah
Dec 31 00:35:15 <DocScrutinizer> 7th hell of manageability
Dec 31 00:35:16 <gena2x> uarts look working guys.
Dec 31 00:35:31 <gena2x> so no problem.
Dec 31 00:35:37 <DocScrutinizer> muhaha
Dec 31 00:36:14 <DocScrutinizer> sorry
Dec 31 00:36:55 <DocScrutinizer> you can't declare an identified problem moot just because it doesn't show up in a single speedy test
Dec 31 00:37:20 <SpeedEvil> Yes you can.
Dec 31 00:37:30 <SpeedEvil> 'Ship it, it compiles'.
Dec 31 00:37:46 <SpeedEvil> OTOH. 
Dec 31 00:37:48 <DocScrutinizer> the problem persists, and you got an aditional one that's either your understanding of the original problem, or your test setup
Dec 31 00:37:57 <SpeedEvil> What potential data corruption issues are there?
Dec 31 00:38:00 <gena2x> hey, i want first to see problem
Dec 31 00:38:12 <SpeedEvil> GPS should be largely unproblematic - it will resend more data
Dec 31 00:38:15 <gena2x> then start thinking is it solvable or not
Dec 31 00:38:29 <DocScrutinizer> gena2x: is this how russia builds nuklear powe rplants?
Dec 31 00:38:30 <SpeedEvil> modem will be unproblematic in some cases, and fail in others.
Dec 31 00:38:35 <gena2x> so far my modem registers and recieve smses
Dec 31 00:38:45 <SpeedEvil> gena2x: try a gprs connect
Dec 31 00:38:56 <SpeedEvil> though ppp can cope with link-level errors
Dec 31 00:38:59 <gena2x> DocScrutinizer: where is difference between power plant and mobile phone
Dec 31 00:39:30 <DocScrutinizer> gena2x: FFS! just because you not yet met the coincidence of cpufreq switch while receiving an important byte of serial data
Dec 31 00:40:17 <DocScrutinizer> gena2x: exactly none. Both shall *eliminate* possible problems
Dec 31 00:40:35 <gena2x> i see no theretical problem
Dec 31 00:40:42 <DocScrutinizer> not wait until they show up, to appreciate them
Dec 31 00:40:57 <gena2x> what the speed of switching FCLK on s3c?
Dec 31 00:41:22 <SpeedEvil> gena2x: several hundred microseconds IIRC
Dec 31 00:41:22 <gena2x> tell me if you want to speak without 'experinets'
Dec 31 00:41:33 <DocScrutinizer> you don't suggest your code is "fast enough"???
Dec 31 00:41:56 <gena2x> SpeedEvil: microseconds to just change divisors? why so long?
Dec 31 00:41:59 <SpeedEvil> Or around a byte at 115200 IIRC
Dec 31 00:42:21 <SpeedEvil> gena2x: Hmm - the PLL needs to stabilise
Dec 31 00:42:29 <SpeedEvil> I thought
Dec 31 00:42:42 <gena2x> It's then you turn it on or off
Dec 31 00:42:42 <SpeedEvil> I forget the architecture
Dec 31 00:43:04 <gena2x> then you, but how long does it take to change dividers?
Dec 31 00:43:21 <gena2x> s/then you,//
Dec 31 00:43:22 <SpeedEvil> If it's just changing dividers, it might be quasi-instant.
Dec 31 00:43:23 <apt> gena2x meant:  but how long does it take to change dividers?
Dec 31 00:43:38 <gena2x> and this is what you do in cpufreq
Dec 31 00:43:52 <gena2x> so i see no reason to get problems with serials
Dec 31 00:43:59 <DocScrutinizer> BS
Dec 31 00:44:02 <SpeedEvil> So, if you can change the frequency divider, and the UART clock at almost the same time, it may work - but the documents aren't clear on this point.
Dec 31 00:44:15 <DocScrutinizer> s/almost//
Dec 31 00:44:16 <SpeedEvil> From memory - it's a long time since I read the docs on this.
Dec 31 00:44:25 <gena2x> more, cpufreq in implemented on huge amount of devices, and seem that work
Dec 31 00:44:33 <gena2x> i mean s3c24xx devices of course
Dec 31 00:44:48 <gena2x> so i see no reason why it should not work on FR
Dec 31 00:45:07 <SpeedEvil> If it's in under 1/nth bit-time - where n is probably 4 or 8 - the skew - and if the underlying hardware is not reset, it's plausible it should 'just work'.
Dec 31 00:45:10 <DocScrutinizer> gena2x: sorry, that's complete crap
Dec 31 00:45:26 <SpeedEvil> But there are a lot of assumptions here.
Dec 31 00:45:34 <DocScrutinizer> yes
Dec 31 00:45:37 <DocScrutinizer> exactly
Dec 31 00:45:42 <SpeedEvil> I'd first want to measure the divider latency
Dec 31 00:45:51 <SpeedEvil> read some other clock before, and after. 
Dec 31 00:45:59 <gena2x> SpeedEvil: 1 bit is 1ms, and our cycle is 1/100 ms
Dec 31 00:45:59 <SpeedEvil> Or emit a signal that can be measured externally
Dec 31 00:46:03 <DocScrutinizer> and my assumption is the systems claiming "WFM" are just not noticing the problems
Dec 31 00:46:17 <gena2x> it's good idea in fact
Dec 31 00:46:21 <DocScrutinizer> or attributing them to something else
Dec 31 00:46:25 <SpeedEvil> gena2x: 1 bit is 1ms at 1000 baud
Dec 31 00:46:26 <gena2x> and relatively easy to measure
Dec 31 00:46:42 <SpeedEvil> gena2x: you have 9us/bit at 115200
Dec 31 00:46:50 <gena2x> ah, sorry i mean us
Dec 31 00:47:04 <SpeedEvil> gena2x: And you need skew to be lower than ~2us, and interruptions to be of the same order
Dec 31 00:47:34 <DocScrutinizer> unfeasible
Dec 31 00:47:54 <gena2x> SpeedEvil: it's easy to measure speed of changing - just do 100'000'000 of them and measure time
Dec 31 00:48:05 <SpeedEvil> My 0th order approach would be to set a GPIO before clock down, and raise it at clock up
Dec 31 00:48:05 <DocScrutinizer> WAAAH
Dec 31 00:48:12 <SpeedEvil> and then hit it with a scope
Dec 31 00:48:19 <SpeedEvil> gena2x: that's not the time you care about
Dec 31 00:48:34 <SpeedEvil> gena2x: though that would work too.
Dec 31 00:48:44 <gena2x> then divide time to 100'000'000 and you'll see 1 switch time
Dec 31 00:48:49 <SpeedEvil> gena2x: though it would give considerably more than the down/up time
Dec 31 00:48:51 <DocScrutinizer> learn to design system architecture
Dec 31 00:48:53 <DocScrutinizer> !!!
Dec 31 00:49:05 <DocScrutinizer> gena2x: ^^^
Dec 31 00:49:08 <SpeedEvil> gena2x: as you don't care about the whole time - simply the time it's not clocked.
Dec 31 00:49:14 <gena2x> DocScrutinizer: which book you can recommend?
Dec 31 00:49:41 <DocScrutinizer> something along the line "writing kernel driver for RTOS" maybe
Dec 31 00:49:41 <gena2x> SpeedEvil: time may be measured with external timer
Dec 31 00:49:44 <SpeedEvil> gena2x: Then you need to address the issue of how the serial module responds to being re-clocked in the middle of a byte. 
Dec 31 00:50:06 <gena2x> SpeedEvil: simple test on large scale
Dec 31 00:50:09 <DocScrutinizer> IT WONT WORK
Dec 31 00:50:26 <DocScrutinizer> it's botch
Dec 31 00:50:28 <gena2x> hey, no heat, we can just test :)
Dec 31 00:50:57 <SpeedEvil> gena2x: Reasonable tests might be to connect the serial port to something external, and run 10 meg of data through it while switching much more often than you would normally
Dec 31 00:51:03 <SpeedEvil> At various baudrates.
Dec 31 00:51:07 <SpeedEvil> Is this ideal - no.
Dec 31 00:51:07 <DocScrutinizer> gena2x: I'm not interested in a (linux) system that just *happens* to work
Dec 31 00:51:37 <DocScrutinizer> I could have a few monkeys code some shit and then test if it seems to do what I want
Dec 31 00:51:39 <SpeedEvil> Ideally you'd want clarification of how the internal clocking of the UART works. I would be surprised if samsung would answer a query on this.
Dec 31 00:52:07 <DocScrutinizer> you need to stop UARTs, then set up all clocks new, then continue UARTs
Dec 31 00:52:17 <SpeedEvil> Why?
Dec 31 00:52:26 <gena2x> why should i resetup UART clocks if clock source is same?
Dec 31 00:53:00 <gena2x> probably only stop them
Dec 31 00:53:02 <SpeedEvil> There are plausible - perhaps even likely architectures for the UARTs that would mean that the above scheme is sane.
Dec 31 00:53:13 <SpeedEvil> If you can keep the skew to under 1/8th bit or so.
Dec 31 00:53:18 <gena2x> this is absolutely not a problem
Dec 31 00:53:31 <gena2x> as cpufreq has special notifications
Dec 31 00:53:46 <gena2x> and if modem has cts/rts no problem at all to pause it
Dec 31 00:53:58 <DocScrutinizer> SpeedEvil: 1/8bit is maximum tolerance on arbitrary UARTs for clock jitter over a whole byte
Dec 31 00:54:22 <gena2x> and GPS is at 9600, and data is repeated, so all this problem is sucket out of finger
Dec 31 00:54:28 <SpeedEvil> DocScrutinizer: Indeed. 1/8th is pretty much the absolute max you'd want.
Dec 31 00:54:44 <SpeedEvil> GPS isn't the problem - problem is the modem.
Dec 31 00:54:47 <gena2x> afair 10%
Dec 31 00:54:58 <gena2x> SpeedEvil: does it have cts/rts?
Dec 31 00:55:20 <gena2x> yeah
Dec 31 00:55:27 <gena2x> according to schematic
Dec 31 00:55:32 <DocScrutinizer> gena2x: now you say "oh well, there might be errors but we don't care"??? DUDE!
Dec 31 00:55:35 <gena2x> so no problem to pause it.
Dec 31 00:55:55 <gena2x> DocScrutinizer: where did i told that?
Dec 31 00:56:03 <SpeedEvil> gena2x: I vaguely recall that tehre were issues with the modem speedily responding to rts/cts
Dec 31 00:56:11 <DocScrutinizer> [2010-12-31 01:51:25] <gena2x> and GPS is at 9600, and data is repeated, so all this problem is sucket out of finger
Dec 31 00:56:29 <gena2x> DocScrutinizer: in GPS single byte error is really not a problem
Dec 31 00:56:38 <gena2x> as data is crced and repeated.
Dec 31 00:56:43 <DocScrutinizer> gena2x: TTY is not made for gps
Dec 31 00:56:58 <DocScrutinizer> FREAKINgF'ng SHIT
Dec 31 00:57:09 <DocScrutinizer> TTY has to WORK!
Dec 31 00:57:52 <gena2x> ok, guys, are you really thinking this will not work reliably?
Dec 31 00:57:53 <DocScrutinizer> ***UNCONDITIONALLY***
Dec 31 00:58:04 <gena2x> i mean cpufreq?
Dec 31 00:58:07 <SpeedEvil> gena2x: However - will the parser cope well with single byte errors
Dec 31 00:58:21 <gena2x> s/?/./
Dec 31 00:58:22 <apt> gena2x meant: i mean cpufreq.
Dec 31 00:58:22 <SpeedEvil> gena2x: that is uart.
Dec 31 00:58:52 <gena2x> i have working cpufreq right now
Dec 31 00:59:01 <gena2x> so i can do simple tests of any kind.
Dec 31 00:59:21 <DocScrutinizer> no kernel dev will be interested in this kind of tests
Dec 31 00:59:29 <SpeedEvil> gena2x: I think it is plausible it could work without errors. Even if there are errors, in general, if the user is informed about these, it's not an issue. As some may find cpufreq more useful.
Dec 31 00:59:41 <DocScrutinizer> the code is flawed, the concept is buggy
Dec 31 00:59:46 <lindi-> DocScrutinizer: gena2x is a kernel dev now :)
Dec 31 00:59:52 <DocScrutinizer> LOL
Dec 31 01:00:01 <SpeedEvil> Barring deep documentation of the UART, I'm not seeing any other nice way.
Dec 31 01:00:20 <gena2x> DocScrutinizer: what's so funny?
Dec 31 01:00:57 <gena2x> DocScrutinizer: you may try to ask people to exclude my patches from kernel from all distros.
Dec 31 01:02:12 <DocScrutinizer> gena2x: fuck you
Dec 31 01:02:24 <gena2x> DocScrutinizer: excellent answer.
Dec 31 01:02:29 <lindi-> calm down :)
Dec 31 01:02:32 <gena2x> DocScrutinizer: fuck you self.
Dec 31 01:02:34 * SpeedEvil wonders if alcohol may be involved.
Dec 31 01:03:08 <gena2x> no, i just have old problem with DocScrutinizer, and i really can't understand what is cause of this.
Dec 31 01:03:29 <gena2x> EVRYTHING i am trying to do got LOTS of negative from him.
Dec 31 01:03:38 <gena2x> and i don't know why :(
Dec 31 01:03:46 <SpeedEvil> While I don't in principle disagree with what Doc's saying, I think that with enough testing, and perhaps a note that concerns have been raised about possible lost bytes when switching, so users can be aware of it, I don't see a major issue.
Dec 31 01:04:23 <SpeedEvil> gena2x: the approach you are taking is not adequately documented in the documentation, and would ideally be avoided, in a good product. 
Dec 31 01:04:29 <SpeedEvil> However. 
Dec 31 01:04:57 <DocScrutinizer> absolutely not. He's telling me "I don't care about proper system architecture. I like to have my botched design with evidently race conditions occuring any time. I don't care about and I'll push it upstream. And you can't do anything." He told ME to fuck off. My answer was accordingly
Dec 31 01:05:13 <SpeedEvil> Umm.
Dec 31 01:05:19 <gena2x> i am taking care
Dec 31 01:05:24 <gena2x> this is not true
Dec 31 01:05:24 <SpeedEvil> It's plausible that it's not a race condition.
Dec 31 01:06:00 <SpeedEvil> If you can guarantee that the skew is under a critical amount, which is possible, then tehre may be no errors.
Dec 31 01:06:08 * SpeedEvil sighs.
Dec 31 01:06:13 <lindi-> gena2x: do you know how it is done on other systems?
Dec 31 01:06:40 <gena2x> lindi-: unfortunately not. i never implemented cpufreq before
Dec 31 01:07:00 <SpeedEvil> In general, it's not related to serial at all.
Dec 31 01:07:05 <lindi-> gena2x: on x86 it is probably not a problem since serial is not affected
Dec 31 01:07:14 <SpeedEvil> It's only in the case of SoCs that it will be an issue.
Dec 31 01:07:22 <gena2x> lindi-: but i can see that where is many s3c24xx cpufreq implementations
Dec 31 01:07:32 <SpeedEvil> As only there will the clocking be related.
Dec 31 01:07:51 <lindi-> gena2x: "The cpufreq notifier on drivers/serial/s3c2410.c is responsible for (if possible) pausing both sides of the serial transmission before the frequency change and reloading the baud generator (and unpausing the serial transmission) after the change. "
Dec 31 01:08:19 <lindi-> -- http://wiki.openmoko.org/wiki/User:CesarB/cpufreq#Serial_driver
Dec 31 01:08:43 <gena2x> lindi-: where is no such code in mainline i as far as i know
Dec 31 01:08:48 <SpeedEvil> That's the way to do it - ideally.
Dec 31 01:08:59 <lindi-> gena2x: maybe it's only in cesarb's branch?
Dec 31 01:08:59 <SpeedEvil> However - it's also possible to do it 'live'
Dec 31 01:09:03 <gena2x> lindi-: also, this is only significant than you change PCKL
Dec 31 01:09:04 <SpeedEvil> And it may be safe.
Dec 31 01:09:07 <gena2x> *PCLK
Dec 31 01:09:18 <gena2x> guys, really i see no problem.
Dec 31 01:09:19 <SpeedEvil> It is certainly not safe if the PLL needs to re-clock
Dec 31 01:09:36 <gena2x> i'll just implement all and we can test
Dec 31 01:09:39 <SpeedEvil> At any other than the lowest baudrates anyway
Dec 31 01:09:42 <SpeedEvil> Sounds sane.
Dec 31 01:09:56 <gena2x> if no user will have any problem with serials -> what to investigate?
Dec 31 01:10:06 <SpeedEvil> I'd totally agree with DocScrutinizer51 if resources are unlimited - but...
Dec 31 01:10:20 <gena2x> i told about thoeretical grounds
Dec 31 01:10:25 <SpeedEvil> I would say test for a day at various serial rates with data coming in flat-out.
Dec 31 01:10:30 <gena2x> i think dividers switching FAST.
Dec 31 01:11:11 <gena2x> so i see no reason to invent problems on flat ground
Dec 31 01:11:27 <gena2x> if we'll see problems with serial, we'll fix em
Dec 31 01:11:33 <gena2x> that's all
Dec 31 01:11:55 <gena2x> i disagree that switch should take long time
Dec 31 01:12:02 <SpeedEvil> You can't disagree.
Dec 31 01:12:07 <gena2x> why?
Dec 31 01:12:12 <SpeedEvil> The hardware doesn't care if you agree or not.
Dec 31 01:12:18 <gena2x> hey. see
Dec 31 01:12:21 <SpeedEvil> It either is a problem, or it's not.
Dec 31 01:12:23 <gena2x> we have document
Dec 31 01:12:33 <gena2x> nothing is written in document
Dec 31 01:12:54 <gena2x> i think this means switch is instant. DocScrutinizer thinks it takes long time
Dec 31 01:13:12 <gena2x> it's impossible to tell who is right
Dec 31 01:13:36 <SpeedEvil> yes - the hardware doesn't care about opinions.
Dec 31 01:13:36 <gena2x> without investigation or requset to samsung
Dec 31 01:14:34 <gena2x> so i see no grounding to tell that i or DocScrutinizer is wrong
Dec 31 01:14:56 <gena2x> and really don't understand grade of discussion from Doc's side
Dec 31 01:15:38 <SpeedEvil> In principle, your approach is wrong. You cannot validate that your suppositions are correct. The behaviour of the chip is free to change without notification if it conforms to datasheet. Doing this is bad design.
Dec 31 01:15:46 <SpeedEvil> However.
Dec 31 01:16:05 <SpeedEvil> The hardware is all out there - with one revision of the chip - and more are not coming out.
Dec 31 01:16:37 <gena2x> you not right, sorry :) in datasheet it is written: "IT IS SUBJECT TO CHANGE WITHOUT NOTICE"
Dec 31 01:16:55 <gena2x> on first page with uppercase letters
Dec 31 01:17:04 <SpeedEvil> Sure - but they issue a new revision of the datasheet if that happens
Dec 31 01:17:20 <SpeedEvil> If they change it such that it still complies with the datasheet they don't.
Dec 31 01:17:26 <SpeedEvil> I know someone that got bitten by this.
Dec 31 01:17:52 <SpeedEvil> A CPU specified the clock accuracy as +-1%. This was fine, and the new and old parts both met this.
Dec 31 01:18:29 <SpeedEvil> However - the old parts happened to have the error of +-1% average frequency, and would be short-term stable within .005% or so.
Dec 31 01:18:39 <lindi-> gena2x: does  s3c24xx_serial_stop_tx get called when you change frequency?
Dec 31 01:18:44 <SpeedEvil> The new parts would actually vary cycle-by-cycle by .05%
Dec 31 01:19:22 <SpeedEvil> This meant that the product failed in the field (the jitter caused servos controlled by the micro to use unacceptably high power when idle)
Dec 31 01:20:58 <gena2x> lindi-: let me consider how to implement it. i think as long as we not changing PCLK, no need to stop and reconfigure serials.
Dec 31 01:21:50 <gena2x> lindi-: the default behaviour of cpufreq is actually to _change_ PCLK, so it NEEDS reconfiguration
Dec 31 01:22:29 <gena2x> lindi-: i am on _purpose_ writing such implementation to _NOT_ touch PCLK and _NOT_ stop serials.
Dec 31 01:22:58 <gena2x> lindi-: if this will not work, will implement everything need to start/stop.
Dec 31 01:23:32 <SpeedEvil> I can't really comment more than the above - as I'd have to re-read the datasheet - and - well - I have little motivation to, as I don't even have a FR. (though the neo is probably similar)
Dec 31 01:23:41 <SpeedEvil> Good luck though!
Dec 31 01:23:45 <gena2x> SpeedEvil: gn
Dec 31 01:24:01 <gena2x> SpeedEvil: and thank you
Dec 31 01:24:05 * SpeedEvil wishes for gta05
Dec 31 01:24:53 <gena2x> heh, have to add DocScrutinizer to ignore list, can stand suck lack of respect any more... no chance to find common language.
Dec 31 01:30:38 <gena2x> the main advocate against removing debug info were DocScrutinizer, against jitterless touchscreen too, he even told i stolen his battery charging script for n900 from him, now he tells something about cpufreq and tell me 'fuck you', i think this is much more than any person should tolerate.
Dec 31 01:32:04 <gena2x> but it is him, not me who NOT implementes jitterless TS, and were CAUSE of using DEBUGGING kernels for YEARS.
Dec 31 01:32:16 <gena2x> so FR FAILs.
Dec 31 01:33:04 * gena2x have to sleep
Dec 31 01:33:18 <gena2x> gn all, sorry, just tired a bit of this...
Dec 31 01:33:29 <lindi-> good night, i'm still watching the ccc talk about desktop environment wars :P
Dec 31 01:33:51 <gena2x> lindi-: oh, thanks, nice idea, i've downloaded it too :)
Dec 31 01:35:26 <lindi-> my download list is http://paste.debian.net/103508/
Dec 31 01:41:55 <Broam> evening folks
Dec 31 01:46:54 <lindi-> "console-kit does not kill people. people kill people." this is more hilarious than I thought :P
**** ENDING LOGGING AT Fri Dec 31 02:59:58 2010