JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
radxanaoki has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
radxanaoki has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
radxanaoki has quit [Ping timeout: 480 seconds]
iscle has joined #linux-sunxi
bauen1 has joined #linux-sunxi
iscle has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
chewitt has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
paulk: that's an interesting topic: the sunxi-ng parent selection seems to leave quite some opportunities on the table, for instance IIUC it prefers the first match (if two are equally good), and it looks like it never tries to change the parent (PLL) rate
<apritzel>
there might be more clever algorithms, not sure if you could sketch something out based on your use case?
<apritzel>
OR: the more pragmatic solution might be to use assigned-clock-parents in the .dtsi, see 8715c91a83650292
<paulk>
apritzel: last time I tried it just failed to find a working setup in my case, leaving either the display or camera failed
<paulk>
I think it's easier to just assign the isp pll at probe time instead of doing it dynamically
<paulk>
though I haven't looked at the algorithm exactly indeed
<paulk>
apritzel: the dt approach used to work for me but I tried yesterday and it go -EBUSY for some reason
gsz has joined #linux-sunxi
<apritzel>
paulk: are you using the CSI1 or MIPI clock? And is the default 297MHz for the ISP PLL a usable rate? So would it work just to change the mux bits in those two mod clocks?
apritzel_ has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
apritzel__ has joined #linux-sunxi
apritzel_ has quit [Read error: Connection reset by peer]
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<paulk>
apritzel: it's the CSI1 SCLK clock (MIPI is actually for the d-phy, which gets reparented to the periph pll correctly)
<paulk>
yes the 297 MHz rate is what we want
<paulk>
the Allwinner BSP does the reparenting, the ISP PLL was really designed to be used like this
<apritzel>
yeah, I can see that, it's really only those two clocks that can use that anyway
<apritzel>
paulk: but PLL_VIDEO also defaults to 297 MHz, does someone change that rate?
<paulk>
apritzel: yes it's changed to accomodate the pixel clock rate used by DE
<paulk>
so using video-pll is fine when there's no display attached but it breaks one or the other when display is there
<paulk>
I'll hook a panel to my board again and dig a bit deeper though
<apritzel>
Thanks, sounds reasonable, just wanted to double check. I guess the DE changes the clock before the camera requests it? I wonder why it doesn't find the ISP-PLL as a better version then ...
evgeny_boger has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel has quit [Read error: Connection reset by peer]
apritzel__ has joined #linux-sunxi
apritzel_ has quit [Read error: Connection reset by peer]
apritzel__ has quit [Read error: Connection reset by peer]
Net147 has quit [Read error: Connection reset by peer]
cnxsoft has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest17841
dsimic has joined #linux-sunxi
Guest17841 has quit [Ping timeout: 480 seconds]
<paulk>
mhh actually it might be trickier than that
<paulk>
it seems that it can actually achieve the display pixel rate from the 297 MHz base using the integer diviser between the pll and the tcon clock
<paulk>
but the display doesn't work
<paulk>
in that case it puts the DE clock and the TCON clocks under a different parent
<paulk>
maybe that causes some clock phase shift that makes it unhappy?
<paulk>
yeah forcing de to pll-video makes it work again, everything else being exactly the same
<paulk>
so maybe that was the cause of the issue in the end
apritzel__ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<apritzel>
paulk: did you figure *why* the DE clock goes under a different parent? And is it periph0 then? I wonder if that's because PLL_VIDEO is initially disabled?
Net147_ has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
<paulk>
apritzel: yes it's pll-periph0, what happens is that it moves de to it to achieve the 150 MHz mod clock that's requested by the drm driver
<paulk>
when forcing the parent it goes with the same 297 MHz, which is not what the drm driver wants, but also works
<paulk>
so it makes sense
<paulk>
except that the driver doesn't know that (as far as I understand) tcon and de clocks should have the same parent
<paulk>
honestly I don't see why the drm driver requests 150 MHz, most other platforms are at 297
<paulk>
apritzel: if I change the drm driver to request 297 then it keeps everybody under the video pll without having to force the parent
ftg has joined #linux-sunxi
<paulk>
so I think the takeaway is that the drm driver should better also request 297 for V3 and that DE and TCON clock should have the same parent
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has quit [Quit: Leaving]
iscle has joined #linux-sunxi
gsz has quit [Quit: leaving]
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
paulk: interesting, but I can clearly see why PERIPH0 wins when DE asks for 150 MHz. Have you tried forcing .modrate in sun8i-mixer.c to 297MHz for the the V3s as well?
<apritzel>
commit edea372bd205 mentions that it needs that frequency, but it doesn't mention the V3s explicitly, and it's already 8 years old, so I wonder what's behind that
wens has quit [Read error: Connection reset by peer]
bauen1 has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
<paulk>
apritzel: yeah it definitely works!
<paulk>
looks like 150 MHz was picked-up as a safe default value and others platforms got upgraded
<paulk>
I don't think it really matters all that much
<paulk>
As long as it's faster than the pixel rate by some factor
<paulk>
I mean it probably just stalls twice as often at 297
<paulk>
given that there's no analog things involved or particular timing constraints I suspect it could work within a range
<paulk>
bsp has DE_CORE_CLK_RATE 300000000
<paulk>
which also works
<paulk>
anyway the tcon is limited to 1027x768
<paulk>
so I think we should just configure it to 297 and remove the periph0-pll as a possible parent to avoid future trouble (tcon is only on video-pll)
evgeny_boger has quit [Ping timeout: 480 seconds]
<apritzel>
paulk: ah, great. I am all for upgrading it to 297 MHz, if that fixes the issue.
<apritzel>
But I don't think we can remove the parent, as this is supposed to reflect the hardware, and PERIPH0 is documented as a possible parent
libv has quit [Remote host closed the connection]
<paulk>
apritzel: it looks like this is a possible but non-functional situation
<paulk>
maybe it makes sense when using the DE with writeback
<paulk>
but with tcon from what I could see it won't work if both blocks have different clock parents
<paulk>
and the problem is that the code may auto-reparent both to different parents automatically
<paulk>
so ideally this would be expressed in the description and used by the algorithm, but it seems like a lot of effort for little gain
<paulk>
(aka I'm too lazy to do it)
<apritzel>
mmh, but effectively there isn't too much choice for the algorithm anyway, is there? I mean isn't it always the same clock rates (now 297MHz), which should lead to the same results?
<apritzel>
so you mean it works if both TCON and DE use either PERIPH0 or VIDEO, but they must choose the same?
evgeny_boger has joined #linux-sunxi
eldondev has joined #linux-sunxi
vagrantc_ has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
<paulk>
apritzel: right right with 297 the de clock will always stay on video-pll so it won't be moved automatically
iscle has quit [Ping timeout: 480 seconds]
<paulk>
apritzel: the problem is that tcon cannot be parented to periph0-pll, it only has video-pll as parent
<paulk>
so if the de clock gets moved to periph0-pll it stops working
<apritzel>
... which is a bug in the clock driver? According to the "V3s Datasheet" I am looking at, TCON has the same parents as DE. So it should be de_parents, not tcon_parents?
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<paulk>
apritzel: ooh right right, didn't catch that, both clocks support both sources
ftg has quit [Read error: Connection reset by peer]