<robmur01>
JPEW: Great work! And that's a really nice writeup too - respect :)
<nomis>
argh. I think I found the root problem for my nonfunctional wireless module.
<nomis>
I was operationg under the assumption that it was connected to "sdio: dwmmc@ff510000", but it seems that it might be "sdmmc_ext: dwmmc@ff5f0000" - which apparently is not yet available by default in the mainline kernel.
<robmur01>
AFAIU it means pretty much what it says - it tried to tune the clock and couldn't find any setting that worked properly
<robmur01>
as to why, could be something to do with the clock driver, could be slightly wonky pinctrl, could possibly even be some arbitrary GRF magic
<nomis>
I discovered that I was might have been missing clk_32k/clk-32k-out . But the weird thing is, that these entries don't seem to be referenced anywhere in the dts-files I am looking for reference.
<nomis>
well. clk_32k_out is referenced in a weird way in the pinctrl-Block itself. Which feels wrong.
<nomis>
And there is a block xin32k, which is not referenced anywhere else, so I wonder if that is an artefact.
<robmur01>
beware that the SoC has its own 32KHz clock input for... stuff... which other than possibly being driven from the same source is unrelated
<robmur01>
wait, I may be getting mixed up there
<robmur01>
sorry, it's 3399 that takes its 32KHz from outside; 3328 appears to generate its own internally, and has a pin function for optionally outputting it
<nomis>
ok. Yeah, there is a pinctrl-block configuring this pin: <1 RK_PD4 RK_FUNC_1 &pcfg_pull_none>
<robmur01>
in the reference design, that's present as an alternative option to using the RK805's CLK32K to supply the wifi module
<nomis>
and it seems to become enabled by a "pinctrl-0"-property within the pinctrl-block - which seems odd.
<robmur01>
so your box probably is using it that way
<nomis>
I'd have expected that this clock would be referenced in the wireless-wlan or wireless-bluetooth block.
<robmur01>
meh, as long as *something* claims the config it'll work... ship it!
<robmur01>
if you want to be super-honest, I guess you can model clk32k_out with a fixed clock that claims the pinctrl for itself
<nomis>
that might be what was intended with this "xin32k" clock, but it doesn't reference the pinctrl block and doesn't seem to be referenced elsewhere.
<robmur01>
vendor DTBs: just hold your nose and wade on through ;)
<nomis>
robmur01: I am wondering: if the dwmmc@ff5f0000 is not referenced in the mainline kernel rk3328.dtsi, could that mean that it'd need some tweaking in the kernel driver to get it working?
<nomis>
or is it certain that this is the same function block as the other dwmmcs?
<nomis>
(I am a bit curious about the register adresses: dwmmc@ff500000, dwmmc@ff510000, dwmmc@ff520000 and dwmmc@ff5f0000? Huh?
<robmur01>
AFAICS the block itself is just another DesignWare MSHC instance, but as I said it's certainly possible that there might be mistakes in the clock, pinctrl, etc. drivers where they do SDMMC_EXT-related things
<robmur01>
if the initial low speed enumeration at least detects a card, but negotiating a higher-speed mode fails, try bumping up the drive strength for the clock/data pins (and make sure the pullup/down settings are right - if there are external pulls on the board you probably don't want the internal ones enabled as well)
armoon has joined #linux-rockchip
<robmur01>
and IIRC, don't trust that the upstream and downstream pinctrl drivers behave *exactly* the same way
<robmur01>
ISTR having to dredge through the 3.10 source to decode raw values for something or other
mnemoc has joined #linux-rockchip
armoon has quit [Ping timeout: 240 seconds]
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
<nomis>
("ISTR"?)
<robmur01>
I Seem To Recall/Remember
<nomis>
ah, right.
<tuxd3v>
Still fighting to get HiFi ES8316 codec driver working properly in RockPro64
<tuxd3v>
does any one succeded?
<stikonas>
did you select the right DTS file? what is your board revision?
<stikonas>
(although, I haven't tried sound myself yet)
<tuxd3v>
stikonas, its the v2
<tuxd3v>
I choosedn rockpro64-v2dtb
<stikonas>
ok, so that's fine...
<tuxd3v>
I am now in Derivers-SoundCard->Advanced LinuxSound Card-> Alsa for Soc audio support -> CODEC drivers
<tuxd3v>
and HiFi ES8316, is selected, but I dunno if I need to select something more..
cristian__c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
<stikonas>
probably not, I suppose everything necessary should already be included by defconfig
vicencb has joined #linux-rockchip
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #linux-rockchip
anarsoul has quit [Remote host closed the connection]
<stikonas>
ok, I get [ 7.122619] No soundcards found in dmesg
<tuxd3v>
stikonas, heheh
<stikonas>
mine is revision 2.1 though
<tuxd3v>
yeah you need to go to menuconfig 'Drivers-SoundCard->Advanced LinuxSound Card-> Alsa for Soc audio support -> CODEC drivers' :)
<stikonas>
I also can't get my sata to PCI adapter to work...
<stikonas>
yeah, I check there for ES8316 and it was enabled
<tuxd3v>
what kernel do you have?
<stikonas>
5.6.9
<tuxd3v>
maybe that revision has yet to mature..
<stikonas>
argh, could be because it needs firmware
<robmur01>
what's the actual ASoC card using the codec? simple audio, audio graph, or a board-specific glue layer? Whichever it is, do you have *that* in your config?
<stikonas>
I'm not sure what's the actual card...
<tuxd3v>
its simple audio
<tuxd3v>
in my case
<tuxd3v>
I also think I have v2.1
<robmur01>
are you sure? Looking at the upstream rockpro64 DT the card for the analog codec is using audio-graph
<stikonas>
oh, so then you need tockpro64.dtb
<stikonas>
not v2.dtb
<tuxd3v>
yes its writen in the board v2.1 2018-06
<tuxd3v>
but rockpro64-vs was not created for v2.1?
<stikonas>
it was
<tuxd3v>
rockpro64-v2.dtb
<stikonas>
2.1 has different sound wiring vs 2.0
<tuxd3v>
I have the same impresion
<stikonas>
it was mentioned onlinux-rockchip mailing list
* tuxd3v
tuxd3v is calmly checking its boot.cmd file to check dtb version..
<robmur01>
IIRC v2.1 is the main production run so is the "normal" version, while v2.0 is the less common early release and thus the special-case
<tuxd3v>
i'm in -v2.dtb version
<tuxd3v>
but in my case I have choosen both modules simple card and graph card
<tuxd3v>
but in dmesg it uses simple card
<tuxd3v>
well,it only works for 'asoc-simple-card hdmi-sound'
<tuxd3v>
[ 4.516258] asoc-simple-card hdmi-sound: i2s-hifi <-> ff8a0000.i2s mapping ok
<tuxd3v>
[ 4.524223] asoc-simple-card hdmi-sound: ASoC: no DMI vendor name!
<robmur01>
well, either way if you're using the wrong DT variant you'll be trying to talk to the codec at the wrong I2C address, so fix that first#
<tuxd3v>
what is the right address for v2.1
<tuxd3v>
?
<tuxd3v>
ff8a0000
<robmur01>
the one in rockpro64.dts
<robmur01>
0x11 rather than 0x10
mraynal has quit [Remote host closed the connection]
mraynal has joined #linux-rockchip
<tuxd3v>
but then pcie will suffer if I use rockpro64.dtb right?
<tuxd3v>
the idea I had was that v2.1 was launched because of a pcie problem with 1 resistor not delivering 3v3 volts to pcie
<tuxd3v>
but then the -v2,dtb only has audio descriptions..
<robmur01>
literally the only difference between the two DTs is the ES8316 address
<tuxd3v>
robmur01, so you say that we need graph sound with the first one right? intead of simple card?
<robmur01>
(well, and the board-level compatible/model strings, but meh)
<robmur01>
HDMI audio is using simple, analog audio is using graph.
<tuxd3v>
via hdmi, simple card, is only sending cracks
<tuxd3v>
spikes
<tuxd3v>
with
<tuxd3v>
speaker-test -twav -c2 -Ddefault:0
<tuxd3v>
does I need a monitor attached to get sound correctly?
<tuxd3v>
like in Lime2 board?
<tuxd3v>
I am only using the hdmi dongle getting audio via the 3.5mm Jack
<robmur01>
no idea - I don't have a HDMI audio splitter, only my TV
<tuxd3v>
front left...;front right...;
<tuxd3v>
yeahhhh
ldevulder_ has joined #linux-rockchip
<tuxd3v>
I have sound via HDMI simple card
<tuxd3v>
:)
<tuxd3v>
now...the worst part is still the Analog Audio
<tuxd3v>
I don't have analog Audio
ldevulder has quit [Ping timeout: 260 seconds]
<tuxd3v>
So the problem with hdmi-simple audio, is that you need a monitor attached to the dongle so that the sound card is created on the fly...
<tuxd3v>
The same hapens in Olinuxino Lime2
<tuxd3v>
which I think its unnatural
<tuxd3v>
I have a dongle with a 3.5mm Jack, and I can plug the dingle, but not the monitor.. with this solution I always need a monitor attached...to listen sound..
<tuxd3v>
mehh
<tuxd3v>
robmur01, thanks for your imput :)
<tuxd3v>
stikonas, we need the rockpro64.dtb instead of the -v2.dtb...judjing by the sound lol
<tuxd3v>
judjing -> judging
<tuxd3v>
robmur01, do you have analog sound?
<tuxd3v>
robmur01, do you have analog sound?
<tuxd3v>
even after detaching the display I still have hdmi-simple sound via 3.5mm jack
<tuxd3v>
but if I disconect it, the sound card goes away
<robmur01>
not on NanoPC-T4, I dug into it a bit, but the RT5651 codec driver wants an external board driver just to set I2S mclk :(
<robmur01>
so I gave up
<robmur01>
however it's currently playing me a CD over my new bluetooth headphones, and frankly I'm amazed that that much just works without any hassle :D
<tuxd3v>
Nice
<robmur01>
hardest part was figuring out player what to install since apparently physical CD drives are too retro for Gnome 3...
<stikonas>
tuxd3v: yes, I use rockpro64.dtb
<tuxd3v>
I had a usb-CD adapter
<tuxd3v>
and it works in rockpro64, but only connected to usb3
<tuxd3v>
stikonas, afaik 5.6.9 has the last stuff for rockpro64, I mean 5.6.10 has only a commit for meson