<suprothunderbolt>
LRCK_PERIOD looks a bit confusing for i2s... In left J mode it's set to slot width and doesn't take into account number of slots... which might be correct, but the docs and timing look like it should be * the number of slots...
uis has joined #linux-sunxi
<smaeul>
suprothunderbolt: which SoC and which doc are you looking at? there are several slightly different variants of the i2s block
kaspter has joined #linux-sunxi
<smaeul>
e.g. A64 manual says "I2S / Left-Justified / Right-Justified mode: Number of BCLKs within each individual channel width (Left or Right)"
lerc has quit [Remote host closed the connection]
lerc has joined #linux-sunxi
<suprothunderbolt>
smaeul, A64
<smaeul>
the Linux driver was updated to match the doc I quoted, but it's always possible that the doc is wrong. You'd have to check with a logic analyzer if the behavior seems wrong
<wens>
spotted a H616 TV box on the local ebay going for 150 USD ...
lerc has quit [Remote host closed the connection]
lerc has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
gaston1980 has joined #linux-sunxi
victhor has quit [Remote host closed the connection]
<suprothunderbolt>
smaeul, I'm a bit confused if that means per channel (left or right) or per individual channel (1-8) in a "side". The issue i'm trying to solve is that I'm only seeing the first 4 channels of 8.
<suprothunderbolt>
so it should either be 32 or 128
buzzmarshall has quit [Remote host closed the connection]
<suprothunderbolt>
128 doesn't work. 32 or 64 interestingly both just give me the first 4 channels...
<smaeul>
are you sure you want left justified and not PCM if you're doing TDM?
<suprothunderbolt>
not totally sure, but I think so, the codec i'm using (pcm3168a) supports i2s and left j in TDM mode
<suprothunderbolt>
but only supports the other modes in non-TDM
<suprothunderbolt>
a confusing thing is that in the timing diagram for the a64 channels are listed odd on one LRCK, even on the other, the TI docs list channels as 1-8 in order
<smaeul>
hmm, so I think you're probably right that it's the sum of all channels in that side
<smaeul>
you could try setting `lrck_period = slot_width * slots / 2`
gediz0x539 has joined #linux-sunxi
<suprothunderbolt>
smaeul, alas I did just that, and it times out on arecord / aplay
<suprothunderbolt>
I just tried i2s mode instead of left_j and it starts fine but I can't see anything on any channel. On left j it works fine for first 4 in and out
<smaeul>
which first four? two left and two right, or all four left?
<suprothunderbolt>
channels 1-4
<suprothunderbolt>
which would be 0 2 4 6 in the allwinner diagram
<suprothunderbolt>
so all left
<suprothunderbolt>
maybe if I say LRCK is inverted I'll just get the others?
<smaeul>
> In the case of I2S, left-justified, and right-justified data formats, 64 BCKs, 48 BCKs, and 32 BCKs per LRCK period are supported
<smaeul>
oh, nvm, that's not referring to TDM
gediz0x539 has quit [Quit: Leaving]
<suprothunderbolt>
figure 52 on page 32 of the TI datasheet shows the timing diagram, which looks like the allwinner one apart from the channel numbering
<suprothunderbolt>
which suggests just one side of the LRCLK is being read
gediz0x539 has joined #linux-sunxi
<smaeul>
suprothunderbolt: and which side is master? note the difference between the two LRCKAD/DA lines
<suprothunderbolt>
ADC is master
<suprothunderbolt>
the slave mode in the TI doc looks similar to PCM B in the allwinner doc
<suprothunderbolt>
I can't appear to run with polarity inverted from the lrck not sure why...
<suprothunderbolt>
okay I can and it makes no difference, only 1-4 get signal out...
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
kaspter has joined #linux-sunxi
chewitt_ has joined #linux-sunxi
chewitt has quit [Ping timeout: 268 seconds]
prefixcactus has joined #linux-sunxi
victhor has joined #linux-sunxi
tnovotny has joined #linux-sunxi
jstein has joined #linux-sunxi
<apritzel>
mripard, wens: I have updates to the H616 support series, does it make sense to send it this week (just for review, they are targeting 5.14), or shall I wait after -rc1?
suprothunderbolt has quit [Ping timeout: 252 seconds]
tnovotny has quit [Ping timeout: 240 seconds]
<apritzel>
wens: was that H616 TV box gold plated and used diamonds to disperse the LED light?
<JoaoSchim>
apritzel, MoeIcenowy: the board is booting now. I kinda neglected a termination resistor between CS/CS# and gave the LPDDR3 some reflow. Also i needed to change some voltages that were in the u-boot config. BPI-M3 uses a lot more of the DCDC/LDO from AXP.
<JoaoSchim>
We're getting there.. Thanks. Guess, its time now for new device tree adventures.
<JoaoSchim>
typo: should be CK/CK# of course.
ganbold has quit [Ping timeout: 246 seconds]
kmaincent has quit [Quit: WeeChat 1.9.1]
mirko has quit [Ping timeout: 240 seconds]
kmaincent has joined #linux-sunxi
Naka is now known as Nakaori
mirko has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 260 seconds]
choozy has quit [Ping timeout: 245 seconds]
choozy_ has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
<MoeIcenowy>
JoaoSchim: glad to here that
<MoeIcenowy>
(although A83T is really old chip now
<tllim>
Regarding D1 SBC, PINE64 just pass handle Allwinner D1 SBC to Icenowy.
<tllim>
Please noted that Allwinner only provide board for now and not selling the D1 chip yet. The D1 chip may start available sometime in Q3 2021.
<tllim>
PINE64 D1 SBC, code name PineOne, will only start once D1 chip available, the Wifi/BLE module will use BL602 instead of XR829 that currently using Allwinner D1 board..
<tllim>
PINE64 still have the Allwinner D1 boards but in very limited quantity.