ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
stikonas has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
lurchi__ is now known as lurchi_
lurchi_ has quit [Quit: Konversation terminated!]
lurchi_ has joined #linux-rockchip
archetyp` has quit [Quit: Leaving]
lurchi__ has joined #linux-rockchip
lurchi_ has quit [Ping timeout: 265 seconds]
jagan has joined #linux-rockchip
stikonas has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 265 seconds]
kevery1 is now known as kevery
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 264 seconds]
leming has quit [Ping timeout: 256 seconds]
leming has joined #linux-rockchip
camus has quit [Ping timeout: 265 seconds]
camus has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 250 seconds]
kevery1 is now known as kevery
<dvergatal> kevery: i have a question about NDA with rockchip because our company would like to sign it and no one is answering to us
<dvergatal> kevery: who should we talk to?
kevery has quit [Ping timeout: 264 seconds]
archetyp has joined #linux-rockchip
<mmind00> dvergatal: I think it might be easier to write an email to Kever Yang <kever.yang@rock-chips.com> ... a public irc channel might not be the right place to handle these things ;-)
<mmind00> dvergatal: Kever is normally really great in bringing the relevant people together :-)
<mriesch> hi mmind00
<mmind00> mriesch: heya :-)
<mriesch> is it a good time to ask a question about clocks? :-) i am experiencing some strange ethernet behaviour on the quartz64
<mmind00> mriesch: just ask and we'll see where we end up ;-)
<mriesch> right :-) i am running barebox and would like to boot via nfs. i found that dhcp did not work in barebox and found that removing <&gmac1_clkin> from the assigned-clock-parents fixed it somehow
<mriesch> then, the kernel did boot but ran into the same problem
<mriesch> apparently having this clock parent or not sets a mux in order to switch between external and internal clocks.
<mriesch> but actually i am not sure. what is really the consequence of removing this parent?
<mmind00> the gmac clock can come from two sources normally ... from the cru itself via dividers (mostly for rmii) or from an external 125MHz source (for rgmii)
<mmind00> that parent assignment makes the gmac use the external clock input ... not sure if that is a separate chip or something
<mmind00> mriesch: I had that issue in the past, that the clock was generated from _inside_ the phy and routed to the soc
<mriesch> in the case of the quartz64 it should be generated by the phy
<mmind00> mriesch: so something had to turn it on ;-) ... which in turn the vendor u-boot might actually do already
<mmind00> mriesch: see for example https://lkml.org/lkml/2020/6/18/359 and https://lists.denx.de/pipermail/u-boot/2020-June/415553.html ... for some stalled attempts for another phy
<mriesch> that is the clock generation in the phy needs some attention. and the routing should work (at least there is a change with and without the parent)
<mriesch> s/is/means
<mmind00> mriesch: yep ... so I guess you're suffering from barebox :-P ... i.e. the vendor u-boot probably turns on the clock inside the phy in some hackish way, while barebox does not
macromorgan has quit [Quit: Leaving]
<mmind00> but that needs some more general love ... as that static clock definition for gmac1_clkin is then definitly wrong and should be defined correctly
<mriesch> it would explain we no one complained so far, yes
<dvergatal> mmind00: u think?
<mriesch> as to the static clock definition, is this coincidence or is the exact naming important to achieve matching?
<dvergatal> mmind00: because nobody answers our emails from rockchip
<mmind00> dvergatal: did you write Kever or someone else? My past experience is that Kever is pretty good at poking the right poeple, but the rest of Rockchip is not that good at responding
<dvergatal> mmind00: nope not kever, some other guys can't remember their names
<dvergatal> mmind00: ok i'll give a ry with kever
<mmind00> mriesch: you can ask questions ;-) ...judging by the clock-output-names = "ext_gmac"; in my patch series, I guess the naming matters, as that connection is done lazily
<mmind00> mriesch: which in this case is even helpful, as the phy will probe way later than the cru itself
<mmind00> mriesch: gmac1_clkin in the rk3568 case I guess
<mmind00> mriesch: and yep, looking at the clock driver - the naming is important as expected
<dvergatal> mmind00: btw. i have verified uboot and optee together and this is really strange because with optee 3.7.0 and uboot 2022.01-rc2 all is working and with optee 3.15.0 and the same uboot it hangs but if i switch uboot to 2020.04 the optee 3.15.0 is working
<dvergatal> mmind00: i think i need to investigate which commit has made such regression
<mmind00> mriesch: background for that is, that some clocks in Rockchip SoCs have circular dependencies ... you need the cru to probe the gmac, but you need the gmac to probe the eth-phy ... same for the usb phy
<mmind00> dvergatal: 2 years or changes ... that's at least an afternoon ;-)
<dvergatal> mmind00: :D yeah
<dvergatal> mmind00: i'll check that on my free time:P
<clarity> how much does free time cost and where can i buy it?
<mriesch> mmind00: oh yes, asking questions is something i am particularly good at :-) and once again, it is all about quantity.
<mriesch> i'll check out what the phy does. thanks meanwhile for the pointer
<mriesch> mmind00: <columbo mode on>just one more thing...
<mmind00> :-D
<mriesch> this xpcs clock is not really used, is it?
<mriesch> "pclk_xpcs" -> it appears in the sdk and slipped into rk3568.dtsi, but i guess we can remove it during the next cleanup or so?
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #linux-rockchip
<mmind00> mriesch: probably ... if it's not in the binding, it shouldn't be there in the first place
<mriesch> ok! thx
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Read error: Connection reset by peer]
jagan has quit [Quit: Client closed]
jagan has joined #linux-rockchip
DavidHeidelberg has quit [K-Lined]
psydroid has quit [K-Lined]
nergzd723[m] has quit [K-Lined]
samueldr has quit [K-Lined]
amstan has quit [K-Lined]
RayyanAnsari[m] has quit [K-Lined]
LinuxHackerman has quit [K-Lined]
MatrixTravelerbo has quit [K-Lined]
ServerStatsDisco has quit [K-Lined]
csrpi[m] has quit [K-Lined]
Max1Truc[m] has quit [K-Lined]
maxim[m] has quit [K-Lined]
lurchi_ is now known as lurchi__
psydroid has joined #linux-rockchip
samueldr has joined #linux-rockchip
amstan has joined #linux-rockchip
nergzd723[m] has joined #linux-rockchip
DavidHeidelberg has joined #linux-rockchip
maxim[m] has joined #linux-rockchip
MatrixTravelerbo has joined #linux-rockchip
LinuxHackerman has joined #linux-rockchip
ServerStatsDisco has joined #linux-rockchip
RayyanAnsari[m] has joined #linux-rockchip
csrpi[m] has joined #linux-rockchip
Max1Truc[m] has joined #linux-rockchip
warpme__ has quit [Ping timeout: 256 seconds]
norris has quit [Ping timeout: 268 seconds]
dianders has quit [Read error: Connection reset by peer]
daniels has quit [Read error: Connection reset by peer]
eballetbo has quit [Read error: Connection reset by peer]
arnd has quit [Ping timeout: 250 seconds]
tucanae47_ has quit [Read error: Connection reset by peer]
norris has joined #linux-rockchip
arnd has joined #linux-rockchip
daniels has joined #linux-rockchip
dianders has joined #linux-rockchip
eballetbo has joined #linux-rockchip
tucanae47_ has joined #linux-rockchip
warpme__ has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
psydroid has quit [Quit: Client limit exceeded: 20000]
MatrixTravelerbo has quit [Quit: Client limit exceeded: 20000]
ServerStatsDisco has quit [Quit: Client limit exceeded: 20000]
DavidHeidelberg has quit [Quit: Client limit exceeded: 20000]
LinuxHackerman has quit [Quit: Client limit exceeded: 20000]
samueldr has quit [Quit: Client limit exceeded: 20000]
nergzd723[m] has quit [Quit: Client limit exceeded: 20000]
<dvergatal> clarity: i dunno:P but i would like to buy it too o/
psydroid has joined #linux-rockchip
samueldr has joined #linux-rockchip
LinuxHackerman has joined #linux-rockchip
ServerStatsDisco has joined #linux-rockchip
MatrixTravelerbo has joined #linux-rockchip
nergzd723[m] has joined #linux-rockchip
DavidHeidelberg has joined #linux-rockchip
jagan has quit [Quit: Client closed]
vagrantc has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
jagan has joined #linux-rockchip
stikonas_ is now known as stikonas
robmur01 has quit [Ping timeout: 265 seconds]
jagan has quit [Quit: Client closed]
UndrWater has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 265 seconds]
stikonas_ is now known as stikonas
UndrWater has joined #linux-rockchip
lurchi__ is now known as lurchi_
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #linux-rockchip
warpme__ has quit [Quit: Connection closed for inactivity]