<ity>
I wrote an attempt at documenting basic info about the drivers, would it be possible to get it fact-checked? I only skimmed the Kconfig & drivers https://hastebin.skyra.pw/imokelidef.nestedtext .
<anarsoul>
btw, it may not work properly because tcon0 and tcon1 share clock
dsimic is now known as Guest489
dsimic has joined #linux-sunxi
Guest489 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
<KREYREN_oftc>
anarsoul, recommendation?
<anarsoul>
none
<apritzel>
KREYREN_oftc: to test that theory, you could temporarily disable the panel, and just use HDMI
<apritzel>
no, in the DT, set the status to "disabled"
<apritzel>
ity: since this question (which drivers for a certain SoC) pops up from time to time, can you put that (for just the A64) in a table in the Wiki?
<KREYREN_oftc>
apritzel, link the table plz
<apritzel>
I don't think there is none, so it would need to be created
<apritzel>
I don't think there is *one, ...
DuClare_ has joined #linux-sunxi
<apritzel>
tokyovigilante: macromorgan: I think you mentioned issues with the AXP717 U-Boot driver, can you confirm what changes you made? Disable the ID check, I2C address from 68h->34h?
DuClare__ has joined #linux-sunxi
DuClare has quit [Ping timeout: 480 seconds]
DuClare_ has quit [Ping timeout: 480 seconds]
<macromorgan>
I haven't progressed much in a few days. I'm bouncing between a Rockchip board and an Allwinner board. The Rockchip one has won the last few days but it's looking like it's going to be an Allwinner kind of day tomorrow.
<KREYREN_oftc>
apritzel, one's at the teres's wiki page but it's lacking a lot of info
<KREYREN_oftc>
as i am still researching which modules are needed for what >_<
apritzel has quit [Ping timeout: 480 seconds]
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
flyback has quit [Remote host closed the connection]
flyback has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
nashpa has joined #linux-sunxi
dliviu has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
tnovotny has joined #linux-sunxi
warpme has joined #linux-sunxi
ynezz has quit [Ping timeout: 480 seconds]
ynezz has joined #linux-sunxi
ynezz is now known as Guest525
Guest525 is now known as ynezz
vpeter has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
dsimic is now known as Guest538
dsimic has joined #linux-sunxi
Guest538 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
<ity>
apritzel: Hmm, so I should clean up the doc and put it on the linux-sunxi wiki somewhere? I am still not 100% sure which driver corresponds to what chips, I just made guesses based on the Kconfig, the DT matches in the driver, and depmod, would that be enough? I am also not sure if I got the DE 1.0 & DE 2.0 stuff correct... Well, I could do the A64 stuff as I am testing it with
<ity>
Krey.
<ity>
There is *quite a lot of chips*, so doing it just for the A64 would make it easier haha
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
warpme has quit []
ungeskriptet is now known as Guest565
ungeskriptet has joined #linux-sunxi
Guest565 has quit [Ping timeout: 480 seconds]
tnovotny has quit [Quit: Leaving]
warpme has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
<ity>
What does sun6i_dma do? Or, to be more specific, what would break should the driver not be loaded? It *seems* like a pretty core driver, but not sure.
vagrantc has joined #linux-sunxi
<apritzel>
ity: we have to start *somewhere*. Make it a table, and just fill one column, the A64. We can then go over it and add more chips
<ity>
Ah, fair hahah
<apritzel>
and fix up things
<ity>
I do have a cleaned up version, it's not complete but lemme send it over
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
<apritzel>
sun6i_dma is a separate DMA controller, which can transfer data from memory to a device, without the CPU needing to take care of that
ungeskriptet has joined #linux-sunxi
<apritzel>
... which is admittedly the definition of a DMA controller ;-)
dliviu has joined #linux-sunxi
<ity>
Hmm, is it utilized by any of the modules in the A64? Or is it used for peripherals connected externally
<apritzel>
ity: if you look into the A64 .dtsi, you should see it referenced
nashpa has quit [Ping timeout: 480 seconds]
<ity>
.dtsi? Is that diff from the .dts
<apritzel>
for SPDIF, I2S, SPI
ungeskriptet is now known as Guest571
<apritzel>
the basic SoC dtsi (device tree source include), in contrast to the board .dts, which builds on that
<ity>
OOOH
ungeskriptet has joined #linux-sunxi
<apritzel>
sun50i-a64.dtsi
<apritzel>
if you look at any random board .dts, you will see that it includes the SoC .dtsi at the very beginning
<apritzel>
then basically overwrites the status properties in peripherals that it needs, like SD card, UART, I2C, whatever
<ity>
OOOH, status as in whether it's connected or not? Oooooh
<apritzel>
in the .dtsi you will find most devices having a: status = "disabled";
<apritzel>
if a board uses that device, say it connects an SD card slot to the MMC0 pins, then it enables the device by saying: status = "okay";
ungeskriptet has quit []
<ity>
OOOOH I see, that makes so much sense now haha
ungeskriptet has joined #linux-sunxi
<ity>
mbus & deinterlace reference dma, not really sure what that implies, as deinterlace references it with interconnect-names = "dma-mem", while mbus with dma-ranges = <0x00000000 0x40000000 0xc0000000>
Guest571 has quit [Ping timeout: 480 seconds]
<ity>
As opposed to the other 4 (SPIDF, I2S, SPI, DAI) which reference it through `dmas`
<apritzel>
mbus and deinterlace don't have anything to do with sun6i-dma, I believe
ungeskriptet is now known as Guest573
ungeskriptet has joined #linux-sunxi
<ity>
Ah, interesting. So, without sun6i-dma, the 4 listed peripheral interfaces won't function?
<apritzel>
SPI would work, as it's optional there (the CPU will then just manually fill the FIFOs). I don't know about the audio devices, DMA might be mandatory there
gamelaster has joined #linux-sunxi
gamelaster has quit []
Guest573 has quit [Ping timeout: 480 seconds]
gamiee_ has joined #linux-sunxi
<gamiee_>
test
<gnarface>
gamiee_: test acknowledged
<gamiee>
gnarface : thanks! Just testing new bouncer which can receive PMs (the current account is just Discord bridge)
<apritzel>
gamiee: Shall we play a game? (uh oh, you triggered it ...)
<gamiee_>
:D
ungeskriptet is now known as Guest576
ungeskriptet has joined #linux-sunxi
<apritzel>
jernej: can you send an ACK for the H616 thermal patches, if you are fine with them now? Daniel said he would take all but the last patch (the .dts change), if he sees ACKs from the other maintainers
<apritzel>
and anarsoul kindly enough send his ACK for the sunxi thermal part (many thanks for that!)
Guest576 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest577
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
Guest577 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
mripard_ has quit [Remote host closed the connection]
ungeskriptet has quit [Read error: Connection reset by peer]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
<ity>
apritzel: ah, I see. I'll put it as required for the three audio things then
KREYREN_oftc has quit [Remote host closed the connection]
warpme has quit []
<ity>
apritzel: https://itycodes.org/A64.html got smth, can you take a look at it and check if it's correct and all? There's also a few TODOs, namely I am not really sure what each of the sound drivers do, what the media drivers do, what the PWM is needed for, and what's needed for the camera
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
ity: what's the difference between module and .ko?
<apritzel>
and I don't think we need explanations for every single driver, some parts are just internal, because how the subsystem or driver is structured
<apritzel>
what people are really after is more like functionality: like display, digital audio, video decoding, etc.
<apritzel>
so what about having one table, with the functionality in the first column, then the driver name in the second, or maybe just the CONFIG_ symbol name
<apritzel>
or maybe two tables: one with SoCs and driver names, a second with driver names and the KConfig symbol
<apritzel>
and you don't need to list hidden symbols, like SND_SUN8I_ADDA_PR_REGMAP
<apritzel>
users cannot select those, and Kconfig makes sure they are selected automatically when one of the other symbols is enabled
<apritzel>
you spot those hidden symbols by them having no prompt after the data type in the KConfig file, so just "bool" or "tristate"
<apritzel>
also I don't think we need SND_SUN8I_CODEC_ANALOG for the A64, do we?
<apritzel>
PWM is mostly used for LED or backlights, to control the brightness
<apritzel>
Jookia: did you find any evidence of CAN controllers in SoCs other than those the driver supports atm? Like H3/H5/H6/H616/A64? I don't see CAN mentioned there, and it sounds unlikely, but wanted to check
<Jookia>
apritzel: not that i can see from checking datasheets
<apritzel>
Jookia: thanks, I just find it odd that they had it in the early SoCs, and now have it again
<Jookia>
i get the vibe they have decided to put it in the 'industrial' socs, not ones designed for multimedia
<Jookia>
so i wouldn't expect to see it in H or A socs
<Jookia>
but who knows, allwinner is allwinner
<ity>
module is the name listed by lsmod, .ko is the name of the .ko file in /usr/share/modules/ (since they aren't the same, and some stuff might be sensitive to the - vs _). I am trying to document even the internal infrastructure of the stuff, aka what each driver corresponds to, as it's decently important in debugging things for me. I feel like the current style is pretty clear,
<ity>
you look at the functionality (eg Display), then set the right CONFIG in the kernel & modules to be loaded. I will try to think how to handle the hidden symbols, thanks for that! Had no idea those were a thing like that. I don't think SND_SUN8I_CODEC_ANALOG is listed? Unless I am blind. Thanks for the PWM explanation, I will add it!
<Jookia>
allwinner seem really protective of their CAN controller for some reason
<apritzel>
ity: this underscore/dash thing is documented in the kernel documentation somewhere. For instance you give both versions to modprobe and rmmod
<apritzel>
ity: what I want is this table for as many SoCs as possible, so we need to confine that to a single short entry
<apritzel>
if we have a second table, indexed by driver name, we can have more columns for each driver, like KConfig symbol, module file name, supported SoC list, etc.
<apritzel>
I don't think you need to list those hidden symbols at all, there is no point. Users select the high level options, and the rest is done automatically
<ity>
Hmm, I am not 100% sure I follow. I was thinking of having a similar set of tables for each SoC
<ity>
I wanna list it as I want the docs to answer the question *what is this module doing, can I safely remove it or do I need to include it for X feature*
<apritzel>
that sounds like a very special question, wouldn't: "what driver do I need for SoC xyz, for X feature" be more common and helpful
<apritzel>
then you just down your SoC column, and if your driver isn't in there, you don't need it
<Jookia>
you could build a dependency graph by reading /sys/module if you really want to
<ity>
Well, it's the same question in a way. If I simply *delete* the sun8i_tcon_top.ko, then it will no longer load and things will break, won't they?
<Jookia>
i think lsmod does this
<apritzel>
also this second table I mentioned could help: you list the SoCs supported for each driver
<ity>
I think I am a bit lost in the tables here haha
<Jookia>
/sys/devices tells you which modules are used by which hardware
<ity>
Jookia: Hmm, where? As in, which path
<apritzel>
ity: /sys/devices/platform on a live system is what Jookia is referring to
KREYREN_oftc has joined #linux-sunxi
<ity>
All devices? Like, overall?
<Jookia>
those are all the devices registerd in the kernel
<Jookia>
found from the dt and dynamically
<ity>
Hold on, all as in all, or those using dt, or
<apritzel>
all loaded modules
<ity>
It's very chaotic but that doesn't seem to be the case? At least, not in a general, every single module on all Linux systems kinda thing. I might also just be blind
<Jookia>
i think they pull in dependencies when probing
<ity>
Not sure I follow
<apritzel>
ity: all Linux systems? We are talking about the listing for a particular board and a running kenrel
<ity>
That is what I was asking. Whether that applies in general, or just in this particular case.
<apritzel>
Jookia: anyway, what ity (and others) are after is to get a list of required kernel config options, for a given SoC / board
<ity>
I am after documenting as much things as I can, and the list of required kernel options is indeed one of those ya
<Jookia>
ah
<Jookia>
that sounds a little messy and unstable
<Jookia>
good luck though
<ity>
Ah, why so?
<apritzel>
Jookia: sigh, I know :-) but it seems a lot of people don't want to listen, and keep asking the same questions here in the channel ;-)
<Jookia>
ity: kernel modules and configs aren't a stable interface, refactoring might change things up and break your config
<apritzel>
Jookia: so I figure we give them a link to a Wiki page and can keep doing real stuff ;-)
<Jookia>
maybe there is a way to make a script to find all the modules needed for a specific loaded system? not sure
<apritzel>
i think there is, you can automatically configure the kernel like this
<Jookia>
localmodconfig i think?
<apritzel>
yes, that's the one
<Jookia>
if i were to make something like this i would try to make a compatible->module mapping since that's how the kernel kind of handles things on these devices
<apritzel>
also the initrd build scripts do this somehow, as they copy only required modules into the image
<Jookia>
maybe there's something that can take a device tree, walk the compatibles, then walk the dependencies?
<apritzel>
I dimly remember there was something in scripts/, but can't find it quickly
<KREYREN_oftc>
> <apritzel> Jookia: so I figure we give them a link to a Wiki page and can keep doing real stuff ;-) < actually can we the fuck put the kernel modules together? it's been taking me nearly a month of hell and suffering to get that at least somewhat understood and working atm
<apritzel>
also there is /lib/modules/modules.alias, which already maps compatible strings to module names, used by the automatic module loading
<jernej>
scripts/dtc/dt_to_config
<jernej>
apritzel: ^
<ity>
Jookia: ah, fair. Would just have to follow the kernel as it updates no? Not sure I follow the "compatible" part though, what's meant by that?
<apritzel>
ah, jernej for the rescue, thanks!
<KREYREN_oftc>
like i have to use sun4i and sun8i for sun50i while kernel modules that are meant to not work on sun50i are required to work with sun50i and stuff alike atm
<ity>
Naming things is a very hard problem
<Jookia>
ity: you'll always have to follow kernel updates if you care about modules
<ity>
Yea obv
<apritzel>
KREYREN_oftc: kernel driver or module names don't mean anything, blame Allwinner for their inconsistent device / SoC / generation naming
<jernej>
driver are named by the first generation of SoC that they support
<jernej>
if cores are similar enough, it can extend very far
<apritzel>
exactly, we gave up coming with something meaningful
<KREYREN_oftc>
i blame sunxi bcs at very least we could make a sunx4i-drm to have an aliases for sun50i-drm that activate the same thing or sunxi_drm
<Jookia>
that's kind of what device tree compatibles are for
<apritzel>
jernej: now I see why I missed that script, it's in a subdirectory ;-)
<Jookia>
maybe you could add module aliases yourself?
<Jookia>
but kernel modules are just source files loaded at runtime, it's not really meant to represent something concrete
<KREYREN_oftc>
Jookia, i will try to re-organize it once i have a good enough understanding about kernel modules for teres i just annoyed by the real work comment
<KREYREN_oftc>
*i am
<Jookia>
' scripts/dtc/dt_to_config arch/arm/boot/dts/allwinner/sun9i-a80-cubieboard4.dts' gives some nice output
<KREYREN_oftc>
will take a look
<apritzel>
KREYREN_oftc: as you figured it's just a lot of work for one very particular problem, and for the next kernel version the list might be outdated again
<Jookia>
KREYREN_oftc: thanks for keeping up with this though. kernel work can be extremely, EXTREMELY frustrating. i spent a month getting fractional clocks working :( i still haven't even submitted that patch...
<Jookia>
because i need to update the i2s driver to support fractional clocks first...
<apritzel>
in general this problem has been solved by just providing all modules in /lib/modules, and you just get those loaded that the user needs
<Jookia>
i think desktops and systems with encrypted boot want a lightweight initrd that doesn't import all modules since they involve things like usb
<Jookia>
my distro's /lib/modules on my desktop is 293M
<ity>
Krey is tired and gave me a lot of the work to do instead haha :D Unfortunately I don't have direct access to a device rn, so I am stuck with reading the source code
<apritzel>
I mean this effort gets a bit futile if you for instance consider USB device drivers: how do you know which USB network adapter or sound card or what not a user wants to plug in to your laptop?
<Jookia>
yeah, it's not great if your usb keyboard stops working for your disk encryption...
<KREYREN_oftc>
apritzel, like yes but still there should be a better management for the kernel modules to make it less likely to need a change depending on versions and avoiding naming modules for one sub-family when it's used for multiples
<apritzel>
Jookia: that's why initrds are generated on the fly on your system, and get exactly those modules you need
<Jookia>
KREYREN_oftc: my two cents is you need to try and re-focus on things that are stable, and these are the tables the kernel uses to determine a module based on hardware, there is a different one for each bus
<apritzel>
KREYREN_oftc: I don't think you will get any renaming upstream, just because it's confusing. As I said, people will point you to the existing solutions.
<Jookia>
KREYREN_oftc: for device trees you have compatibles, for usb you have vendor/product ids, etc
<Jookia>
if you make a solution that works based on these you will have a much better time
<Jookia>
these are stable interfaces
<apritzel>
Having some kind of consistent naming is just never going to work in the long run, we gave up on this years ago, and just went with: first device to be supported gets the name, others piggy back on that
<Jookia>
the kernel also provides information about currently connected devices in these formats i think
<Jookia>
/sys/firmware/devicetree can be walked to find all the compatibles too
<Jookia>
i think sysfs is a stable interface, as are device trees
<KREYREN_oftc>
for that dt_to_config bcs env-dependent shebang
Syter has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
but seems to output helpful things
<Jookia>
all shebangs are env-dependent
<Jookia>
maybe you could create /bin/bash
<KREYREN_oftc>
oh i meant fs dependent
<KREYREN_oftc>
#!/usr/bin/env bash
<Jookia>
/usr/bin/env is fs dependent too
<KREYREN_oftc>
for the executable only
<Jookia>
yeah, same with /bin/bash
warpme has joined #linux-sunxi
<Jookia>
maybe you could make a script in /bin/bash that just runs /usr/bin/env bash ?
<ity>
There are systems that do not have a /bin/bash, it's recommended to use /usr/bin/env bash for scripts that need bashisms
<Jookia>
i didn't write the scripts i'm just telling you how to run them
<KREYREN_oftc>
ye fair
<KREYREN_oftc>
thanks for the pointer
<ity>
Could I maybe make a patch for fixing this in mainline, or is that not welcome?
<Jookia>
i think nixos is the only system to not have /bin/bash
<Jookia>
it's probably better to get nixos to add it
<ity>
Huh, why so?
<apritzel>
but dt_to_config is perl script?
<Jookia>
so you don't have to deal with /bin/bash ever again
<ity>
I think yielding to substandardtly-written scripts is not a good solution
<Jookia>
i mean this is only a nixos problem soo
<Jookia>
it seems like a bit of a problem created to solve nothing
<ity>
Because NixOS does not put bash on /bin/bash
<Jookia>
it makes /bin/sh which points to bash
<Jookia>
so it can just symlink to /bin/bash
<Jookia>
it just seems like a self-inflicted problem that doesn't provide any benefit to me and wastes everyone's time
<ity>
The script does not seem to use bashisms anyway...? I changed it to /bin/sh and it seemed to work
<Jookia>
/bin/sh is bash...
<Jookia>
unless you're on a system like debian?
<ity>
In compatiblity mode.
<ity>
Actually, it seems to not work on dash, hmm
<apritzel>
ity: great, please send a patch!
<aren>
I ran it with dash, which complained about lines 258 and 274
<ity>
Lemme try to fix it up to work with more shells then try sending a patch ^^ It will be my first patch to the kernel, so I am not really sure what I am doing...
<Jookia>
ity: could be a good first patch
<apritzel>
ity: that's the Open Source spirit: don't complain, but fix it ;-)
<apritzel>
though I have the feeling that people didn't put bash there without a reason. Most Kernel folks understand that difference quite well
<apritzel>
but give it a try, maybe you are lucky
<apritzel>
KREYREN_oftc: with "real work" I meant: there are so many things to do (code on the kernel side), for instance to enable/enhance drivers for all those SoCs like the H616, or to enable HDMI on the Teres-I, etc.
<KREYREN_oftc>
and all of that work blocked for me by me not having a clear understanding of the kernel configuration to avoid having non-clean environment for development
<KREYREN_oftc>
which is why i was annoyed by the comment
<KREYREN_oftc>
bcs from developing in non-sunxi part of the linux kernel that at least always bit me in the ass
<ity>
Any reason they use (( ${help} )) & set help=0 at the beginning + help=1 if the flag is used, instead of just... help=, & [ -n "${help}" ] + help=1 in the param
<Jookia>
ity: try checking git blame to see what commit introduced that
<ity>
I *think* it's the initial commit, 8 years ago with msg "dtc: create tool to diff device trees"