<mort>
that was re: the "seems like it" not re: the link -- is that dummy_dai usable from devicetree? If so maybe I can avoid
<qschulz>
no it's not
<qschulz>
and it's on purpose IIUC
<qschulz>
though you probably could write your own card driver that makes use of ti
<qschulz>
it seems to be used on some mtk and imx cards?
<mort>
I fucking hate this garbage kernel
<mort>
man
<mort>
just let me play audio! Don't make me write a kernel driver just to play audio, that's literally the meme
* qschulz
shrugs
<mort>
maybe I should check out freebsd, I bet they don't make you write your own kernel driver *on purpose* to output audio on hardware which they have *already written drivers for*
<mort>
this isn't directed at #linux-rockchip so I guess it's off topic but every single little thing I want to do is met with so much INTENTIONAL resistance, this kernel really doesn't want me to use it without writing custom out-of-tree kernel drivers (but then if I write custom out-of-tree kernel drivers, kernel upgrades become hell, and then if I ever
<mort>
complain about that to someone then I was the moron who didn't just use unmodified upstream Linux)
<mort>
I hate it
<CounterPillow>
then fuck off already
<mort>
oh I would love to
<mort>
but this user hostile piece of shit operating system happens to be the only realistic option for most stuff I want to do
<mort>
nothing makes my blood boil more than when developers of what's meant to be a general purpose piece of software INTENTIONALLY block certain basic things like fucking playing audio
<qschulz>
nobody's forcing you to use out-of-tree kernel drivers, you could contribute them to upstream so you don't have to carry them for too long for example
<mort>
No I can't
<qschulz>
i don't have the background for this specific use case but it could simply be that nobody's actually done the work and this one driver isn't for it
<mort>
My driver would literally be a dummy driver, and it sounds like upstream intentionally doesn't want to expose a dummy codec driver to devicetree
<qschulz>
**I** (with no knowledge of anything in this subsystem) would think that it could be possible to create a new driver which takes things like data format, clocks, etc... from DT/ACPI for hardware that is truly not configurable
<mort>
I should gtfo before I get myself banned. Thanks for your help and I wish the operating system we all rely on was less preoccupied with making my life hell
<qschulz>
mriesch: they're gone :) maybe they'll monitor the logs though /me shrugs
<qschulz>
mriesch: but that does seem interesting
<mriesch>
qschulz: i can still answer them on stackoverflow :-)
<qschulz>
why it has SPDIF in the name is beyond me though
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
erg_ has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
Ermine_ has joined #linux-rockchip
Ermine_ is now known as Ermine
<CounterPillow>
mort has been engaging in bad faith arguments and done nothing but complaining for months. They're not interested in solutions, or in doing any of the work themselves.
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
mort has joined #linux-rockchip
<mriesch>
qschulz: well maybe spdif outputs are more common than i2s ones
<mriesch>
so the solution exists for spdif and not (yet) for i2s
<mriesch>
but i guess solving this issue for i2s would go along these lines
<robmur01>
yes, where "those lines" are literally "provide the OS with a driver for your hardware so the OS has some idea of how to actually use your hardware"
<robmur01>
S/PDIF transmitters (although they're often actually TOSLINK) are real pieces of hardware, albeit very simple ones
<robmur01>
AIUI a raw I2S interface *has* to know what it's talking to on the other end, because stuff like clock directions aren't negotiated in the protocol
<mriesch>
robmur01: so, in summary, not at all along those lines :-)
<mriesch>
mort: so what is actually at the other end of i2s lines?
<qschulz>
mriesch: they're gone again :)
<mriesch>
grmpf. do i really need to turn in joins and parts in my client?
<qschulz>
mriesch: if you have autocomplete it usually doesn't work with people that are gone :)
<mriesch>
ah that explains why it didn't work 🙈
<robmur01>
mriesch: no, if it's some fixed I2S sink with no configurability then it should be absolutely similar to spdif-dit, i.e. simply wanting a similarly trivial driver to describe the format/rate/mclk direction/etc. it expects
<mriesch>
ah ok
<robmur01>
FWIW my experience in this is a couple of days of banging my head against I2S and simple-audio-card on the NanoPC-T4, when there *was* already an upstream driver for the codec on the other end, and still failing :)
sre has joined #linux-rockchip
* robmur01
shakes fist at mclk...
raster has quit [Quit: Gettin' stinky!]
stikonas has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
vagrantc has quit [Ping timeout: 265 seconds]
alpernebbi has quit [Ping timeout: 255 seconds]
alpernebbi has joined #linux-rockchip
naoki has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
<naoki>
hmmmm
eballetbo has quit [Quit: Connection closed for inactivity]
<naoki>
about U-Boot, I really want to change defconfig name from rock5a-rk3588s_defconfig and rock5b-rk3588_defconfig to rock-5a- and rock-5b-
<naoki>
mmind00: why you used rock-5-itx- instead of rock5-itx- ?
<mmind00>
naoki: suggested by dsimic ... due to Radxa naming that one board differently
<naoki>
if my memory is correct, I suggested rock5a(5b?) should be rock-5a, but it was declined :(
<naoki>
declined by someone
mort has joined #linux-rockchip
<mort>
so I guess I try to write a fucking kernel driver
<mort>
where the hell do I start
<mort>
I hate this
<mort>
I don't know what the difference is between a cpu dai and a a codec dai, I don't know what a dit is, I don't know what a "card" is, and I sure as hell don't want to do any of this
<mort>
but digging down and learning about all of this is apparently how you get this kernel to output audio
<mort>
I don't understand why linux,spdif-dit is allowed to exist
<diederik>
mort: getting into a different state of mind seems like a prerequisite for doing anything productive
<mort>
too bad
<mort>
devicetree was a mistake, the fantasy that it should be an OS-agnostic description of the hardware seems to be the cause of most problems I encounter
<mort>
I'll stop talking about this here because it's mostly off topic
vagrantc has joined #linux-rockchip
System_Error has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 252 seconds]
alpernebbi has joined #linux-rockchip
smaeul has quit [Read error: Connection reset by peer]