<apritzel>
I guess this check needs to be changed as well, as now the addresses don't match anymore, with bit 32 differing
<jernej>
yeah, that's why I asking if it works otherwise
cnxsoft has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<kuba2k2>
does anyone know what determines the assignment of clocks to peripherals on sunxi? I mean, for example the CLK_SRC_SEL bits in TVE_CLK_REG or TCONTV_CLK_REG
<kuba2k2>
for example, why is it assigned to PLL_VIDEO0_1X and not PLL_VIDEO1_4X for instance
psydroid has quit []
psydroid has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
kuba2k2: that's done by the Common Clock Framework (CCF) in Linux, so generic clock code
<apritzel>
it gets the layout of the clock tree, encoded in the hardware clock drivers, and some parts in the DT, then picks the "best suitable" parent, depending on the rate requested
<kuba2k2>
when I try to enable the TVE (and the TCON TV) on a T113, the same clock source is used for both
<apritzel>
I *think* if it can reach the frequency with the currently selected parent, it keeps it that way, otherwise it tries the other parents
<apritzel>
I think that's part of the strategy: to reuse existing clock sources
<kuba2k2>
that would make sense; however, in my case, both the LCD and TV TCONs try to use the same parent
<apritzel>
is that a problem?
<kuba2k2>
yeah, because first the LCD tcon sets it to 65 MHz (at least that's what is passed to clk_set_rate(), somehow it becomes 450 MHz in the end)
<kuba2k2>
and then the TV tcon sets it to 13 MHz...
<kuba2k2>
which, logically, changes the clock rate that LCD tcon wanted to have
<apritzel>
that sounds odd, the CCF should not do that: if there are conflicting clock rates, it would reconfigure or pick another parent
<apritzel>
so are you sure that the clock tree is described correctly?
<apritzel>
keep in mind that most mod clock have a divider, so you can have a higher clock parent, shared by multiple mod clocks, with different dividers
<kuba2k2>
all I can see is ccu-sun20i-d1.c, and it *seems* correct
<apritzel>
kuba2k2: are you using both TCONs at the same time?
<kuba2k2>
well I'm trying to, unless it's impossible by design
<kuba2k2>
ultimately I want to get the TVE to work alone, at least
<apritzel>
there was a patch lately, which forces parents for some video clocks, in the DT, let me find it
<kuba2k2>
this ends up setting the TCONLCD_CLK to 450 MHz
<kuba2k2>
and mode->crtc_clock is 65000 here
<apritzel>
those clocks are divider clocks, and have CLK_SET_RATE_PARENT set, so the request is handed up to the (currently selected) PLL
<apritzel>
which has a minimum frequency of 252MHz, so the algorithm should start searching there for a combination of factor and dividers that express the requested rate as close as possible
<apritzel>
so I guess it's PLL_VIDEO0 that gets 450 MHz, and then gets divided down, say by 7, to get to the 65 MHz?
<kuba2k2>
PLL_VIDEO gets 450 MHz, but it's not divided, TCONLCD_CLK_REG has N=1 and M=0
<kuba2k2>
so unless there's another divider that I'm not seeing, TCONLCD gets 450 MHz
<kuba2k2>
which makes sense - 65 mhz is the pixel clock, obviously the tcon must run faster than that - what I don't get is where does the 450 come from if 65 is (seemingly) requested
<kuba2k2>
I want to understand that for the TCON TV case, which requests 13.5 MHz and that exactly is set - which makes both TCONs clocked way too slowly
<apritzel>
kuba2k2: try to play that through in drivers/clk/sunxi-ng/ccu_mp.c:ccu_mp_find_best_with_parent_adj(), that should be the function in charge, IIUC
<kuba2k2>
ok, thanks, I'll try that
IlikeTech has quit [Read error: Connection reset by peer]
dsimic is now known as Guest9771
dsimic has joined #linux-sunxi
<jernej>
apritzel, kuba2k2: sunxi-ng clk driver usually botches clock setting when there are two video output active at the same time without some pointers in DT.
Guest9771 has quit [Ping timeout: 480 seconds]
IlikeTech has joined #linux-sunxi
<jernej>
there was hope that some purely algoritmic solution will be implemented, but nobody figured it out yet
<kuba2k2>
I assume the BSP just hardcodes everything
<apritzel>
jernej: right, so I was wondering how it handles those conflicts? It seems like clk_set_rate() goes straight to the hw clk driver, there is no CCF logic involved?
<jernej>
older BSP clock drivers work differently, more manually, like device drivers usually select parent and clock
<apritzel>
I mean the obvious algorithm would be: check if parent is already used: then try to find a divider with that fixed parent rate. If not, try another parent (we typically have a choice)
<jernej>
apritzel: main issue is that clock rates aren't lock in place. so if you set one clock rate for one core, let's say TCON, next one, for example, HDMI PHY may use same parent, but thus change it and thus influence TCON clock.
hexdump01 has quit []
<apritzel>
yes, but that seems like an obvious and generic problem, isn't it?
hexdump0815 has joined #linux-sunxi
<jernej>
of course
<apritzel>
something that the CCF should take care of, not necessarily the sunxi-ng drivers?
<apritzel>
but it any case: it doesn't sound too complicated to implement, which makes me wonder why nobody has done this before?
hexdump0815 has quit []
<apritzel>
because rarely anyone uses two video outputs at the same time?
hexdump0815 has joined #linux-sunxi
<jernej>
apritzel: be my guest :)
<jernej>
there is clk_set_rate_exclusive() but if I'm not mistaken, it also locks parent rate
<kuba2k2>
iirc it won't be a problem then if I use assigned-clock-parents = <> in the DT?
<jernej>
oh, BSP also set parents to fixed rate, for example, PLL_VIDEO 297 MHz, which can be easily divided to pixel clocks for standard resolutions. But that also means that all weird screen sizes many have don't work.
<jernej>
kuba2k2: that's possible solution but I would like to avoid it, if possible. IIRC it's also more of a suggestion and driver can change parent later.
<kuba2k2>
well, for now all I get on the CVBS output is a green screen anyway :)
<kuba2k2>
(the colorbar works though, but anything coming from the TCON TV to TVE doesn't)
<jernej>
apritzel: I don't remember which use case shows the issue. Probably some A64 board with LCD and HDMI, like pinebook.
<jernej>
kuba2k2: colorbar in TCON?
<apritzel>
jernej: yes, that Pinebook patch lately, but I thought that the parent choice also influenced some other mux?
<kuba2k2>
jernej: no, colorbar in TVE. setting TV_SRC_SEL in TCON doesn't make a difference (i.e. to see the RGB color gradient test)
<apritzel>
jernej: anyway, interesting, I always thought that the CCF would take care of that, given that it knows the number of users per clock, for instance, and those generic flags
<jernej>
kuba2k2: oh, I wasn't aware that TVE also has colorbar setting, I only know TCON one
<kuba2k2>
yeah it has a separate one. solid color bars, white/yellow/cyan/lime/magenta/red/blue/black, i.e. the 8 basic colors
<jernej>
apritzel: I think issue is in sunxi-ng driver. When clock is asked to find closest rate to the requested, it first check current parent. If there is perfect match, that's it. If it's not, it finds first perfect or best match with other parent, regardless if it already supports some other active clock.
<jernej>
but take that with grain of salt, it's been years since I worked on clock driver
<jernej>
kuba2k2: which clocks are you using? I want to check something.
<kuba2k2>
to get the green screen? same as the BSP, PLL_VIDEO1_4X for TCON TV0, and PLL_VIDEO0_4X for TVE
<kuba2k2>
but I just found the register map for TCON TOP, and noticed there are also clock gates and source select bits there.. so I'm trying to set it up now too
<jernej>
ah yes, that's also needed :)
<kuba2k2>
right, I see text now :) though it's very much squished vertically and I don't think colors work... but it's something :)
<apritzel>
jernej: makes sense, that's what I also got from skimming over the code
<kuba2k2>
(which is odd now that I think about it, the code clearly disables all the bits)
<kuba2k2>
or maybe not, sun8i_tcon_top_de_config() will probably set this bit if mixer is 1
<jernej>
actually, if you have both mixer1 active, it should be reconfigured after init, so this is good
<kuba2k2>
hmm, the patch says "makes sure both DEs never share the same output", maybe they can't *ever* be set to the same output, even before the init completes?
<kuba2k2>
I'll try the patch then
<jernej>
kuba2k2: do you have TCON_TOP register 0 configured? Bit 8 and possibly bit 0 set?
<jernej>
and bit 20 in register 0x20?
<kuba2k2>
register 0 bit 0 (TV0_CLK_SRC) is set, others cleared
<kuba2k2>
register 0x20 bit 20 (TV0_CLK_GATE) is set, others cleared
<jernej>
that code is specific to DE2, yes. With every generation of DE, CSC units get moved a bit
<jernej>
kuba2k2: no, but I'm not sure if it outputs in RGB or YUV
<kuba2k2>
well whatever it outputs in, it works on BSP - and if the mixer isn't in play here (with the color gradient), then it shouldn't need the color conversion for that anyway
<jernej>
do you have working BSP? check if TCON CEU registers are set
<jernej>
that's basically CSC unit too
<kuba2k2>
CEU_EN = 0
<kuba2k2>
but the coef's are set (Rr, Gg, Bb) and the ranges
<kuba2k2>
I have a working BSP, and I saved all the registers when it was configured in TVE mode. So I'm setting most of them to the same values on mainline
<kuba2k2>
oh? I removed mixer1 completely, just like the patch in the google group (https://paste.xogium.me/pn.txt), and the colors are now perfectly fine
Topi has joined #linux-sunxi
Topi has quit []
<jernej>
but you don't have TVE output now, right?
<kuba2k2>
I do
<kuba2k2>
still needs the color correction patch, but with mixer1 gone the TVE works. Don't know if LVDS will work simultaneously
<jernej>
oh, so that patch you linked is not yours
<kuba2k2>
yep, found that, but it's just so different from mainline that it's hard to read exactly which registers do what
<jernej>
it's always good to check clock and feat modules too
<jernej>
it takes some practice :) btw, there is DE2 documentation on wiki, if you're interested
<kuba2k2>
oh.. I totally missed the PDF
<kuba2k2>
thanks for the help so far. I'll see tomorrow if I can get anywhere with this
smaeul_ has quit []
smaeul has joined #linux-sunxi
<smaeul>
02:30 <loki666> tokyovigilante: pwm patch is not for h616 yet, marcromorgan is waiting for D1 to be merged first
<smaeul>
merging D1 PWM support first would mean that the fallback compatible string is not the original SoC containing the hardware, which isn't ideal, but isn't so much of a problem either