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
<arnd> HdkR: have you looked at how https://github.com/qemu/qemu/blob/master/net/vhost-user.c does it? I think they have a separate fd for each mapped region, which may not be helpful for what you want
amitk has quit [Ping timeout: 276 seconds]
amitk has joined #armlinux
mcoquelin has quit [Quit: Leaving]
<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]
<geertu> ukleinek: my test setup when I fixed parity error detection on SCIF https://lore.kernel.org/all/CAMuHMdXmfQ0x7mCZ-E7OPQFv2z-=mFDT20hJ2_JKax=OePB8eA@mail.gmail.com
<geertu> ukleinek: Do you have DMA enabled?
<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'
<Xogium> Freeing unused kernel image (initmem) memory: 7168K
<Xogium> Run /init as init process
<Xogium> ah
<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
<Xogium> missing clock
<hanetzer> last boot
<hanetzer> to be frank my bogomips/lpj are very low compared to the vendor kernel boot
<Xogium> well bogomips are not a real thing, are they ?
<jn> bogus by definition, hence the name
<hanetzer> yeh, think so. but 48.00 compared to 1k+ seems off
<Xogium> jn: why are they there, then ?
<Xogium> pretty to look at, I guess :D
<hanetzer> as a code smell, perhaps?
<hanetzer> but yeah, that boot log looks pretty 'normal', right?
<hanetzer> https://brpaste.xyz/3Nar8Q for reference, this is the vendor kernel boot
<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!]
darkapex_ has quit [Ping timeout: 240 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<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)]
<gpiccoli> guess it has all I need =D
mcoquelin has joined #armlinux
sudeepholla has quit [Ping timeout: 246 seconds]
headless has quit [Quit: Konversation terminated!]
<broonie> gpiccoli: If you mean the architecture reference manual it's https://developer.arm.com/documentation/ddi0406/cd/ for v7-A/R
<gpiccoli> tnx broonie , this is the one I got! But I couldn't find anything about IPIs
<broonie> DDI0487 s v8.
<gpiccoli> is this something special in ARM or it's more of a software implementation ? Code is in arch, or in the GIC irqchip ?
<gpiccoli> I'm studying that a bit...how IPIs related with IRQs/FIQs in arm32
* broonie would need to refresh his memory but the code will mostly be in the arch.
<gpiccoli> thanks broonie, studying there, I guess I have the needed level of understanding, hoipefully! hehe
<marex> gpiccoli: SDM as in the SoC FPGA SDM ?
<marex> (in Agilex/N5X) ?
<broonie> I think Software Development Manual
<gpiccoli> yeah, this one marex - software devel manual, it's the regular Intel/AMD manuals for x86 architecture
<marex> oh, I thought secure device manager, too many confusing conflated TLAs
<gpiccoli> ARM has it as well, as we discussed here, but in ARM developer website I first found 5190 documents, was a bit confused heh
<gpiccoli> indeed! so many acronyms heh
<broonie> No collisions with the Arm ARM!
<gpiccoli> hehe
<marex> broonie: are you still taking regmap patches next week for 5.19 btw ? :)
<marex> broonie: ohoho ... the arm arm, nice
* broonie tends to take patches up until Linus cuts the release, but might slow down if they seem risky or something.
<broonie> If it's new functionality that isn't going to disrupt anyone else then whatever, just go for it.
<marex> just the regmap bulk read/write patch to avoid the regmap bus hackage
<broonie> That's probably fine, yeah.
sudeepholla has joined #armlinux
frieder has quit [Remote host closed the connection]
djrscally has quit [Ping timeout: 250 seconds]