ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
field^Zzz3 has quit [Ping timeout: 244 seconds]
CarlosEDP has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 256 seconds]
kevery has quit [Read error: Connection reset by peer]
return0e_ has joined #linux-rockchip
return0e has quit [Ping timeout: 260 seconds]
niceplace has quit [Ping timeout: 256 seconds]
niceplaces has joined #linux-rockchip
kevery has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-rockchip
vstehle has joined #linux-rockchip
DuClare has quit [Ping timeout: 260 seconds]
return0e has joined #linux-rockchip
return0e_ has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-rockchip
drrty has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has quit [Ping timeout: 272 seconds]
DuClare has joined #linux-rockchip
new_geek is now known as stefan_
stefan_ is now known as new_geek
JohnDoe_71Rus has joined #linux-rockchip
new_geek has quit [Ping timeout: 256 seconds]
chiastre_ has quit [Ping timeout: 240 seconds]
chiastre_ has joined #linux-rockchip
chiastre_ has quit [Ping timeout: 240 seconds]
chiastre_ has joined #linux-rockchip
kevery has quit [Ping timeout: 272 seconds]
<nomis> robmur01: ok, some insights: My 32khz clock goes missing. It is there for a short while at startup but then disappears.
<nomis> robmur01: do you use it in your device trees? Is it defined in your device trees? Do other nodes in your devicetree reference the xin32k-node?
<nomis> the pin seems to be configured to the correct function.
<nomis> I wonder if the 5.4 kernel tries to manage this now. I.e. there is no user for this clock mentioned in the devicetree, hence it gets disabled.
matthias_bgg has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-rockchip
<nomis> meh, except for the pinmuxing I am unable to find any references to the 32k functionality in the datasheet.
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-rockchip
PoueT has quit [Read error: Connection reset by peer]
PoueT9 has joined #linux-rockchip
adjtm has joined #linux-rockchip
mazema has joined #linux-rockchip
adjtm_ has quit [Ping timeout: 256 seconds]
sb35 has joined #linux-rockchip
dlrobertson has quit [Quit: WeeChat 2.8]
vagrantc has joined #linux-rockchip
PhoenixMage has quit [Ping timeout: 256 seconds]
PhoenixMage has joined #linux-rockchip
adjtm_ has joined #linux-rockchip
adjtm has quit [Ping timeout: 256 seconds]
sb35 has quit [Ping timeout: 240 seconds]
kevery has joined #linux-rockchip
maze-BUG has quit [Ping timeout: 264 seconds]
new_geek has joined #linux-rockchip
<nomis> robmur01: ok, seems at some point the bit 11 in CRU_CLKGATE_CON0 gets set to one. No clue yet as of why
mps has quit [Ping timeout: 256 seconds]
mps has joined #linux-rockchip
mazema has quit [Remote host closed the connection]
mazema has joined #linux-rockchip
mazema has quit [Client Quit]
new_geek has quit [Quit: Konversation terminated!]
maze-BUG has joined #linux-rockchip
kevery has quit [Ping timeout: 258 seconds]
drrty has joined #linux-rockchip
drrty has quit [Remote host closed the connection]
vicencb has joined #linux-rockchip
field^Zzz3 has joined #linux-rockchip
<robmur01> nomis: yeah, the kernel will shut off clocks it thinks aren't needed - pass "clk_ignore_unused" on the command line to prevent that
<robmur01> clk/clk_summary in debugfs will show what it thinks is used or not
<robmur01> for added weirdness, connecting a display might make things work, given that HDMI happens to reference the 32K clock
<nomis> ah, hah. Yeah. I don't yet have tried to dabble with the graphics part...
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<nomis> I did an oscilloscope trace today of the clock pin and the power pin on the module. If you're curious: https://imagebin.ca/v/5Lqd1P6zmzLE
<tuxd3v> can this be the source of not getting HIFI analog audio on Rockpro64 ?
<tuxd3v> [ 4.204055] es8316 1-0011: Failed to get IRQ 0: -22
<nomis> tuxd3v: clock stuff seems to be fairly cpu specific, so it is hard to say. Although you might want to check if your DAC depends on an external clock and check that the clock is actually available on the resp. pin.
<nomis> but "Failed to get IRC" sounds weird. -22 is -EINVAL, maybe you have an error in your IRQ specification in the devicetree.
<nomis> are the schematics of a rockpro64 available?
<tuxd3v> yes they are its revision 2.1
<tuxd3v> but I don't know how to interpret it..
vicencb has quit [Ping timeout: 246 seconds]
<nomis> tuxd3v: I just took a glance of the es8316 datasheet. It certainly can't do anything with the low frequency 32khz clock I have troubles with.
<nomis> "The device can work either in master clock mode or slave clock mode. In slave mode, LRCK and
<nomis> SCLK are supplied externally, and LRCK and SCLK must be synchronously derived from the
<nomis> system clock with specific rates. In master mode, LRCK and SCLK are derived internally from
<nomis> device master clock."
<nomis> not sure how to interpret that for now.
<tuxd3v> nomis thanks
<nomis> tuxd3v: the schematics have that on page 28 (the "CODEC" section).
<nomis> MCLK is connected to I2S from the CPU (and there is a resistor inbetween, so you might be able to check there for the clock with an oscilloscope)
<nomis> The connection pops up again on page 16, lower left block. ("I2S_CLK"), which is the GPIO4/A0-Pin.
<nomis> You now can check on the running system, ob the pin indeed is muxed to the i2s-clk functionality. And if it is (needs an appropriate pinctrl section) and doesn't give a clock anyway you might want to check if the respective clocks are gated (they shouldn't be).
<nomis> if you're really desparate use a tool like devmem2 to actually verify that the register contents of the GPIO/clock Registers is in line with what you expect.
<nomis> But to get to that point you need to dig through the CPU datasheet to figure out what value to expect in which register.
<nomis> but wait, didn't you say earlier that you were able to control mixer settings for this device? If that is the case then the clock for the DAC is not your problem.
<robmur01> tuxd3v: that probably just means that there's no IRQ specified in DT. AFAICS it's not fatal and the driver will continue to register without it
<robmur01> could well be that the codec's own IRQ isn't wired up at all on RockPro64 - I know that's the case on my board
<nomis> there os one GPIO-pin of the codec (apparently for headphone-detection) connected to GPIO0_B0
<nomis> actually it is also connected to the headphone connector, so it might be an input for the codec as well.
field^Zzz3 has quit [Ping timeout: 256 seconds]
ldevulder has joined #linux-rockchip
ldevulder_ has quit [Ping timeout: 264 seconds]
vagrantc has quit [Quit: leaving]
matthias_bgg has quit [Quit: Leaving]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #linux-rockchip