**** BEGIN LOGGING AT Fri Nov 22 03:00:00 2013
Nov 22 21:49:27 <ant_home> lumag: hi there
Nov 22 21:51:31 <lumag_> hi ant_home
Nov 22 21:52:03 <ant_home> so can we remove the two mtd hacks/patch and add a new one?
Nov 22 21:57:18 <lumag_> Didn't have time to progress on that.
Nov 22 21:57:29 <lumag_> I think we should really check timings/settings of MCS0.
Nov 22 21:57:53 <lumag_> I think that the problem is not in the state machine, but rather in our Sharp flash devices not understanding the command.
Nov 22 21:57:53 <ant_home> like in kernel 2.4 ?
Nov 22 21:58:33 <ant_home> one difference I've seen btw strataflash and sharp flash are the buffer write cycles
Nov 22 21:58:38 <ant_home> sharp >4
Nov 22 21:58:42 <ant_home> strataflash >2
Nov 22 21:59:12 <ant_home> if you send commands during buffer write the chip switch state and status register is set
Nov 22 21:59:41 <ant_home> that's valid for both and the code checks for this
Nov 22 22:00:01 <lumag_> Hmm.
Nov 22 22:00:49 <lumag_> That won't tell us why QRY is handled badly, because there no buffer writes at that time.
Nov 22 22:00:51 <ant_home> i.e I could log  SR.4 or SR.5 bits set in buffer write (status ffffffff). Clearing.
Nov 22 22:01:05 <lumag_> And my issue also happens in FL_READING state
Nov 22 22:01:28 <ant_home> ah, ok, I'm telling after inizialization
Nov 22 22:02:23 <ant_home> afais the timings are read from the cfi query so should be correct
Nov 22 22:02:54 <ant_home> they match with technical sheet
Nov 22 22:03:36 <ant_home> no idea about MCS0 and such registers ;)
Nov 22 22:05:44 <ant_home> ah, wrt poodle, pls show me how would you pull the gpio of the battery switch in the poweroff path
Nov 22 22:06:07 <ant_home> I'd like to fix the kexecboot kernel
Nov 22 22:09:18 <ant_home> seems a low hanging fruit...
Nov 22 22:38:34 <ant_home> Jay7: FYI
Nov 22 22:38:36 <ant_home> [PATCH 0/6] kexec: A new system call to allow in kernel loading
Nov 22 22:38:48 <ant_home> [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
Nov 22 22:55:46 <lumag_> ?
Nov 22 22:55:55 <lumag_> Don't we already have kexec?
Nov 22 23:04:03 <lumag_> You probably mean this piece of code from 2.4 kernel:
Nov 22 23:04:05 <lumag_> #if defined(CONFIG_ARCH_PXA_POODLE) || defined(CONFIG_ARCH_PXA_CORGI)
Nov 22 23:04:05 <lumag_>         // charging , so CHARGE_ON bit is HIGH during OFF.
Nov 22 23:04:05 <lumag_>         if ( GPLR(GPIO38_FFRI) & GPIO_bit(GPIO38_FFRI) ) {
Nov 22 23:04:05 <lumag_>           PGSR1 |= GPIO_bit(GPIO38_FFRI);
Nov 22 23:04:05 <lumag_>         } else {
Nov 22 23:04:08 <lumag_>           PGSR1 &= ~GPIO_bit(GPIO38_FFRI);
Nov 22 23:04:10 <lumag_>         }
Nov 22 23:04:20 <lumag_> I think this just forces the charging in sleep mode.
Nov 22 23:06:55 <ant_home> I see that kexecboot does RB_POWER_OFF
Nov 22 23:07:07 <ant_home> and a restart follows
Nov 22 23:07:39 <ant_home> both on poodle and collie
Nov 22 23:07:58 <ant_home> but on ppodle the magic switch allows the 'poweroff'
Nov 22 23:08:27 <ant_home> rest of pxa does apparently 'shut down'
Nov 22 23:08:40 <ant_home> (c7x0 and spitz)
Nov 23 00:25:54 <ant_home> lumag_: checkout last two commits
Nov 23 00:25:56 <ant_home> https://github.com/andrea-adami/meta-handheld/commits/master
Nov 23 00:50:54 <ant_home> gn
**** ENDING LOGGING AT Sat Nov 23 02:59:59 2013