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
sakman has quit [Remote host closed the connection]
djrscally has quit [Ping timeout: 260 seconds]
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakman has joined #armlinux
CrashTestDummy has quit [Quit: Leaving]
cdaudt has joined #armlinux
CrashTestDummy has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apritzel_ has quit [Ping timeout: 268 seconds]
gclement has quit [Ping timeout: 246 seconds]
gclement has joined #armlinux
Pali has quit [Ping timeout: 260 seconds]
cdaudt has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tudorel has joined #armlinux
rockosov has joined #armlinux
djrscally has joined #armlinux
iivanov__ has joined #armlinux
milkylainen76 has joined #armlinux
milkylainen76 is now known as milkylainen_
iivanov has quit [Ping timeout: 268 seconds]
iivanov__ has quit [Remote host closed the connection]
iivanov has joined #armlinux
guillaume_g has joined #armlinux
apritzel_ has joined #armlinux
matthias_bgg has joined #armlinux
matthias_bgg has quit [Read error: Connection reset by peer]
sszy has joined #armlinux
apritzel_ has quit [Ping timeout: 250 seconds]
monstr has joined #armlinux
alexels has joined #armlinux
apritzel has joined #armlinux
Pali has joined #armlinux
faiL has joined #armlinux
djrscally has quit [Remote host closed the connection]
alexels has quit [Ping timeout: 245 seconds]
djrscally has joined #armlinux
faiL has quit [Quit: Leaving]
alexels has joined #armlinux
bps has quit [Ping timeout: 264 seconds]
saip has joined #armlinux
Turingtoast has joined #armlinux
Amit_T has joined #armlinux
saip has quit [Quit: Client closed]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
Amit_T has quit [Ping timeout: 245 seconds]
Amit_T has joined #armlinux
Amit_T has quit [Ping timeout: 260 seconds]
<broonie>
ardb: Even on x86 Windows relies on loading platform drivers to fill in the gaps in the ACPI spec for non-server hardware, it's just a bit less bad as the hardware tends to be a better fit for ACPI so you're more likely to be able to boot.
<ardb>
broonie: i understand that platform drivers will always be needed
<ardb>
it's the power management and device power state management in particular that I am referring to
<broonie>
TBH they should be needed a lot less - it's not that ACPI couldn't cope, it's that the standards process doesn't seem to allow anyone to make appropriate extensions to teh spec.
<broonie>
Yeah, the power management is a huge part of the differences between the models.
<ardb>
broonie: i can see how modern SoCs are simply too complex to describe using a paradigm that was invented 20+ years ago
<javierm>
ardb, broonie: the clock hierarchy is another aspect I think
<javierm>
with DT the kernel needs to know all the details while ACPI abstracts most of it
prabhakarlad has quit [Quit: Client closed]
<broonie>
ardb: Yeah, though there's some finesse there with how much of the complexity needs to actually be visible to the OS of course. And the fact that ACPI is mainly intended for systems which if they are battery operated have batteries an order of magnitude larger than a phone,
<broonie>
javierm: That's another big bit indeed.
<mvaittin>
Interesting reading for me. I am not really familiar with ACPI - but working for a component vendor I've a practical problem to solve. A PMIC is used both on x86 and ARM based platforms. How should I do a driver so it could support both the ARM with DT and x86 with ACPI? I was thinking of using the fwnode API to read the DT properties (and thought something similar could be given from ACPI tables) - but seeing the regulator core uses of_ for
<mvaittin>
all property parsing... I must be looking for wrong solution. I guess ACPI tables would never provide same properties as DT does.
<jn>
ACPI tables can contain DT properties since recently, a year or so ago
<mvaittin>
is the only real way to do separate drivers for same IC to cover ACPI and DT cases :/
<ardb>
mvaittin: does the PMIC need a driver in the ACPI case?
<mvaittin>
ardb: I would _assume_ it does. Someone must do the voltage settings/power.rail toggling. Or, at least it needs _some_ code, right?
<javierm>
mvaittin: but that logic could be in the firmware, not in the kernel
<ardb>
mvaittin: the code could be in the ACPI DSDT, that is basically the point of ACPI
<mvaittin>
javierm: that explains
<mvaittin>
ardb: thanks
<mvaittin>
So, that leaves a component vendor to write the DSDT/firmware part for ACPI-case, and then separate drivers for DT case.
<ardb>
mvaittin: it you are just poking a couple of control registers on device power state changes, that cann all be abstracted into the ACPI firmware
<mvaittin>
ardb: Mostly that. Probably some protection configurations on top of that - but those are probably one-time configs
<ardb>
mvaittin: right
<mvaittin>
thanks :)
<ardb>
so the usual model with ACPI is rich firmware that sets up all hardware, not only the pieces the bootloader needs for itself
<ardb>
and then, power state handling based on abstract device object methods that are implemented in the DSDT
<ardb>
which could include accessing PMICs over I2C or other transports
<mvaittin>
So the DSDT on ACPI-case and OS/drivers at DT case need to provide the I2C access / register logic to rest of the system. Kind of do the same thing in two different ways. But it sounds like this can't really be (easily) helped
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
<mvaittin>
which is probably the reason regulator core does not use the fwnode APIs.
<javierm>
mvaittin: as ardb said, the Open Firmware standard defined both a way to describe the hardware (device trees) and a programming model for the OS to call firmware code (implemented in forth)
<javierm>
mvaittin: so in that sense it's similar to ACPI + AML, but for arm only the first part is used (as flattened device trees)
<javierm>
you get the hardware description part but all the runtime logic has to be implemented in the kernel
<javierm>
mvaittin: it's a different trade off. It's true that you need to do it in two different ways, but on the other hand the same firmware code could be used by many operating systems
<mvaittin>
javierm: yep. I guess I got it :) For arm the OS/driver code is needed to do things based on DT descriptions. I think I am somewhat familiar with this. What I pick on your and Ardb's explanation is that with ACPI, the access is implemented in firmware. Whether the existing fw works for the new PMIC or not depends on how the PMIC HW is implemented.
<ardb>
mvaittin: indeed, but the point is that usually (in the ACPI/UEFI world at least) the vendor is in control of both the hardware and the firmware
<ardb>
so the vendor can tweak the BOM of an existing product with the OS being none the wiser
<mvaittin>
ardb: so at UEFI/ACPI case the OS does not need to contain the driver code to access the PMIC. Makes sense.
prabhakarlad has joined #armlinux
geertu has quit [Ping timeout: 265 seconds]
pg12 has quit [Ping timeout: 256 seconds]
geertu has joined #armlinux
pg12 has joined #armlinux
monstr has quit [Remote host closed the connection]
cdaudt has joined #armlinux
<broonie>
mvaittin: Note that the ACPI/DT thing isn't an x86/arm distinction - there's Arm server platforms with ACPI, and the x86 LynxPoint platforms will be DT based
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<milkylainen>
That's more like proof of concept than in-real-life architectural indifference to lowlevel enumeration. :)
Misotauros has quit [Read error: Connection reset by peer]
<mvaittin>
Right. I still think most of the x86 setups do not support DT at all(?) Or that's what I remember from the past.
<mvaittin>
I didn't know about ARM platforms with ACPI though.
* mvaittin
needs to go out and start shoveling some snow...
<mvaittin>
thanks all
<broonie>
Well, we've not seen the Lyxpoint stuff yet but the Arm stuff is certainly real and achieving goals
<CounterPillow>
I'm currently fiddling around with hdmi audio on the rk356x. My i2s-tdm driver shouldn't be adding a capture channel if I leave out the dma, but something is still trying to add one, resulting in:
<CounterPillow>
I can't really figure out what it is. What's the codepath for the audio subsystem critical for the decision whether to add a pcm channel here?
<broonie>
What makes you think that omitting the DMA will cause it to not add teh channel?
<CounterPillow>
I wrote the driver this way, and the rockchip i2s driver is also written this way, and it works.
<broonie>
Ah, there's custom code in the binding.
<CounterPillow>
Yeah, to avoid vendor properties for playback-only/capture-only
<broonie>
Well, whatever is asking for the DMA channel is coming from that driver - nothing outside the driver cares if it uses DMA, PIO or something else.
<CounterPillow>
Hmmm, interesting. Thanks
<broonie>
You should probably just remove that code from the driver TBH rather than having per-system fiddling with DMA setup depending on the board.
<broonie>
The core will only offer TX/RX to userspace if both ends of the DAI support each direction - the driver shouldn't need to worry about it unless it requires that the hardware be reconfigured somehow.
<CounterPillow>
and in this case I'd always specify two DMAs?
<broonie>
Yeah, then people wouldn't need to fiddle about with the DT description for the SoC internals.
<CounterPillow>
What if I don't have a DMA to use for the rx direction of my HDMI i2s thing?
<broonie>
It looks like you're using the dmaengine_pcm stuff which will request DMA for each PCM you register, it's not expecting to have a mix of PCMs with and without DMA.
<broonie>
Does the SoC not have enough DMA channels for everything, and do you have to set up a static allocation of DMA channel to device at DT time? Normally the mapping is hard wired due to request signalling (at which point you always have a channel).
<broonie>
see dmaengine_request_channel_of()
iivanov__ has joined #armlinux
Tokamak_ has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
bps has quit [Read error: Connection reset by peer]
Tokamak_ has quit [Read error: Connection reset by peer]
unixsmurf_ has joined #armlinux
rfried3 has joined #armlinux
Pali_ has joined #armlinux
Pali has quit [Killed (zinc.libera.chat (Nickname regained by services))]
Pali_ is now known as Pali
Tokamak_ has joined #armlinux
geertu_ has joined #armlinux
alexels_ has joined #armlinux
sszy_ has joined #armlinux
Amit_T has joined #armlinux
Misotauros has joined #armlinux
<CounterPillow>
dmaengine_pcm_request_chan_of? I'll look into it.
<broonie>
yes, that sorry
<CounterPillow>
Let me check the SoC documentation for DMA channels and such
geertu has quit [*.net *.split]
alexels has quit [*.net *.split]
sszy has quit [*.net *.split]
iivanov has quit [*.net *.split]
luispm has quit [*.net *.split]
Tokamak has quit [*.net *.split]
russ has quit [*.net *.split]
dtor has quit [*.net *.split]
tfiga has quit [*.net *.split]
khilman has quit [*.net *.split]
ndesaulniers has quit [*.net *.split]
nohit has quit [*.net *.split]
sjg1 has quit [*.net *.split]
rfried has quit [*.net *.split]
alpernebbi has quit [*.net *.split]
scosu has quit [*.net *.split]
sboyd has quit [*.net *.split]
unixsmurf has quit [*.net *.split]
kbingham has quit [*.net *.split]
Fridtjof has quit [*.net *.split]
rfried3 is now known as rfried
unixsmurf_ is now known as unixsmurf
arnd has quit [Ping timeout: 245 seconds]
kbingham has joined #armlinux
<CounterPillow>
the SoCs TRM does indeed say that I2S0_8CH_TX (which is HDMI) has DMAC1 req number 0, and req number 1 is given to SPDIF. i.e., I have no leftover DMA channel for I2S0_8CH_RX
<CounterPillow>
(or am I thinking about this wrong?)
<broonie>
Wow, that's weird.
arnd has joined #armlinux
alpernebbi has joined #armlinux
<broonie>
So it can't do DMA on capture at all? In that case I guess you need the code to skip some of the DMAs after all and need to make sure the generic dmaengine code can handle skipping some PCMs. That's a really surprising hardware configuration if it's the case.
luispm has joined #armlinux
Fridtjof has joined #armlinux
scosu has joined #armlinux
khilman has joined #armlinux
tfiga has joined #armlinux
sboyd has joined #armlinux
nohit has joined #armlinux
ndesaulniers has joined #armlinux
sjg1 has joined #armlinux
dtor has joined #armlinux
russ has joined #armlinux
<CounterPillow>
That specific instance of the controller block apparently does not do capture at all
<broonie>
You could also do this by having a separate compatible for a capture only instance (I guess this is for set top box type applications?) and registering only the TX DAI when that compatible is selected.
<broonie>
That feels like a more idiomatic way of doing things (and indeed I see the driver already has per-SoC compatibles).
<broonie>
and means you don't need to teach the generic dmaengine code about mixed PIO/DMA setups (which would probably wind up being a mess to do).
<CounterPillow>
Hmmm, alright. I'm just wondering how the rockchip_i2s.c driver gets away with the current way of doing things
<CounterPillow>
Maybe it doesn't.
<broonie>
From a quick glance it looks like it only ever supports one direction in a given instantiation and hence only ever registers a single direction, but I've never looked in detail at that hardware.
<CounterPillow>
When you say register only the TX DAI, how is this done? To me it seems the DAI struct always has a .capture and a .playback member
<broonie>
It leaves everything in the unused member zero.
<broonie>
The TDM variant uses a template which has the stream name set up.
<CounterPillow>
Yeah, for testing I moved that out and it still tried to register it :( Let me try removing the member altogether
* broonie
might be missing something about the flow here, like I say I've never actually worked with these devices.
<CounterPillow>
I think I may have found the issue, the per-compatible data has some TX/RX only stuff for each block
<CounterPillow>
... which is weird considering this would mean this never worked in the downstream driver either
XV8 has joined #armlinux
<CounterPillow>
hmmm wait no, this refers to the clock syncing stuff
<broonie>
There has been some refactoring in the core with how we iterate over things, it's possible some of that caused an issue and nobody noticed.
<broonie>
Vaguely surprised nobody noticed if that was the case though, but I guess if the affected IPs are relatively rarely used...
damxsa has joined #armlinux
<broonie>
Yeah, I can't immediately see what the _tdm driver is doing wrong here unless it's triggered by having capture.stream_name set.
pg12 has quit [Ping timeout: 245 seconds]
Amit_T has quit [Ping timeout: 256 seconds]
alexels_ has quit [Quit: WeeChat 3.3]
Amit_T has joined #armlinux
<CounterPillow>
Weird peculiarity I've just found: the spdif driver does also look at both capture and playback streams, also only has one DMA defined, but in dmaengine_pcm_new it bails out of the loop before the error
tudorel has quit [Quit: tudorel]
<CounterPillow>
!pcm->chan[i] branch is not taken for spdif, hmmm
pg12 has joined #armlinux
<CounterPillow>
wait no nevermind
<CounterPillow>
it bails out because it's a "substream"
<CounterPillow>
wait no, it bails because it is not a substream
damxsa has quit [Ping timeout: 240 seconds]
<CounterPillow>
err, *it doesn't have a substream
Tokamak_ has quit [Read error: Connection reset by peer]
Amit_T has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 245 seconds]
sszy_ has quit [Ping timeout: 260 seconds]
Tokamak has joined #armlinux
<CounterPillow>
Ok this made me none the wiser, this just tells me that indeed, the problem is that something is creating the capture substream
<CounterPillow>
But now I also know that the spdif driver can get around this in the very same kernel, so I shouldn't need to dig too deeply
cdaudt has joined #armlinux
headless has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cdaudt has joined #armlinux
<CounterPillow>
hoookay, something is setting the capture min/max channel and format.
<CounterPillow>
But not the name! So I know it's not me.
<CounterPillow>
It's our friend hdmi-codecs.c, I believ
<CounterPillow>
e
<CounterPillow>
Or maybe not. Oh well, I'll look into this later.
<CounterPillow>
Any guesses on why a thing (and what thing) could be playing with my DAI's stream settings are welcome
<CounterPillow>
Hacked something in to set everything to 0 again in _dai_probe and now it works
wens has quit [Ping timeout: 260 seconds]
apritzel_ has joined #armlinux
wens has joined #armlinux
damxsa has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<CounterPillow>
... I'm dumb. I made the DAI struct static.
mripard has quit [Read error: Connection reset by peer]
headless has quit [Quit: Konversation terminated!]
mripard has joined #armlinux
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #armlinux
XV8 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
XV8 has joined #armlinux
XV8 has quit [Client Quit]
damxsa has quit [Remote host closed the connection]
damxsa has joined #armlinux
damxsa_ has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
damxsa has quit [Ping timeout: 245 seconds]
damxsa_ has quit [Remote host closed the connection]
damxsa_ has joined #armlinux
damxsa_ has quit [Ping timeout: 240 seconds]
<amstan>
broonie: heh i just spared you from an ugly alsa driver coming your way, they might respin it first
Misotauros has quit [Ping timeout: 260 seconds]
cdaudt has joined #armlinux
djrscally has quit [Quit: Konversation terminated!]
djrscally has joined #armlinux
cdaudt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]