<tuxd3v>
does any one found what pins are assigned to LINEOUT{L,R} on H3?
<anarsoul>
tuxd3v: depends on what's your goal
<anarsoul>
i2s alone isn't enough, you also need a codec
<anarsoul>
(and likely a dma for i2s)
<tuxd3v>
anarsoul, thanks
<tuxd3v>
I believe sunxi-h3-h5.dtsi already has that right?
<tuxd3v>
dmas = <&dma 3>, <&dma 3>;
<tuxd3v>
I tried to search for the driver for "allwinner,sun8i-h3-i2s", on the root of the kernel drivers but I found none :(
<tuxd3v>
I am on kernel 5.10.41
<tuxd3v>
ho, probably sound/soc/sunxi/sun4i-i2s.c
<tuxd3v>
I wanted to have i2s0 availlable via GPIO
<tuxd3v>
and also availlable analog LINEOUT{L,R} via gpio I am on NanoPi Neo Air
<anarsoul>
i2s is a digital interface
<anarsoul>
you need a codec to get analog output
<tuxd3v>
it has mapped on GPIO i2s0, Line in/out l/r
<tuxd3v>
yeah, my Idea would be to activate and left i2s has is..
<tuxd3v>
And get analog Audio to work on LINEOUT{L,R} :)
<tuxd3v>
how do I map in the device tree the LINEOUT{L,R} pins, I get no reference to them in pinctrl :/
<tuxd3v>
I know they exist, because I saw them in the datasheet of H3, but don't find what pins.,.
<tuxd3v>
anarsoul, what do you mean by a codec? there are some in the mainline kernel?
ftg has quit [Read error: Connection reset by peer]
<tuxd3v>
CONFIG_SND_SUN8I_CODEC=y
<tuxd3v>
CONFIG_SND_SUN8I_CODEC_ANALOG=y
<tuxd3v>
should this work on audio pins out of the box?
<wens>
I thought I2S on H3 was already added and tested?
<wens>
just enable the i2s0 node, add appropriate pinctrl properties, and add a node describing your external i2s codec, and a soundcard node tying everything together
<tuxd3v>
could I route internally i2s0 to LINEOUT{L,R}
<tuxd3v>
to have analog audio?
<tuxd3v>
my initial I dea would be to have i2s0 as is, as a digital output
<tuxd3v>
and have i2s1 for analog audio
<tuxd3v>
but I noticed now that I can't use i2s1 because its already used by WIFI/bluetooth/usb :/
<tuxd3v>
so the Idea would be to use i2s0 for analog audio
vagrantc has quit [Quit: leaving]
<wens>
i2s0 is for external codec
<tuxd3v>
ok, forgetting external audio :)
<wens>
if you want to use the built-in analog audio, just enable the "codec" node
<wens>
that is the internal audio codec. No I2S required.
<wens>
see any of the h3/h5 boards that have audio for examples
<tuxd3v>
ho..many many thanks :)
<wens>
the h3 uses an integrated audio codec with direct DMA
<wens>
not an internal I2S interface like on some other chips
<tuxd3v>
so just enabling the codec is enough? :)
<wens>
I suggest looking at the user manual to understand the hardware first, before looking at the dts and guessing
<wens>
yes
<wens>
you need to provide some routing data though, so please look at other boards
<wens>
and read the bindings
<tuxd3v>
ho I tought that I would have to route i2s1 internally to the audio codec..
<tuxd3v>
nice! :)
faruk has joined #linux-sunxi
hanetzer has quit [Quit: WeeChat 3.0.1]
hanetzer has joined #linux-sunxi
faruk has quit []
faruk has joined #linux-sunxi
cmeerw has joined #linux-sunxi
faruk has quit []
apritzel has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
Nemo_bis has quit [Quit: leaving]
Nemo_bis has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
Is there a newer patch for hdmi audio than the now over a year old one linked from the "Linux mainlining effort" page?
<plaes>
I guess not..
prefixcactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<MoeIcenowy>
apritzel: of course it's sunXi, X=20
<apritzel>
MoeIcenowy: do you have a branch somewhere?
<MoeIcenowy>
no
<apritzel>
I was wondering what would be the exact consequences of having CONFIG_ARCH_SUNXI=y and CONFIG_RISCV=y
<apritzel>
it's hard to tell without trying
<BroderTuck>
Well, latest version seems to be https://mailman.alsa-project.org/pipermail/alsa-devel/2020-October/175248.html which has a note "To avoid using set-tdm property of the simple-soundcard we will introduce a specific soundcard for Allwinner HDMI later", but I've not been able to find that "later introduction" anywhere.
ftg has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<libv>
so fun and games at freenode
<libv>
they seem to have thrown everything away
<libv>
time to leave. all of us.
<libv>
nickserv and chanserv were purged completely
<karlp>
yeah, even I turned it off today.
<karlp>
they didn't hjave to do anything, juust ride the status quo, but no....
<karlp>
couldn't do that.
<libv>
like david dawes and xfree86
<libv>
if he had not gone there, it would probably still be alive
Mangy_Dog has quit [Ping timeout: 480 seconds]
<karlp>
yes yes... always have to go there don't you
<apritzel>
so they have thrown away all they had: their user base?
<libv>
whoever was left has now been pushed out as well
<apritzel>
has anyone ever played around with the RC calibration on the H6 (or later) RTC?
<apritzel>
smaeul, jernej ^^^
<apritzel>
the performance of the uncalibrated RC clock is abysmal, the RTC loses 10 seconds per minute(!)
<apritzel>
I triggered the calibration, and the new divider values I found in the register look very reasonable, but the RTC doesn't use it
<jakllsch>
heh, nice
<apritzel>
jakllsch: well, not really, it's just the RTC counters progressing more slowly, I am not ageing slower ;-)
<jakllsch>
:-D
jernej has joined #linux-sunxi
jernej has quit []
jernej has joined #linux-sunxi
<smaeul>
apritzel: the immediate consequence of configuring sunxi+riscv is that all of the legacy non-DM drivers (and everything that uses them) fail to compile, due to the headers being in arch/arm/include/asm/arch-sunxi
<apritzel>
can't we just copy the ones required to arch/riscv/...?
<smaeul>
ewww :)
<smaeul>
apritzel: I have not played much with the RC calibration circuit. when you enabled it, did you also select "Calibrated RC" in RC CLK SRC SEL ?
<apritzel>
smaeul: yes
<smaeul>
I've noticed that on D1, the BROM does an initial calibration, and uses it to set the integer prescaler, but that is still rough compared to the fractional divider from the calibration circuit
<apritzel>
I see, on the H616 it's the nominal 488 from the manual
<smaeul>
so maybe as an initial solution you could do that: read the factor from 0xc and write to 0x8
<apritzel>
but apparently on my device the RC is more like 13.9 MHz
<apritzel>
smaeul: in my case it should bring this down to 1.3 seconds / minute
<smaeul>
ooh what an improvement! ;)
<BroderTuck>
smaeul: Thanks, will take a look at it later
BroderTuck has quit [Quit: -]
<apritzel>
I just don't get why AW just allowed the divider to be programmed manually
<apritzel>
one can easily do the calibration in software, with the help of the arch counter and one 16 bit counter register
<apritzel>
... why AW *did not* allow the divider ...
<smaeul>
I think the calibrated RC is supposed to automatically use the fractional divider. so maybe your setup is missing something
<apritzel>
yeah, I guess so
<apritzel>
I was just curious why they went for such a rather complicated calibration process in hardware
<smaeul>
apritzel: to allow delaying the decision on the RTC binding, my plan for the D1 was to start with no RTC at all and use fixed clocks for HOSC/LOSC. if the other CCUs use the clock-names property correctly, later switching to an RTC clock provider should be seamless
<apritzel>
smaeul: that is one possibility, but will prevent newer DTs to run on older kernels
<apritzel>
we had this issue with the AXP in the early A64 development: there were fixed regulators everywhere, and only later the PMIC was introduced
<smaeul>
hmm, true, maybe that's the problem. we got things "just enough" working initially on H6, without fully thinking through how the hardware had changed. and now we are trying to catch up
<apritzel>
yeah, that's a general problem
<apritzel>
we can't really achieve this on the first try, there are just so many unknowns
<apritzel>
or the initial support would take forever
<smaeul>
yeah, nobody (including me) wants to read through 1000 pages of manual or BSP code when the existing driver Just Works :)
<apritzel>
I know, I was actually suspecting the RTC to be an issue
<apritzel>
but even briefly comparing the registers I missed so many things
<apritzel>
in an ideal world (TM) we would create bindings purely from manuals (+ experience), and this could be theoretically done long before silicon is oum
<apritzel>
s/oum/out/
<smaeul>
... and another first party driver appears!
<apritzel>
karlp: not really foolishly - the kernel.org list is rather new
<apritzel>
karlp: one problem with the Google groups list is that only subscribers can post, which means it gets much less used, especially by infrequent contributors
<smaeul>
the google group also mangles subjects (prefix) and bodies (footer)
<sunshavi>
jernej: ok. last time I compiled archlinux-arm kernel it took me 45m on the most powerfull machine at my reach. So that is something I just could do on weekends. Let's wait for the best. Thanks for the info
qCactus has quit [Ping timeout: 480 seconds]
<jernej>
if you do incremental builds, that should be still quick enough
Luke-Jr has joined #linux-sunxi
<MoeIcenowy>
apritzel: if you do not like board/vendor/model, then it would be quite okay to put all architecture-neutral things to board/sunxi
<MoeIcenowy>
only some ARM-specific things to arch/arm/mach-sunxi (e.g. enable SMP bit)
<MoeIcenowy>
or arch timer
<apritzel>
yes, that sounds good to me
<apritzel>
we could also keep stuff in there that won't apply to the D1, like older IP (DRAM controllers, for instance)
<apritzel>
but I was always annoyed by the seemingly random choice of code being in board/ or arch/
<apritzel>
just there was no real good reason to change that
<apritzel>
looks like we have that reason now
<sunshavi>
jernej: ok. I am going to keep that in mind. Even I usually compile in RAM
Mangy_Dog has joined #linux-sunxi
<apritzel>
jernej: smaeul: I think I found the calibration trick: you have to leave the calibration running
<apritzel>
so just write 0x3 into the calibration register, and that's it
<jernej>
oh, if you manage to figure it all out, it can be very useful
<apritzel>
it's 40 minutes now, and date and hwclock still give the same time
<jernej>
without that, there is big discrepancy?
<apritzel>
huge: 10 seconds every minute
<apritzel>
with this 5 bit divider this comes down to 1.3 seconds per minute
<apritzel>
which is still not what you would expect from a *real* time clock
<apritzel>
how many H6 boards are out there without a 32K crystal?
<apritzel>
(because I think they would benefit from that as well)
<apritzel>
jernej: seems like the Tanix TX6 doesn't have one?
<jernej>
apritzel: afaik most cheap H6 TV boxes are without 32k crystal
<jernej>
yes
<jernej>
and we had to disable it on Beelink (which is higher quality), because it didn't work on fair share of them
<jernej>
by higher quality I mean proper PMIC and probably more
<apritzel>
I see
<apritzel>
do you actually use the RTC on those boards (in LE)? For alarm wakeup, for instance?
<jernej>
no, but strange things happen if external crystal is activated but not present
<jernej>
for example, HDMI CEC doesn't work (although it has different 32k source)
<jernej>
and another issue is also Crust resume - something with watchdog
warpme_ has quit [Quit: Connection closed for inactivity]
<jernej>
apritzel: do you know how to interpret BSP gpio flags?
<jernej>
I have a feeling that on T95 and possibly others, SD card CD pin needs pull up to be enabled
<jernej>
register value shows pull up enabled...
<apritzel>
jernej: do you mean in the DT? I found it more useful to dump the GPIO MMIO registers to learn what they are *really* doing
<jernej>
yeah, true, that's why I suspect that pull up is necessary
<apritzel>
but makes sense: a resistor to save ;-)
<apritzel>
in U-Boot we always activate the pull up for the CD pin
hlauer has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]