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
Pali has quit [Ping timeout: 250 seconds]
apritzel_ has quit [Ping timeout: 250 seconds]
mcoquelin has quit [Ping timeout: 256 seconds]
mcoquelin has joined #armlinux
<HdkR>
I'm looking at the viability of a `process_vm_readv` syscall that takes a pidfd that was passed via SCM_RIGHTS rather than requiring ptrace rights. Is this viable or something not desired?
<HdkR>
Alternatively `process_vm_mmap` but it seems that isn't available.
darkapex has joined #armlinux
darkapex_ has joined #armlinux
darkapex has quit [Ping timeout: 246 seconds]
amitk has joined #armlinux
Grimler has quit [Ping timeout: 248 seconds]
tlwoerner_ has joined #armlinux
tlwoerner has quit [Ping timeout: 260 seconds]
tlwoerner_ has quit [Ping timeout: 240 seconds]
tlwoerner has joined #armlinux
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 256 seconds]
djrscally has joined #armlinux
<tmlind>
arnd: there are two typo fixes from julia for omap1, want to pick them up into your multiarch branch? [PATCH] omap1: htc_herald: fix typos in comments, [PATCH] ARM: OMAP1: fix typos in comments
<arnd>
tmlind: sure, will do. Trying to find out what happened to the warning fix at the moment. I had meant to fix all the sram pointer warnings in one patch, but as you pointed out the patch I sent is incomplete
<HdkR>
arnd: separate fd for each mapping would get a bit unwieldy
mcoquelin has joined #armlinux
<tmlind>
arnd: ok thanks
<arnd>
HdkR: I suppose it works for qemu because the guest address space does not have that many distinct mappings, compared to a normaluser process
<HdkR>
arnd: Yea, and I want to pass over a fair number of VMA regions
<arnd>
I think I've other suggestions for a similar interface in the past, but I don't remember the names, so maybe keep searching on lore.kernel.org
biju has joined #armlinux
<biju>
Hi
<biju>
I have a question related to PWM. RZ/G2L PWM has 8 channels and each channel has 2 IOs{A,B}, from binding perspective how do we model this, as user can choose IO_A, IO_B or both. Any ideas?
<biju>
32 bits × 8 channels
<biju>
● Up-counting or down-counting (saw waves) or up/down-counting (triangle waves) for each
<biju>
counter.
<biju>
● Clock sources independently selectable for each channel
<biju>
● Two I/O pins per channel
<biju>
● Two output compare/input capture registers per channel
<biju>
● For the two output compare/input capture registers of each channel, four registers are provided
<biju>
as buffer registers and are capable of operating as comparison registers when buffering is not
<biju>
in use.
<biju>
● In output compare operation, buffer switching can be at crests or troughs, enabling the
<biju>
generation of laterally asymmetric PWM waveforms.
<biju>
● Registers for setting up frame cycles in each channel (with capability for generating interrupts at
<biju>
overflow or underflow)
<biju>
● Generation of dead times in PWM operation
<biju>
● Synchronous starting, stopping and clearing counters for arbitrary channels
<biju>
● Starting, stopping, clearing and up/down counters in response to input level comparison
<biju>
● Starting, clearing, stopping and up/down counters in response to a maximum of four external
<biju>
triggers
headless has joined #armlinux
frieder has joined #armlinux
<ukleinek>
output compare / input capture shouldn't be implemented in drivers/pwm. (There is one driver which does it, but I'd say this is unused and you should implement a counter for that)
nsaenz_ has joined #armlinux
<ukleinek>
biju: maybe the easiest option is to model this as 16 pwm channels such that 0 => channel 0A, 1 => channel 0B, 2 => channel 1A, ...
<ukleinek>
and if 0 (=hw0A) is used, return -EBUSY for 1 (=hw0B)
<geertu>
ukleinek: both can be used at the same time, same freq, but different phase.
<geertu>
biju: right?
matthias_bgg has joined #armlinux
<ukleinek>
geertu, biju: Then allow what is possible
<biju>
if there is a shortage of pin user may choose only 1 IO?
<biju>
Q1) How do we handle 2 IO's per channel? as each IO can be driven seperately and we should provide flexibility for the user to choose IO_A, IO_B or both
<biju>
for output compare / input capture, which framework we need to use?
<ukleinek>
or in a first step hardcode channel A and improve once the need arises
<ukleinek>
biju: drivers/counter
<ukleinek>
not sure its suitable for output compare, but input capture should work
<geertu>
ukleinek: linux pwm doesn't seem to support phase?
<biju>
ukleinek: hardware supports deadtime feature through which it will be in a different phase.
<biju>
if we disable deadtime, it can be in same phase.
<geertu>
biju: the 2-pin examples in the hardware manual only use phase differences between pin A and B, but I guess you can also use it for different duty cycles on pin A and pin B by using the trinagular mode?
<ukleinek>
geertu: indeed
<ukleinek>
geertu, biju: There was an approach to implement PWMs with two outputs at some point, but we didn't succeed to agree on an implementation.
<biju>
ukleinek, geertu Ok will go with simplest one first and later will enhance based on the feature
<biju>
One more question, we have another IP Port Output Enable for PWM
<biju>
which framework fir into this?
<biju>
We can disable output from PWM IP?
<biju>
The output pins of the general PWM timer (GPT) can be disabled by using the port output enabling function for the
<biju>
GPT (POEG). Specifically, either of the following ways can be used.
<biju>
● Input level detection of the GTETRGA to GTETRGD pins
<biju>
● Output-disable request from the GPT
<biju>
● Register settings
<biju>
driver/pincontrol ?
<tagr>
arnd: can you also revert the boolean properties patch for v5.18? it's now fixed in linux-next, but v5.18 is still broken
<tagr>
arnd: I mean this one: 1a67653de0dd ("arm64: dts: tegra: Fix boolean properties with values")
<arnd>
tagr: the fix is in my fixes branch, need to forward it to torvalds today
<tagr>
arnd: excellent, thanks!
<arnd>
not sure about the other platforms, I applied the same patch for npcm, qcom and stm32, but only reverte the tegra one
<ukleinek>
biju: The intended behaviour is that after pwm_apply(mypwm, &(struct pwm_state){.enable = false}) the output is driven to the inactive level. So it depends on the pin behaviour what "disable output" means for your HW
<arnd>
tagr: the bug is the same everywhere, right?
Turingtoast has joined #armlinux
apritzel has joined #armlinux
Pali has joined #armlinux
luispm has joined #armlinux
monstr has joined #armlinux
<arnd>
robher: can you have a look at https://lore.kernel.org/lkml/YlVAy95eF%2F9b1nmu@orome/? It sounds like we have to revert all your changes to "drive-push-pull" properties and change the binding instead to match the code.
sszy has joined #armlinux
* ukleinek
has built a loop with two uarts. If I configure the one with even parity and the other with odd parity, I receive all characters with and without ignpar. Is there something obviously I'm doing wrong?
frieder has quit [Remote host closed the connection]
<ukleinek>
geertu: this is a 8250, there is no DMA
<ukleinek>
I would have expected that with ignpar read on the reciving end doesn't get a character
vigneshr has left #armlinux [#armlinux]
apritzel_ has joined #armlinux
Amit_T has joined #armlinux
amitk has quit [Ping timeout: 250 seconds]
amitk has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<hanetzer>
so. got the board booting to the point where I *think* a login prompt should pop. last message on console is 'Freeing unused kernel image (initmem) memory: 1024K'. At that point I can type into the serial line, but nothing comes of it. so '\n' or 'root\n' or 'whatever', so I think its still live
<Xogium>
hanetzer: sounds like there's no init ? I mean. Why don't you see text from init ? It should be executed right after freeing the memory
headless has quit [Quit: Konversation terminated!]
<hanetzer>
in the last boot, the cmdline was 'console=ttyAMA0,115200n8 slub_debug=FZP init=/bin/sh'
<hanetzer>
both /bin/sh, /init, and /sbin/init exist in the intrd
<Xogium>
hmm you should still have that run whatever as init process line… I'd think
<hanetzer>
(buildroot built)
<hanetzer>
and the kernel sees this: (line 'Kernel command line: console=ttyAMA0,115200n8 slub_debug=FZP init=/bin/sh' shows up relatively early in the boot proc)
<Xogium>
hmm. I'm assuming you enabled the, start a getty login prompt after boot thing in system configuration ?
<hanetzer>
I haven't done the pinctrl stuff yet, but I don't think its strictly needed yet (the pinctrl regs that run the uart0/gpioN_x mux have default reset values that enable the uart)
<hanetzer>
yeah, I've set that to varying values (console,ttyS0,ttyAMA0) and no results.
<Xogium>
hmm
<Xogium>
and the uart does get initialized properly, or you couldn't type… that is weird
<hanetzer>
also tried varying init systems (busybox and sysv) and dev mgmt (static/mdev/devtmpfs/eudev) combos just in case that's it.
<hanetzer>
I'm pretty sure it works, because previoiusly I've seen 'Warning, unable to open an initial console' or something similar
<Xogium>
and that warning is now gone right ?
<hanetzer>
yeh
<Xogium>
hmm right just asking cause I had one of these a while back and it sure was no fun to track
<jn>
Xogium: i'd have to dig into prehistory to answer that :)
<hanetzer>
Calibrating delay loop... 2197.09 BogoMIPS (lpj=10985472) vs [ 0.000000] SMP: Total of 1 processors activated (48.00 BogoMIPS).
<Xogium>
boot log does look fine to me
<Xogium>
but for what its worth even on stm32mp157 I get 48 bogomips
<hanetzer>
beefy?
<Xogium>
probably more than that one
<Xogium>
800 mhz dual core cpu
<hanetzer>
ehhhh. this one is a 1.1ghz single, so ?
<jn>
Xogium: when you get values like 48 bogomips, i think it's due to a non-cpu-based delay timer
<jn>
that runs at 48 MHz or something
<Xogium>
I mean, if that had anything to do with cores or cpu freq then I'd thin 2x 800 would be higher than 1x1.1
<Xogium>
jn: ah, that'd make sense
<Xogium>
and then you get insane numbers like on x86, which don't make sense either…
<Xogium>
like my ryzen 7 3700x has 7203.81 bogomips :D
<hanetzer>
yee
<hanetzer>
Calibrating delay loop (skipped), value calculated using timer frequency.. 7386.06 BogoMIPS (lpj=3693033) (2700x)
<Xogium>
indeed
<Xogium>
so not using cpu clock for it
<hanetzer>
maybe I'll add some more printk debugging. too bad I don't have a mechanism for rebooting the board remotely yet.
Turingtoast has joined #armlinux
<hanetzer>
I literally have to replug it lmao
<Xogium>
Calibrating delay loop (skipped), value calculated using timer frequency… 48.00 BogoMIPS (lpj=240000) on stm32mp1
<hanetzer>
yeah. 240,000. strange, as the cp15 timer is 24,000,000 and the primary crystal is also 24mhz
<hanetzer>
there's also a 32768 osc for the rtc.
Grimler has joined #armlinux
<hanetzer>
if I could do commands I could use devmem to poke and see what the pinctrl stuff is, buuuuut.
<hanetzer>
so, about pinctrl stuff. define in ${chip}.dtsi or ?
<Xogium>
I'd assume so, but I am not an expert
<Xogium>
unless they are board specific
<hanetzer>
(vendor kernel's version of pinctrl is funny. in u-boot they put 4096 bytes of blank space 64 bytes into the image, which works basically like a binary csv file [addr,op,value,flag] and loop it until they get four nulls. in linux they just use himm which is basically devmem2 lmao)
<hanetzer>
the binary csv is produced from an excel workbook with vba macros
<hanetzer>
I wish I grok'd pinctrl-single lmao
biju has quit [Quit: Client closed]
<hanetzer>
or at least that vendors with upstream support for their chips were more generous with their datasheets
prabhakarlad has quit [Quit: Client closed]
<hanetzer>
because I don't quite understand the beaglebone datasheet layout
<hanetzer>
sp804_get_clock_rate:arm,sp804:62500000 and sp804_get_clock_rate:arm,sp804:3000000, those look right :)
<hanetzer>
is it possible that since a given gpio block which is muxed with the uart is 'status = "disabled"' in dts it's not gonna work right?
<Xogium>
I honestly don't know :S
prabhakarlad has joined #armlinux
apritzel_ has quit [Ping timeout: 272 seconds]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
jlinton has joined #armlinux
<robher>
arnd: uggg. will look at it some more. I guess changing 'drive-push-pull;' to 'drive-push-pull = <1>' instead should be safe at least.
jlinton has quit [Ping timeout: 252 seconds]
monstr has quit [Remote host closed the connection]
frieder has joined #armlinux
<arnd>
thanks robher
<arnd>
I'm looking at the other patches again now, it looks I misunderstood earlier and the other patches from your series were mostly unaffected by this.
<hanetzer>
kernel nerds, any idea about my above quandry?
<arnd>
0dc23d1a8e17 ("arm: dts: at91: Fix boolean properties with values") is the only one I'm not sure about still
<arnd>
apparently the "drive-open-drain" property is interpreted inconsistently, it is definitely a 'bool' type property in some places, but it's also one that I revert back to =<1> in the tegra fixup, apparently as drivers/pinctrl/pinconf-generic.c treats it as an int
<arnd>
tagr, robher: can you take a look at the at91 patch to see if that should be reverted or not?
<arnd>
the other ones that use bool-type properties for pinctrl may or may not work as intended, but at least those did not change recently, so I don't have to worry about them for today's pull request
ide12 has joined #armlinux
<ide12>
Hey all, I am having a hell of a time with an LTE modem. Is there someone here that can help me out? It's based on a qualcomm MDM9250
<hanetzer>
burn it :P
<ide12>
Honestly wish I could
<ide12>
It's the last piece of the puzzle before I can add this new device to the upstream OpenWRT source
<ide12>
I'm not sure what I am doing wrong, the lights show I have a connection to the cell network but having it get an IP and talk to the OS is a challenge
<robher>
arnd: The tristate argument doesn't make sense here because if you want to set to !push-pull that's drive-open-drain.
<robher>
I'm still trying to figure out the code for this though...
torez has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
mcoquelin has quit [Ping timeout: 276 seconds]
matthias_bgg has quit [Quit: Leaving]
amitk has quit [Quit: leaving]
mcoquelin has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
archetech has joined #armlinux
headless has joined #armlinux
Turingtoast has joined #armlinux
jlinton has joined #armlinux
Turingtoast has quit [Client Quit]
luispm has quit [Quit: Leaving]
<robher>
arnd: the at91 patch needs to be reverted too.
<archetech>
any rk 3588 progress yet
jlinton has quit [Quit: Ping timeout (120 seconds)]
apritzel has quit [Ping timeout: 276 seconds]
Amit_T has quit [Quit: Leaving]
archetech has quit [Quit: Konversation terminated!]
<abelloni>
broonie: we have a codec that support TDM with 128 slots we actually have a 64 slot TDM bus on that board, it seems ALSA only support 32bit wide TDM slot masks
<abelloni>
should we move to a bitfield?
<abelloni>
broonie: I guess this is an issue for DT compatibility too
iivanov has quit [Quit: Leaving...]
<broonie>
The in-kernel stuff should be fine up to int so on modern stuff I guess it should be fine up to 64 bit.
<broonie>
DT might be more fun though :/
<broonie>
We'd need new APIs for anything that won't fit in an int.
torez has quit [Quit: torez]
<abelloni>
well, this is on an ancient powerpc soc
<abelloni>
so 32bit only
jlinton has joined #armlinux
jlinton has quit [Client Quit]
headless has quit [Ping timeout: 256 seconds]
<broonie>
Ah, then yeah you'll need the new API bit.
headless has joined #armlinux
mcoquelin has quit [Ping timeout: 240 seconds]
jlinton has joined #armlinux
Turingtoast has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
darkapex has joined #armlinux
apritzel_ has joined #armlinux
frieder has quit [Ping timeout: 276 seconds]
frieder has joined #armlinux
<gpiccoli>
what is the arm analog of Intel SDM ?
<gpiccoli>
ARM32 I mean...
<gpiccoli>
I found so many documents in ARM website, I'm a bit lost...
jlinton has quit [Quit: Ping timeout (120 seconds)]