<Jookia>
it's the right code it just doesn't belong there i think
<apritzel>
but it seems like a lot of complexity comes from trying to serve multiple SoCs? If we naturally have those implementations per-SoC, this could be simplified, naturally
<Jookia>
yeah
<Jookia>
ideally there should be no ccm-related code in drivers/video/sunxi for the DE2 code at leats
<apritzel>
absolutely agree
<apritzel>
but I don't think going full CCF crazy for this is the answer
<Jookia>
yeah. hmm
<apritzel>
because this gets quite complex, see the Linux clock drivers
<apritzel>
and we don't need that for U-Boot, I think
<apritzel>
Linux for instance needs to support multiple video clocks (multiple displays), plus multiple audio clocks (44.1 and 48 KHz based at the same time, for instance)
<apritzel>
and for that we need capable parent selection, reparenting and clock programming code
<Jookia>
if i drop the idea of caring about clock parents and only having specific set_clock_for_this_purpose function then it would simplify a lot, i would just have to add some setters/getters that handle clock setting
wingrime-ww has quit [Ping timeout: 480 seconds]
<Jookia>
maybe making set_pll and stuff more generic would help
<apritzel>
yes, I think this the direction. But have that code in the clock driver
<apritzel>
if I see this correctly, the DE2 driver would be exposed to just say <&ccu CLK_PLL_VIDEO0> and <&ccu CLK_DE>
<apritzel>
and I guess we actually only need to support a certain range of frequencies for that, and can always fix the muxers to certain parent clocks
<Jookia>
something like that. i don't remember the exact clock setup but there are two different sets of clocks because the H6 and H616/D1 have two different parent setups
<Jookia>
currently the clock init/get/set code is in arch/arm/mach-sunxi/clock_sun50i_h6.c
<apritzel>
yes, and we can handle this by having this implemented differently in the respective clock drivers, which are per-SoC anyway
<Jookia>
it feels a bit weird having drivers/ touch the ccm...
<Jookia>
it's touched in the nand code too
<apritzel>
of course it's weird, it should absolutely not do this
<Jookia>
ah
<apritzel>
could it be we want the same thing, but don't understand each other?
<Jookia>
probably! :)
<Jookia>
or i just went down the wrong road
<Jookia>
working with u-boot is confusing as i'm not sure what's best practice and what is old code that should be changed
<apritzel>
so to be clear: there is ancient legacy clock code in the video/display drivers, which directly reaches into the CCM MMIO
<apritzel>
and that's bad, and we want to get rid of that
<Jookia>
i don't think i can fix the DE1 code
<Jookia>
but probably the DE2 code if someone can test it on non-T113 boards
<apritzel>
I don't care too much about DE1, honestly
<apritzel>
I feel like we should start with DE2 on A64, to pick one prominent and accessible example
<Jookia>
the only allwinner board i have for development atm is a D1 and T113, and i don't really want to touch the D1 as it runs my 3d printer and uses legacy sunxi cruft
<Jookia>
i never wanted to be a sunxi developer but here i am
<apritzel>
that's fine, clock wise they should be very similar
<Jookia>
yeah, fine enough that i can probably write some code that might work :)
<Jookia>
hmm i think for the clock driver for now get_rate could just be hardcoded for specific clocks
<apritzel>
yes, that's what I am thinking as well
<Jookia>
i could probably add a ccu_clks table that lets you specify the clock id and give a register and clock type such as FIXED, and in the future maybe PLL which would just call get_pll or something which would be mach-specific
<Jookia>
though this wouldn't work very well for SPL code
<Jookia>
maybe the clock getting/setting needs to be mach-specific and have the ccu delegate to that
<Jookia>
not sure
<Jookia>
wait, this is very dynamic brained
<Jookia>
:)
<apritzel>
the SPL clock code stays like it is: and honestly we don't need many clocks, and certainly none through any CCF
<Jookia>
for a static setup it just needs to report fixed clocks set at init/compile-time
<apritzel>
for instance there is no video or backlight or USB or networking in the SPL
<Jookia>
what does the sunxi ccm code even do? is it used anywhere?
<Jookia>
uh
<Jookia>
the drivers/clk/sunxi code
<apritzel>
yes, we need it for all those bus gates
<apritzel>
that are referenced in the DT, for like USB, SPI, I2C, Ethernet
<Jookia>
interesting
<Jookia>
so it is mainly intended for DT peripheral gating/resets, NOT setting clocks
<apritzel>
all we need *in the SPL* is the MMC and SPI clocks, and they are already handled in their respective drivers
<apritzel>
not "mainly", but *only* ;-)
<apritzel>
so far we get away with that
<apritzel>
and that's the first hurdle, to actually introduce get_rate and set_rate
<apritzel>
it could be as simple as having one function per SoC, and in there a switch/case
<apritzel>
since we only need a handful of clocks supported
<Jookia>
i'm not sure set_rate is needed
<apritzel>
even better, but eventually we do need it, for DE2?
<Jookia>
i'm not sure. it depends how the maching-specific code will be implemented. there would likely be some kind of setup_de2_clocks in arch/arm/mach-sunxi that calls set_pll/get_pll which is also specificed in arch/arm/mach-sunxi
<Jookia>
unless it's better to have the setup_de2_clocks in drivers/clk for some reason
<apritzel>
I think so
<apritzel>
the DE2 driver should request the rate it wants, through the clock framework
<apritzel>
but that basically just calls into code very similar to what we have, just in drivers/clk/sunxi
<Jookia>
that makes sense
<apritzel>
but that should stop at that one function, and should not decent into the rabbit hole of the SoC specific clock tree
<Jookia>
yeah
<Jookia>
that's a much higher level function than asking for a specific clock
<Jookia>
as much as it is 'set up clock for tcon'
<Jookia>
or a job like that
<Jookia>
i'll have to think more about it as there are some extra snags: such as asking if a clock rate is valid
<Jookia>
i'll think some more about it
<apritzel>
yeah, me too
<apritzel>
the MMC driver would be an easier example, I think, but here we need in-driver code to support the SPL, so it's less of a win
<apritzel>
Jookia: to be clear, the non-SPL clock code in arch/arm/mach-sunxi needs to go away as well, and be moved into drivers/clk/sunxi
<Jookia>
oh, interesting
<apritzel>
for DRAM and MMC (periph0) this might be not too useful, since we need them for the SPL as well
<apritzel>
but definitely the video clocks
<apritzel>
so looking at your statement above: this is an example of old crufty legacy U-Boot code that we don't want anymore
<Jookia>
it's a little strange to split up clock setting code out of mach-sunxi and in to drivers/clk isn't it? or do i not get it
<apritzel>
why strange? We do want DT driven code, so it's the natural place. And stuff like video only exists in U-Boot proper, so no reason to not have DT based clock drivers there
<apritzel>
in the past this was all one soup, so having the clock code in arch/arm/mach-sunxi was fine, since drivers could call into there as well
<apritzel>
but with drivers being DT and DM driven, this changed. We handled all the gates clocks already, because that was easy
<Jookia>
interesting
<Jookia>
that makes sense, i didn't understand the reasoning for the split
<apritzel>
honestly this should all been converted and cleaned up years ago, but nobody could be bothered to disentangle and clean up that code, also it worked fine(TM) ...
<apritzel>
but for new video drivers (H6, D1) we need to have clean clock code from day one
<Jookia>
does ACPI map to DT?
<Jookia>
i understand just how unhinged that question is
<apritzel>
well, it's a common misconception that both are different implementations of the same requirement, but they are quite different, actually
<apritzel>
ACPI relies on a much more abstracted hardware design, potentially moving a lot of detail into firmware or hardware
<apritzel>
firmware could be ACPI (AML) code
<Jookia>
it seems a little strange that there's all these dt drivers that ACPI can't use. or maybe they just ship a small dt that refers to acpi
<apritzel>
DT on the other hand tries to model the hardware in great detail, and leaves the code to the OS
<apritzel>
there are not that many platforms that support both, actually
<Jookia>
i think ARM64 and RISCV64 are pushing for UEFI/ACPI
<apritzel>
UEFI is orthogonal, you can have both UEFI/DT and UEFI/ACPI
<Jookia>
interesting
<apritzel>
and there is basically little point in pushing for ACPI if the underlying hardware platform is deeply embedded
<apritzel>
that's just not a fit
<Jookia>
i guess maybe ACPI is intended for desktops and servers where you have a generic model of a compatible machine
<apritzel>
you can try to do this, but it's quite a pain, and does not work really well
<apritzel>
yes
<Jookia>
oh, i get it, that's what ACPI is
<apritzel>
for Raspberry Pi there exist both ACPI and DT support, but I hear that ACPI is not very complete, and it was reportedly a pain to implement
<Jookia>
a hardware abstraction layer to make an ACPI machine, with firmware doing heavy lifting
<Jookia>
and then handoff to linux i guess
<apritzel>
ACPI works more like: "enable this device", "switch this device to power saving", and it's expected that either platform firmware or AML code implements this
<apritzel>
whereas DT is more like: those are the two clocks, the power domain, the regulator, and the pins needed
<Jookia>
i think ACPI also works with the dreaded embedded controller?
<apritzel>
and it expects there to be drivers to care for them
<apritzel>
yes
<Jookia>
wild
<Jookia>
i appreciate the effort people have put in to making computer hardware not be a pain :)
<apritzel>
many fail regularly ;-)
<Jookia>
yes, i'm a little salty about my motherboard's fan controller only being available by WMI over ACPI with no documentation
<apritzel>
it's a different mind set: embedded Linux is very itchy about not having control over something
<Jookia>
that's changing a little with the move to arm trusted firmware i think
<Jookia>
or rather, having a supervisor
<apritzel>
and firmware on embedded devices is many times quite bad, not updateable and so highly frowned upon
<Jookia>
i did some work with the stm32mp151 and it has a hardware security partition, which means power management is now split and has to be communicated using scmi
<apritzel>
I was once exploring a more abstracted way for the A64: for instance by implementing regulators and potentially even clocks in Trusted Firmware, using the SCPI or SCMI protocl
<apritzel>
which would mean that Linux wouldn't need SoC specific drivers
<apritzel>
but there was a lot of pushback on this
<Jookia>
i think it makes sense to do that if you have a hardware security boundary but not for making drivers more generic
<Jookia>
it was also a bit of a headache having 3 different device trees and having to build a clock tree in your head from it
<apritzel>
yeah, STM32 seems to embrace that idea very much, but it sometimes feels overly complicated
<Jookia>
having 3 levels of execution times two levels (secure/nonsecure) with things like userspace, kernelspace, hypervisor, tfa
<apritzel>
also I feel like STM32 being more on the low end performance and resource wise, they cannot really afford the overhead
<Jookia>
interesting
<Jookia>
by the way, thanks for your patience and guidance on these patches :)
montjoie_ has joined #linux-sunxi
<apritzel>
np, thanks for working on those, and doing it the proper upstream way!
<apritzel>
(and I still owe you a review of the SPI U-Boot patches ...)
montjoie has quit [Ping timeout: 480 seconds]
<Jookia>
:D
ftg^ has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
<tokyovigilante>
Is there a robust way to boot a FIT kernel image over FEL? Working on kernel modules is pretty painful via SD
<Jookia>
fel u-boot + fastboot maybe?
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<jernej>
tokyovigilante: do you really need kernel modules? for dev purposes, I have U-Boot on SD card, which loads all-in-one kernel over ethernet
<jernej>
and that allows pretty fast testing
<tokyovigilante>
no not at all, only mean module inasmuch as a driver that can be built as a module, working on a cut-down config with everything built in. Might have to set that up myself
<tokyovigilante>
only downside is my device doesn't have ethernet
<tokyovigilante>
hmm, although it seems I can use ethernet over usb...
<Jookia>
i use usb gadget ethernet to transfer files over ssh and ssh to my board
<Jookia>
it's a really good approach for kernel development imho
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
hmmm, do I want RNDIS or CDC-ECM?
<Jookia>
for u-boot? not sure. RNDIS. for kernel? i use g_ether
<tokyovigilante>
ta, don't suppose you know which usb driver I need?
warpme has quit []
<tokyovigilante>
which peripheral driver i mean, just the generic ehci?
apritzel has joined #linux-sunxi
<Jookia>
not sure right now
<Jookia>
i'm about to sleep
<tokyovigilante>
no worries. either its not supported or i dont know how to configure it to build in u-boot.
Schimsalabim has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
dsimic is now known as Guest2484
dsimic has joined #linux-sunxi
Guest2484 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
electricworry has joined #linux-sunxi
warpme has quit []
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
wingrime1 has quit []
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
wasutton- has joined #linux-sunxi
paulk has quit [Remote host closed the connection]
paulk has joined #linux-sunxi
wasutton3 has quit [Ping timeout: 480 seconds]
paulk has quit [Remote host closed the connection]
paulk has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Remote host closed the connection]
paulk-bis has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.2, revision: 5.2.0+git-7571-8c8adf27c, build type: debug, sources date: 20160102, built on: 2024-03-24 18:03:42 UTC 5.2.0+git-7571-]
paulk-bis has quit [Ping timeout: 480 seconds]
paulk-bis has joined #linux-sunxi
paulk-ter has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
paulk-ter has quit [Ping timeout: 480 seconds]
paulk-ter has joined #linux-sunxi
paulk has joined #linux-sunxi
paulk-ter has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
paulk-bis has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]