**** BEGIN LOGGING AT Mon Jan 27 03:00:00 2014
Jan 27 08:44:19 <ant_work> lumag: hi, what does that mean? http://tinyurl.com/ndcm7kb
Jan 27 08:45:50 <ant_work> this modifies the original (mostly unchanged) 2004 code   http://lists.infradead.org/pipermail/linux-mtd-cvs/2004-June/003734.html
Jan 27 08:46:59 <lumag> It is not possible to schedule (=wait, sleep, delay, etc.) while holding spinlock.
Jan 27 08:47:16 <lumag> mutex is like a spinlock, but you are allowed to sleeep.
Jan 27 08:47:42 <lumag> In fact mutex_lock will sleep, if mutex is already taken by somebody.
Jan 27 08:47:57 <lumag> So you can not use mutexes in irq context, because you can't sleep in IRQ handlers.
Jan 27 08:50:12 <ant_work> hm.. there are changes to cmdset_0001 with that patch
Jan 27 08:50:18 <ant_work> ofc
Jan 27 08:50:33 <ant_work> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/mtd/chips/cfi_cmdset_0001.c?id=8ae664184c45def51ff0b61d4bd6c6671db6cb4f
Jan 27 08:52:19 <ant_work> so " I have checked the code of the drivers and there is no use of atomic pathes like interrupt or timers"
Jan 27 08:52:26 <lumag> No semantic changes.
Jan 27 08:52:27 <ant_work> can we trust that?
Jan 27 08:54:29 <lumag> Hmm. I'd trust Artem's sign-off. I won't trust Stefani out of box. She did strange things back when we touched at NSN.
Jan 27 09:08:51 <ant_work> I may try reverting her last change to flashchip.h touching the multi-partition code
Jan 27 09:17:48 <ant_work> about that, I'm again confused...why did Sharp decide to put the WM status on the high byte? 0x8080 and 0x80  both pass the map_wordandequal test
Jan 27 09:18:52 <ant_work> nico patches did provide an exit/break checking if the first bit of the low byte was set -> status (0x01)
Jan 27 09:20:10 <ant_work> so in our case we should break the loop if we read 0x00 in the high byte, even if the low byte is 0x80
Jan 27 09:43:36 <ant_work> lumag: BTW, I found all Rev. 2.44 for the LH28F* models apart our -PTTL90
Jan 27 09:44:26 <ant_work> i.e. for the PTTL80 the Rev. 2.41 doesn't mention that SR.15 register (as in Rev. 2.41 for our)
Jan 27 09:44:48 <ant_work> I'd say the model in collie does behave the same way
Jan 27 09:45:16 <ant_work> for I've readings like 808080 and 800080 and even 0
Jan 27 09:46:23 * lumag is going to try 3.13 on tosa
Jan 27 10:03:15 * ant_work is writing to  sharpsde@sharp.eu
Jan 27 10:11:13 <lumag> Good luck with that
Jan 27 10:13:06 <ant_work> heh, I've asked about Table A-3-1. Status Register Definition (SR.15 and SR.7)
Jan 27 10:14:07 <lumag> /home/lumag/linux/sound/soc/pxa/tosa.c:141:17: error: 'PXA_NR_BUILTIN_GPIO' undeclared (first use in this function)
Jan 27 10:14:36 <ant_work> hm.. I had undeclared GPIO_MAX iirc
Jan 27 10:14:44 <ant_work> on collie
Jan 27 10:16:55 * lumag wants to do something bad to Haojian
Jan 27 10:17:55 <lumag> He broke tons of things despite being fine PXA maintainer.
Jan 27 10:18:34 <lumag> To have PXA_NR_BUILTIN_GPIO one has to inclue mach/irqs.h
Jan 27 10:19:54 <ant_work> lumag: one last naive question...
Jan 27 10:20:05 <lumag> go on
Jan 27 10:20:09 <ant_work> (last about mtd partitions ;)
Jan 27 10:20:12 <ant_work> http://elcodis.com/parts/5781267/LH28F320BFE-PBTL60_p37.html
Jan 27 10:20:33 <ant_work> what is AC timing? isn't AC current?
Jan 27 10:22:10 <ant_work> if AC timing... processor can check .. instead
Jan 27 10:22:29 <ant_work> not totally clear to me
Jan 27 10:22:43 <lumag> The only place where that datasheet also talks about AC timing, is page i (A-1.1).
Jan 27 10:22:54 <lumag> Where it is logical - reset/power on timing sequence.
Jan 27 10:24:34 <ant_work> so this SR15 has 'less latency' and can be read earlier?
Jan 27 10:24:57 <lumag> It looks so from the description, but not from the figure A-3-1
Jan 27 10:25:16 <lumag> Where SR.15 changes simultaneously to SR.7
Jan 27 10:25:19 <ant_work> yes, the trapezoids are the same
Jan 27 10:25:37 <ant_work> well, the transients
Jan 27 10:25:52 <ant_work> (I think this is the correct name)
Jan 27 10:28:49 <ant_work> which instrumentation would on eneed to measure that things?
Jan 27 10:28:56 <ant_work> professional?
Jan 27 10:30:05 <lumag> Unfortunately there is no such instrument other than a model of the NOR embedded controller.
Jan 27 10:30:25 <lumag> SR signals are not available outside.
Jan 27 10:35:26 <lumag> oh, my. Now backlight makefile hack doesn't work anymore for tosa.
Jan 27 10:37:22 <lumag> With 3.13 it hangs during the boot around backlight/framebuffer probing.
Jan 27 10:43:00 <lumag> Hmm. Strange. Now it works.
Jan 27 10:59:04 <ant_work> ah, I've discovered collie NOR are of Industrial grade (TA=-40°C to +85°C)
Jan 27 11:30:08 <lumag> suspend/resume test fails :(
Jan 27 11:30:47 <lumag> Maybe it's due to ohci being enabled.
Jan 27 11:38:15 <ant_work> does tosa-battery work properly?
Jan 27 11:38:57 <lumag> It looks so.
Jan 27 11:42:06 <ant_work> what if you poweroff? Stays off or reboots?
Jan 27 11:48:36 <lumag> Didn't try.
Jan 27 11:48:38 <lumag> yet
Jan 27 11:53:52 <lumag> Strange. Got a lockup somewhere in scsi code on suspend
Jan 27 11:54:53 <lumag> Thanks to CF memory card, most probably
Jan 27 12:01:30 <lumag> poweroff works
Jan 27 12:05:13 <lumag> Hmm. Now pcmcia/scsi works during suspend.
Jan 27 12:06:35 <ant_work> nice
Jan 27 12:22:43 <ant_work> lumag: btw, is on esupposed to change the internal 'button' battery of collie and tosa?
Jan 27 12:23:11 <lumag> Only if it fails badly.
Jan 27 12:23:15 <ant_work> seems rather hard...  http://www.zaurus.org.uk/6000-dismantled.html
Jan 27 12:23:25 <lumag> Just like battery on the motherboard.
Jan 27 12:23:29 <lumag> Or rather in laptop.
Jan 27 12:23:39 <lumag> Heh.
Jan 27 12:23:53 <lumag> Heh. scsi suspend lockup again.
Jan 27 12:24:12 <lumag> Thankfully this happens with ohci enabled, so it won't happend on production platforms.
Jan 27 12:24:19 <lumag> s/platforms/setups/
Jan 27 12:34:04 <ant_work> ehm.. in linux-yocto ohci is enabled...
Jan 27 12:34:31 <ant_work> for tosa/spitz/akita
Jan 27 12:36:08 <lumag> ant_work, On tosa ohci should be unbound during suspend (that is/was handled by some custom apmd script, I think).
Jan 27 12:36:13 <lumag> Otherwise tosa will crash
Jan 27 12:36:35 <ant_work> yes, there was something tosa-specific, right
Jan 27 12:37:50 <ant_work> about that inbternal battery, I can't see it on collie pics...
Jan 27 12:38:30 <ant_work> must be different-shaped
Jan 27 12:44:33 <lumag> Can't see it on photo.
Jan 27 12:44:39 <lumag> It might be under the plastic shield
Jan 27 12:47:10 <ant_work> collie will move to gpio_charger isn't?
Jan 27 12:47:46 <lumag> Yes.
Jan 27 12:48:07 <lumag> I don't remember if it in 3.13 or scheduled for 3.14 (or 3.15?)
Jan 27 12:49:04 <ant_work> I lost a bit the count of your pending patches...
Jan 27 12:49:11 <ant_work> I fear all is postponed for 3.14
Jan 27 12:50:06 <ant_work> I think only irda is in 3.13
Jan 27 12:50:16 <lumag> For 3.15. It looks like it did not hit the road for 3.14
Jan 27 12:50:20 <lumag> Irda is for 3.14
Jan 27 12:51:10 <lumag> Hmm. No. Russell did not merge irda into -next, so it will not hit 3.14
Jan 27 12:51:12 <lumag> Damn him.
Jan 27 12:51:44 <ant_work> I was waiting for the other bunch of sa-1100 patches...
Jan 27 12:52:19 <lumag> Damn Russell. He also postponed h3xxx uart patches, so I can't submit gpio-sa1100 updates.
Jan 27 12:53:10 <lumag> BTW: If I send you few patches for tosa for 3.13, would you mind putting them to meta-hh?
Jan 27 12:53:26 * lumag doesn't have time for all the tasks.
Jan 27 12:53:38 <lumag> Once meta-hh will switch to 3.13
Jan 27 12:57:32 <ant_work> should not take long, atm linux-yocto-dev is on 3.13
Jan 27 12:58:42 <ant_work> there is a little yaffs2 issue breaking build and then for collie the GPIO_MAX
Jan 27 13:02:16 <ant_work> so yes, pls send me that and I'll put in -dev
Jan 27 13:03:31 <lumag> Sent
Jan 27 13:07:09 <ant_work> thx
Jan 27 13:07:24 <ant_work> were you booting from kexecbnoot?
Jan 27 13:07:30 <ant_work>  -n ?
Jan 27 15:45:55 <ant_work> lumag: http://cgit.openembedded.org/meta-handheld/commit/conf?id=01f3e2c1be8f7e8a3b5c417a4e1a48c79dbf69dd
Jan 27 15:46:08 <ant_work>  -# MACHINE_EXTRA_RRECOMMENDS_tosa = "apm-tosa-suspendfix"
Jan 27 15:47:18 <ant_work> vs. http://lists.openembedded.org/pipermail/openembedded-commits/2008-December/096040.html
Jan 27 15:47:22 <ant_work> my bad ;)
Jan 27 15:49:42 <ant_work> bluelightning: we have still to revert/replace missing bits of  http://cgit.openembedded.org/meta-handheld/commit/conf/machine/include/zaurus.inc?id=08855d4a059a1fa19f77a83978ea8cfb0067069d
Jan 27 15:50:07 <ant_work> is there now consensus about module list/autoloading? kmod? udev?
Jan 27 15:52:47 <bluelightning> ant_work: not sure, but last I recall there being a question, module_autoload is still supposed to work
Jan 27 15:55:02 <ant_work> and what about ripping/merging zaurus.inc in the respective machines.conf?
Jan 27 15:58:03 <bluelightning> ant_work: you don't want to share anything anymore?
Jan 27 16:01:03 <ant_work> most defs will not change anymore
Jan 27 16:02:02 <ant_work> we could properly reorder the fields in each .conf
Jan 27 16:02:28 <ant_work> finally, some settings are Distro choices, like the fstypes
Jan 27 16:04:45 <ant_work> about the unneeded device tables, maybe the defaults in oe-core ought to be changed
Jan 27 16:05:18 <ant_work> devtmpfs is around since 2.6.30
Jan 27 16:33:36 <ant_work> bluelightning: ah, btw...
Jan 27 16:33:47 <ant_work> packagegroup-core-x11-xserver.bb sets
Jan 27 16:33:54 <ant_work> XSERVER ?= "xserver-xorg xf86-video-fbdev xf86-input-evdev"
Jan 27 16:34:04 <ant_work> I think we can keep this one...
Jan 27 16:34:20 <ant_work> afaik we don't use anymore   xf86-input-keyboard xf86-input-mouse
Jan 27 22:32:29 <ant_home> hey lumag_
Jan 27 22:33:48 <ant_home> see, two simple udelay(100) around status check and we have 2 partitions back ;)
Jan 27 22:37:43 <ant_home> argh..let's try with 200...
Jan 27 23:03:12 <lumag_> ant_home, lol
Jan 27 23:04:16 <ant_home> heh.. the test now is ubiformat'ing the rootfs.ubi, reboot from CF, mount it, copy a kernel in /boot, umount it, reboot
Jan 27 23:04:55 <lumag_> We should probably buy you several more nor chips.
Jan 27 23:05:14 <lumag_> So that one can resolder them later.
Jan 27 23:06:46 <ant_home> heh, atr the time NOR were resistent! This is industrial grade even (unsold batch ?)
Jan 27 23:18:45 <ant_home> btw, got answer from nico (Pitre)...he forgot :p
Jan 28 00:00:03 <ant_home> http://xkcd.com/394/
Jan 28 00:00:08 <ant_home> Sharp...
Jan 28 00:00:19 <ant_home> gn
**** ENDING LOGGING AT Tue Jan 28 02:59:59 2014