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
chewitt has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
grming has quit [Quit: Konversation terminated!]
HERIC has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
chewitt has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
JohnDoe_71Rus has joined #linux-sunxi
junari has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
rajkosto has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
junari has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
junari has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
ftg has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
warpme has quit []
Daaanct12 has quit [Ping timeout: 480 seconds]
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
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
apritzel has quit [Ping timeout: 480 seconds]
<warpme> apritzel, jernej: no i have https://gist.github.com/warpme/58c5873a7f25af3b51fa0d16976fee2b Milion THX!
<warpme> no->now
<jernej> warpme: what wifi module is that?
<warpme> ap6330
<warpme> and sp6330 (i have 2 boxes with 6330 module)
<jernej> oh, that's pretty old
<warpme> indeed. I'm getting more and more users with old h616 boxes and usually there is 6330. Still can't find clm_blob for this crap....
Hypfer has quit [Quit: The Lounge - https://thelounge.github.io]
<warpme> jernej : curious your opinion: i have 5 h313/h616 devices and to have working hdmi audio on ALL of them i need to apply https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0635-arm64-dts-allwinner-h616-OrangePI-Zero2-fix-hdmi-audio.patch Without this patch OPiZero2 and 2 other boxes loosing HDMI audio. I developed this patch purely by trial-and-error.....
Hypfer has joined #linux-sunxi
<jernej> clm_blob isn't really needed. why do you want it?
<jernej> I'm not sure in what way those changes would affect RTC and HDMI audio
<warpme> oh believe me: me toooooooo
<jernej> as long as you have h616 compatible on first place, it will use that, so H6 compatible in this case doesn't change anything
<warpme> for sure key seems to be clock entries
<jernej> original interrupt should be used too, as 101 and 102 are non-existing on H616
apritzel has joined #linux-sunxi
<jernej> adding clock-output-names also shouldn't change anything
<jernej> warpme: Try with commenting out whole if block here: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L263
<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?
<warpme> jernej : I verified: it looks like every chnage in https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0635-arm64-dts-allwinner-h616-OrangePI-Zero2-fix-hdmi-audio.patch ir required to: 1)not have kernel oops at boot + 2)having working hdmi audio. Isn't that this patch forces to use h6 rtc implementation?
<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
digetx has joined #linux-sunxi
digetx has quit []
warpme has quit []
digetx has joined #linux-sunxi
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
digetx has joined #linux-sunxi
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
digetx has joined #linux-sunxi
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
vagrantc has joined #linux-sunxi
digetx has joined #linux-sunxi
grming has quit [Quit: Konversation terminated!]
aggi_ has joined #linux-sunxi
aggi_ has left #linux-sunxi [#linux-sunxi]
grming has joined #linux-sunxi
aggi_ has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
aggi_ is now known as aggi
aggi has left #linux-sunxi [#linux-sunxi]
aggi has joined #linux-sunxi