<micken>
anarsoul: I *think* I have the same problem, seems like running linux first fix my problem
<micken>
anarsoul: I tried before to sort out which pmic reg that is connected to vop and or hdmi phy, but never figured it out
adjtm_ has quit [Quit: Leaving]
<micken>
anarsoul: bah reading power tree gives me nada
_whitelogger has joined #linux-rockchip
stikonas has joined #linux-rockchip
<micken>
anarsoul: 0x10 and forward shows same after reset and from power off
stikonas has quit [Remote host closed the connection]
<micken>
I believ that hdmi phy reg is correct, otherwise I shouldnt be able to use it at all
<micken>
but vopbig might be wrong
<micken>
should be pf_vo
<micken>
pd_vo
<micken>
and pd_hdcp for hdmi
rkos has quit [Quit: Lost terminal]
ayaka has quit [Ping timeout: 265 seconds]
vicencb has joined #linux-rockchip
ayaka has joined #linux-rockchip
ayaka has quit [Ping timeout: 246 seconds]
ayaka has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
vicencb has joined #linux-rockchip
ayaka has quit [Ping timeout: 276 seconds]
ayaka has joined #linux-rockchip
field^Mop has joined #linux-rockchip
leah2 has quit [Ping timeout: 250 seconds]
leah2 has joined #linux-rockchip
aalm has joined #linux-rockchip
stikonas has joined #linux-rockchip
<micken>
sigh
ayaka has quit [Ping timeout: 265 seconds]
ayaka has joined #linux-rockchip
nashpa has quit [Ping timeout: 246 seconds]
nashpa has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
jailbox has quit [Ping timeout: 268 seconds]
ldevulder__ has joined #linux-rockchip
ldevulder_ has quit [Ping timeout: 240 seconds]
nashpa has quit [Ping timeout: 268 seconds]
nashpa has joined #linux-rockchip
<anarsoul>
mmind00: I'm not sure if anyone reported that but rockchip-iommu driver throws a WARN "WARNING: CPU: 5 PID: 1 at drivers/iommu/rockchip-iommu.c:529 rk_iommu_irq+0x140/0x348" on shutdown/reboot
<anarsoul>
also it often oopses, so board can't be reloaded or powered off
<anarsoul>
that's on 5.3, I'll test 5.4-rc later today
<mmind00>
anarsoul: not that I know of ... there are sometimes issues with the iommu driver, but I can't at least remember something from the 5.4 cycle - at least on my boards
<anarsoul>
I hope it's fixed in 5.4
<anarsoul>
:)
<anarsoul>
btw, I assume that rockchip-drm hanging system when built-in is a known issue? it works fine as a module
<stikonas>
anarsoul: I wouldn't assume bugs as known issues...
<mmind00>
anarsoul: I guess not widely known ... at least new for me
<anarsoul>
I saw some commits that are supposed to fix it but looks like they're not
<stikonas>
anarsoul: oh thanks, I can try to test it too
<stikonas>
although, I'm not currently subscribed to that list, so can't reply to your mail
<mmind00>
at least the iommu warning comes from the pm_runtime_get_if_in_use ... it returns an error when runtime_pm is disabled ... but so far I fail to see any pm_runtime_disable in the iommu driver
<mmind00>
hmm, ok pm_runtime_force_suspend() does disable runtime-pm, but then it should've freed the irq before that already ... maybe a weired race condition with the irq routine?
<anarsoul>
mmind00: I'm not familiar with this code, sorry
<micken>
while you are here, which pmic regs is for vop/hdmi. I get vd_vo and vd_hdcp , but I don't know where to find them and if those are the *only* regs involved. HDMI phy works , which suggests that it gets power. Image output works good 30% of bootups, but get blurry the rest. If first booting linux, then reset and then riscos th image is perfect..
<anarsoul>
so yeah, looks like driver didn't remove irq
<anarsoul>
and it fired
<anarsoul>
:)
<anarsoul>
micken: hdmi is digital, so I don't get how you can get blurry image
<anarsoul>
maybe you have some post processing occasionally enabled?
<anarsoul>
e.g. deinterlacer or something like that (not sure if rk3399 has it though)
<micken>
anarsoul: it is like pixel get doubles
<micken>
but not extending length
<micken>
it seems random :/
<micken>
but always works after linux
<anarsoul>
maybe there's some scaler? :)
<micken>
anarsoul: so I got the idea of pmic from our recent conversations
<anarsoul>
I doubt it's pmic. With hdmi you either get a picture or not
<micken>
anarsoul: yea but why kick in it is random
<anarsoul>
micken: likely you leave it uniniailized?
<micken>
ram timings? , but then most other stuff would go wrong
<micken>
basicly I do the frambuffer from : either a os allocated ram area or a fixed address and write that to vop_big yrgb win0
ayaka has quit [Ping timeout: 252 seconds]
<micken>
both ways fail the same way, even if the framebuffer just is a bitmap image
ayaka has joined #linux-rockchip
<stikonas>
anarsoul: am I missing osmething, or did you forget to git add some files in your patch?
<anarsoul>
hm
<anarsoul>
let me check it
<stikonas>
configs/rockpro64_rk3399.h is not in
<anarsoul>
yeah
<anarsoul>
sorry
<anarsoul>
will resend
<stikonas>
and also rebase on top of master maybe...
<anarsoul>
definitely looks like some pixels are misplaced
<anarsoul>
is there any kind of lookup table for reordering pixels?
<anarsoul>
stikonas: did it work? :)
<stikonas>
anarsoul: no...
<stikonas>
just tried
<stikonas>
still can't detect my USB hard drive
<anarsoul>
are you sure you flashed it?
<stikonas>
yes, it reports today's date
<stikonas>
in version field
<anarsoul>
make sure you ran 'make rockpro64_rk3399_defconfig'
<stikonas>
well, I used menuconfig to pick the board, maybe I need to run defconfig...
<anarsoul>
(or check what's your target in .config)
<micken>
anarsoul: no lut. (but there is a lut setting in win0, dunno what it do) and it works sometimes. The image I linked is just memcopied out to the yrgb framebuffer
<anarsoul>
stikonas: you should have "CONFIG_TARGET_ROCKPRO64_RK3399=y" set
<stikonas>
yes
<stikonas>
I have it set
<anarsoul>
hmm
<stikonas>
maybe it helps up to certain power level?
<stikonas>
hmm
<anarsoul>
maybe?
<anarsoul>
it works pretty reliably for me now
<stikonas>
it still works with my usb flash...
<stikonas>
anarsoul: my external SSD also doesn't work
<micken>
ok. so new findings... running linux before is no guaranty that it will work.. if just press reset and not powercycle riscos I end up with about 90% success rate (compared to ~30 with powercycle)
<micken>
i wish there was a consistant error
<anarsoul>
:(
<anarsoul>
you need some expert in rk3399 display hardware
<micken>
within a week or so I can share some source
<micken>
most of it is assembler
<anarsoul>
ouch
vicencb has joined #linux-rockchip
BenG83 has joined #linux-rockchip
vagrantc has joined #linux-rockchip
adjtm has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<anarsoul>
stikonas: do you also have a lot of issues with emmc on rockpro64?
<anarsoul>
it boots off emmc 1 out of 4 times
field^Mop has quit [Ping timeout: 268 seconds]
<stikonas>
anarsoul: I had, but I swapped it with another emmc and they are gone
<stikonas>
I had something like that with emmc shipped by pine64 store
<anarsoul>
:\
<stikonas>
but the one I had from odroid (my odroid-u2 recently died) works fine
<anarsoul>
I have some other emmcs but they're all from pine64 store :)
<stikonas>
I tried patches from 5.4 but didn't help...
<anarsoul>
yeah
<stikonas>
anarsoul: I had some kernel patch that helped when Linux kernel booted