| 01:34.13 | *** join/#openezx johanbr (n=j@blk-7-129-106.eastlink.ca) |
| 02:01.10 | *** join/#openezx gDD (n=gDD@unaffiliated/gdd) |
| 02:01.22 | *** join/#openezx gDD (n=gDD@unaffiliated/gdd) |
| 03:08.23 | *** join/#openezx arne__ (i=nobody@dslc-082-082-074-016.pools.arcor-ip.net) |
| 05:17.35 | *** join/#openezx _Andrew_ (n=andrew@82.152.176.9) |
| 07:19.51 | *** join/#openezx darion76 (n=darion76@94-248-70-211.dynamic.peoplenet.ua) |
| 07:29.41 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 07:48.01 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 08:25.22 | *** join/#openezx florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de) |
| 08:56.48 | *** join/#openezx Sleep-Walker (n=Sleep@193.179.96.131) |
| 09:13.24 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 10:11.08 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 10:22.32 | *** join/#openezx marex (n=marex@thor.hackndev.com) |
| 11:15.03 | *** join/#openezx darion761 (n=darion76@94-248-70-211.dynamic.peoplenet.ua) |
| 11:40.40 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 11:55.50 | *** join/#openezx darion76 (n=darion76@94-248-70-211.dynamic.peoplenet.ua) |
| 11:59.50 | *** join/#openezx gmzhuo (n=gmzhuo@118.114.146.25) |
| 12:02.43 | *** join/#openezx CIA-19 (n=CIA@208.69.182.149) |
| 12:37.40 | *** join/#openezx gmzhuo_ (n=gmzhuo@221.237.65.87) |
| 12:38.07 | *** join/#openezx gmzhuo__ (n=gmzhuo@118.114.146.25) |
| 12:45.06 | *** join/#openezx Sleep_Walker (n=Sleep@nat/novell/x-2473dd35d24b9b5b) |
| 13:14.47 | *** join/#openezx stefan_schmidt (n=stefan@w1190.wlan.rz.tu-bs.de) |
| 13:22.17 | *** join/#openezx johanbr (n=j@blk-7-129-106.eastlink.ca) |
| 13:23.33 | *** join/#openezx pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 13:51.56 | *** join/#openezx Sleep_Walker (n=Sleep@nat/novell/x-d2ef745bd3035903) |
| 15:23.58 | *** join/#openezx Z0RE_ (n=gDD@unaffiliated/gdd) |
| 15:56.10 | *** join/#openezx tombhadAC (n=tombhad@pD95DE0C7.dip.t-dialin.net) |
| 16:27.23 | *** join/#openezx johanbr (n=j@JBrannlund2.MathStat.Dal.Ca) |
| 16:31.17 | *** join/#openezx tmzt_ (n=tmzt@adsl-76-244-147-106.dsl.akrnoh.sbcglobal.net) |
| 16:45.58 | *** join/#openezx sabrod (n=sab@mic92-8-82-234-143-184.fbx.proxad.net) |
| 17:15.57 | *** join/#openezx shoragan (n=shoragan@debian/developer/shoragan) |
| 17:39.16 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) [NETSPLIT VICTIM] |
| 17:39.16 | *** join/#openezx ghane (n=ghane@unaffiliated/ghane) [NETSPLIT VICTIM] |
| 17:39.17 | CIA-19 | OpenEZX: 03ao2 * r2480 10/trunk/src/blob/gen-blob/src/blob/ (boot_modes.c pcap.c): |
| 17:39.17 | CIA-19 | OpenEZX: Prevent writing arbitrary value to AUX_VREG |
| 17:39.17 | CIA-19 | OpenEZX: This happens when turning off mmc without having ever turned it on. |
| 17:39.17 | CIA-19 | OpenEZX: On my phone, this made the vibrator to turn on unconditionally, funny! |
| 18:03.35 | *** join/#openezx yang (i=yang@freenode/sponsor/cacert.assurer.yang) [NETSPLIT VICTIM] |
| 18:09.18 | *** join/#openezx shoragan (n=shoragan@debian/developer/shoragan) [NETSPLIT VICTIM] |
| 18:22.19 | *** join/#openezx ghane (n=ghane@1-1-4-27a.mdp.mlm.bostream.se) [NETSPLIT VICTIM] |
| 18:38.14 | *** join/#openezx ao2 (n=u@2001:1418:117:0:0:0:0:1) |
| 18:49.43 | *** join/#openezx florian (n=fuchs@f048201097.adsl.alicedsl.de) |
| 18:51.26 | *** join/#openezx marex (n=marex@thor.hackndev.com) |
| 19:07.26 | *** part/#openezx darion76 (n=darion76@94-248-70-211.dynamic.peoplenet.ua) |
| 19:18.36 | *** join/#openezx arne__ (i=nobody@dslc-082-082-074-016.pools.arcor-ip.net) |
| 19:26.14 | WyrM | ao2: hi :) |
| 19:26.28 | ao2 | hi WyrM |
| 19:26.35 | WyrM | ao2: uninintialized values makes funny magic some times ;) |
| 19:26.47 | WyrM | ao2: but 0 is a valid value... |
| 19:26.52 | ao2 | eh :), how are you doing? |
| 19:27.14 | WyrM | ao2: im fine, thanks for asking. :) |
| 19:27.34 | ao2 | my first version of the patch just wrote the 0, but then I thought that the first blob could be doing something |
| 19:28.04 | WyrM | ao2: I think you can (ab)use the higher bits.. |
| 19:28.12 | WyrM | pcap registers are 25 bits. |
| 19:28.51 | WyrM | maybe you can use higher bits to signal store if that the value was never read. |
| 19:29.14 | ao2 | I will think about that, thanks |
| 19:30.44 | WyrM | anyway, this "backup" thing is non-sense.. |
| 19:31.20 | WyrM | maybe we should not save a backup of the register value, just turn on/off the mmc voltage regulator is probably cleaner. |
| 19:31.29 | WyrM | I don't remember why we need this "backup" at all. |
| 19:31.30 | WyrM | LOL |
| 19:31.53 | tmzt | some chips are write-only, I didn't think pcap was though |
| 19:31.54 | ao2 | on LAK they are discussing the dev_pm_ops issue, when they settle on a preferred solution I'll change that on our side as well :) |
| 19:32.09 | WyrM | ao2: good, thanks! |
| 19:32.15 | WyrM | tmzt: some registers are read only. |
| 19:32.30 | WyrM | tmzt: not the case with the AUX_VREG register. |
| 19:32.31 | tmzt | sure, but that's not the same issue |
| 19:32.41 | tmzt | write only chips need the shadow register |
| 19:33.08 | WyrM | hum.. write-only.. |
| 19:33.25 | tmzt | like htc cpld or asic3 |
| 19:33.39 | WyrM | Not on pcap, I don't remember a single bit that is write only.. |
| 19:33.45 | WyrM | Only some read-only. |
| 19:34.09 | tmzt | ok, so whatwas the shadow used for |
| 19:34.28 | WyrM | shadow you mean mask? |
| 19:34.54 | WyrM | IIRC its to flag only the SD/TF related bits. |
| 19:35.08 | tmzt | no, not mask |
| 19:35.16 | tmzt | shadow as in a copy of the register |
| 19:35.19 | tmzt | the "backup" |
| 19:36.02 | WyrM | tmzt: yes, it looks non-sense to me. |
| 19:36.18 | WyrM | I don't remember why/if I wrote it this way |
| 19:36.29 | WyrM | or it may be from Moto... |
| 19:41.31 | ao2 | It is in a section marked ALEX, maybe Alex Zhang wrote that |
| 19:44.26 | WyrM | Yes, it may be from Alex too. |
| 19:44.51 | WyrM | He wrote the mmc driver, and probably the vreg functions for mmc too. |
| 19:45.32 | ao2 | The backup trick is the very thing which turns OFF mmc, it's not a proper OFF, it's more a "put it like the original bootloader decided" |
| 19:46.02 | WyrM | so, we can't turn it off. |
| 19:46.10 | WyrM | its definitelly wrong then. |
| 19:48.56 | ao2 | right, powering it on twice will loose the default state. I'll try to revisit that part. |
| 19:49.35 | WyrM | ao2: yes, and if it defaults to ON at hardware level, it can't be turned off. |
| 19:49.55 | ao2 | of course |
| 19:52.45 | *** join/#openezx FeLLa (n=46241@mnhm-590d96a0.pool.einsundeins.de) |
| 20:01.48 | tmzt | state of what? |
| 20:06.24 | WyrM | tmzt: boot state. |
| 20:06.37 | WyrM | tmzt: the hardware default. |
| 20:06.45 | WyrM | tmzt: the current implementation is non-sense. |
| 20:07.23 | tmzt | I mean what state will it lose and why does it matter? |
| 20:07.54 | WyrM | the boot state. |
| 20:08.05 | WyrM | and it doesn't matter, that is the point. :) |
| 20:08.25 | ao2 | tmzt, the current code in gen-blob assumes the bootloader (or the hardware configuration) turns MMC off, and uses this assumption in the "backup" trick |
| 20:08.44 | ao2 | to turn it off again, but it even does it in the wrong way |
| 20:08.54 | tmzt | still don't get it, why does it matter if the vreg is 0 |
| 20:09.01 | tmzt | or the clocks are disabled |
| 20:09.14 | tmzt | why do you need some "boot" state to turn it off |
| 20:09.18 | WyrM | tmzt: hum... |
| 20:09.27 | WyrM | we don't need the boot state to turn off. |
| 20:09.44 | WyrM | but it DOES matter if it is on or off before we give control to kernel. |
| 20:10.02 | tmzt | right, okay |
| 20:10.15 | WyrM | some kernel subsystems are "broken by design" (David Brownell) |
| 20:10.34 | tmzt | like? |
| 20:10.52 | WyrM | clock and regulator. |
| 20:10.58 | WyrM | stupid refcounting. |
| 20:11.18 | WyrM | they can't work sanelly if the bootloader leaves a clock or a voltage regulator on. |
| 20:11.26 | tmzt | ah |
| 20:12.07 | WyrM | google for regulator use_count |
| 20:12.21 | WyrM | and you will see what im talking about. |
| 20:16.28 | WyrM | heh |
| 20:16.44 | WyrM | Mark Brown sent a "fix" for the issues. |
| 20:17.35 | WyrM | but the comment is wrong... Its not that they need to disable the regulator... Well, whatever. ;) |
| 20:17.42 | WyrM | http://patchwork.kernel.org/patch/36542/ |
| 21:41.33 | CIA-19 | OpenEZX: 03ao2 * r2481 10/trunk/src/blob/gen-blob/src/blob/pcap.c: |
| 21:41.33 | CIA-19 | OpenEZX: Fix pcap_mmc_power_on() |
| 21:41.33 | CIA-19 | OpenEZX: Now we can reliably turn mmc off. |
| 22:58.48 | *** join/#openezx Sleep_Walker (n=Sleep@193.179.96.131) |