| 00:53 | mk01_ | jnettlet: regarding the "flickering" we have been discussing - with removing the fb depth conversion (32->16b), it completely disappears. |
| 00:53 | mk01_ | (re not conversion, ... fb1 reconfiguration to 16bit in case deint is running) |
| 09:28 | palatin | I experience a clock drift of approx. 1 min per month on cubox V1, is that expected ? |
| 12:35 | vpeter | jnettlet: one short question - what is the purpose of reg = <0>; in regulator? |
| 12:36 | jnettlet | vpeter, where are you looking exactly? |
| 12:37 | vpeter | In imx6q-sabrelite.dts for example |
| 12:38 | vpeter | or imx6qdl-sabresd.dtsi |
| 12:38 | jnettlet | oh that is just the device enumeration |
| 12:39 | vpeter | So just starts with 0 on first and add 1 on second? |
| 12:39 | jnettlet | yep |
| 12:40 | jnettlet | you don't have to add them, then they will be auto-enumerated I believe |
| 12:40 | jnettlet | but sometimes they need to come up in a specific order |
| 12:40 | vpeter | Understand. ty. |
| 14:37 | zrasim | Hello! Havung trouble with runing bcm4330 on my imx6 solo microsom. I am using Yocto, kernel driver compiled as built-in, B43_SDIO. But there is no wlan iface in ifconfig output. "dmesg | grep -i brcm" gives "brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50" |
| 14:38 | Artox | zrasim: I wonder if the firmware is missing |
| 14:38 | Artox | try |
| 14:38 | Artox | dmesg | grep firm |
| 14:39 | Artox | though yocto should have the firmware .... hmmm |
| 14:40 | zrasim | "[ 0.454246] imx-sdma 20ec000.sdma: firmware not found" |
| 14:40 | Artox | :/ |
| 14:40 | Artox | thats not an issue as far as I know |
| 14:40 | Artox | then idk |
| 14:40 | zrasim | but /lib/firmware/imx/sdma/sdma-imx6q.bin is present |
| 14:41 | Artox | yeah, the message is because sdma firmware has to be loaded before userspace is up |
| 14:41 | Artox | so its not happening |
| 14:41 | Artox | not a big deal for your wifi |
| 14:44 | zrasim | "/lib/firmware/brcm/brcmfmac4330-sdio.bin" is present too |
| 14:45 | Artox | there should also be a .txt in there |
| 14:45 | zrasim | yes |
| 14:52 | zrasim | hmm, in device-tree found only interface preparing, nothing that likes "compatible = "brcm,bcm4330". Is it ok? |
| 15:01 | zrasim | looks like not neaded... |
| 15:04 | zrasim | will try to enable debug output of brcm driver, may be will get some additional info |
| 16:05 | jnettlet | mk01, do you stop the renderer when the screen is blanked? |
| 16:08 | zrasim | hmmm... i don't know why, but building this driver as builtin was bad idea |
| 16:09 | zrasim | i am about broadcom 4330 |
| 16:11 | zrasim | as module it works fine |
| 16:27 | mk01 | jnettlet: are you asking generally about xbmc's rendering, or it's gles renderer implementation or imxcodec's process() (or specifically because of sync & flip?) ? |
| 16:28 | jnettlet | mk01, all of the above. just because when the screen blanks power usage actually goes up because the GPU can render faster because IPU isn't limiting it. |
| 16:30 | mk01 | ok, so your question goes to case of cable disconnect / connect ... ? |
| 16:30 | jnettlet | well similar to that yes. |
| 16:31 | jnettlet | I don't know where blank/unblank is tracked in kodi |
| 16:31 | mk01 | NOWHERE |
| 16:31 | jnettlet | blah |
| 16:31 | mk01 | that's why i'm asking what case you are concerned |
| 16:32 | mk01 | jnettlet: |
| 16:32 | jnettlet | I think xbmc's rendering in general. |
| 16:32 | mk01 | this is why implemented the hdmi cable changes tracking .... (to take down rendering, refresh resolutions etc) |
| 16:35 | mk01 | this nicely works with the latest work on mxc-hdmi (where cable_connected/disconencted) |
| 16:36 | jnettlet | and you are listening to udev events for the hdmi cable state right? |
| 16:36 | mk01 | but generally speaking of such (IMHO mandatory enhancements), there was never two side understanding on that (me speaking to Koying for example) |
| 16:37 | mk01 | ((understanding meaning = 'I don't see a use case here') |
| 16:37 | mk01 | jnettlet: yes, udevmonitor |
| 16:39 | mk01 | basically the design is like this: |
| 16:40 | mk01 | the is vanilla function rendergui(true/false) which is causing Render() ((in main thread)) to return immediatelly |
| 16:41 | mk01 | I added additional wrapper standbyscreen() |
| 16:41 | mk01 | and this is called from within udevmonitor or cecmonitor |
| 16:42 | mk01 | ((udev on disconnect/connect events, cec on active/inactive events)) |
| 16:42 | mk01 | so whenever Kodi has _inactive_ output (harware wise or even just cec wise) |
| 16:42 | mk01 | rendering doesn't occur |
| 16:43 | Artox | mk01: that actually sounds pretty horrible to me. I guess kodi devs dont care about screen blanking? (e.g. x11, screensaver?) |
| 16:44 | mk01 | Artox: I really never digged into x11 part, so I can't tell here. |
| 16:44 | Artox | I see |
| 16:45 | Artox | because I'd imagine bnoth x11 and windows would benefit from pausing a renderthread when screen is blank |
| 16:45 | Artox | and I mean real pausing, not the while(true) continue; |
| 16:47 | mk01 | Artox: ehm, Kodi's design is NOT event based on in the main thread (Process()) |
| 16:48 | Artox | Oh ;/ |
| 16:48 | Artox | *Thats* bad |
| 16:48 | Artox | on the other hand |
| 16:49 | Artox | I dont think its too hard to listen for one event |
| 16:49 | Artox | on java I'd do synchronized(BlankListener) { while(BlankListener.isBlanked()) BlankListener.wait(); }; |
| 16:49 | Artox | just in the middle of any mainloop |
| 16:50 | Artox | .wait() is so nice to actually pause the thread |
| 16:50 | jnettlet | well I guess in theory most tv's should provide cec events when you switch off the input |
| 16:51 | mk01 | jnettlet: yes, this is why one call to renderegui(false) is going from CEC (active/inactive/standby events) |
| 16:52 | jnettlet | mk01, yeah so really what we want to do then is stop rendering, which you are doing, but also to blank the fbdev. |
| 16:52 | jnettlet | that will save us power while not in use. |
| 16:54 | mk01 | jnettlet: yes, this is no problem. I can add call from the wrapping standbyscreen() to egl->showwindow(false) |
| 16:54 | jnettlet | cool, that will also then take effect if you choose blank screen as the screen saver mode |
| 16:55 | jnettlet | unfortunately I don't think we can get wakeup events from CEC, so using suspend to RAM isn't an immediate option. |
| 16:55 | jnettlet | I need to open a question in the community forum to figure that out. |
| 16:56 | jnettlet | mk01, I would also recommend you set /sys/class/scsi_host/host0/link_power_management_policy to min_power in your distro. This saves another 60+ mA's about 20% at idle. |
| 16:57 | jnettlet | this should work fine, it only breaks S/R which we can't use. |
| 16:57 | mk01 | .... stupid question - what is S/R ? |
| 16:58 | jnettlet | suspend resume |
| 16:58 | mk01 | ah sure ok |
| 16:58 | jnettlet | I haven't figured out if CEC events can wake the cpu. so far I don't think so, but I may be missing something. The docs are contradicting. |
| 16:59 | jnettlet | but until we get that working, we can. blank the screen, put the sata in low power, and then suspend the disk and get our idle power usage below 1Watt |
| 16:59 | jnettlet | which is not bad |
| 17:00 | mk01 | hmm I have to get a power usage meter .... |
| 17:00 | mk01 | have one , but it has only USB A connectors |
| 17:01 | mk01 | so can't hook it up between new microUSB connectors supplying power |
| 17:01 | mk01 | did you got FEC on magicpacket to wake CPU up ? |
| 17:02 | mk01 | re 'did you GET' |
| 17:03 | jnettlet | mk01, I haven't tested it yet. I assumed it worked. |
| 17:03 | mk01 | ok, will retest again |
| 17:03 | jnettlet | I did get SmartEEE stable. Haven't had any link drops in 2 days. |
| 17:03 | jnettlet | that also saves another 60-80mA for gigabit connections |
| 17:04 | mk01 | last time I spent some hours on that, I got kernel & board to nicelly suspend and wakeup (on timed event) |
| 17:04 | mk01 | but never via FEC |
| 17:04 | mk01 | (((and double checked that the driver has the proper code /patches))) |
| 17:05 | jnettlet | well if you S/R with Sata plugged in then it works but you still draw a lot of power. Still at about 120mA's |
| 17:05 | jnettlet | without Sata you can get down to 50mA |
| 17:10 | mk01 | jnettlet: regarding the black screensaver triggering the whole render savings: |
| 17:11 | jnettlet | yep |
| 17:11 | mk01 | ((just thinking how to tell it shortly)) |
| 17:12 | mk01 | - I will retest the hooks again (I only recently reverted the code which was managing screensaver in the context of cec/hdmi/blanking events). |
| 17:13 | jnettlet | oh there were hooks. okay I can look through your branch |
| 17:13 | mk01 | reverted mine own commit after the new mxc-hdmi commits |
| 17:13 | mk01 | problem is the screensaver code in general in kodi is overly complicated |
| 17:14 | mk01 | (to my taste) |
| 17:14 | jnettlet | yep ether-wake doesn't work at all. |
| 17:15 | mk01 | and as we changed the mxc hdmi and some mine other changes - I was simply looping sleeping / waking process over and over |
| 17:16 | mk01 | but for sure it makes sense - only need to look on the process from the top again |
| 17:17 | jnettlet | mk01, and I think I have a bunch of performance issues sorted and just need to clean up the code. |
| 17:17 | mk01 | I was managing that from inside the wrapper snadbyscreen(), but perhaps I will just (as is from udevm and cec) add calls back to it from screensaver code (after checking it is set to BLACK) |
| 17:17 | mk01 | jnettlet: btw I have not forgotten about the re-submit of codecimx cleanup/update |
| 17:18 | mk01 | just realised that Koying reposted own PR from April |
| 17:18 | jnettlet | the problem is that for de-interlacing and other scaling/cropping etc concerning VPU -> IPU we need to use the VPU's special tiled formats and then pass them over the VDOA to handle and make ready for the IPU to display |
| 17:19 | jnettlet | using this fastpath will keep de-interlaced content from slowing down once the gui is displayed. |
| 17:19 | mk01 | that PR is completely repositioning the IMX relevant code to other files / parts - and I don't want to rehunk all the code now and then again in a week |
| 17:20 | jnettlet | okay. Once you get that sorted let me know and I will base my stuff on top of yours. |
| 17:20 | mk01 | ok |
| 17:20 | jnettlet | I also don't have time for re-implementing things 2-3 times |
| 17:20 | mk01 | ok so agreed |
| 17:21 | mk01 | inbetween I will sort out the black screensaver |
| 17:22 | mk01 | then rebase the code, squash commits regarging the renderer<>screen stuff we discussed and send you links. that you can take look or easy re-use |
| 17:22 | jnettlet | I will take a look at the ethernet magic-packet problem. Maybe that is the same problem as the CEC wakeups |
| 17:22 | jnettlet | cool thanks |
| 17:23 | jnettlet | mk01, this might not effect you much because I believe you only use the VPU for decoding, but I did find that at 352Mhz the VPU was unstable while encoding. |
| 17:23 | jnettlet | so I have dropped it down to 327Mhz and both encoding and decoding seem happy. |
| 17:26 | mk01 | jnettlet: i have seen that in logs and even responded ;) |
| 17:27 | mk01 | yes, I just reverted the one line from you commit back as it was (change of clk_parent for vpu happens only if vpu352=1). |
| 17:27 | mk01 | so I kept the parent like you changed it , just it want happen unconditionally |
| 17:28 | mk01 | want = wont |
| 17:28 | jnettlet | I pushed the change. Basically nothing else uses that 352pfd, so you can just change the rate of it. |
| 17:29 | mk01 | wait will fetch your tree |
| 17:31 | jnettlet | oh, that reminds me. I think I still want to clock down the iMX6S/DL to 305Mhz |
| 17:40 | mk01 | (just looking at clk-imx6 how looks the code now) |
| 17:41 | mk01 | ok I see so unconditional change to 352pfd, 327mhz unconditional and 352 if vpu352=1 - and you consider 327->305, right ? |
| 17:42 | jnettlet | mk01, just pushed the patch for the imx6S/SL to 305...really 306.5 |
| 17:43 | jnettlet | I think those clockings all make sense. |
| 17:46 | mk01 | I changed the original vpu352 patch to be no CONFIG_ parameter but kernel cmd line parameter - so I was rather not touching the default setup for now (as user could always just put vpu352=1 into kernel boot params (so user's responsibility). I was a bit scary to follow or the clock changes - maybe you remember the one FSL patch which set quite insane clock for gpu2d core. |
| 17:46 | mk01 | and I have the feeling the code is still valid in FSL trees :-/ |
| 17:47 | jnettlet | it is. I have fixed it in my clock tree |
| 17:48 | jnettlet | I don't like how they do 352mhz support. it is dumb and pointless. Not using the 352pfd makes no sense at all. |
| 18:04 | mk01 | we are all humans, I suppose. ... (but sure to miss this clean solution and mis-use 396pfd, re-clock it... specially when other clocks depends on it too - is illogical) |
| 18:05 | mk01 | I see some new commit around FEC as well. (so to be clear, when I was trying the wakeup last time,,, it was long before that) |
| 18:08 | mk01 | (((with extra patching from some vanilla tree commits adding wakeup awareness to FEC - so don't be hunting ghosts - I will just retest during weekend))) |
| 18:10 | mk01 | ad "mmc: core: Don't fail UHS transition if host max_current fails." I had this issue on 4.1.y too, and wanted you ask about that. but you sorted this out I see |
| 22:00 | vpeter | jnettlet: Can you set in your kernel config for openelec also CONFIG_SENSORS_GPIO_FAN=m ? |
| 22:03 | vpeter | About openelec: I assume some packages must be upgraded to use with this kernel? |