| lel | IMbackK opened a pull request: https://github.com/maemo-leste-extras/simple-brightness-applet/pull/2 (port to new mce interfaces, removes all gconf dependancy) | 00:45 |
|---|---|---|
| uvos | https://github.com/maemo-leste-extras/simple-brightness-applet/pull/2 | 00:45 |
| Wizzup | uvos: thanks will try to pick these up tomorrow | 01:21 |
| LjL | hi people, new here, haven't used my N900 in a long time... is Leste in a state where it would be relatively usable with no major missing things on the N900? if not could i dual-boot it easily with classic Maemo? is the N900 even being targeted as viable anymore? | 04:15 |
| * enyc meows LjL | 04:53 | |
| * LjL meows back | 05:07 | |
| * joerg chases 5 dozen white mice towards enyc and LjL | 05:08 | |
| tmlind | freemangordon: so looks like we're missing the power domain handling for omap3, here's an initial patch for it muru.com/linux/n900/omap3-prm-gfx.patch | 06:05 |
| tmlind | that get's modprobe of the pvr module working with no reverts for me, but there are other pvr kernel module related problems remaining | 06:05 |
| tmlind | it seems that the pvr module does internal powerdown for omap3/sgx530_125 and behaves somehow in a different way compared to omap4 | 06:06 |
| tmlind | or something like that, need to figure that out when i get a chance | 06:07 |
| tmlind | so pvrsrvinit will still fail for omap3 after the power domain patch | 06:07 |
| tmlind | looks like somehow on omap3 PVRSRVSetDevicePowerStateKM fails to properly power up the device, the module is clocked as i can read the regs when enabling the module via sysfs manually | 06:39 |
| tmlind | oh well need to continue tonight | 06:39 |
| freemangordon | tmlind: hmm, ok, maybe it counts on something being powered-up automatically. | 07:29 |
| freemangordon | tmlind: yeah, with this patch pvrsrvctl --init --no-module hangs the device | 08:59 |
| uvos | LjL: "is Leste in a state where it would be relatively usable with no major missing things on the N900?" no absoulty not there are no working phone calls on n900 and lots of other stuff is also still missing | 11:32 |
| uvos | LjL: "is the N900 even being targeted as viable anymore?" yes it is, but our other 3 main supported devices are in a better state atm (particularly power managment is totaly broken on n900, there are sever bugs with the pvr driver and there is no routing for the n900s complex audio setup), but there is promesing work goning on right now on all of those problems so n900 should hopefully catch up soon | 11:35 |
| uvos | also you need to temper your expectations with n900 wrt performance, its not going to run modern desktop applications like browsers anymore due to the limited ram. | 11:36 |
| Wizzup | LjL: dual-booting is easy though | 12:02 |
| Wizzup | I think once we get working phone call audio (+ audo integration) and sms I will personally switch though | 12:05 |
| Wizzup | dogfood all the way :) | 12:05 |
| uvos | btw Wizzup is there a way to force the n900 to allways show the uboot menu | 12:08 |
| uvos | even with the device closed? | 12:08 |
| uvos | i gues its hardcoded | 12:09 |
| Wizzup | It's check a gpio in u-boot | 12:09 |
| Wizzup | so it can be changed for sure | 12:09 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste-extras/profilesx/pull/1 (add support for touchscreen.vibration.enabled) | 12:17 |
| uvos | profilesx works now | 12:17 |
| uvos | wrt adding removeing profiles | 12:17 |
| Wizzup | neat | 12:19 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste-extras/profilesx/pull/1 (add support for touchscreen.vibration.enabled) | 12:19 |
| uvos | id also take this package if youlike | 12:19 |
| Wizzup | granted | 12:24 |
| Wizzup | Although I think somethings needs to be done in jenkins as well | 12:24 |
| Wizzup | cc parazyd | 12:24 |
| uvos | "Also renames the cp applet to just Profiles, since its the only applet we have to change profile settings" | 12:25 |
| uvos | what do you think about this? | 12:25 |
| uvos | i found the control pannel profilesX name unseamly | 12:25 |
| Wizzup | yeah agreed | 12:27 |
| uvos | ok i also added a new string: dgettext("osso-profiles", "profi_fi_touch_screen_vibrate") | 12:29 |
| uvos | not sure where to add this | 12:29 |
| Wizzup | https://github.com/maemo-leste-translations/osso-profiles-l10n | 12:33 |
| Wizzup | https://github.com/maemo-leste-translations/osso-profiles-l10n/blob/master/po/osso-profiles.pot + https://github.com/maemo-leste-translations/osso-profiles-l10n/blob/master/po/en_US.po | 12:33 |
| Wizzup | and then hope others do the rest | 12:34 |
| uvos | i can do german at least :P | 12:34 |
| * sicelo notes that reminding people that the N900 is underpowered for browsers is such a common theme here ... | 12:47 | |
| Wizzup | hehe | 12:48 |
| parazyd | uvos, Wizzup: You need write permissions on the repo? | 12:52 |
| Wizzup | no, the question is how to add uvos to jenkins for that repo | 12:53 |
| Wizzup | (profilesx) | 12:53 |
| parazyd | We just add it to the bot's ACL | 12:53 |
| Wizzup | oh, so not in jenkins itself? | 12:53 |
| Wizzup | either way I don't know where it's stored | 12:53 |
| parazyd | Done | 12:54 |
| parazyd | Wizzup: Will pm | 12:54 |
| parazyd | We have a separation here | 12:55 |
| parazyd | I see uvos prefers IRC, so I added him to the IRC ACL | 12:55 |
| parazyd | Otherwise there's also the option to add to Jenkins' ACL, but then one has to use the Web UI to trigger builds. | 12:55 |
| uvos | "I see uvos prefers IRC, so I added him to the IRC ACL" heh thats a self fufilling Prophecy you only gave me IRC permissions to my other packages, ofc i use irc :P | 13:05 |
| uvos | not that i mind | 13:05 |
| Wizzup | I think that's another way of saying "the jenkins web ui is cumbersome to use" :) | 13:05 |
| Wizzup | also to configure accounts | 13:05 |
| uvos | yeah its fine :) | 13:05 |
| parazyd | Yeah it sucks | 13:20 |
| parazyd | We also have python cli scripts to interface with it internally | 13:21 |
| lel | IMbackK closed a pull request: https://github.com/maemo-leste-extras/profilesx/pull/1 (add support for touchscreen.vibration.enabled) | 15:34 |
| freemangordon | uvos: that "profiles" rename is what is seen in control panel? | 17:47 |
| Wizzup | right | 17:48 |
| freemangordon | how is that rename done? in .desktop file? | 17:49 |
| freemangordon | this https://github.com/maemo-leste-extras/profilesx/pull/1/commits/6ce72179ab4820816a1de8bf87d4b7d6321ceef0 ? | 17:49 |
| Wizzup | yes, looks like it in the pr | 17:50 |
| freemangordon | this is a hack | 17:50 |
| freemangordon | English name should not be in the desktop file like that, IIUC | 17:51 |
| freemangordon | for example sharing-accounts.desktop: | 17:52 |
| freemangordon | Name=share_cpa_ti | 17:52 |
| freemangordon | X-Text-Domain=osso-sharing-ui | 17:53 |
| Wizzup | makes sense, uvos^^ | 17:55 |
| uvos | freemangordon: hmm ok | 18:54 |
| uvos | freemangordon: currently this string was never translated | 18:54 |
| uvos | what X-Text-Domain would you suggest to put this string? | 18:54 |
| uvos | its own | 18:54 |
| uvos | profilsx dosent have one | 18:54 |
| freemangordon | check fremantle one | 18:54 |
| uvos | this is an extras pacakge | 18:54 |
| freemangordon | sec | 18:55 |
| uvos | it wasent in fremantle as sutch | 18:55 |
| uvos | btw this method violates xdg spec | 18:55 |
| uvos | for translations | 18:55 |
| uvos | not that it matters mutch | 18:55 |
| freemangordon | fremantle has "profiles" | 18:55 |
| uvos | since its a plugin | 18:55 |
| uvos | ok | 18:56 |
| freemangordon | lemme check what is the package name | 18:56 |
| uvos | could you check its desktop file | 18:56 |
| freemangordon | sure | 18:56 |
| uvos | on a running system simply | 18:56 |
| freemangordon | yes doing that as we speak :) | 18:56 |
| freemangordon | uvos: maemo-applet-profiles is the package name | 18:59 |
| freemangordon | I would recommend to download and have alook at it | 18:59 |
| uvos | where are fremantle repos? | 18:59 |
| freemangordon | there is more that just transaltions that shall be done for a cpl applet replacement | 18:59 |
| freemangordon | sec | 19:00 |
| freemangordon | https://coderus.openrepos.net/n900mirror/downloads.maemo.nokia.com/fremantle/ssu/mr0/ | 19:00 |
| uvos | sure im also not sure profilesx is a permanent solution | 19:00 |
| uvos | we should just have _something_ for now to set the ring tone and sutch | 19:00 |
| freemangordon | then I'll RE the original applet | 19:00 |
| uvos | sure if its better | 19:01 |
| freemangordon | uh, 37372 bytes | 19:01 |
| freemangordon | this dude has lots of stuff in it | 19:01 |
| uvos | maybe do it some other time then | 19:01 |
| freemangordon | yeah | 19:01 |
| uvos | profilesx can serve | 19:01 |
| freemangordon | yep | 19:01 |
| freemangordon | uvos: btw, still, have a look at stock applet | 19:02 |
| uvos | ok | 19:02 |
| freemangordon | what I meant was CUD and RFS scripts | 19:02 |
| freemangordon | (Clear-User-Data, Restore-Factory-Settings) | 19:03 |
| freemangordon | those are important | 19:03 |
| uvos | not sure why those are particulary important | 19:06 |
| uvos | but ok | 19:06 |
| uvos | would also want to change this to not depend on /home/user | 19:06 |
| freemangordon | because - OS is intended to be used on mobile devices, being able to restore to factory setting and to clear user data was there before even flashlight capability | 19:08 |
| uvos | anyhow i renamed the cp applet | 19:15 |
| uvos | parazyd: would you move profilesx to core and add it to the metapackages at your leisure | 19:16 |
| uvos | as it looks like its going to be our default profile applet for a while | 19:16 |
| freemangordon | tmlind: who controls CM_xxx_SGX and PM_xxx_SGX regs and are we sure those have correct values? how could I verify? | 19:45 |
| freemangordon | I think I maybe should edit the driver to call EnableSGXClocks() on exit from probe and then verify if allregisters look ok | 19:51 |
| freemangordon | shall I verify other registers but PRCM? | 19:52 |
| tmlind | freemangordon: the clocks should be ok, but the rate may need to be configured. the clocks are claimed by drivers/bus/ti-sysc.c and managed by runtime pm | 20:08 |
| tmlind | the clock rate and parent clock can be configured with assigned-clock-parents etc in the dts like we did for droid4 | 20:09 |
| freemangordon | but wrong rate should not lead to bus error but bad performance, no? | 20:09 |
| tmlind | too high clock rate would cause crashes for sure | 20:09 |
| freemangordon | tmlind: also, I checked the rate (when it was working) and it was ok, 110666 or somesuch | 20:10 |
| freemangordon | I compared with fremantle | 20:10 |
| tmlind | ok | 20:10 |
| tmlind | what is the source clock supposed to be | 20:10 |
| freemangordon | the clock parent was same in either cases | 20:10 |
| freemangordon | not sure, but I cam check | 20:11 |
| freemangordon | *can | 20:11 |
| freemangordon | shall I? | 20:11 |
| tmlind | sure makes sense, the clock rate can be found in /sys/kernel/debug/clk or something like that | 20:12 |
| freemangordon | yeah | 20:12 |
| freemangordon | that's where I look | 20:12 |
| freemangordon | :) | 20:12 |
| tmlind | ok, then checking the fremantle source clock can be done by dumping regs | 20:12 |
| freemangordon | I am on kernel-power | 20:13 |
| freemangordon | which exports clock tree in /sys/kernel/debug | 20:13 |
| freemangordon | that's why I said that I compared the clocks and they are same | 20:13 |
| tmlind | ok | 20:13 |
| freemangordon | root@devuan-n900:/sys/kernel/debug/clk/sgx_fck# cat clk_parent | 20:16 |
| freemangordon | core_d3_ck | 20:16 |
| freemangordon | root@devuan-n900:/sys/kernel/debug/clk/sgx_fck# cat clk_rate | 20:16 |
| freemangordon | 110666666 | 20:16 |
| freemangordon | tmlind: ^^^ | 20:16 |
| freemangordon | l3_ick is parent of sgx_ick | 20:17 |
| freemangordon | clk_rate is 166000000 | 20:17 |
| freemangordon | tmlind: whall I disable off mode? | 20:18 |
| freemangordon | *shall | 20:18 |
| tmlind | should not matter, but worth trying :) | 20:19 |
| freemangordon | ok, what else could be then? | 20:19 |
| tmlind | so is fremantle also using 110666666 and core_d3_ck? | 20:20 |
| freemangordon | lemme check to be 100% sure | 20:20 |
| tmlind | ok 110 sounds about right to me though | 20:21 |
| tmlind | on droid4 we have 307 looking at commit fab030ac99978d235ca3889262b28d93c8bccd30 | 20:21 |
| freemangordon | /sys/kernel/debug/clock/virt_19_2m_ck/osc_sys_ck/sys_ck/dpll3_ck/dpll3_m2_ck/core_ck/sgx_fck | 20:23 |
| freemangordon | 110666666 | 20:23 |
| freemangordon | on fremantle | 20:23 |
| tmlind | ok | 20:24 |
| freemangordon | do you need ick? | 20:24 |
| tmlind | nah | 20:24 |
| freemangordon | /sys/kernel/debug/clock/virt_19_2m_ck/osc_sys_ck/sys_ck/dpll3_ck/dpll3_m2_ck/core_ck/l3_ick/sgx_ick | 20:24 |
| freemangordon | too late :) | 20:24 |
| freemangordon | hmm | 20:25 |
| freemangordon | tmlind: on fremantle there is no core_d3_ck | 20:26 |
| freemangordon | or maybe it is just not important, as soon as the rate is fine | 20:27 |
| freemangordon | also, | 20:27 |
| freemangordon | if we do not play with PM, it works fine | 20:27 |
| tmlind | yeah weird | 20:27 |
| tmlind | the same clocks are enabled even without pm so those should be fine then | 20:28 |
| uvos | just check the clock resigers after the hang over jtag? | 20:28 |
| uvos | the pins on the back of the n900 have jtag right? | 20:28 |
| freemangordon | maybe, but I dont; have the equipment to do that | 20:28 |
| tmlind | well i force enabled sgx module via /sys and can read the regs just fine before prvsrvinit | 20:29 |
| uvos | sure but the dirver might be messing with the clock regs in an unexpected way after prvsrvinit | 20:29 |
| freemangordon | pvrsvrinit does the same as pvrsvrctl? | 20:29 |
| uvos | i have no idea what the point of pvrsrv is even | 20:30 |
| uvos | freemangordon: yes | 20:30 |
| uvos | it proububly uploads fw? | 20:30 |
| tmlind | it should not even know about the clock regs.. but maybe there's some pvr internal gate or multiplier | 20:30 |
| freemangordon | uvos: the driver does not touch clock regs, besides calling pm_xxx functions | 20:30 |
| uvos | tmlind: it knows for sure | 20:30 |
| freemangordon | uvos: not really | 20:30 |
| uvos | i know the userspace knows the clock and decides behavior based on it | 20:30 |
| freemangordon | clocks are controlled by linux | 20:30 |
| uvos | no here me out | 20:31 |
| uvos | on ddk1.9 and the android blobs | 20:31 |
| tmlind | uvos: i don't think we have the pvr freq scaling enabled in the driver | 20:31 |
| freemangordon | even of remantle, where you have freq scaling, it is done by the driver | 20:31 |
| freemangordon | it gathers performance data based on load that's reported by uKernel | 20:32 |
| uvos | so on d4 on the older blobs (icl android) there is wierd behavior where the driver changes the frequency based on load and the display refeshing | 20:32 |
| freemangordon | and decides to change opp | 20:32 |
| uvos | but only if its set to exactly 307Mhz | 20:32 |
| uvos | if you set it to something else in linux | 20:32 |
| uvos | all this activity stops | 20:32 |
| uvos | this code has to be _somewhere_ | 20:33 |
| uvos | i faild to find it | 20:33 |
| freemangordon | yes, in the driver :) | 20:33 |
| uvos | ok | 20:33 |
| uvos | then i missed it while looking | 20:33 |
| tmlind | i guess it must be there buried into the 60k lines of ifdefs.. | 20:33 |
| freemangordon | yeah | 20:33 |
| freemangordon | I can show it where it is in fremantle driver | 20:34 |
| freemangordon | it is not that different to what we use though | 20:34 |
| tmlind | well the clock rate we can read in a loop from the regs while prvsrvinit is running | 20:34 |
| uvos | well at the time i was concerned that pvrsrv uploads some fw and that sgx dose clock managment on device | 20:34 |
| uvos | like modern desktop gpus | 20:34 |
| tmlind | the driver certainly has all kinds of ioctl controls in place | 20:34 |
| freemangordon | no, sgx does what it has been told, at least for sgx530, AFAIK | 20:35 |
| tmlind | would not be surprised if there's write to any reg ioctl there too | 20:35 |
| freemangordon | could be | 20:35 |
| freemangordon | but still the oops we get is a simple "resume from suspend" path | 20:36 |
| freemangordon | which behaves in exactly the same way with SUPPORT_ACTIVE_POWER_MANAGEMENT disabled, besides enabling/disabling clocks, IIUC | 20:37 |
| freemangordon | tmlind: is it possible that there is some period after clocks being enabled but the PLL is still not stable? | 20:38 |
| freemangordon | or some other timeout needed to stabilize the clocks? | 20:38 |
| tmlind | sure it takes a while to lock, but the pll should be enabled and we just mult/div/gate it | 20:38 |
| freemangordon | yeah | 20:39 |
| freemangordon | what about those prcm regs? reset one? | 20:39 |
| freemangordon | is it possible that for some reason SGX is hold in reset? | 20:40 |
| freemangordon | and how to verify? | 20:40 |
| uvos | irrc there is a reset reg for sgx in omap4 | 20:40 |
| uvos | so just look at the omap3 datasheet and read it? | 20:41 |
| freemangordon | I think it is the same for omap3, reading through TRM as we speeck to find it | 20:41 |
| freemangordon | *speak | 20:41 |
| freemangordon | hmm, what about PM_PWSTCTRL_SGX | 20:42 |
| freemangordon | 0x4830 6BE0 that is | 20:42 |
| tmlind | i don't think there's a rstctrl for sgx on omap3, if it was in reset no register access at all would work | 20:45 |
| tmlind | freemangordon: the patch i posted this morning manages PM_PWSTCTRL_SGX | 20:45 |
| tmlind | hmm i guess i should check the 34xx trm for that reg though, that's from the dm3730 trm | 20:46 |
| freemangordon | I think it is the same | 20:48 |
| freemangordon | from 3430: PM_PWSTCTRL_SGX 0x4830 6BE0 | 20:49 |
| freemangordon | PM_PWSTST_SGX 0x4830 6BE4 | 20:49 |
| tmlind | looks like the available modules are a bit different | 20:50 |
| tmlind | sorry available modes i mean | 20:50 |
| freemangordon | POWERSTATE bits? | 20:51 |
| tmlind | yeah but we don't care about the inactive mode | 20:51 |
| freemangordon | hmm, in TRM I look at INACTIVE is defined for PM_PWSTST_SGX | 20:52 |
| freemangordon | the readonly POWERSTATEST | 20:52 |
| freemangordon | so I am not sure what you mean in terms of PM_PWSTCTRL_SGX/POWERSTATE | 20:52 |
| tmlind | oh right, i was looking at the wrong reg.. | 20:55 |
| tmlind | no statechange bit there it seems | 20:56 |
| freemangordon | hmm, what do you mean? | 20:59 |
| freemangordon | you have INTRANSITION | 21:00 |
| freemangordon | hmm, seems we have /sys/kernel/debug/pm_genpd/prm_gfx with current_state 'off-0' | 21:03 |
| tmlind | some prm have bit 4 for statechange, i doubt that matters in this case as the regs are readable | 21:04 |
| tmlind | /sys/kernel/debug/pm_genpd/prm_gfx | 21:04 |
| freemangordon | does sysc (or whoever controls prcm state) waits for INTRANSITION to become zero? | 21:05 |
| tmlind | yeah the prm driver does | 21:06 |
| tmlind | might be worth checking the /sys/kernel/debug/pm_genpd/prm_gfx state that it shows the real reg value and not the idle state value.. | 21:07 |
| freemangordon | usingdevmem? | 21:08 |
| freemangordon | by using devmem? | 21:08 |
| tmlind | yeah | 21:09 |
| freemangordon | I have to find it first :) | 21:09 |
| freemangordon | ok, not now, but tomorrow I will do a couple of experiments, unless you provide a fix by then :) | 21:10 |
| freemangordon | like, recording the reg values with and without SUPPORT_ACTIVE_POWER_MANAGEMENT | 21:10 |
| freemangordon | besides PRCM regs, what else shall I look at? | 21:11 |
| tmlind | checking the values without SUPPORT_ACTIVE_POWER_MANAGEMENT seems like a good idea | 21:11 |
| freemangordon | ok | 21:12 |
| tmlind | the other things to look for are silly typos :) | 21:12 |
| freemangordon | where? :) | 21:12 |
| freemangordon | in the kernel source? :p | 21:12 |
| tmlind | dts, the patch i posted this morning, pvr changes affecting pm_runtime.. | 21:13 |
| freemangordon | hmm, pvrsrvctl *DID NOT* crash this time | 21:15 |
| freemangordon | with your patch that is | 21:15 |
| tmlind | weird | 21:15 |
| freemangordon | however, kmscube did | 21:15 |
| freemangordon | yes | 21:16 |
| freemangordon | but, I disabled off mode | 21:16 |
| tmlind | that sounds still like too high clock rate.. | 21:16 |
| freemangordon | this is controlled by tds, no? | 21:16 |
| freemangordon | *dts | 21:16 |
| tmlind | maybe we have some cpuidle race with the PM_PWSTCTRL_SGX register access | 21:17 |
| tmlind | yeah the rate seems just fine though | 21:17 |
| freemangordon | yeah, rate seems fine | 21:17 |
| tmlind | how about add some load to keep system from idling? like dd if=/dev/zero of=/dev/null & | 21:18 |
| freemangordon | also, keep in mind we have issues where maybe half of the time device cannot boot | 21:18 |
| freemangordon | ok, I can try that | 21:18 |
| freemangordon | not now though, have to run | 21:18 |
| freemangordon | also, I plan to weak the driver to try to leave the cloaks running after probe has finished | 21:19 |
| freemangordon | to see what is the actual state | 21:19 |
| freemangordon | anyway, ttyl | 21:19 |
| tmlind | ok ttyl | 21:19 |
| tmlind | freemangordon: so if omap3 or 34xx sgx ocp registers are broken like they seem based on what i noticed, maybe we should not enable SYS_USING_INTERRUPTS as that enables SGX_OCP_REGS_ENABLED, and seems SUPPORT_ACTIVE_POWER_MANAGEMENT depends on these.. | 22:22 |
| tmlind | there's also SGX_OCP_NO_INT_BYPASS option that might be for 36xx if the ocp reg got fixed or something | 22:23 |
| tmlind | anyways, ttyl | 22:23 |
| freemangordon | SYS_USING_INTERRUPTS interrupts alone (without SUPPORT_ACTIVE_POWER_MANAGEMENT) works perfectly fine | 22:23 |
| freemangordon | glmark score I posted yesterday was with SYS_USING_INTERRUPTS enabled | 22:24 |
| freemangordon | tmlind: ^^^ | 22:25 |
| tmlind | ok, i guess they are also increasing in proc then.. | 22:25 |
| freemangordon | can't parse, sorry, could you rephrase | 22:25 |
| freemangordon | you mean interrupt counter? | 22:25 |
| tmlind | uvos: adding SGX_OCP_NO_INT_BYPASS might enable some runtime gating as it tinkers with the sgx sysconfig reg | 22:26 |
| tmlind | freemangordon: yeah so i'd assume fremantle has the sgx interrupts increasing? :) | 22:26 |
| freemangordon | yes, so is 1.17 with SYS_USING_INTERRUPTS enabled | 22:26 |
| tmlind | ok | 22:27 |
| freemangordon | (13,53,07) freemangordon: root@devuan-n900:/sys/kernel/irq/37# cat per_cpu_count | 22:27 |
| freemangordon | (13,53,07) freemangordon: 64234 | 22:27 |
| freemangordon | (13,53,07) freemangordon: root@devuan-n900:/sys/kernel/irq/37# cat per_cpu_count | 22:27 |
| freemangordon | (13,53,07) freemangordon: 66336 | 22:27 |
| freemangordon | this is while glmar is running | 22:27 |
| freemangordon | *glmark | 22:27 |
| tmlind | ok | 22:27 |
| tmlind | probably SUPPORT_ACTIVE_POWER_MANAGEMENT | 22:28 |
| tmlind | is for omap4 and later then | 22:28 |
| tmlind | maybe omap3 assumes just gating using the sysconfig register or something | 22:29 |
| freemangordon | what I saw from the code, it just enables the code that calls pm_runtime_get()/pm_runtime_put() | 22:30 |
| freemangordon | so I doubt this is invalid for omap3 | 22:30 |
| freemangordon | olso, this seems to work fine in fremantle, where it calls clock_disable() instead | 22:31 |
| freemangordon | *also | 22:31 |
| tmlind | yeah ok, ttyl | 22:34 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!