diego71 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
DevrimGecegezer has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
cnxsoft1 has quit []
grming has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
cnxsoft has quit []
<warpme>
apritzel : will you find spare cycles to help me with non-working h616 CLK_OSC32K_FANOUT issue?
<apritzel>
warpme: what's the issue, exactly? Also I think jernej mentioned some issue related to some 32K clock lately?
<warpme>
issue: i have board with dead ap6330 wifi and it looks it is not working because lacking lpo clock. I added CLK_OSC32K_FANOUT in dt - but still nothing on PG10 pin. I asked Jernej for suggestions. Jernej found bug in current kernel code and proposed patch: http://ix.io/4sKf But I still see CLK_OSC32K_FANOUT in not enabled in clk_summary ( https://controlc.com/f6f59cb1 )
<warpme>
in not enabled-> is not enabled
<jernej>
apritzel: it seems like rtc-32k gets enabled instead of osc32k-fanout
<jernej>
note: rtc-32k is only internal clock and in theory would be enabled only if some other clock uses it
<apritzel>
warpme: so how do you reference CLK_OSC32K_FANOUT in the DT, exactly?
<apritzel>
warpme: from a brief look it looks like you must use: clock-names = "ext_clock";
<apritzel>
clock-names must match the binding, and most (though not all) drivers require that certain fixed string - that is in contrast to clock-output-names, which is more descriptive
<jernej>
apritzel, warpme: I don't know how I missed that. Yes, driver expects that clock name is "ext_clock".
<jernej>
warpme: clock patch is probably not needed
<jernej>
this logic worked fine for H6 and older RTCs, but now with H616 and others probably needs update
<warpme>
sure. give me sec!
<warpme>
to test on 5 boxes i need rebuild image + publish this to on-line updates
<jernej>
don't forget to remove DT patch :)
<jernej>
take your time
<warpme>
DT patch: already done :-p
grming has quit [Quit: Konversation terminated!]
<apritzel>
warpme: does this patch drop all the clocks completely?
<warpme>
apritzel : i think yes
JakobL has joined #linux-sunxi
JohnDoe_71Rus has quit []
<apritzel>
jernej: do I get this right that the new rtc clock driver actually doesn't use those clocks? It just seems to get ext-osc32k, but not for the H616.
<apritzel>
ah, I guess that's somewhat hidden by the usage of fw_name? For hosc and pll-32k
<warpme>
jernej : commenting-out L263-L267 not helps
<jernej>
warpme: can you first confirm that only removal of clock lines help?
<warpme>
sure. i'm exactly testing this now...
<JakobL>
Hi everybody and happy easter!
<JakobL>
I have a RGB LCD here that behaves very picky in regard of dclk phase and i cant get it to work with A33 under linux (5.16). With uboot (2020.10) it works fine using same timings.
<JakobL>
But i noticed uboot signal looks different on scope (sync:3). Using the same register settings as in uboot for TCON0 results in a reduced dclk speed. At the moment i can't find the place to set the clock - is it AHB?
<JakobL>
Does anybody know how to work around this and enable the phase shift?
<apritzel>
warpme: what kernel version is this? And do you have CONFIG_SUN6I_RTC_CCU=y?
<warpme>
apritzel : yes i have CONFIG_SUN6I_RTC_CCU=y. Kernel is 6.2.10
<apritzel>
because jernej is right: the fallback compatible should be irrelevant (and is wrong anyway); clock-output-names should not matter; the interrupts are wrong; and I think the clocks might not be needed at all
<apritzel>
so the original DT node looks correct, the changes are just disguising something
<warpme>
oh - i'm not questioning jernej's opinion. I'm only saying that: 1)not have kernel oops at boot + 2)having working hdmi audio requires every chnage in patch
<apritzel>
yes, I am not questioning that, but the DT changes look all wrong
<apritzel>
the relation between the RTC driver and the RTC clock is a bit special, maybe there is something fishy in there?
<apritzel>
warpme: and how does the kernel oops?
<apritzel>
and does it already work if you just add the fallback compatible string?
<warpme>
oops place depends on what was changed in DT
<warpme>
well - what i can say: applying portions of this patch results: ooops or no audio
<apritzel>
my hunch is the key is the compatible string: if you use H6, you get the old (integrated) RTC clock driver, H616 uses the new driver (CONFIG_SUN6I_RTC_CCU)
<apritzel>
the rest of the options (minus interrupts) depend on which driver you are using
<warpme>
exacly this what i think!
<apritzel>
can you post the oops if you take the original DT, and just add the compatible fallback string?
<warpme>
+ to force old RTC drives i need remove some entries needed by new. As DT is not satisfacting new driver, old one is loaded as fallback
<warpme>
sure let me get it
<warpme>
apritzel : add only compatible will be not enough to provoke oops. I need to cause new rtc driver is not loading (due missings in dt). then old one starts to load. and it loads ok when dt has all requirements for old driver. this may explain why i i.e need add: interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<warpme>
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>; Without this i have oops. Adding clock-output-names = "osc32k", "osc32k-out", "iosc"; is needed to have audio....
<apritzel>
so it looks a bit like the two drivers would race if you provide both the h616 and h6 compatible string
<apritzel>
or maybe there is something to force an order of this
<warpme>
i'm not sure about this: isn't that first patched compatible causes rest are not tested/loaded?
<warpme>
patched->matched
<apritzel>
normally yes, but this case is a bit more tricky
<apritzel>
there is an OF_CLK_DECLARE with the compatible string, used by the clock part, and the normal matching for the actual RTC part
<warpme>
more and more i see that: new h616 rtc driver breaks h616 audio?
<apritzel>
yes, just wanted to say that
<warpme>
:-)
<apritzel>
the H616 RTC clock is implemented differently, though: it's probed by an explicit call from the the rtc probe routine
<apritzel>
so I think the oopses are because: the old clock driver triggers via OF_CLK_DECLARE, but also the new driver probe does, and if that fails, the whole RTC driver bails out and refuses to load
<apritzel>
which probably frees something that the OF_CLK_DECLARE part relied on
<apritzel>
anyway: this combination of compatible strings is both wrong, in multiple ways
<apritzel>
did you post the HDMI audio DT part somewhere already? Unfortunately another nion
<apritzel>
... non-mainline part :-(
<warpme>
for making audio part more "mainline-like" i think our friend codekipper is working now....
<apritzel>
well, I guess we need HDMI in general first, don't we?
JakobL has quit [Read error: Connection reset by peer]
<warpme>
indeed. and iirc csc has some issues which are a bit blocker (i have nicelly working media player with rendering via EGL_DMABUF. but rendering to DRM planes results with v.dark unwatchable picture)
grming has joined #linux-sunxi
<warpme>
also i'm really missing iommu. on small ram systems (1G) occasional swapping really breaks UX