ruleh93 has quit [Ping timeout: 256 seconds]
xmn has quit [Quit: xmn]
akossh has quit [Quit: Leaving.]
uvos has quit [Ping timeout: 268 seconds]
System_Error has joined #maemo-leste
n900 has quit [Ping timeout: 245 seconds]
n900 has joined #maemo-leste
Pali has quit [Ping timeout: 260 seconds]
vifino has quit [Ping timeout: 268 seconds]
sunshavi has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
n900 has quit [Ping timeout: 256 seconds]
n900 has joined #maemo-leste
ceene has quit [Ping timeout: 260 seconds]
inky has quit [Ping timeout: 240 seconds]
_inky has quit [Ping timeout: 250 seconds]
joerg has quit [Ping timeout: 245 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
_inky has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
Wikiwide has quit [Ping timeout: 268 seconds]
uvos has joined #maemo-leste
Pali has joined #maemo-leste
doc has quit [Ping timeout: 264 seconds]
peetah has quit [Ping timeout: 245 seconds]
peetah has joined #maemo-leste
<Wizzup> these seem quite small
<uvos> not sure why you need sutch a thing
<uvos> just one of these
<uvos> set it to 3.7v before you leave
<uvos> and have a usb cable feed it
<uvos> maybe rather this
<Wizzup> mhm
<uvos> transient current can be pretty high with these things
<Wizzup> I might be able to find those locally here now
<uvos> sure yeah
<uvos> but you need a multimeter too
<uvos> not sure what you have
<Wizzup> nothing, but there should be shops with that stuff here
<Wizzup> probably better if I just wait and focus on other stuff, but I don't like waiting :)
<uvos> probubly more sane just to work on userspace with the d4
<Wizzup> mhm
<Wizzup> I'll work on the bootmenu+recovery-mode and omap-linux some, try to get that going
<bencoh> uvos: wait, is that thing reliable
<bencoh> uvos: it looks like a toy
<uvos> ofc its just a lm259
<uvos> extreamly widly used in products
<bencoh> no I meant, your first link
<uvos> and the rest is just its referance implementation
<bencoh> the "power supply" with the lcd screen
<uvos> those work great too
<Wizzup> the one I linked?
<uvos> cant vautch for this exact one
<uvos> but i have several
<uvos> they are fine
<bencoh> Wizzup: ah right, that one too
<uvos> no match for a real lab supply on output ripple or regulation
<uvos> but perfectly fine otherwise
<bencoh> hm
<Wizzup> I mean I don't think I can find a lab psu here, that's the problem :p
<Wizzup> I'll just wait
<bencoh> Wizzup: what kind of voltage do you need anyway?
<bencoh> ~4V ?
<Wizzup> a bit less, but around that, yes
mrtux2 has joined #maemo-leste
Armen2 has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
tmlind_ has joined #maemo-leste
mardy has quit [Ping timeout: 260 seconds]
tmlind has quit [Ping timeout: 260 seconds]
blasty has quit [Ping timeout: 260 seconds]
n900 has quit [Ping timeout: 260 seconds]
mrtux has quit [Ping timeout: 260 seconds]
asrieldreemurr has quit [Ping timeout: 260 seconds]
Armen has quit [Ping timeout: 260 seconds]
mrtux2 is now known as mrtux
Armen2 is now known as Armen
blasty has joined #maemo-leste
mardy has joined #maemo-leste
n900 has joined #maemo-leste
adc has quit [Quit: reboot]
adc has joined #maemo-leste
ruleh has joined #maemo-leste
<Wizzup> found a local shop, will go there now I guess
<sicelo> :-)
<uvos> "[12:41] <Wizzup> I'll just wait" that lasted long :P
<Wizzup> hehe
vifino has joined #maemo-leste
[TheBug] has quit [Changing host]
[TheBug] has joined #maemo-leste
<freemangordon> uvos: drmModePageFlip takes 6 ms
<freemangordon> according to docs it shall return immediately
<Wizzup> got it at least
<freemangordon> well, not sure
<uvos> freemangordon: thats wierd drmModePageFlip shouldent really do anything at all
<uvos> plenty of reasons why drm_mode_page_flip_ioctl can stall for a while really
<freemangordon> I think in our case it is that it pins the framebuffer
<freemangordon> but I think we have more general issue here - it seems buffer is created for every frame
<freemangordon> not that I know how is that supposed to work
<freemangordon> but in armsoc we have ARMSOCDRI2ReuseBufferNotify()
<uvos> in our flipchain dri2 in x calls a function called check_resue_buffer (or something like that)
<uvos> it returns false
<uvos> maybe check whyy
<Wizzup> ok, I have a working serial. now to remember which string to use for kernel command line
<uvos> freemangordon: its allocate_or_reuse_buffer
<uvos> the ddx implements ReuseBufferNotify
<uvos> yeah looks like what armsoc probubly dose
<freemangordon> hmm, where do you see that?
<freemangordon> uvos: I don;t see such function
doc has joined #maemo-leste
<uvos> hw/xfree86/dri2/dri.c
<uvos> hw/xfree86/dri2/dri2.c
<uvos> allocate_or_reuse_buffer
<uvos> line 503
<uvos> gets called on every flip and returns false on d4 - i checked this yesterday
<freemangordon> I don;t understand what do you mean "the ddx implements ReuseBufferNotify"
<freemangordon> omap-video ddx does not implement that
<freemangordon> maybe this is one of the problems
<uvos> right
<uvos> thats why allocate_or_reuse_buffer returns false
<uvos> the ddx implements ReuseBufferNotify if it wants
<uvos> actually thats not what happens
<freemangordon> ah, yeah, sure
<uvos> it returns false for another reason
<uvos> actually false is reuse
<uvos> so no idea
<freemangordon> uvos: what about (both of us) try to find some time these days and debug this?
<freemangordon> I mean - to have a debug session
<freemangordon> not to say that it somehow manages to tear while doing page flip
<freemangordon> this is impossible on theory :)
<freemangordon> *in theory
<uvos> why would that be impossible, you can flip during hblank
<freemangordon> no, because the flip requested is "flip on next vblank"
<freemangordon> Wizzup: do we have some budget to spend on that?
<uvos> sure we can debug some time
<uvos> synconiously
<freemangordon> yeah
<uvos> idk if it makes sense but sure
<freemangordon> I am not sure too
<freemangordon> thus my question ^^^ to Wizzup
<freemangordon> if we can find someone who knows how all this is supposed to work
<Wizzup> freemangordon: probably depends on how much the person needs
<freemangordon> well, I guess we have to fina that 'person' first
RedW has quit [Ping timeout: 268 seconds]
RedW has joined #maemo-leste
<Wizzup> let's see if I can boot to recovery mode with serial now :)
vifino has quit [Ping timeout: 245 seconds]
<sicelo> :-)
<Wizzup> uvos: do we need to install something to make the recovery softlevel work?
<Wizzup> hm, ok, nevermind, it works I think
<Wizzup> uvos: btw since I attached serial I haven't bad any random boot failure ;)
peetah has quit [Ping timeout: 245 seconds]
peetah has joined #maemo-leste
<Wizzup> tmlind_: ok, I have a shell now with the uarts idled and no modules loaded
<Wizzup> the screen seems to be on still though
<Wizzup> I guess I'll load omapdrm and friends?
RedW has quit [Ping timeout: 250 seconds]
<Wizzup> uvos: ping
<uvos> Wizzup: hmm?
<Wizzup> uvos: how do I blank a display with drm
<Wizzup> I might not have enough modules loaded yet but it's also not clear to me
<Wizzup> uvos: as in, I have the n900 booted to init=/bin/bash and enabled off mode
RedW has joined #maemo-leste
<Wizzup> but I don't think the screen is off
<Wizzup> ok, I do not have /dev/dri/ yet
<Wizzup> so more is missing
<Wizzup> the panel is loaded though
<uvos> is omapdrm loaded?
<Wizzup> yes
<uvos> udev?
<Wizzup> no, definitely not udev since that loads all the modules
<Wizzup> which is the point: I don't want it to do that
<freemangordon> Wizzup: maybe mknod
<Wizzup> when I booted to init=/bin/bash the display was still on from u-boot
<uvos> Wizzup: well udev also creats lots of the files in /dev/
<uvos> yeah mknod
<Wizzup> I ran busybox mdev -s and it didn't make it
<Wizzup> as you sure what's all that is needed?
<parazyd> You should mount devtmpfs first, no?
<parazyd> Then mdev
<uvos> module wise that looks correct
<Wizzup> oh you're right, even devtmpfs is not set up
<Wizzup> argh
<uvos> heh
<parazyd> Then also sys and proc manually
<Wizzup> maybe not, it says it's already mounted
<Wizzup> but it's not in mount
<Wizzup> parazyd: yes I did that
<freemangordon> Wizzup: I think you should mknod /dev/dri/card0 c 226,0 at some point
<Wizzup> # mount -t devtmpfs devtmpfs /dev
<Wizzup> mount: /dev: devtmpfs already mounted on /dev.
<freemangordon> sorry, it is mknod /dev/dri/card0 c 226 0
<freemangordon> (no comma)
<Wizzup> still, I don't have internet so I can't build uvos tool anyway
<Wizzup> I'll have to reset/reboot
<Wizzup> kinda weird that kernel provides no way to do this
<parazyd> In my initramfs shell script I have:
<parazyd> mount -t devtmpfs none /dev
<parazyd> mount -t proc none /proc
<parazyd> mount -t sysfs none /sys
<parazyd> in that order
<Wizzup> ty
<freemangordon> glib upstream replied, finally :)
<Wizzup> tmlind_: this traces happens when n900 fails to boot randomly https://dpaste.com/GRWDBS2PA
<Wizzup> uvos: ^
<freemangordon> pm runtime
<Wizzup> yes, as always
<Wizzup> :P
<freemangordon> :)
<freemangordon> lets hope tmlind_ know how to find the offending module
<freemangordon> *knows
<freemangordon> Wizzup: maybe post on linux-omap
<Wizzup> yeah, I'm just trying to catch a bunch
<Wizzup> I'll have to build nokia modem again later as well
<Wizzup> parazyd: btw kernel does it:
<Wizzup> # dmesg|grep devtmp
<Wizzup> [ 5.040222] devtmpfs: mounted
<Wizzup> [ 0.134277] devtmpfs: initialized
vifino has joined #maemo-leste
<Wizzup> so the mknod is not enough (or just wrong) since uvos drm tool gets Can not open drm device /dev/dri/card0: No such device
<freemangordon> maybe you need to mknod render node as well
<Wizzup> modprobe display_connector
<Wizzup> this was necessary
<Wizzup> alas, uvos https://dpaste.com/DN8678RA8
<Wizzup> it looks like the touchscreen doesn't even support runtime pm?
<uvos> i mean it just calls perror() regardless
<uvos> so that dosent mean anything
<uvos> unless drmSetMaster is failing
<uvos> i should klean that thing up a bit
<uvos> dose it not work?
<Wizzup> uvos: well maybe I need to also disable the backlight manually?
<uvos> if the backlight is associated with the right output device in dts it should also turn off
<uvos> cat /sys/class/drm/*/dpms
<uvos> should tell you if the display is on or not
<uvos> according to drm
<Wizzup> ok
<Wizzup> it looks like you things turns off only one
<Wizzup> On
<Wizzup> # cat /sys/class/drm/*/dpms
<Wizzup> On
<uvos> obivously you need to have whatever module the baclight led is on loaded too
<uvos> btw
<Wizzup> (runs tool)
<Wizzup> # cat /sys/class/drm/*/dpms
<Wizzup> On
<Wizzup> Off
<Wizzup> yes, but I can control the backlight via sys so it is loaded with the panel
<Wizzup> I think probably it turns off the s-video/composite but not the lcd
<uvos> it should turn off both
<uvos> code wise
<Wizzup> # cat /sys/class/drm/card0-Composite-1/dpms
<Wizzup> Off
<Wizzup> t# cat /sys/class/drm/card0-DPI-1/dpms
<Wizzup> On
<Wizzup> right
<uvos> works on d4 with dsi and hdmi
<uvos> drmModeConnectorSetProperty also returns 0 for both displays
<uvos> so it not haveing any effect is wierd
<Wizzup> 't is what is happening though
<uvos> maybe something else is reneableing it, could you have drm_blankscreen not quit
<uvos> and not drop master
<uvos> that way nothing can renable
<uvos> so move drmSetMaster(device); out of the loop
<uvos> and add while(true) to the end
<uvos> after the loop
<uvos> and remove drmDropMaster(device); ofc
<Wizzup> the only process that runs is bash
<uvos> the kernel might for its console, it dident when i wrote the program but it might now
<Wizzup> in any case currently: # sleep 5; ./idle.sh
<Wizzup> ST_UART2,ST_MCSPI1
<Wizzup> uvos: console=ttyS2 though
<uvos> Wizzup: ok
<uvos> Wizzup: no idea then
<Wizzup> spi1 = touchscreen as far as I can tell
<Wizzup> (and it's not loaded, and it doesn't do pm)
<uvos> and uart is undetached kernel console
<uvos> proubly
<Wizzup> it is detached actually
<Wizzup> uart2 seems to be bt
<Wizzup> [ 2.565093] printk: console [ttyS2] enabled
<Wizzup> [ 17.983398] printk: console [ttyS2] disabled
<Wizzup> uvos: maybe fbdev can be used to blank or something?
<uvos> you can try fbdev blanking
<uvos> but on d4 it dosent allow it it idle
<uvos> *to
<Wizzup> ok
<Wizzup> interesting, without drm loaded (just serials idled and off mode enabled) I get this:
<Wizzup> # sleep 5 ; ./idle.sh
<Wizzup> ST_MCSPI1
<uvos> dose i2cdetect suggest you have any i2c devices in use by the kernel?
<Wizzup> it looks like RET increases though
<uvos> looking at /sys/class/i2c-dev/ should also work
<uvos> ah so its not blocked all the time
<Wizzup> yes, which is great, I haven't seen that before
<uvos> that might be the best you can do, tmlind mentioned that the kernel is too busy with timers to enter off mode with stock cost table
<Wizzup> hmm, ok
<uvos> dunno if it applies when you have so little modules loaded or not
<uvos> tmlind_: ?
<Wizzup> # sleep 5; ./idle.sh
<Wizzup> ST_MCSPI1
<Wizzup> OFF:0,RET:458
<Wizzup> uvos: fwiw no modules loaded at all atm
<Wizzup> well I guess this is some progress
<Wizzup> looks like loading just drm (not omapdrm) and panel adds uart2 as blocker, but allows me turn off backlight and it's not too bad ...
<Wizzup> 0.01A at 0.34V
mardy has quit [Quit: WeeChat 2.8]
<Wizzup> so like 71mW?
<uvos> 0.34v?
<Wizzup> # sleep 10 ; cat /sys/class/power_supply/bq27200-0/power_avg
<Wizzup> 71540
<Wizzup> uvos: 3.4V
<Wizzup> sry
<Wizzup> my display is showing 03.4v ;)
<uvos> 0.01A at 0.34V =/= 71mW
<uvos> or 0.01A at 3.4V =/= 71mW even
<Wizzup> right, which is why I took the measure from bq27200
<uvos> 71mW is the same as bionic at idle
<Wizzup> 71mW seems about right for hitting RET some time but not OFF, no
<uvos> also ret no off
<uvos> so that makes sense
<Wizzup> alright
<uvos> actually bionic is about 60
<uvos> but ~
<Wizzup> yeah maybe I need to let it settle some more
<uvos> roughly
<Wizzup> ok, I'll document all of this, but then there is a big task of loading modules one by one I guess
<Wizzup> seeing what causes what kind of blocks
<Wizzup> I suspect there's more than a few different ones
<Wizzup> also didn't tmlind_ say he fixed OFF not being hit?
<uvos> not that i remember
<uvos> but maybe
<uvos> i remember him hacking the cost table
<uvos> no idea how this ended up
<Wizzup> sicelo: ok, so looks like we probably dn't have it yet
<Wizzup> thanks for digging that up :)
<sicelo> 18:40 <tmlind> uvos: yup trying with target_residency of 50000 and 60000 makes core ret work
<sicelo> 18:40 <tmlind> core_pwrdm (ON),OFF:19,RET:6,INA:0,ON:26,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
<sicelo> so you could try that and see
<uvos> yeah
<uvos> but we need to mesure target_residency really
<uvos> and see if the current value is wrong
<Wizzup> so this would be replacing 15000 with 50000 and 30000 with 60000 ?
<Wizzup> in arch/arm/mach-omap2/cpuidle34xx.c
<uvos> you should lower it really
<uvos> if you want it to pick it more often
<Wizzup> well it looks like we're raising it atm?
<Wizzup> unless I am missing something?
<uvos> right
<uvos> that makes no sense
<uvos> thats why im mentioning it
<Wizzup> well I might do what tmlind said worked first
<Wizzup> and then see what better values we need?
<uvos> just set off to what ret is now
<uvos> there might not be better values
<uvos> so the point of target_residencey is that this is the minimum time the device must spend there for it to make sense to enter this state
<uvos> from a pm perspective
<uvos> off requries you to reload all registers
<Wizzup> hmm
<uvos> its expensive
<uvos> power wise
<Wizzup> then why does it only work for tmlind_ if he increases it?
<Wizzup> idgi
<uvos> his values must be wrong/typo, he must be looking at a different file or he/someone changed it to a lower value since
<Wizzup> last change Date: Wed Mar 4 14:54:30 2020 -0800
<Wizzup> grepping for omap3_idle_driver only shows this file
<Wizzup> and these are the only target_residency mentions
<Wizzup> oh hmmmmm
<Wizzup> omap3_idle_driver vs omap3430_idle_driver
<Wizzup> ok I see what I should change now
<Wizzup> sorry for being slow
<uvos> np
<uvos> we are all slow sometimes
<lel> MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/545 (N900: Try to hit OFF mode (low power consumption))
<Wizzup> ttps://github.com/maemo-leste/bugtracker/issues/545#issuecomment-980438141 posted some info here
<uvos> Terrorist Tactics and ProcedureS?
<Wizzup> ^_^
<Wizzup> totally worth the 40 euro for this lab psu
<uvos> heh
<Wizzup> any ideas about the best way to load specific modules and do off mode tests?
<Wizzup> to see which ones block idle
<Wizzup> I figured maybe I can make some script that one can set as init= that also sets up wifi and sshd, but I don't think I have job management in my bash shell currently
<uvos> not really
<uvos> omap3430 having its own special cost table probubly has a reason btw
<uvos> there is likley some bug that causes it to take forever to restore from idle or some errata that wastes a buch of power on wakeup
<Wizzup> mhm
<uvos> ie this numbers suggest something is broken hw wise
<Wizzup> well, what can we do :)
<uvos> no idea, we need to quiet down the kernel timers
<Wizzup> I meant we cannot fix the hw
<Wizzup> but yeah I guess you mean lowering the timers doesn't necessarily help
<Wizzup> maybe tmlind was also onto something when he said maybe they overflow
<Wizzup> # sleep 5; ./idle.sh
<Wizzup> OFF:13,RET:1
<Wizzup> ST_MCSPI1
<sicelo> that's beautiful sight :-)
<Wizzup> doesn't seem to matter much for power usage compared to ret though
<uvos> probubly the errata biteing
<uvos> maybe some value higher than what you have
<uvos> but lower than before would be better
<Wizzup> it looks like kernel also just wakes up more than before perhaps
<Wizzup> causing it not to be hit
<uvos> right yes thats true for sure
<uvos> its very busy
<uvos> increably so compeard to the motorola kernel for instance
meldrian is now known as IchBinDerUweUndB
IchBinDerUweUndB is now known as IchBinDerUwe
<Wizzup> uvos: do you see that in powertop?
<uvos> yeah
<Wizzup> looks like tsc2005 just outright blocks idle when probed
<Wizzup> lol
<uvos> whats lol about that?
<uvos> if it dosent support runtimepm
<Wizzup> well I think it does in some form
<Wizzup> at least open/close do something
<Wizzup> uvos: well it's mostly lol in the sense that it's the first module I probed
<Wizzup> and it blocks idles right away
<uvos> not sure if suprising, ts on d4 also blocked idle at all times untill tmlind improved the driver
<uvos> fixing various drivers is likely going to be the story of your life for a while :P
<Wizzup> at least wifi does not block idle
<uvos> thats something
uvos has quit [Read error: Connection reset by peer]
freemangordon has quit [Ping timeout: 256 seconds]