scelestic has quit [Remote host closed the connection]
cristian__c has joined #linux-rockchip
drrty has quit [Quit: Leaving]
cristian_c has quit [Ping timeout: 245 seconds]
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
cristian__c has quit [Ping timeout: 248 seconds]
cristian_c has joined #linux-rockchip
cristian__c has joined #linux-rockchip
cristian_c has quit [Ping timeout: 272 seconds]
cristian_c has joined #linux-rockchip
cristian__c has quit [Ping timeout: 248 seconds]
cristian__c has joined #linux-rockchip
cristian_c has quit [Ping timeout: 248 seconds]
leming has quit [Ping timeout: 244 seconds]
leming has joined #linux-rockchip
_whitelogger has joined #linux-rockchip
vstehle has joined #linux-rockchip
buzzmarshall has quit [Remote host closed the connection]
yann has quit [Ping timeout: 272 seconds]
BenG83 has quit [Ping timeout: 268 seconds]
cristian_c has joined #linux-rockchip
cristian_c has quit [Ping timeout: 268 seconds]
cristian_c has joined #linux-rockchip
field^Zzz1 has joined #linux-rockchip
somy has quit [Ping timeout: 248 seconds]
levd has joined #linux-rockchip
default__ is now known as ldevulder
<levd>
Hi all, I try U-Boot v2019.04 on Firefly-RK3399 and failed during kernel booting. After git bisect, I find the commit e7ae4cf27a6d5837cb5e868712cdaa61d3ceb5e0 (which is adding common rockchip pinctrl driver) is where the problem starts to emerge.
<levd>
After some trial and error, it seems that the new pinctrl driver get rid of the request op, hence in board/rockchip/evb_rk3399/evb-rk3399.c, pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0) will fail, which lead to the kernel hang.
<levd>
Adding a dummy request function (return 0) to rockchip_pinctrl_ops solves the kernel hang. But I wonder why no other RK3399 boards experience the same problem. If I'd like to write a patch to address this, a dummy request function is not proper IMO.
cristian__c has joined #linux-rockchip
cristian_c has quit [Ping timeout: 246 seconds]
<levd>
Have written to the u-boot mail list asking for help.
<levd>
the mail is being held until the list moderator can review it for approval :)
<inode>
have you mentioned this problem in #u-boot?
jaganteki has joined #linux-rockchip
cristian_c has joined #linux-rockchip
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #linux-rockchip
cristian__c has quit [Ping timeout: 272 seconds]
vicencb has joined #linux-rockchip
cristian__c has joined #linux-rockchip
jelly has quit [Ping timeout: 248 seconds]
cristian_c has quit [Ping timeout: 245 seconds]
cristian_c has joined #linux-rockchip
cristian__c has quit [Ping timeout: 246 seconds]
jelly-home has joined #linux-rockchip
<mmind00>
levd: I think there were a number of fixup patches coming after that conversion, not sure if they're in .04 though
<inode>
mmind00: thanks for the "assigned-clocks" adjustment, i didn't know you could do this
<inode>
i've just reverted clk-rk3228.c, and taken your rk322x.dtsi adjustment for a rebuild but there's a syntax error detected by dtc
<mmind00>
inode: I may have messed something up ... that stuff was completely untested
<inode>
and it seems to be due to no definition of SCLK_HDMI_PHY include/dt-bindings/clock/rk3228-cru.h
<mmind00>
inode: I just found it way easier to show code than trying to explain what I wanted in a long text :-D
levd has quit [Quit: Connection closed for inactivity]
jaganteki has quit [Ping timeout: 256 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #linux-rockchip
<inode>
mmind00: unfortunately there is no hdmi output now
<inode>
if i look at: grep hdmiphy /sys/kernel/debug/clk/clk_summary
<inode>
hdmiphy and children are clocked at 24MHz instead of 148.5MHz
<mmind00>
inode: can you check the kernel log if it complains about something
<mmind00>
inode: just to check, the "hdmiphy_phy" clock is present in your clock-tree?
<inode>
mmind00: no complaints display related apart from drm_atomic_helper_wait_for_vblanks, which was also there prior my hardcoded clock reparenting
<mmind00>
inode: I was looking for complaints regarding the assigned-clocks stuff, like the clock-framework telling that something is not working right
<inode>
i can't see anything like that, but based on the clk_summary it appears that mux_hdmiphy_p (RK2928_MISC_CON BIT(13)) is still selecting 0 (xin24m) instead of 1 (hdmiphy pixel clock)
<inode>
sorry cancel the last line
<inode>
i can't see anything like that, but based on the clk_summary it appears that mux_hdmiphy_p (RK2928_MISC_CON BIT(13)) is still selecting 1 (xin24m) instead of 0 (hdmiphy pixel clock)
<inode>
^ this one is what i meant
<mmind00>
inode: hmmm ... could you try the following: drop the assigned-clocks stuff and and instead add the <&cru SCLK_HDMI_PHY> clock to the hdmi-node as "vpll" ... in theory that should make sure the hdmiphy-clock is at a matching rate, which includes re-parenting to the actually pll clock, due to the CLK_SET_RATE_PARENT for that clock