ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
<Jookia> sorry linux-sunxi but i need your help: how do i set the i2s2 (or really any) clock frequency? i know the registers to set but i don't know how linux lets you do it. the i2s clock divisor is set by default in linux ... somewhere
<Jookia> setting assigned-clock-rates = <0>, <49152000>; doesn't seem to help
<Jookia> ah. the i2s driver is setting the clock
wasutton3 has quit []
wasutton3 has joined #linux-sunxi
<apritzel> Jookia: yes, as a user you do not set any clock rate at all, at least not directly
<apritzel> The device drivers are responsible to calculate the required rate (for a given baudrate, or sample rate, or video mode) and let the common clock framework figure out how to realise this frequency
montjoie_ has joined #linux-sunxi
<Jookia> hmm. the common clock framework can not seem a way to find the frequency 4915200 even though i think it should be able to
<apritzel> clk_set_rate() is one of the functions triggering this
<Jookia> not too sure how factor N and M work in a clock though
<apritzel> which clock in which SoC is this about?
<Jookia> t113
<apritzel> if you know the register offset, you can look this up in the manual
<Jookia> i don't quite understand how the factors work in the manual, it just stays N and M
montjoie has quit [Ping timeout: 480 seconds]
<Jookia> i guess n and m are multiplied together
<Jookia> which isn't good news for me, because it means i can't reach the needed clock
<apritzel> the formula is mentioned in the description of the gating bit 31
<apritzel> 2S/PCM1_CLK = Clock Source/M/N
<Jookia> ah
<Jookia> yeah, i'm out of luck then
<apritzel> the possible clock sources are listed below, clk_src_sel
<apritzel> and those audio PLLs can be typically programmed to any rate you need, especially those for common audio rates needed
<Jookia> i'm trying to program it for 49.152mhz but i can't seem to figure out how to get there
<apritzel> 49MHz or 4.9 MHz?
<Jookia> 49mhz
<apritzel> are you sure you need such a high rate?
<Jookia> i'm trying to do 192khz 8 channel 32-bit tdm
<Jookia> which needs a 49152000hz bclk
<Jookia> I'll try messing around with clocks a bit more tomorrow, thanks for your help so far
<apritzel> I don't see an immediate problem: the PLL algorithm should be able to calculate the required factors for the audio PLL
<apritzel> the manual says the default is 24.5714 MHz, which is 24 MHz * 86 / 21 / 4
<apritzel> the N factor can go up to 256
<apritzel> (though you don't need this here, I think, since 49.152 MHz = 2.048 * 24 MHz
<apritzel> Jookia: chapter 3.3.4.2 (configuring the frequency of PLL_AUDIO talks in details about how to achieve typical bit rates
<apritzel> I think the audio PLLs have special tricks up their sleeves to generate those "odd" rates required
<Jookia> i'll have another look, thanks
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<wens> the audio PLLs have a fractional divider
<wens> however since there is no real explanation of how it works, I believe we only copied the parameters for the two common clock rates, 24.576 and 22.5792 MHz
vagrantc has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Halamix2 has quit [Quit: Gone (and/or ZNC is doing something stupid)]
Halamix2 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
buZz_ has joined #linux-sunxi
buZz has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
<jernej> wens: There is only one parameter set, for 22.5792 MHz based clocks
<jernej> for some reason
<jernej> If it works, please send patch to mainline :)
<jernej> hm... neither of thise is in mainline, maybe there are multiple versions of this table
<jernej> wens: There is explanation on wiki (I got answer from AW): https://linux-sunxi.org/User:Jernej/PLL_Pattern_Control_Register
gnarface has quit [Read error: Connection reset by peer]
gnarface has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
<wens> yeah, I believe you sent it to me once?
<wens> thing is I calculated the parameters for the two common rates, and they were close but not the same as found in the BSPs
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<jernej> maybe they are closest possible?
<jernej> linkmauve: I have setup prepared. As expected, IOMMU triggers fault.
<jernej> first bug, width and height were set in wrong positions
dsimic is now known as Guest13956
dsimic has joined #linux-sunxi
Guest13956 has quit [Ping timeout: 480 seconds]
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
junari has joined #linux-sunxi
<jernej> fixed off by one in dh table parsing and quantization tables may hold either 8 or 16 bit values
<jernej> however, it still doesn't work...
<junari> jernej: thanks for the info about tv out. I was just asked by several users about it
<jernej> junari: np. it seems cvbs is one of those things no developer cares as much, but there are some users that want it
<junari> yep, perhaps these are true fans of NES and warm CRT light
warpme has joined #linux-sunxi
warpme has quit []
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
junari_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> jernej, Jookia, wens: The T113s manual has examples for common audio PLL clock rates, among them multiples of 49.152MHz, so maybe we can copy those values?
<apritzel> haven't checked whether those explanations cover every register that needs to be set, though, but it seems rather elaborate
junari has quit [Remote host closed the connection]
<jernej> linkmauve: another bug fixed - JPEG outputs to rotate/scale down registers
<jernej> at least I don't get timeouts anymore now
<jernej> but still page faults
apritzel has quit [Ping timeout: 480 seconds]
<jernej> linkmauve: using ST12 format I only get error marked in interrupt status, but otherwise it finishes without page fault
<jernej> with NV12, it fails
ftg has joined #linux-sunxi
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
junari_ has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
f_ has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
buZz_ is now known as buZz
machinehum has joined #linux-sunxi
junari_ has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
warpme has quit []
<Jookia> aperezdc: the PLL only goes up to 255, not 256 :(
JohnDoe_71Rus has quit []
<Jookia> i think i could reconfigure pll_audio0 to run at the proper speed
<apritzel> Jookia: for those audio frequencies, there are special patterns, so you don't use the normal N/M scheme
<Jookia> isn't n/m more exact than fractional dividers?
<apritzel> not in this case, since we cannot really generate this frequency with the range of factors, as you figured
<Jookia> i think you can for audio0
<Jookia> just not audio1
<apritzel> that what wens meant earlier: we have the pattern for 90.3168 MHz (22.5792*4) for the D1/T113s, but we are lacking the other frequency
<apritzel> 98.304 MHz (24.576 * 4 or 49.152 * 2)
<apritzel> that frequency is mentioned in the manual
<apritzel> we have both freqs for the A64 and H6, for instance
<apritzel> Jookia: look for the struct ccu_sdm_setting in drivers/clk/sunxi-ng/ccu-sun20i-d1.c
Hypfer is now known as Guest13993
Hypfer has joined #linux-sunxi
<Jookia> yeah i don't think that will work for i2s
<apritzel> what do you mean? once we have a setting for 98.304 MHz, the CCF algorithm will find that frequency, and just divide it by two to get you your 49.152 H
<apritzel> MHz
<Jookia> i think it wants an exact multiple
<apritzel> 98.304 is exactly twice of 49.152
<Jookia> it's currently at 98285714 which divided by 4 gives 24571428, which isn't 24560000
<Jookia> so i don't know how accurate that clock can be
<apritzel> IIUC this sdm (sigma delta modulation, used for fractional dividers) table allows to inject certain values for certain frequencies, bypassing the normal algorithm
<apritzel> and yes, the normal clock is a bit off, but I think SDM would fix that, using the "wave bottom" field of the pattern register
<Jookia> this is using sdm
Guest13993 has quit [Ping timeout: 480 seconds]
<Jookia> audio0 uses sdm
<apritzel> IIUC it *can* use SDM, but you program the pattern register, with magic values, which we don't know or understand
<Jookia> idk im going by the mainline code, it uses sdm
<apritzel> there is FRAC_EN (bit 20) in 0x17C (PLL_AUDIO0 Pattern1), which is 0x0 on reset
<Jookia> if the frequency was flat then i could just use pll_audio2
<Jookia> but right now its 49.1428mhz not 49.152mhz
<Jookia> though the SDM table says it should be 22.5792
<Jookia> so im not sure why its 8mhz off from the sdm 90mhz
<Jookia> it's a little frustrating that linux won't tell me how it generates the clocks because nowhere in the source code does it really show me how it arrives at the current frequency
machinehum has joined #linux-sunxi
warpme has joined #linux-sunxi
<Jookia> copying the sdms from tina linux does give me a 49142857 clock but it's not exact enough for i2s
warpme has quit []
sunshavi_ has joined #linux-sunxi
sunshavi has quit [Ping timeout: 480 seconds]
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
<jernej> linkmauve: can you test http://sprunge.us/97Myne ? It doesn't work for me, but at least colour palette seems to be about right
psydroid[m] has joined #linux-sunxi
<jernej> linkmauve: it almost works now: http://sprunge.us/gOchJR only last row and column are blocky
<jernej> and no more memory corruption
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<apritzel> Jookia: "Linux won't tell me...": do you mean how it programs the registers? The CCF is admittedly quite convoluted, but you should be able to dump the registers
<apritzel> have you checked ccu_sdm.c?
<Jookia> I'll check it out. I'm just really confused about why I get certain values that seemingly come out of no-where. Maybe the documentation is wrong
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]