ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel has quit [Ping timeout: 240 seconds]
<alyssa>
Are there any norms for how to organize kernel drivers with more than one file?
<alyssa>
I guess that's probably subsystem specific
LeSpocky_ has joined #armlinux
LeSpocky has quit [Ping timeout: 245 seconds]
arnd has quit [Ping timeout: 240 seconds]
sjg1 has quit [Read error: Connection reset by peer]
sjg1 has joined #armlinux
broonie has quit [Ping timeout: 258 seconds]
arnd has joined #armlinux
broonie has joined #armlinux
Drek45 has quit [Quit: Leaving]
amitk has joined #armlinux
Drek45 has joined #armlinux
Drek45 has quit [Ping timeout: 252 seconds]
_whitelogger has joined #armlinux
sven has joined #armlinux
marcan has joined #armlinux
Patater has quit [*.net *.split]
vup has quit [*.net *.split]
abelvesa has quit [*.net *.split]
palmer has quit [*.net *.split]
palmer1 has joined #armlinux
abelvesa has joined #armlinux
Patater has joined #armlinux
rfs613 has joined #armlinux
vup has joined #armlinux
Drek45 has joined #armlinux
<biot>
alyssa: my impression as well... some have hardly any headers even
guillaume_g has joined #armlinux
sakman has quit [Remote host closed the connection]
guillaume has joined #armlinux
tudorel has joined #armlinux
guillaume_g has quit [Ping timeout: 252 seconds]
guillaume is now known as guillaume_g
sakman has joined #armlinux
sakman has quit [Remote host closed the connection]
LeSpocky_ is now known as LeSpocky
sakman has joined #armlinux
frieder has joined #armlinux
iivanov has joined #armlinux
Drek45 has quit [Ping timeout: 245 seconds]
eduardas has joined #armlinux
Pali has joined #armlinux
apritzel has joined #armlinux
Nact has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 244 seconds]
matthias_bgg has joined #armlinux
bps has joined #armlinux
<HdkR>
Is there a way to get partial faulting FD reads working on AArch64? I've noticed this...misfeature is supported on x86 but not AArch64
guillaume has joined #armlinux
guillaume has quit [Client Quit]
guillaume has joined #armlinux
guillaume_g has quit [Ping timeout: 250 seconds]
guillaume is now known as guillaume_g
monstr has joined #armlinux
apritzel has joined #armlinux
alpernebbi has joined #armlinux
punit_ is now known as punit
alpernebbi has quit [Quit: alpernebbi]
atorgue has joined #armlinux
<alyssa>
HdkR: partial.. faulting?
Amit_T has joined #armlinux
guillaume_g has quit [Ping timeout: 250 seconds]
guillaume_g has joined #armlinux
tmlind_ is now known as tmlind
monstr has quit [Remote host closed the connection]
Drek45 has joined #armlinux
<gpiccoli>
Hey folks, I'm new to the ARM development, I'm curious about something - device tree vendor spec. I mean, how the device tree specs are constructed on kernel? In other words, where thedata come from ?
<gpiccoli>
I guess board vendors do have a specification with the details, like clocks, frequencies, voltage, registers, etc? And this is written in the dts file, does it make sense ?
<jn>
gpiccoli: there are three parts coming together
<jn>
- infomation about the hardware is available in datasheets and reference manuals, etc.
<jn>
- the devicetree bindings (which bind the DT syntax to meaning) is defined in files in Documentation/devicetree/bindings/ in the linux source tree
<jn>
- combining the two, a devicetree can be written for any particular device (it's usually split into a .dtsi for the SoC and a .dts for the board)
<jn>
not sure what you mean by "device tree specs" though
<Amit_T>
and even firmware populates some of the DT data at runtime.
<gpiccoli>
awesome jn (and Amit_T ), thank you! My question is more about the part 1 on what you just explained
<gpiccoli>
the datasheets/ref manuals
<gpiccoli>
So, to create this dtsi/dts files, besides knowing the syntax (based on the bindings documentation), it's even more important to know the hardware details, right? Which can be usually obtained through the vendor docs, like datasheets
<gpiccoli>
As an example, do you know any vendor that provides such datasheets publicly, so I can compare to the dtsi/dts file ?
<jn>
yes
<gpiccoli>
It's a good way to study the syntax, to understand how one usually "translates" between the vendor docs and the dts(i) files
<jn>
Freescale/NXP is a good example, at least for most of the i.MX series
<gpiccoli>
ok, great!! I'll try to find some of their doc then!
<jn>
Allwinner datasheets also float around in the internet (see linux-sunxi.org)
<jn>
a word on nomenclature:
<jn>
sometimes you find "datasheets" and "technical reference manuals"
<jn>
in that case the DS contains pinout, electrical characteristics, ordering information, etc.
<jn>
while the TRM contains all the nice details necessary for programming the chip
guillaume_g has quit [Quit: Konversation terminated!]
<jn>
(this split is especially the case with NXP)
<gpiccoli>
oh, great! Thanks a lot jn =))
bps has quit [Ping timeout: 252 seconds]
<alyssa>
and then sometimes the TRM doesn't provide what you need to program the chip either
<jn>
true
<gpiccoli>
hehe business as usual lol
<gpiccoli>
does any of you know if Qualcomm is as friendly as NXP with regards to docs ?
<gpiccoli>
I guess I understand now how to look that info - for example, I want precise information to describe an ethernet controller in dts format, and for that, I'd like to see the detailted datasheet for Atheros 8151 controller
<gpiccoli>
Atheros is a Qualcomm company, hence my question.
eduardas has quit [Quit: Konversation terminated!]
<jn>
it's probably worse
headless has joined #armlinux
frieder has quit [Remote host closed the connection]
<jn>
Atheros stuff from the pre-qcom days might be a bit easier
<jn>
gpiccoli: anyway, from the product sheet (those two pages of advertising information), i could see that the AR8151 has a PCIe interface
<jn>
PCIe is a discoverable bus, it doesn't need devicetree description
<gpiccoli>
yeah, it has !
<jn>
the tbale in drivers/net/ethernet/atheros/atl1c/atl1c_main.c looks like it includes 8151 support
<jn>
(or maybe not)
<gpiccoli>
really? Although it's under PCIe, the device-tree for my 4.14 working kernel has a description of that, I guess the description is a PHY
<gpiccoli>
this one is deactivated on the new kernels
<jn>
well, show details :)
<gpiccoli>
like 5.6+ , due to an ew devtree commit for my board (inforce)
<gpiccoli>
sure!
<gpiccoli>
jn, this is the description on 4.14, which I think is responsiblefor making the eth work: https://termbin.com/lyl5
<gpiccoli>
there's a disable there, I'll change it and I hope eth is discoverable
<gpiccoli>
But what about other stuff, like clocks...
<gpiccoli>
maybe I'm talking bullshit hehe - but they differ between them, I'm not sure if this value is a handle inside the devtree file (then it's naturalk to differ) or if this comes from the spec
<gpiccoli>
Also, there are multiple things missing in the newer devtree (from 5.6+), like modem, camera stuff, differences in some pins, voltage, etc
<jn>
ah, a qcom msm SoC
<jn>
"qcom,msm8996-qmp-pcie-phy" -- it's the PCIe PHY, the physical layer hardware for PCIe
<jn>
not related to atheros
<gpiccoli>
ok, cool! I think the atheros device is under this PCIe phy/controller - not having this enable, just make the eth absent
<gpiccoli>
same for other of these pcie,phy entries vs usb3
<jn>
makes sense
<jn>
the PCIe PHY is necessary for PCIe to work
<gpiccoli>
indeed! but how can I be sure the 4.14 value is correct, it's a linaro tree (landing-team) ? Hence my search for the official doc
<jn>
which value? each of these snippets is a page full of values
<gpiccoli>
oh yeah, I agree - I'm saying in a more generic way. for any of the devtree entries, if I have a difference between 4.14-qcom_lt tree vs the upstream dts, how to be sure which is correct? One must rely in some official guide/document, and this should be the official datasheets
<alyssa>
wait till you get to hw with no public docs *or* public code š
<jn>
in an ideal world, you could look at the hardware documentation for hardware facts (---- yeah, probably not with QCOM MSM)
<jn>
beyond that, you have to understand what the difference *means*
<jn>
sometimes both variants can be correct, etc.
<gpiccoli>
ugh alyssa , seems like an exercise of patience hehe
<jn>
sometimes the devicetree binding is different between the two kernel versions you're looking at
<gpiccoli>
agreed jn!!
bps has joined #armlinux
bps has quit [Changing host]
bps has joined #armlinux
<gpiccoli>
need to understand exaclty what does it *mean* , and if the difference makes sense. Lemme give you an example: I'm feeling on newer kernels, the board is very slow, I/O-wise. And I found a lot of differences on the UFS bindings between the kernels (and also in the cpu freq bindings, upstream seems to "ceil" the max bogomips stuff)
<gpiccoli>
so, I'll investigate these to try understanding if this is causing some performance limitations on the board when using upstream kernel
<jn>
ok, if there are differences in the bindings, you have to read each devicetree in the corresponding binding to extract the same kind of "facts". then you can compare the facts stated in the two DTs
<gpiccoli>
make sense! I'm doing this I guess - extracted both in dts/sorted, and comparing...and I'm also "resourcing" to the kernel bindings docs =)
elastic_dog has quit [Ping timeout: 250 seconds]
<jn>
good good
<jn>
(and i don't envy you for trying to hunt down a UFS performance regression. it sounds pretty complicated)
<alyssa>
gpiccoli: is the regression from downstream to mainline or from older mainline to newer mainline?
<alyssa>
if the former, why do you think it's a DTS issue (and not a driver bug, or missing driver optimization, etc)?
<alyssa>
if the latter, bisection might be faster
<gpiccoli>
lol jn, although complicated ,seems interesting!
<jn>
alyssa: or worse, a regression from older downstream to newer downstream
<gpiccoli>
alyssa, the regression was noticed between 2 linaro trees, the 4.14-qcom_lt and 5.4-qcom_lt
<gpiccoli>
jn: this ^
<gpiccoli>
lol
<gpiccoli>
and you're totally right alyssa , could be a driver issue, a lot of stuff...
<gpiccoli>
I'll try booting a 5.13/5.10 tree and see if that persists, if so I'll try to compare and make the dts for ufs nodes the same. If all fails, likely it's a kernel "regression", so let's see
<gpiccoli>
could be a plethora of stuff, from blk-layer, ufs-related drivers, iommu even!
elastic_dog has joined #armlinux
<alyssa>
You seem very excited about the prospect of an iummo bug
<alyssa>
iummo
<alyssa>
iommu
<gpiccoli>
haha I would be! love that kind of code...but (hopefully?) it's going to be simpler!
<jn>
gpiccoli: in case you want to complicate matters and test a third kernel, there is some SoC support for MSM8996 in mainline...
headless_ has joined #armlinux
<gpiccoli>
indeed there is! I tried, and failed to work for 5.4 - unless I use qcom tree. But for 5.13, this is the way to go, after I make eth/usb to work hehe
headless has quit [Ping timeout: 252 seconds]
headless_ is now known as headless
<alyssa>
device trees turn my brain to guacamole
<jn>
at least there's no FORTH involved, these days
<alyssa>
there used to be forth?
<jn>
yes, devicetrees emerged out of OpenFirmware, and the OS had the call function pointers in the firmware to traverse the devicetree
<jn>
i forgot the exact details
<jn>
(back in the days of the PowerMacs, for example)
<Xogium>
oh yeah device tree is hard sometimesā¦ but I like it too, kinda. I like the way it allows you to configure things
<Xogium>
I wish x86 was like that ;)
<alyssa>
oof
<Xogium>
bios hurt my head even more since I can't even use one
<jn>
some people wanted to use kexec on powerpc machines, so they invented the kind of flattened devicetree that remained popular in linux
<Xogium>
hah good old kexec
<jn>
apple invented its own kind of flattened devicetree for the iphones, apparently
<alyssa>
Yeppo
<jn>
(but the common roots can be seen)
<alyssa>
used on the m1 macs too
<jn>
interesting how these decades-old technological lineages run through the computing world
<Xogium>
honestly I stayed on x86 because I need a powerhouse without having to pay a fortune for one that is primarily netwrok-focusedā¦ And lets face it, to date, I have not seen a SoC that could be as powerful or even more powerful than a ryzen threadreaper, for example
sakman has quit [Remote host closed the connection]
headless has quit [Quit: Konversation terminated!]
Drek45 has quit [Ping timeout: 250 seconds]
apritzel has quit [Ping timeout: 244 seconds]
sakman has joined #armlinux
sakman has quit [Remote host closed the connection]
sakman has joined #armlinux
sakman has quit [Remote host closed the connection]
tudorel has quit [Quit: tudorel]
headless has joined #armlinux
Drek45 has joined #armlinux
Drek45 has quit [Read error: Connection reset by peer]
apritzel has joined #armlinux
sakman has joined #armlinux
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #armlinux
apritzel has quit [Ping timeout: 244 seconds]
Drek45 has joined #armlinux
Amit_T has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 240 seconds]
Drek45 has quit [Ping timeout: 244 seconds]
Nact has joined #armlinux
Drek45 has joined #armlinux
headless has quit [Quit: Konversation terminated!]
Nact has quit [Quit: Konversation terminated!]
Nact has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
djrscally has joined #armlinux
apritzel has joined #armlinux
Drek45 has quit [Remote host closed the connection]
Pali has quit [Ping timeout: 244 seconds]
Drek45 has joined #armlinux
<HdkR>
alyssa: Partial faulting is a bit...weird. It allows you to attempt a read a part of a file in to a memory region of a constrained size. Giving you back only the amount that can fit in the region
<HdkR>
some like `read(fd, <End of page> - 1, 4096);` will return 1 byte on x86, error on ARM :D