<smaeul>
apritzel: no, mctl_com == MBUS. so the whole mctl_com region uses the register layout from H6.
Serge_ has quit []
hallyn has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
tuxd3v has quit [Ping timeout: 480 seconds]
mehdix has quit []
mehdix has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
aggi has quit [Quit: connection closed.]
<MoeIcenowy>
smaeul: at least the CR register is old because it's bound to controller
paulk has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
paulk has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
<KotCzarny>
hello folks
<KotCzarny>
which module controls analog audio on h5 ?
<KotCzarny>
i've tried loading sun8i_codec_analog and sun50i_codec_analog
<KotCzarny>
but nothing showed in aplay -l
rajkosto has joined #linux-sunxi
<KotCzarny>
heh
<KotCzarny>
defconf is missing a lot of stuff
hlauer has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
paulk has quit [Quit: WeeChat 3.5]
paulk has joined #linux-sunxi
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
Daaanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
Daaanct12 has quit [Ping timeout: 480 seconds]
apritzel_ has left #linux-sunxi [#linux-sunxi]
montjoie has quit [Read error: Connection reset by peer]
montjoie has joined #linux-sunxi
JohnDoe_71Rus has quit []
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Quit: evgeny_boger]
apritzel has joined #linux-sunxi
<apritzel>
KotCzarny: defconfig is not there to cover every functionality on every system, but to provide a decent base which allows *booting* many boards and distros, so that people can bug hunt on the same config
<KotCzarny>
main problem with sunxi (and probably others) is those crypting submodules that are hard to find
<KotCzarny>
*cryptic
<KotCzarny>
that dont depend on each other and result in non working device
<KotCzarny>
and the naming is totally unintuitive for new users
<KotCzarny>
that's why default conf covering most (all?) possible devices for particular platform would be nice
<KotCzarny>
it's easier to cut down, than to hunt all those dependencies
<KotCzarny>
yeah
evgeny_boger has joined #linux-sunxi
<KotCzarny>
just hid sun4i_codec and sun8i_codec didnt find the audio card
<KotCzarny>
it might be triggering something that enables the device for sun8i_codec
<KotCzarny>
yup
<KotCzarny>
unless audio codec in h5 is sun4i one
<KotCzarny>
or its some kind of glue
anarsoul|2 has joined #linux-sunxi
anarsoul has quit [Read error: No route to host]
evgeny_boger has quit [Quit: evgeny_boger]
tuxd3v has joined #linux-sunxi
<apritzel>
KotCzarny: I think there is a common misunderstanding that configuring the kernel is something *you* (as a user) should do
<apritzel>
either you spend your sweet time in figuring everything out, but this is not trivial, as you have learned
<apritzel>
but normally you offload that task to distributions
<apritzel>
which spend a lot of time and effort in working out all the dependencies
<KotCzarny>
not trivial, yes
<apritzel>
this is not the 90s anymore, where you just create your own .config in an .hour and be happy
<KotCzarny>
but sun4i_codec required for sun8i_codec initialization is probably a bug
<apritzel>
KotCzarny: might well be, you know the drill then: report!
<KotCzarny>
i just did :)
<apritzel>
to the mailing list?
<KotCzarny>
i wonder if its that way since 4.10 or its something that changed lately
<KotCzarny>
tbh never played with h5 before much
<KotCzarny>
btw. is there some github with issues for sunxi? or the mailing list is the only way to report?
<apritzel>
the mainline kernel uses mailing list, please report there
<KotCzarny>
do i need some registeration or sending mail is enough?
<apritzel>
sending an email should be enough. Worst case is it requires moderation, which should be done in a few hours, at most
<KotCzarny>
linux-sunxi@lists.linux.dev ? or something specific for audio?
<KotCzarny>
mail sent
<KotCzarny>
offtopic, it's funny how adding crust lowered power usage (while playing audio) from 210mA to ~70mA
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit []
<KotCzarny>
microamp takes more in idle than the sbc, funny
ftg has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
<gamiee>
KotCzarny: the power idling is better managed thanks to crust
rajkosto has quit [Read error: Connection reset by peer]
Danct12 has quit [Remote host closed the connection]
rajkosto has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
rajkosto has joined #linux-sunxi
rajkosto has quit [Read error: Connection reset by peer]
<apritzel>
KotCzarny: are you sure that sun8i_codec is actually needed for the H5?
<KotCzarny>
yes
<KotCzarny>
i can check again tho
<KotCzarny>
yes
<KotCzarny>
both sun8i_codec_analog and sun4i_codec show 'used' >0
<KotCzarny>
i can try booting with sun8i_codec_analog removed from modules
<apritzel>
it looks like the H5, being very close to the H3, uses "allwinner,sun8i-h3-codec", but the A64 uses "allwinner,sun8i-a33-codec"
<apritzel>
the former is in sun4i_codec, but the latter in sun8i_codec
<KotCzarny>
hmm
<KotCzarny>
yes, it works without sun8i_codec_analog
<KotCzarny>
i wonder what was using it tho
<KotCzarny>
maybe hdmi?
<KotCzarny>
although hdmi is i2s
<apritzel>
and in general I think no one is expected to know those dependencies, as this should be automatically probed, by virtue of modules.alias knowing the compatible strings each module supports
tuxd3v has quit [Ping timeout: 480 seconds]
<KotCzarny>
in my case gotcha was thinking sun8i_codec was the audio part in h5
<KotCzarny>
otoh none of the analog codec were selected in defconfig
<apritzel>
as sound is rarely required to boot a board ...
<KotCzarny>
yes, but then it would be helpful to put at least socs lists in module description
<KotCzarny>
i guess you can nuke my report then on the list
<apritzel>
I don't think this is how it's supposed to work (SoC lists)
<KotCzarny>
btw. h3 is sun8i, no?
<apritzel>
by Allwinner's weird naming scheme, which confuses more than it helps: yes
<apritzel>
but driver naming doesn't mean anything, it's just some name that was invented at the time the first device got support
<apritzel>
hence all those sun4i names in the drivers
<KotCzarny>
then sunXi shouldnt be used in descriptions
<KotCzarny>
only soc names
<apritzel>
I think you are holding it wrong ;-)
<KotCzarny>
still, confusion reigns soc land
<apritzel>
either you know what you do, then you compile your own kernel, and maybe create your own config, but know that getting this to work can be tedious
<apritzel>
or:
<KotCzarny>
sure, but that information should be somewhere
<apritzel>
you leave that to distributions, that do all the hard work for you, compile and ship all the modules, and make sure they load automatically
<apritzel>
this information is in the compatible strings
<apritzel>
you match those from your DT to the drivers using them
<gamiee>
tbqh, I have issues with defconfig's too
<apritzel>
gamiee: because you are holding it wrong, see above ;-)
<KotCzarny>
maybe there should be some tool to walk the drivers and create a nice page with search/graph
<apritzel>
KotCzarny: I think there is something like that, but again: if you are compiling your own kernel, you either use a known-good config, or leave that to others to figure out
<KotCzarny>
sure, but the 'figure it out' part is lacking a bit
<gamiee>
this ^^
<apritzel>
KotCzarny: feel free to add something to the Wiki ...
<KotCzarny>
one shouldnt have to walk the drivers source to figure it out what particular module is for
<apritzel>
who is "one"?
<KotCzarny>
me
<KotCzarny>
or any other user new to sunxi land
<apritzel>
normally you shouldn't be in that business at all, you just use an Ubuntu or Debian or LibreELEC or what not kernel and it wortks
<KotCzarny>
and i guess most of the experienced one would be confused as well
<apritzel>
nobody said that creating a config and compiling a kernel is a walk in the park
<KotCzarny>
apritzel, did you forget linux roots?
<gamiee>
the thing is, if I'm compiling kernel, then I do that for custom distro and custom board. Mostly I just pick up default defconfig, hope that it will boot, and then add more stuff to enable peripherals I need, but it's messy, I'm always not sure if everything will work properly.
<KotCzarny>
it wasnt always like that
<apritzel>
things got more complicated
<KotCzarny>
in fact, one of the christianing rules was to 'build a kernel'
<apritzel>
in the 1990's, yes
<KotCzarny>
even in 2000's
<apritzel>
well, it's 2022
<KotCzarny>
still
<apritzel>
and you can do it
<apritzel>
it's just not trivial
<apritzel>
so you decide:
<apritzel>
either you invest the time to find that out (using the compatible strings)
<KotCzarny>
keeping a soc list in the description of the driver isnt a bad idea imo
<apritzel>
or you decide that lifetime is spent more wisely on other things, and use the kernels that LE bakes, for instance
<apritzel>
KotCzarny: if you want to maintain that: now, and in five years time, sure: just send a patch
<KotCzarny>
if it had everything i needed for particular task, yes
<apritzel>
or put that in the Wiki
<apritzel>
remember the Linux roots ;-) just do it!
<KotCzarny>
yup
<KotCzarny>
do you have any clue about 'figure out driver by compatibles' thingy so i wont reinvent the wheel?
<apritzel>
but send stuff early, to avoid disappointment, as this might get shot down by the maintainers, for the reasons I mentioned above
<apritzel>
KotCzarny: since compatible strings have a nice "vendor,device" syntax, most strings are pretty unique
<KotCzarny>
yes, but i'm asking if anyone did it already
<gamiee>
apritzel: adding sunxi stuff to defconfig is easier (since as you said, you can search for compatible strings), my issue is with everything else, all other things I need to enable within kernel to build a (let's name it) proper version of Linux
<apritzel>
KotCzarny: so in your case you could do: dtc mydt.dtb | grep compatible; then search for each string in the source: $ grep <compatible> drivers/
<KotCzarny>
apritzel, i know, just asking if there is a tool before i write my own parser/config generator
<apritzel>
but this is the embedded 2000's approach, where you tailor a kernel for a particular board
<apritzel>
I dimly remember there was something, but can't remember any details, sorry
<KotCzarny>
ok
<apritzel>
gamiee: what you are doing (creating a config from scratch, then compiling your custom kernel) is the "old" embedded approach
<KotCzarny>
nothing wrong with 'old' approach, if the result is slim kernel that builds quick as a bonus
<apritzel>
gamiee: and yes, this is tedious, that's why we pushed for a single image kernel approach in arm64, where distros compile *one* image and *one* set of modules
<apritzel>
KotCzarny: nothing wrong, *if* you are willing to invest the time
<KotCzarny>
yes, i dont mind investing time, just would be nice if the drivers werent hidden all around in the code forest
<KotCzarny>
:)
<apritzel>
what code forest? the drivers are nice in that they cover multiple devices, as they should
<apritzel>
as I said: normally you don't care, you just compile all drivers (as modules), and the system loads the right one
<KotCzarny>
for example who would know which audio driver is actually h5 using without digging through more than one source
<apritzel>
if you want to go the extra mile, and just want the drivers needed, you have to actually walk that mile
<KotCzarny>
btw. in my case system was actually autoloading sun8i_codec_analog too
<KotCzarny>
which confused me
<apritzel>
but didn't hurt anyone, right?
<gamiee>
KotCzarny: in this case, best way is to enable all SUNXI based drivers, and then slim it down by testing if it will still work after remove.
<KotCzarny>
it did
<gamiee>
apritzel: yeah, this is good movement for single-board computers and arm64 based computers, but as KotCzarny said, for embedded devices, I need to go this way
<apritzel>
yes, but for *true* embedded devices you should know what you are doing
<apritzel>
nobody said that creating a custom kernel and custom config would be an easy thing
<KotCzarny>
sure, but why putting additional hurdles, all it would take would be having description that isnt confusing
<apritzel>
true embedded devices as in: you are a company shipping some product
<apritzel>
what description are you thinking of?
<gamiee>
apritzel: well, then I'm doing true embedded devices: I'm single-person company shipping some product.
<KotCzarny>
Symbol: SND_SUN8I_CODEC_ANALOG
<apritzel>
put "this covers A10, A20, A33, A23, ..... " in there? And then never update that? (Because this is what happens)
<KotCzarny>
| the codec embedded in newer Allwinner SoCs. |
<KotCzarny>
| Say Y or M if you want to add support for the analog controls for |
<KotCzarny>
how would you know the 'newer' ones?
<KotCzarny>
is h5 newer one or not yet?
<gamiee>
I totally understand it's not easy, I'm very well aware of that, issue is lack of information around defconfigs, and getting it work is just big roulette if you will have just all modules and things enabled as you need for stable and good working build.
<KotCzarny>
Symbol: SND_SUN4I_CODEC
<KotCzarny>
| Select Y or M to add support for the Codec embedded in the Allwinner |
<KotCzarny>
| A10 and affiliated SoCs. |
<KotCzarny>
so, which socs are 'affiliated' to a10 ?
<apritzel>
yes, that is exactly the problem: no one updates those entries
<KotCzarny>
(rethoric question)
<KotCzarny>
that's why i'm saying the descriptions are confusing
<apritzel>
patches welcome ;-)
<KotCzarny>
:)
<KotCzarny>
is bug report enough? ;)
<KotCzarny>
but audio is just an easy example
<KotCzarny>
other drivers suffer similiar fate
<apritzel>
nd yeah, those entries were created about a decade ago, when the AW world was still quite manageable
<apritzel>
if you only look at AW's latest offering: they are going crazy on SKUs, shipping dozens of SoCs which are similar, but differ in slight details
<apritzel>
nobody wants to update those lists in Kconfig
<KotCzarny>
yeah, i understand that too
<apritzel>
especially if that is just informative, and we have the actual information in the drivers and DTs: the compatible strings
<KotCzarny>
but for socs that are quite well mainlined, it would be nice to have proper description
<KotCzarny>
i shall write the compatibles parser/config generator and put it in wiki one day
<apritzel>
or create a new page with a table of symbols needed for certain functionality on each SoC
<KotCzarny>
nah, it should be dynamic
<apritzel>
for those people that want to bake their own kernels
<gamiee>
Generally, Allwinner is stagnating a lot recently
<KotCzarny>
ie. easy to regenerate
<gamiee>
apritzel: that's actually good idea
<apritzel>
gamiee: I think AW is moving in a different direction: they are creating specific SoCs for specific needs, for cheap
<KotCzarny>
werent it the same long time ago? ie. they generally had tablet/stb socs mostly
<apritzel>
for instance one small SoC with two camera interfaces, or something with a lot of audio, plus a NPU, for smart speakers, and so on
<gamiee>
apritzel: yeah, it looks like that, but it's visible on the socs, silicon bugs, BSP being totally terrible etc.
<apritzel>
KotCzarny: to some degree: yes, but they are diversifying much more now
<gamiee>
From me, only V-series looks interesting, like V851 looks amazing
<apritzel>
look at the A20: that had everything, for tablets, STBs and even automotive
<gamiee>
H616 is in dust (in terms of interest from business)
machinehum has quit [coherence.oftc.net synthon.oftc.net]
jakllsch has quit [coherence.oftc.net synthon.oftc.net]
qwestion has quit [coherence.oftc.net synthon.oftc.net]
narmstrong has quit [coherence.oftc.net synthon.oftc.net]
gnarface has quit [coherence.oftc.net synthon.oftc.net]
samueldr has quit [coherence.oftc.net synthon.oftc.net]
smaeul has quit [coherence.oftc.net synthon.oftc.net]
Luke-Jr has quit [coherence.oftc.net synthon.oftc.net]
NekoMay has quit [coherence.oftc.net synthon.oftc.net]
eldondev has quit [coherence.oftc.net synthon.oftc.net]
Turl has quit [coherence.oftc.net synthon.oftc.net]
anarsoul|2 has quit [coherence.oftc.net synthon.oftc.net]
sunshavi_ has quit [coherence.oftc.net synthon.oftc.net]
pnill has quit [coherence.oftc.net synthon.oftc.net]
Asara has quit [coherence.oftc.net synthon.oftc.net]
linusw___ has quit [coherence.oftc.net synthon.oftc.net]
dmh_ has quit [coherence.oftc.net synthon.oftc.net]
buZz has quit [coherence.oftc.net synthon.oftc.net]
NishanthMenon has quit [coherence.oftc.net synthon.oftc.net]
lvrp16___ has quit [coherence.oftc.net synthon.oftc.net]
tomf_ has quit [coherence.oftc.net synthon.oftc.net]
diveben_ has quit [coherence.oftc.net synthon.oftc.net]
palmer has quit [coherence.oftc.net synthon.oftc.net]
arnd_ has quit [coherence.oftc.net synthon.oftc.net]
Pinchiukas has quit [coherence.oftc.net synthon.oftc.net]
key2__ has quit [coherence.oftc.net synthon.oftc.net]
benettig has quit [coherence.oftc.net synthon.oftc.net]
Benjojo has quit [coherence.oftc.net synthon.oftc.net]
sauce has quit [coherence.oftc.net synthon.oftc.net]
megi has quit [coherence.oftc.net synthon.oftc.net]
Hypfer has quit [coherence.oftc.net synthon.oftc.net]
JoaoSchim has quit [coherence.oftc.net synthon.oftc.net]
ynezz has quit [coherence.oftc.net synthon.oftc.net]
freemangordon has quit [coherence.oftc.net synthon.oftc.net]
sajattack[m] has quit [coherence.oftc.net synthon.oftc.net]
insep has quit [coherence.oftc.net synthon.oftc.net]
cyrozap has quit [coherence.oftc.net synthon.oftc.net]
montjoie has quit [coherence.oftc.net synthon.oftc.net]
hentai has quit [coherence.oftc.net synthon.oftc.net]
gamiee has quit [coherence.oftc.net synthon.oftc.net]
digetx has quit [coherence.oftc.net synthon.oftc.net]
Esmil has quit [coherence.oftc.net synthon.oftc.net]
hunbalazs has quit [coherence.oftc.net synthon.oftc.net]
mehdix has quit [coherence.oftc.net synthon.oftc.net]
igraltist has quit [coherence.oftc.net synthon.oftc.net]
milek7_ has quit [coherence.oftc.net synthon.oftc.net]
PPAChao has quit [coherence.oftc.net synthon.oftc.net]
libv has quit [coherence.oftc.net synthon.oftc.net]
vpeter has quit [coherence.oftc.net synthon.oftc.net]
szemzoa has quit [coherence.oftc.net synthon.oftc.net]
obbardc9 has quit [coherence.oftc.net synthon.oftc.net]
JuniorJPDJ has quit [coherence.oftc.net synthon.oftc.net]
cmeerw[m] has quit [coherence.oftc.net synthon.oftc.net]
t4h4[m] has quit [coherence.oftc.net synthon.oftc.net]
psydroid[m] has quit [coherence.oftc.net synthon.oftc.net]
Arthur[m]123 has quit [coherence.oftc.net synthon.oftc.net]
pgwipeout[m] has quit [coherence.oftc.net synthon.oftc.net]
z3ntu has quit [coherence.oftc.net synthon.oftc.net]
Tooniis[m] has quit [coherence.oftc.net synthon.oftc.net]
swiftgeek has quit [coherence.oftc.net synthon.oftc.net]
evadot has quit [coherence.oftc.net synthon.oftc.net]
ndufresne has quit [coherence.oftc.net synthon.oftc.net]
jemk has quit [coherence.oftc.net synthon.oftc.net]
rtp has quit [coherence.oftc.net synthon.oftc.net]
maz has quit [coherence.oftc.net synthon.oftc.net]
apritzel has quit [coherence.oftc.net synthon.oftc.net]
hexdump0815 has quit [coherence.oftc.net synthon.oftc.net]
hallyn has quit [coherence.oftc.net synthon.oftc.net]
indy has quit [coherence.oftc.net synthon.oftc.net]
LordKalma has quit [coherence.oftc.net synthon.oftc.net]
diego71 has quit [coherence.oftc.net synthon.oftc.net]
dittid[m] has quit [coherence.oftc.net synthon.oftc.net]
oliv3r[m][m] has quit [coherence.oftc.net synthon.oftc.net]
Nemo_bis_ has quit [coherence.oftc.net synthon.oftc.net]
pmp-p has quit [coherence.oftc.net synthon.oftc.net]
jernej has quit [coherence.oftc.net synthon.oftc.net]
dliviu has quit [coherence.oftc.net synthon.oftc.net]
mnemoc has quit [coherence.oftc.net synthon.oftc.net]
jelly has quit [coherence.oftc.net synthon.oftc.net]
aperezdc_ has quit [coherence.oftc.net synthon.oftc.net]
AntoniAloyTorrens[m] has quit [coherence.oftc.net synthon.oftc.net]
MatrixTravelerbot[m] has quit [coherence.oftc.net synthon.oftc.net]
SkallwarEstebanBlanc[m] has quit [coherence.oftc.net synthon.oftc.net]
aedancullen has quit [coherence.oftc.net synthon.oftc.net]
mripard has quit [coherence.oftc.net synthon.oftc.net]
karlp has quit [coherence.oftc.net synthon.oftc.net]
heap01_ has quit [coherence.oftc.net synthon.oftc.net]
rellla has quit [coherence.oftc.net synthon.oftc.net]
ad__ has quit [coherence.oftc.net synthon.oftc.net]
ftg has quit [coherence.oftc.net synthon.oftc.net]
paulk has quit [coherence.oftc.net synthon.oftc.net]
KotCzarny has quit [coherence.oftc.net synthon.oftc.net]
juri_ has quit [coherence.oftc.net synthon.oftc.net]
bauen1 has quit [coherence.oftc.net synthon.oftc.net]
DuClare has quit [coherence.oftc.net synthon.oftc.net]
ats has quit [coherence.oftc.net synthon.oftc.net]
Newbyte has quit [coherence.oftc.net synthon.oftc.net]
pg12_ has quit [coherence.oftc.net synthon.oftc.net]
arti has quit [coherence.oftc.net synthon.oftc.net]
bantu has quit [coherence.oftc.net synthon.oftc.net]
DavidHeidelberg[m] has quit [coherence.oftc.net synthon.oftc.net]
chuang[m] has quit [coherence.oftc.net synthon.oftc.net]
kilobyte_ has quit [coherence.oftc.net synthon.oftc.net]
plaes has quit [coherence.oftc.net synthon.oftc.net]
blathijs has quit [coherence.oftc.net synthon.oftc.net]
veremitz has quit [coherence.oftc.net synthon.oftc.net]
cyrozap has joined #linux-sunxi
MatrixTravelerbot[m] has joined #linux-sunxi
blathijs has joined #linux-sunxi
<apritzel>
there should literally be nothing board specific in there, as the contract is the ARM architecture, the AArch64 ELF PCS (calling convention, register usage, linking) and the Linux kernel ABI (syscalls, etc.)
<apritzel>
nothing of which is platform specific
<apritzel>
gamiee: to make that clear: I boot an off-the-shelf Ubuntu kernel on AW boards
<apritzel>
(just not for development, where I use a much slimmed down config, because I can't wait all day for it to compile)
<KotCzarny>
exactly
<KotCzarny>
:)
<gamiee>
KotCzarny: well, that person is me, since I'm single person in company :D
<apritzel>
KotCzarny: have you tried to compile some allmodconfig kernel, then grab that information you need from the modules.alias file?
<gamiee>
apritzel: I understand it, although, in my case, shipping the distro kernel is not good, since it's bigger and I need to have slimmest kernel as possible (also good to note is that I use Buildroot to build the firmware)
<apritzel>
gamiee: well, then you should be able to justify the time spent, since you have a business case
<apritzel>
and if you do it correctly, it's a one time effort
<apritzel>
for instance I use a separate build directory (as you should do, too), and have my .config under git revision control there
<apritzel>
where I once started with defconfig, then added symbols as needed, so I don't lose them
<apritzel>
and I do "make oldconfig" on every -rc1, and commit that, so I can just around kernel versions easily
<apritzel>
s/just/jump/
<apritzel>
and you can also keep different configs for difference purposes, in branches
<gamiee>
apritzel : oh that's good tips, thanks! And yeah, looks like I will just need to try and test, but so far, I had success with default defconfig and custom additions
<apritzel>
gamiee: yeah, defconfig plus what you need is the probably the most sane, for specific needs
<apritzel>
you just keep adding drivers/symbols over time, whenever you stumble upon something missing
<KotCzarny>
and defconfig for arm64 puts a lot of unnecesry things though, since it's not particular vendor/platform specific
<gamiee>
Yeah, okay, once again thanks, this helped me a lot, now I'm sure I'm doing it good (in my use case :D)
<KotCzarny>
also, that defconfig didnt add audio modules for example ;)
<KotCzarny>
but not only that, tmpfs was also missing
<KotCzarny>
etc etc
<apritzel>
KotCzarny: yes, but be careful there, since then you might remove things that are needed, because those kernel developer morons don't name the symbols in a way that make it obvious what they do :-D
<KotCzarny>
hehe
<gamiee>
D
<apritzel>
if you are up for a real challenge, try starting with "make tinyconfig" ;-)
<KotCzarny>
long time ago i did something to that effect
<KotCzarny>
its fun to discover how things depend on each other
<apritzel>
fun, but also tedious!
<apritzel>
so don't complain ;-)
<KotCzarny>
and you have to enable few other things to even be able to see interesting options ;)
<apritzel>
gamiee: if you really want to go custom kernel, you can disabled PCI and all other platforms except sunxi, that removes already a lot of drivers and is done in a minute
<KotCzarny>
unless you have h6 etc, and you want pci? ;)
* apritzel
doesn't want to hear anything about H6 and PCI ...
<apritzel>
KotCzarny: no in mainline anyway
<KotCzarny>
now i wonder which bright head thought it's a nice idea to remove spi params from module options for fbtft, ech
<apritzel>
KotCzarny: git log/git annotate would tell you ;-)
<KotCzarny>
because you know, it's easier to modify dts every time you need to find out the correct params..
<KotCzarny>
then try and reload it on working kernel
<mripard>
KotCzarny: on the other hand, dts are easier to distribute
<mripard>
it's a trade-off, really
<KotCzarny>
sure, its nice if you have something popular
<apritzel>
KotCzarny: use the "fdt" command in U-Boot, that can modify a DT on the fly
<mripard>
and fbtft is going away anyway
<KotCzarny>
i will just hack the module source
<KotCzarny>
and write dts later
<KotCzarny>
once i know the working params
<gamiee>
apritzel: yeah want to do that soon, I just added new things, nothing removed yet so even now the firmware is big, but it's not finished yet, so this is next task.
cnxsoft has quit []
JohnDoe_71Rus has joined #linux-sunxi
<smaeul>
sun8i_codec is effectively == built-in AC100, so it is only found on the "phone/tablet" SoCs that are expected to have a GSM modem (in fact megi has patches adding support for the actual AC100 to that driver)
<smaeul>
06:49 <KotCzarny> offtopic, it's funny how adding crust lowered power usage (while playing audio) from 210mA to ~70mA
<KotCzarny>
hi smaeul :)
<smaeul>
that's probably mostly due to DRAM DVFS, which will go into self-refresh at the lowest step
<KotCzarny>
and thank you for the hard work on crust
<smaeul>
you could reduce that a bit further by enabling cpuidle (build TF-A with SUNXI_AMEND_DTB=1 and use $fdtcontroladdr, or patch the DTS yourself)
<KotCzarny>
what is the lowest mA you have hit without suspend?
<smaeul>
KotCzarny: hi, and thanks! it's exciting to see crust get more usage and mostly Just Work
<smaeul>
without suspend? highly depends on the board
<KotCzarny>
top1 with h3/h5/a64 ?
<smaeul>
e.g. Orange Pi 3 has a USB 3 hub which eats hundreds of mW all of the time
<smaeul>
I don't have numbers handy, sorry
<KotCzarny>
mhm, 70mA is not bad at all
<KotCzarny>
and all that with vanilla kernel
<gamiee>
Hello smaeul, one question, please, is there something from crust side, what would improve thermals of H3?
<KotCzarny>
i've tried compiling the tree with patches but it didnt boot
<bauen1>
does the pine64-lts have like a jumper where you can measure power consumption ?
<KotCzarny>
ahm, your link is just list of commits
<smaeul>
yeah, I'd recommend cherry-picking what you want on top of your preferred stable version
<gamiee>
smaeul: wait, that doesn't work currently? :/ I have product with H3 and it suffers from thermal issues, so anything what will help would be handy.
<KotCzarny>
gamiee: biggest help is having cpu voltage regulator on the board
<smaeul>
gamiee: DRAM DVFS would be the largest improvement in actually reducing heat generated (not just better throttling)
<smaeul>
assuming you already have CPU DVFS working
<gamiee>
KotCzarny: yeah, I know, although, I'm using existing SBC for the first version (due all required manufacture costs and certifications would cost too much for the beginning), and this SBC uses only switch between two voltages for CPU :/
<smaeul>
and no, currently the sun8i-a33-mbus driver is only enabled for A64 and H5
<smaeul>
for H3, it just needs some debugging. which is a bit tricky when the DVFS process blocks DRAM access. thankfully crust has a peek/poke command line over serial and runs from SRAM :)
<smaeul>
and I just brought up crust on A33 last weekend, so it should be possible to add A33 support now as well
<gamiee>
smaeul: well, if by CPU DVFS you mean switching between 1.1V and 1.3V for VDD-CPUX, then yes, as far as I remember, that worked just fine (but I might verify it once again when doing stress tests)
<jernej>
KotCzarny: scripts/get_maintainer.pl sound/soc/sunxi/ <- this will list all relevant MLs and maintainers
<KotCzarny>
jernej, does it allow loading dtb from user space?
<jernej>
bugs should be reported to all relevant MLs
<jernej>
I mean wishes around kernel config
<jernej>
I'm not sure I like idea of loading dtb from users space. Some info is needed before userspace is up and changing dtb after the fact just calls for troubles.
<KotCzarny>
for devel/trying to find out working config it's ok
<KotCzarny>
instead of rebooting every time
<jernej>
If I ever need to find some special driver, I basically did what dt_to_config does by hand.
<jernej>
looked up compatible string, search for it, look at Makefile and finally at Kconfig
tuxd3v has joined #linux-sunxi
paulk has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
jernej: thanks, dt_to_config was what I was thinking of - and what I typically do manually ;-)
<gamiee>
jernej: thanks that's really handy
<jernej>
apritzel: btw, do you plan to send rfc for ac200 ephy?
ftg has joined #linux-sunxi
JohnDoe_71Rus has quit []
<apritzel>
yes, I managed to solve the clock problem properly: adding a clocks property to the generic PHY driver, adding a generic regmap clock gate, and then using both in the EPHY control driver
<apritzel>
just needs some testing, and then weeks of discussion ;-)
<apritzel>
jernej: was the H616 the same when it comes to the AC200 integration? I2C3 device 0x10 and pwm clock #1?
<apritzel>
jernej: ah, thanks for the pointer, I remembered you got this working in U-Boot ...
<apritzel>
jernej: I tried the other day to apply the H6 version of this hack to mainline U-Boot, and it's not trivial, as we got quite some changes meanwhile
<apritzel>
proper support isn't trivial either, so I am back to loading my test kernels via FEL ...
evgeny_boger has quit [Quit: evgeny_boger]
tuxd3v has quit [Ping timeout: 480 seconds]
rajkosto has quit [Read error: Connection reset by peer]