stikonas has quit [Remote host closed the connection]
System_Error has quit [Ping timeout: 260 seconds]
smaeul has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
vagrantc has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
raster has joined #linux-rockchip
<lvrp16>
Is it possible to boot boards over USB without writing the bootloader to eMMC or storage first?
<lvrp16>
Or rather, do I 471 the idbloader and 472 u-boot itb?
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 276 seconds]
<lvrp16>
ahh, figured it out. thanks.
kevery1 has quit [Ping timeout: 244 seconds]
kevery has joined #linux-rockchip
UndrWater has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<naoki>
Kwiboo: you brought several fixes for ROCK Pi S from Linux to U-Boot, does it affect linux functionality?
UndrWater has joined #linux-rockchip
<naoki>
wifi on Pi S is not working on OpenWrt... :(
naoki has quit [Quit: naoki]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
warpme has joined #linux-rockchip
Spirit532 has quit [Killed (NickServ (GHOST command used by Spirit5325))]
Spirit532 has joined #linux-rockchip
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
raster has quit [Quit: Gettin' stinky!]
<wens>
dumb codec: pcm5102a
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hexa- has quit [Quit: WeeChat 4.2.2]
hexa- has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.3.5]
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
detlev has joined #linux-rockchip
detlev is now known as detlevc
warpme has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
valpackett has joined #linux-rockchip
<dsimic>
mort: quite frankly, while I do understand your frustration, I don't appreciate your attitude
<dsimic>
having stuff work "the upstream way" can be tough sometimes, but that's the cost you have to pay for having things implemented in a clean way
<dsimic>
IOW, you may need something to "just work" for your use case, whatever it is, but having things done that way may cause issues or break things for other users of the same subsystem, or whetever... there are many uses and many users of the same stuff
<dsimic>
all that requires that certain rules are followed... I hope all this makes it more clear
<mort>
It honestly doesn't, I don't understand the difference between I2S audio and other forms of digital audio, but we don't need to have this discussion, we're almost certainly not going to agree
<dsimic>
if you don't understand something, it doesn't mean something is bad or not important
<dsimic>
you just need to learn more about it
<mort>
I have heard explanations but feel free to enlighten me regardless
<dsimic>
you need to invest time yourself
<dsimic>
the entire audio subsystem of the Linux kernel is highly comples and I already have some pending patches for it
<mort>
I have
<dsimic>
so I do know how complex it is, and how frustrating it can be
<dsimic>
but it's just a highly complex subsystem, so if you want to use it, you need to learn a lot about it
<dsimic>
if you have invested time already and you're still unclear about the things, you need to invest more time... as simple as that
<mort>
my understanding is that alsa needs an audio card to have a codec in addition to the dai, and the codec needs to at the very least tell alsa which sample rates and formats and number of channels to use
<dsimic>
if so, then you need a codes driver that suits your needs
<mort>
which is what I'm saying is bullshit
<dsimic>
if there isn't one already, then you need to make one
<mort>
the kernel should drive the computer it's running on
<dsimic>
you can keep saying whatever you want, but that won't help you
<mort>
this is like saying, "if you want to connect an HDMI monitor to your HDMI port you need to write a driver for the particular monitor you want to connect"
<dsimic>
that would be needed if you'd use some non-standard monitor
<mort>
but we don't say that, because the people responsible for the display subsystem have some semblence of sanity
<dsimic>
you're trying to some non-standard audio stuff, so you need to do the legwork
<mort>
"output digital audio" sounds pretty damn standard to me
<mort>
the interface for the digital audio interface is already written
<mort>
the driver* for
<robmur01>
well, you absolutely *would*, if the HDMI protocol did not allow the monitor to describe what formats it supports; the I2S protocol does not do that
<dsimic>
"digital audio" is anything but standard or simple, because it can have many different forms
<dsimic>
robmur01: good point
<mort>
robmur01: Linux supported display output even when you had to configure modelines manually
<mort>
how is a modeline different from channel count/sample rate/bit depth
<sigmaris>
SPDIF also has a standard for in-band format signalling, i.e. I can plug my soundbar into my TV via optical SPDIF and it can understand the format the TV is sending via in-band data
<dsimic>
e.g. it's different because it's part of fixed hardware layout, which the DT is supposed to describe
<dsimic>
^^^ mort
<mort>
the fixed hardware layout is: the SoC has an I2S output which is exposed on a pin
<mort>
just let me describe that
<dsimic>
"I2S output" doesn't describe all that's needed
<mort>
yes it does
<sigmaris>
yeah, but I2S has no in-band signalling of format, both ends have to agree/be told somehow out-of-band what format, clock, etc to use
<mort>
sigmaris: yeah, just like you had to configure modelines with your monitor
<mort>
that required out-of-band signalling (in the form of user configuration)
<dsimic>
just like "HDMI output" doesn't describe everything, but there's built-in negotiation that fills in the details
<mort>
I guess you're not reading what I'm writing
<mort>
either that or not understanding my point about modelines
<sigmaris>
so the "out of band signaling" part in your case is the "codec" driver telling the OS what format(s) it can receive
<dsimic>
that was before the auto configuration was possible
<sigmaris>
the reason it's not as simple as putting a modeline in a text file is that this is just not a common use case that the average desktop user would encounter
<dsimic>
yup
<mort>
auto configuration is still not universally possible
<robmur01>
we are understanding; your point is fundamentally "why are different things not the same?"
<mort>
robmur01: no it's not
<dsimic>
mort: I2S is a good example for that
<mort>
dsimic: right
<mort>
so let me configure formats and stuff
<dsimic>
sure, write a driver that provides the configuration
<mort>
no
<dsimic>
but how?
<dsimic>
how would you like that to happen?
<mort>
either userspace or devicetree?
<robmur01>
you're starting from a place of admitting you don't understand something while asserting it should be simple, where once you do understand it you'll realise it's not that simple. Therein lies your frustration.
<mort>
there's absolutely no reason not to have a dummy codec driver which lets you just set the properties you need
<mort>
robmur01: tell me what I'm missing then!
<dsimic>
userspace isn't a viable option, because the configuration isn't supposed to change over time
<mort>
everyone keeps saying "there's something you're missing which makes this impossible" but from what I can tell there's not
<mort>
dsimic: says who
<dsimic>
says the logic that you're relying on the hardware layout
<mort>
dsimic: if I connect a DSP via I2S which I can flash with new software which expects a different sample rate, the configuration should change over time
<dsimic>
you won't be plugging a codec in and out
<mort>
says who
<mort>
I plug shit in and out all the time
<dsimic>
you can keep plugging in and out whatever you want
<mort>
I plugged out a USB hub just earlier today
<mort>
the DSP being connected or not connected is simply a manner of having connected or not having connected the I2S pins
<dsimic>
if you flash a new DSP firmware, you're basically changing the board layout, when it comes to I2S routing and configuration
<dsimic>
you could try writing a new codes driver that accepts some parameters
<dsimic>
s/codes/codec/
<mort>
the DSP expecting 48kHz or 44.1kHz is just a matter of what software I flash it with
<dsimic>
either as module parameters or through /sys
<mort>
dsimic: what if I could just set this at runtime
<dsimic>
that's what /sys could do
<mort>
"play this format through this audio interface" is the most obvious kind of configuration
<mort>
dsimic: right, so why does that require writing a new driver
<mort>
scratch that, that's not the right question
<mort>
why would such a driver not be accepted upstream if I were to write it
<dsimic>
because no such driver seemingly already exists, because it isn't a standard use case
<mort>
that's ultimately the problem
<mort>
Linux is hostile to generic codec drivers which can be configured at runtime
<dsimic>
you need to write it first, then submit it upstream, then "fight" for it to be accepted upstream
<mort>
THAT is the problem I have here
<dsimic>
you have expectancy problems
<dsimic>
you expect a lot
<mort>
dsimic: I have seen countless discussions where people try to upstream such dummy codec drivers (or expose existing ones to devicetree)
<mort>
it's not that people haven't done the work, it's that Linux doesn't want it
<mort>
for the exact sorts of reasons that you've outlined and which I vehemently disagree with
<dsimic>
how can you know that Linux is hostile towards such drivers if you haven't created one and attempted to have it upstreamed?
<mort>
because I have witnessed others try before me and fail
<dsimic>
I went through the first thread, and it explains the reasons rather well, it's simply how the audio subsystem is designed
<dsimic>
let me read the newer thread
<sigmaris>
I see some people on e.g. https://forums.raspberrypi.com/viewtopic.php?t=371957 connecting an I2S transmitter to linux,spdif-dit using a simple-audio-card in devicetree. it's a hack but could be close to what you're looking for?
<mort>
people are also using hifiberry-dac on raspberry pi
<dsimic>
mort: I'm not sure that the newer thread suits your problem well
<dsimic>
It's not clear to me why you'd not just describe the actual CODECs here
<dsimic>
rather than using a dummy CODEC, the fact that the dummy CODEC is doing
<dsimic>
what you want is just an accident of the implementation rather than a
<dsimic>
description of the hardware.
<dsimic>
(a quotation from the thread)
<dsimic>
that shows it isn't a good fit for your problem at hand
<dsimic>
basically, you need a codes driver that can be adjusted through /sys
<dsimic>
s/codes/codec/
<dsimic>
can the firmware be queried about the current I2S parameters it supports or requires
<dsimic>
can the firmware be queried about the current I2S parameters it supports or requires? *
<dsimic>
if it can be, you could create a new codec driver that gets it configuration from the DAC -- which would be ideal for the problem at hand
<mort>
this is the wrong line of discussion honestly
<mort>
at least it clashes entirely with my philosophy when it comes to these things
<dsimic>
so the required I2S configuration would be espablished at boot time
<dsimic>
s/espablished/established/
<mort>
what I want is to output audio through ios
<mort>
i2s*
<mort>
having to write a kernel to describe the receiving end is, to me, equivalent to having to write a kernel driver to describe the other end of a TCP connection
<dsimic>
the trouble is that the audio subsystem currently doesn't seem to support DAI-less operation, which you could solve in two different
<dsimic>
the trouble is that the audio subsystem currently doesn't seem to support DAI-less operation, which you could solve in two different ways *
<mort>
it's like how you have to write a kernel driver to describe the other end of an SPI connection (which I similarly vehemently disagree with)
<dsimic>
(1) by working around the limitations, by creating a new endpoint driver
<dsimic>
(2) by improving the audio subsystem to allow DAI-less operation
<mort>
"the other end is connected via SPI" should require kernel involvement no more than "the other end is connected via TCP"; that is to say, the kernel should handle *this* end's hardware, and userspace should do the rest
<dsimic>
yes, it may seem like a lot of work, but that's the current stats of affairs, I'm afraid
<dsimic>
you can have a look at various SPI drivers and see that the things with SPI are far, far away from such simplicity
<dsimic>
or have a look at various USB drivers, which are also far from that
<sigmaris>
I'm guessing with the simple-audio-card -> spdif-dit hack, the channels, sample rate and similar properties of the I2S link would just be controlled from userspace. And if userspace gets it wrong, you'll just have horrible audio distortion or silence or who knows what
<sigmaris>
this is also probably one of the reasons why this hack is frowned upon; there's a general trend towards having the kernel configure the hardware sanely, preventing userspace from breaking things and not requiring/allowing userspace to set every part of configuration
<mort>
sigmaris: the problem is the kernel shouldn't confiure hardware it's not responsible for
<mort>
the kernel shouldn't be responsible for sensibly configuring the other end of a TCP socket
<dsimic>
sigmaris: yes, so having a new driver that quieries the DAC firmware from the required I2S link parameters might be the best option
<sigmaris>
the fact that basically nobody uses modelines and displays are detected via EDID nowadays is part of the same trend
<mort>
there's another computer over there which does its own thing
<dsimic>
s/from the/for the/
<mort>
dsimic: by "DAI-less operation", do you mean "codec-less operation" and/or "dai-only operation"?
<dsimic>
s/quieries/queries/
<dsimic>
basically, without the need to have DAIs defined, which require definitions of the endpoints
<dsimic>
one endpoint is the codec
<dsimic>
you'd have "outputs" defined, instead of DAIs defined
<dsimic>
but those outputs would need to be configured somehow
<dsimic>
and I don't think letting userspace configure them in any way possible would receive a warm welcome
<mort>
honestly I don't think the current structure is fundamentally bad, I just think there needs to be a codec which can be configured out of band (through config files, sysfs or devicetree)
<dsimic>
but that means there's a driver for that codec
<dsimic>
which goes back to having DAIs defined
<mort>
could you clarify exactly what's the differences and relationships between dai, dai-link, dit, card and codec
<dsimic>
frankly, I think that querying the DAC firmware for the I2S link parameters is the best possible solution
<mort>
I've tried to research it but it's really confusing and I even saw a code comment talking about how something is a dummy card but the name was dummy_dai or vice versa
<dsimic>
DAI is a (digital, obviously) link between two audio chain components
<mort>
dsimic: to me, that is literally the same kind of statement as, "frankly, I think that querying the HTTP API for its schema in the driver so that the kernel can configure the API server sensibly is the best solution"
<dsimic>
as such, both ends of the link need to be configured in the same way, so they can speak, but that has to be configured in advance
<mort>
these are two computers, communicating via a standard (albeit underspecified) protocol called I2S (analogously: HTTP + REST)
<dsimic>
I've been dealing with REST APIs a lot, and automatic schemas there are pure pipe dreams
<dsimic>
they can work for very simple REST APIs that actually aren't true REST APIs
<dsimic>
most people call APIs REST APIs, but those are far, far away from what a true REST API is
<mort>
and importantly, the kernel shouldn't even care whether a schema exists or not, and certainly not its structure; the job of the kernel is to implement what it can of the protocol, letting some things be configured at runtime when needed
<dsimic>
the kernel already does that, but it tries to make things sane but having the "hardcoded" links configured properly, instead of relying on configuration through userspace
<dsimic>
s/but having/by having/
<dsimic>
also, how would you know how to configure the I2S output properly through userspace?
<dsimic>
how would you know what are the right parameters?
<mort>
I wrote the firmware on the DSP
<dsimic>
can your firmware return those parameters?
<mort>
I mean not as in I wrote the low level C code etc but it's a programmable DSP which can be configured via a utility from the manufacturer
valpackett has quit [Remote host closed the connection]
<dsimic>
good, but what about the I2S link parameters?
<mort>
I know what I configured those to be
<dsimic>
well, you know, but how is a random user in the field know that?
<mort>
which random user in the field
<dsimic>
well, you know, but how is a random user in the field going to know that? *
valpackett has joined #linux-rockchip
<dsimic>
hmm, is that some product or project that's going to be available to random users?
<mort>
depends on what you mean by "random" and "users"
<mort>
but I fundamentally disagree with this fear of allowing the user to make mistakes
<dsimic>
if it isn't something that can be available for a random user, or a group of users, then a drivers for it cannot be upstreamed anyway, because there's no userbase
<dsimic>
s/drivers/driver/
<mort>
almost like Linux should try to have flexible drivers which work for people who want to use their computers without making a mass-market product hmmmmmmm
<dsimic>
another option for you is to create a new driver for debugging
<mort>
didn't you say that upstream would be hostile to this sort of driver
<dsimic>
which would allow such parameters to be configured through /sys
<mort>
also it wouldn't be for debugging
<dsimic>
it would be marked as a debugging/development driver
<mort>
so I would lie in order to get it upstream
<dsimic>
hmm
<mort>
Linux needs these sorts of drivers which are perfectly legitimately to use if your use case involves anything other than running a mass-market consumer product
<dsimic>
now that I think about it, perhaps other people would also "lie" about using that driver
<mort>
oh absolutely
<mort>
just like they lie about having i2s connected to a hifiberry dac or an spdif
<mort>
people need to output i2s and they want to do it without writing a driver just to configure sample rate and bit depth
<mort>
carrying out-of-tree kernel drivers is maintenance hell
<dsimic>
but again, I think that a new driver that queries the DAC firmware for the I2S parameters would be the best fit for your ptoblem at hand
<mort>
okay
<mort>
say the DAC doesn't have a generic way to be queried, so I would need to write that as part of the custom firmware we're flashing on it
<dsimic>
a more general approach is something that rquires much deeper research
<mort>
say I then write a driver which queries that firmware
<mort>
do you think anyone would accept "the driver which queries this kind of DAC in the way which mort happened to program format querying for the DAC"
<dsimic>
I think yes, because that's part of the driver
<mort>
if I'm the only user?
<mort>
or if it will be used by 5 other people in addition to me?
<dsimic>
if you're the only human on the planet that uses it, then not
<mort>
but if there are 4 others on the planet who will then yes?
<dsimic>
IDK is five the right threshold :)
<mort>
this is my problem, Linux has grown hostile to anything not for mass market consumption
<mort>
Linux should be flexible enough to let me use my computer the way I want
<dsimic>
but see, if there are only five people on the planet using some driver, who is going to maintain that driver?
<mort>
but when "the way I want to use my computer" includes sending 48kHz 16bit pcm audio through the I2S port on my SBC, Linux says no
<mort>
dsimic: nobody
<mort>
which is why having a driver for this is a terrible idea
<dsimic>
it's a terrible idea only if there's no userbase
<mort>
the userbase is me
<dsimic>
I don't think that qualifies as a userbase
<mort>
well I'm important to me
<dsimic>
anyway, may you could try creating a "raw output" codec driver
<mort>
so I would have to maintain the driver for me (or more realistically, just not upgrade Linux when Linux breaks my driver)
<dsimic>
anyway, maybe you could try creating a "raw output" codec driver *
<dsimic>
that would be some kind of a dummy codec that takes its parameters through /sys
<dsimic>
and produces raw output from the card
<mort>
yeah, a better idea than writing a bespoke driver just for me is to have a generic driver which hundreds or thousands of people would use, which would let you configure (through sysfs or dts) which format to use
<mort>
but as you have both seen through mailing list discussions and said yourself, Linux is hostile to that
<dsimic>
then try writing and upstreaming that "raw output" codec driver
<mort>
no
<mort>
I can't
<dsimic>
why?
<mort>
I can't have this discussion again but 10x
<mort>
you are almost starting to agree with me that this idea is reasonable, that there is a market for it
<dsimic>
is is that you can't or you don't want to?
<mort>
I can't
<dsimic>
s/is is/is it/
<mort>
I can write the driver and throw it to someone who can have that discussion but I can't
<mort>
you see how this topic makes me feel and how I respond to the idea that users shouldn't be able to use their computers how they want
<dsimic>
well, the idea is reasonable because it can be useful for development and debugging, for example
<mort>
it's a dummy driver
<dsimic>
oh, I see, you're also hostile
<dsimic>
but see, how can you expect a nice response when you act like that?
<dsimic>
I WANT MY COMPUTER TO DO BLAH BLAH
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
<dsimic>
instead of "here's a new driver that allows my computer to do blah blah"
<mort>
I frankly hate every single person who's involved in the Linux kernel's crusade against flexibilty
<dsimic>
it's may times just inability to understand the arguments of the other side
<mort>
I can write a nice and pleasant initial e-mail but I can't have the discussion with people who will say that no, computers shouldn't do as users want, because our ideals of the devicetree only describing the hardware is more important
<dsimic>
but you have to discuss
<mort>
can you explain the arguments from the other side which I am misunderstanding
<dsimic>
I can, when I see them
<mort>
I linked to some didn't I
<mort>
I can link you to similar discussions about why spidev was removed too
<dsimic>
all arguments in those two threads were just fine
<mort>
spidev is what people relied on in order to communicate over spi from userspace
<mort>
it's the same thing, "you should write a kernel driver, not communicate with the other computer from userspace"
<mort>
at work we carry a kernel patch to add back spidev because, well, we have an MCU connected to the Linux SoC via SPI and we need to talk to it
<dsimic>
what do you need to talk to it?
<dsimic>
i.e. what it does?
<dsimic>
better said, what does it do? :)
<mort>
and from a business perspective, what makes the most sense? Keep using the code we've been using for a decade, written in a memory safe language in userspace, which takes care of communicating with the MCU, using stable interfaces? Or write a huge kernel driver in C, using unstable in-kernel APIs which will break with every upgrade, and then make
<mort>
that driver expose an interface in sysfs that's hard to implement on the kernel side and hard to talk to from our userspace processes?
<dsimic>
I'd need to know what does the MCU actually do
<mort>
there are two MCUs, one which controls a motor and some status LEDs and talks with a battery "fuel gague" type thing, and one which controls some other motors and some other LEDs
<mort>
they talk with the Linux SoC via SPI, using a protocol we made
<dsimic>
is that battery gauge for the entire system?
<mort>
yeah
<dsimic>
in that case, talking to it that way, instead of writing a new fuel gauge driver, is a horrible idea
<mort>
it does not matter *at all* that it doesn't show up in /sys/class/power_supply or whatever
<mort>
and you wouldn't want a fuel gague driver to control motors and LEDs
<dsimic>
(BTW, memory safe language is nonsensical argument anyway, all that's needed is taking care while writing code)
<mort>
bullshit
<dsimic>
again, please think about your word choice
<mort>
meh some things just are bullshit
<dsimic>
I could say the same
<dsimic>
anyway, relying on userspace to handle a system-level battery gauge is simply a bad idea
<mort>
the thins we want to do based on the battery readings are: 1) update the battery LEDs (also controlled via the MCU); 2) report battery status to our back-end
<mort>
maintaining an out-of-tree kernel driver for that is a terrible idea
<dsimic>
does that battery power the entire system?
<mort>
why does it matter
<dsimic>
because in that case the system (i.e. the kernel) needs to be aware of it
<dsimic>
that's the "upstream way", I'm sorry
<dsimic>
from your business perspective, it may not make sense, which is also fine
<mort>
if you want to just keep shitting on my choice to attempt to reduce the amount of out-of-tree kernel patches and bespoke kernel modules we rely on, then keep going
<dsimic>
let me repeat: please think about your word choice
<mort>
but if you want to talk about the principle of the matter, let's ignore the fuel gague and pretend it only handles LEDs and motors
<mort>
no
<mort>
please stop being hypersensitive
<dsimic>
so, let's lie about the things?
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mort>
let's discuss the MCU which has nothing to do with the battery if you're unwilling to engage in hypotheticals
<dsimic>
anyway, let me sum it up
<mort>
don't
<dsimic>
okay
<dsimic>
I'm trying to make it more clear, which you don't care about
<mort>
okay go ahead if you must
<dsimic>
I don't
<mort>
cool
<dsimic>
it isn't something I have to do
<mort>
let's just discuss the MCU which controls some motors and LEDs
<dsimic>
that's what I wanted to do
<mort>
it could not possibly be more obvious to me that communicating with it from userspace is the right approach
<dsimic>
well, yes and no
<mort>
I'm as sure of that as I'm sure that hosting a web server in userspace is the right approach
<dsimic>
well, that's a whole other class
<mort>
my view is: computers communicate, it is the role of the kernel to fascilitate that communication, but not to meddle with it
<dsimic>
hmm, why don't you connect that MCU over USB and call it a day?
<mort>
would that be better hardware design or would that just be easier to fit into the kernel community's pre-existing notions of how things work
<mort>
also we aren't paying members of the USB IF, we don't have a vendor ID
<dsimic>
I see I need to recap
<mort>
okay recap
<dsimic>
basically, the trouble with "expose it to userspace" drivers is that people are lazy
<mort>
it's not the role of the kernel to make things harder for users and force the user to write kernel drivers for everything
<dsimic>
with that approach available, everyone will try to use various "let's just make it work" userspace scripts of whatever, instead of writing proper drivers for everyone's benefit
<mort>
"expose it to userspace and let the user deal with it in userspace" is reasonable
<dsimic>
it's only partially reasonable, and in the short run
<dsimic>
another job of the kernel is to abstract the hardware, for its use by userspace
<mort>
would it be better if our communication with the MCU which controls motors and LEDs was in kernel space
<mort>
if so: why
<dsimic>
ideally, e.g. the LEDs would be exposed as the "true LEDs" through the kernel
<mort>
that's not ideal, no
<dsimic>
as of why, because the "true LED" interface already exists
<mort>
that's introducing complexity for no benefit
<dsimic>
well, it's no benefit to you, but it's beneficial to the other users of the same hardware, because they get the LEDs working with no additional userspace thigies
<dsimic>
thingies *
<dsimic>
s/no/of no/
vagrantc has joined #linux-rockchip
<mort>
there are no other users of the hardware
<dsimic>
well, that's a separate problem
<mort>
no, it's very much related
<mort>
this isn't a hardware platform which other people are supposed to run their own software on
<dsimic>
I mean, I understand your point, but I hope you understand the benefits I described above
<mort>
I do not
<dsimic>
then I don't know how to describe it better
<dsimic>
maybe someone else can
<mort>
I don't think so
<mort>
I think this is a fundamental difference in philosophy
<dsimic>
then you simply don't understand the long-term goals of the manline kernel
<mort>
I view the role of the operating system as serving the user, you're describing the user as subservient to the operating system
<mort>
in your view, it's the role of the operating system to push the user into doing things in a particular way out of philosophical reasons
<dsimic>
it depends on who's the actual user
<mort>
I am
<dsimic>
well, you seem like a very important user :)
<mort>
I sure am to me
<dsimic>
let me repeat: another job of the kernel is to abstract the hardware, for its use by userspace
<mort>
then abstract the hardware
<mort>
not the software running on the other computer
<dsimic>
that's why you need drivers
<mort>
no
<mort>
I need drivers to abstract the hardware, not the software
<dsimic>
that's why those LEDs would be the "true LEDs"
<mort>
they are true LEDs
<mort>
connected to an MCU which the kernel should let me talk with
<dsimic>
"true LEDs" by using the kernel interfaces, instead of being controlled by talking to the MCU from userspace
<mort>
they are true LEDs
<dsimic>
true to you
<mort>
true to anyone?
<mort>
they exist, they're physically there, they're not false LEDs
<dsimic>
well, no
<mort>
the kernel just doesn't know about it
<mort>
which is fine
<dsimic>
they're "fake" until they exist as kernel interface
<mort>
no
<dsimic>
no to you, again
<mort>
not to anyone
<dsimic>
you don't seem to understand what I'm trying to convey, while I do understand your point
<mort>
I reject your terminology more like
<mort>
they're true LEDs, they're just not LEDs which the kernel knows how to drive
<mort>
which is fine
<dsimic>
well, I wrote "true LEDs" with the quotation marks, didn't I?
<mort>
yes, and I rejected your terminology
<dsimic>
that's fine, but I hope you see that it was "softened"
<mort>
dsimic: imagine a different hardware structure: the LEDs are driven by an esp32 which is connected to the Linux SoC via Ethernet, the esp32 runs a web server, you set the state of the LED by sending a POST request to the esp
<mort>
would you still argue that I should write a kernel driver which sends HTTP POST requests to the ESP32
<dsimic>
that's another thing
<mort>
why
<dsimic>
because it uses far higher levels of abstraction
<mort>
why does that matter
<dsimic>
why anything matters? we're all going to die eventually
<mort>
no, why does it matter
<dsimic>
it matters for the same reasons
<dsimic>
because there are various levels of abstraction
<mort>
so it matters because we're going to die
<mort>
why does the level of abstraction matter
<dsimic>
no, it matters because of the same reasons why we still care about things, despite we all know we're going to die; i.e. we abstract that fact away
<mort>
why does the level of abstraction matter
<dsimic>
because it's handled by different approaches
<mort>
see I don't even agree that the level of abstraction is that different
<dsimic>
it's like surgery and 10-pound hammers -- you don't use such hammers in surgery
<mort>
there are two computers, they have a way to communicate, one computer handles the LED and defines an interface whereby the other computer can request LED states
<dsimic>
how are those computers connected together?
<mort>
one via a ethernet, one via SPI
<mort>
both are just ways to send bytes back and forth
<dsimic>
the emphasis was on "together"
<mort>
then I don't understand the question
<dsimic>
they cannot be connected together the way you described
<mort>
I still don't understand, why not
<dsimic>
because they cannot communicate
<mort>
???
<dsimic>
one talks SPI, the other talks Ethernet
<dsimic>
that's what you wrote
<mort>
in one example, the two computers talk via SPI with each other; in the other example, the computers talk via HTTP over TCP/IP with each other
<dsimic>
BTW, what are you talking about the spidev driver no longer in mainline?
<dsimic>
there's still drivers/spi/spidev.c etc.
<mort>
just like there's dummy codecs in alsa
<mort>
but it's no longer available through devicetree
<mort>
we've been at this for two hours, I think it's time we stop. You already know that I hate the philosophy you represent and everyone associated with it, including apparently most of the kernel community.
<mort>
Let's agree to keep hating each other and do something productive
<dsimic>
well, you have to "register" your device with the spidev driver
<mort>
which is bullshit
<dsimic>
it isn't, it stops people from being lazy, at least a bit
<mort>
it's like saying I have to register www.google.com with the TCP driver if I want to make TCP connections to www.google.com
<dsimic>
using spidev should be the last resort, not the first choice
<mort>
using spidev is perfectly reasonable
<mort>
it's just a protocol for two computers to communicate
<dsimic>
yes, but as the last resort
<mort>
implementing communication between computers in userspace is perfectly reasonable
<mort>
the fact that the kernel requires you to patch the kernel in order to be allowed to talk to other computers is ridiculous
<dsimic>
it is, but all those abstractions shouldn't be ignored
<mort>
can we stop now, we're not getting anywhere
<dsimic>
you keep forgetting that those aren't general-purpose buses or protocols
<mort>
I find your views despicable and this discussion is not helping
<dsimic>
alright
<dsimic>
I also have other things to do
<mort>
SPI is perfectly general purpose
<dsimic>
maybe
<mort>
you literally send bytes between computers
<mort>
just like TCP
<mort>
saying anything else is user hostile
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<dsimic>
that's one way to see it
<mort>
there are *some* hardware devices which speak via SPI, like e.g some touchpads, which it's useful to have drivers for in the kernel, but you're pretending tat *all* uses of SPI are like that
<mort>
and it's this intentional denying of user freedom through intentional inflexibility that I find despicable
<dsimic>
I tried to explain what are the benefits of having kernel drivers, but you ignored those arguments
<mort>
at least when you guys ALSO get mad at us users for patching the kernel, WHEN YOU LEAVE US NO CHOICE
<mort>
your arguments were bullshit
<dsimic>
thanks, I love such words
<mort>
I know
<dsimic>
how can you expect someone to be helpful and friendly when you aren't?
<dsimic>
if someone disagrees with you, that isn't a reason to become hostile
<mort>
there are many things which it is good to have kernel drivers for, but denying users the ability to use their computers as they want because you have this skewed view that EVERYTHING should go through a bespoke kernel driver is evil
<mort>
I don't expect you to be helpful and friendly
<dsimic>
then what do you expect?
<mort>
I don't become hostile with people who disagree with me, I become hostile towards evil people
<dsimic>
you're calling me evil?
<mort>
there are plenty of people who disagree with me on topics where such disagreement is not evil
<mort>
yes
<dsimic>
fuck you!
<mort>
well, the views you represent
<dsimic>
fuck you to the Moon and back, dude
<mort>
thanks
<dsimic>
I'm trying to be as helpful as possible, and you're calling me evil?
<dsimic>
what's wrong with you?
<mort>
maybe you personally aren't evil but I think your views are
<dsimic>
everyone viewpoints are evil to someone else
<dsimic>
everyone's viewpoints are evil to someone else *
<mort>
and yours are evil to mine
<mort>
to me*
<dsimic>
but you keep igoring all the arguments, and keep insisting that only your arguments are right
<dsimic>
"I want to communicate"
<dsimic>
go communicate somewhere else, if you'll keep your ignorant attitude
<mort>
I have two computers, I want them to communicate with each other
<mort>
one of them is running Linux, I want to write the communication in userspace on the Linux computer
<dsimic>
let me repeat: go communicate somewhere else, if you'll keep your ignorant attitude
<mort>
I don't think I have demonstrated ignorance
<dsimic>
yes, you have, multiple times
<mort>
in addition to being evil, the hostility to letting computers communicate via userspace software is just plain weird
<dsimic>
you just keep repeating that you want to exchange bytes through userspace
<mort>
because that's what I want
<dsimic>
I really don't know what else to day
<dsimic>
I really don't know what else to say *
<mort>
because there is nothing else to say
<dsimic>
you want something, which is fine, but you keep ignoring everything else
<dsimic>
that's not the way to work together
<mort>
I have two computers, I connected them together via a common communication bus, I want to write software on them which lets them communicate via that bus
<dsimic>
let me repeat: you want something, which is fine, but you keep ignoring everything else
<mort>
it's fine that many uses of SPI would benefit from a kernel driver, as I said touchpads which speak SPI are excellent candidates
<mort>
it's you who keep ignoring everything else
<dsimic>
no, I wrote multiple times that I understand your point
<mort>
you ignore use cases of these buses, SPI and I2S, which are: "I connected two computers together and I write software on both and want them to send data back and forth"
<mort>
you focus only on the use case where there's a mass-market product which the kernel should have a driver for
<mort>
that's what I'm calling evil
<mort>
it's denying the agency of the user of the computer
<mort>
and I don't understand how it has become such a mainstream view in the Linux kernel community
<mort>
if you think there is something I am ignoring, you will have to repeat it
<dsimic>
is there auto discovery and auto configuration on those buses?
<mort>
no
<mort>
there must be out-of-band configuration, so let me do that
<dsimic>
but that creates possible issues
<mort>
there's no auto configuration of port numbers either, that has to be communicated out-of-band; browsers hard-code ports 80 and 443 for example
<dsimic>
technically, there's /etc/services
<mort>
oh does that auto discover port numbers used by remote services accessible through the internet?
<dsimic>
no, but can be used to find out port numbers for HTTP and HTTPs
<dsimic>
HTTPS *
<mort>
no it can't
<dsimic>
why?
<mort>
it can be used to find *conventional* port numbers for HTTP and HTTPS, and those conventions are communicated out-of-band; but the remote computer can run an HTTPS server on port 9999
raster has quit [Quit: Gettin' stinky!]
<dsimic>
the conventional ports is what we can rely on, everything else is non-standard
<mort>
so the conventional ports are reasonable defaults
<mort>
but I can still connect to other ports, WITHOUT A KERNEL PATCH
<mort>
the kernel doesn't deny me from sending an HTTP request to port 9999
<dsimic>
that's because the entire communications resides in userspace, kernel handles the lower levels only
<mort>
I don't need an HTTP endpoint driver which specifies the port and IP address and Content-Tipe header for an HTTP endpoint
<mort>
exactly
<mort>
that's what I want, at least an option for
<dsimic>
technically, you need "HTTP driver" in userspace
<mort>
be it i2s or spi or i2c or anything else
<dsimic>
I'm not familiar with the spidev driver, but what stops you from using it?
<mort>
nothing
<mort>
but using it requires a kernel patch
<mort>
or lying about the hardware in the devicetree
<mort>
or living with huge warnings in the kernel log on boot
<dsimic>
so you're basically protesting against no "anonymous" use of spidev, if I got it right?
<mort>
yes
<mort>
the removal of the "spidev" compatible string
<dsimic>
hmm, let me think again about it
<mort>
my stance is that a perfectly legitimate use of SPI is: I have two computers which are connected via SPI, I want to write userspace software which uses SPI to communicate
stikonas has joined #linux-rockchip
<dsimic>
is there a header on that computer that exposes the SPI bus?
<mort>
further, I think that the opposition to this is evil, that it comes from a place of user-hostility; a view of the user as subservient to the holy kernel
<mort>
yes
<mort>
well there's a pin in the connector of the SoM
<dsimic>
that's fine, it's still some kind of a header
<dsimic>
basically, the bus is exposed on some pins
<mort>
on the raspberry pi there's a proper pin header, meant for users to play with
<dsimic>
sure, as on other SBCs
<mort>
and let me tell you, people who want to connect their esp32 to their raspberry pi do NOT want to write kernel drivers, they want to import spi in python and send and receive messages there
<mort>
AND THAT IS FINE
<dsimic>
hmm
naoki has joined #linux-rockchip
<mort>
(just to quickly touch on the earlier discussion: in my view, this use case of using SPI without writing a kernel driver is principally identical to the use case of using I2S without writing a kernel driver, a Raspberry Pi user also wants to connect their esp32's I2S pins to their raspberry pi's pins and then just set the necessary parameters and
<mort>
play audio)
<dsimic>
I need to become familiar with the SPI driver and its history before I can discuss it any firther
<dsimic>
s/firther/further/
<dsimic>
I meant spidev driver, sorry
<mort>
I'm pretty sure that Raspberry Pi's kernel has a patched spidev by the way to make compatible="spidev" in devicetree legal again
<dsimic>
could be
<mort>
I'm part of a development process where I'm not responsible for most of the low-level software and we're doing stuff the "right way", by writing kernel drivers for everything
<mort>
and honestly I'm dreading future kernel upgrades
<dsimic>
well, all upgrades bring some risk, be it PHP, kernel or whatever
<mort>
the i2s fuel gague thing becomes a kernel fuel gague driver, the LEDs become proper kernel LED drivers, the motors become whatever IIO thing can deal with motors, and I'm certain that there will come a kernel upgrade in a few years which will break all the interfaces which those drivers use
<mort>
you're mostly wrong! Kernel upgrades bring *very* little risk to properly written userspace software
<dsimic>
you don't have to upgrade
<mort>
I'm sure greg would agree with that
<mort>
hell in the EU, you have to supply security updates for at least 10 years
<mort>
not upgrading the kernel is literally gonna be illegal with the cyber resiliancy act
<dsimic>
I see
<dsimic>
regarding 956b200a846e (spi: spidev: Warn loudly if instantiated from DT as "spidev", 2015-03-27), the main trouble is that the DT is supposed to describe the hardware
<mort>
I see that mantra all over the place, yeah
<mort>
any time there's some bonkers limitation which makes my life hell, I find kernel people repeating that exact line as a reason for why it's a good thing actually
<mort>
IMO a perfectly fine description of the hardware is: "there's a general purpose SPI port here"
<mort>
I don't understand these people's problem
<mort>
maybe you could imagine cleaner ways of describing "general purpose SPI port" than compatible="spidev" but you can't just remove compatible="spidev" without also making a replacement
<mort>
that's the behavior I would, again, characterize as evil
<dsimic>
having an "open" I2S port is somewhat like having a 3.5 mm TRRS jack
naoki has quit [Quit: naoki]
<mort>
yeah, and it's a completely reasonable thing you'd want
<mort>
hey why can we just describe analog audio outputs without also describing the capabilities of the hardware they'll be plugged into
<dsimic>
I can research it all further
<mort>
configuration of things like frequency response curves requires userspace software and out-of-band signalling
<mort>
why is that legal but i2s not
<mort>
often, you need to connect your computer's line-out to an amplifier, and then that amplifier has gain controls; why aren't we describing that hardware in devicetree
<dsimic>
I'll see to become familiar with the SPI driver and its history
<mort>
have fun
<dsimic>
gah... spidev, sorry
<mort>
also, I don't actually hate you either, you do seem like a good person. Sorry for all that
<dsimic>
you can be sure that I don't hate you either
<dsimic>
your points are valid, as I wrote multiple times
<dsimic>
one of the interesting things, regarding the spidev driver, is that many devices in its "compatible" table as described as simple
<dsimic>
I'll research more what does actually qualify as simple enough
<dsimic>
because exchanging bytes between two connectedcomputers is as simple as it gets
<dsimic>
As happens occasionally, an upstream change has once again prevented
<dsimic>
spidev from being loaded via Device Tree. We now need "spidev" to be
<dsimic>
included in the new spi_device_id list, otherwise although the
<dsimic>
spidev driver gets loaded no /dev/spidev*.* entries will appear.
<mort>
I imagine the raspberry pi folks are just as annoyed as me at this stuff
<mort>
(or maybe not "just as annyed" because that'd be unhealthy but you know, at least a little annoyed)
<dsimic>
frankly, I believe that adding support for "open SPI port" is possible
<dsimic>
e.g. the way the above-quoted commit description is written is simply wrong if the intention is to have an "open SPI port"
<dsimic>
it reads like "it just fixes some bug"
<dsimic>
it would need to be written very differently, and "spidev" cannot be reverted back
<dsimic>
IDK, I'll see to research it further and possibly whip up some patch
<mort>
I assume their perspective is as basic as mine: the raspberry pi has a general purpose SPI bus exposed via pins, they need that bus to end up in /dev/spidev0 or whatever
naoki has joined #linux-rockchip
<dsimic>
yes, that's a valid point
<mort>
"spidev" was the way to do that, then the kernel removed "spidev" without a replacement so yeah adding back "spidev" the way it was is the solution
<dsimic>
but it needs to be addressed very carefully
<mort>
I'm very happy with the compatible="spidev" solution but I'm sure whatever downsides it has could be addressed by some other solution
<dsimic>
perhaps 'compatible="raw-header"' (or something simmilar) could be possible
<dsimic>
because it would be associated with raw access on an expansion header, on a development board
<dsimic>
I research it further and probably submit a patch upstream, to see what will happen
<dsimic>
s/I/I'll/
<dsimic>
would you like to be in the Cc list of that patch submission?
<dsimic>
or actually, have your Suggested-by tag included?
<mort>
I wouldn't mind that
<mort>
and maybe one of these days I'll write a driver which tries to be a generic i2s driver, and try my hand at submitting it upstream
<dsimic>
you can let me know your full name and email address, if you want, so I can include your Suggested-by tag when/if my atch gets submitted upstream
<dsimic>
s/atch/patch/
<mort>
Martin Dørum, you can use martin@dorumtech.no
<dsimic>
thanks
<mort>
(I considered DMing but I figure if it ends up in git commit logs it's public anyway)
<dsimic>
if/when my patch gets submitted upstream, your Suggested-by tag will be included
<dsimic>
exactly, that's public info anyway
<mort>
thanks
<dsimic>
see, something good can come out of disagreements :)
<macromorgan>
what's the proper way to communicate to the dwc3 controller that we want to change modes from device to host? Does the PHY, an extcon, or something else communicate that change?
<mort>
the description is "ROCKCHIP I2S/TDM ASoC Interface", but what is that exactly? A DIT? Or a DAI? Or something which is supposed to be used by a potential DIT/DAI/card?
<mort>
macromorgan: hehe... I googled a bit and from what I'm seeing, it seems like you *used to* be able to switch between host and device from userspace but that they then removed that functionality and you now need a kernel patch to restore it
<mort>
this is extremely apropo of what I've spent the past two hours complaining about
<dsimic>
mort: it's a DAI, or at least it should be
<macromorgan>
two hours of complaints seems overkill
<mort>
eh a large part of it was more productive discussion than mere complaining but yes
<dsimic>
mort: that driver implements I2S bus, so it's a DAI which then requires endpoints, etc.
<macromorgan>
my issue is I've got a USB port I'm trying to automatically switch from host to device... it's wired through a type c port manager device so that communicates if I should be host or device, and it works
<dsimic>
macromorgan: shouldn't the switch be handled through extcon, initiated by the port controller?
<mort>
dsimic: so I have to make a codec (say /spdif-dit which is compatible with "spdif-dit"), and a "sound card" at /sound which is compatible with "simple-audio-card", then create a dai-link where the CPU side is the i2s_8ch DAI and the codec side is the /spdif-dit?
<mort>
Or have I missed or misunderstood something
<macromorgan>
near as I can tell the port manager consumes an extcon but doesn't generate one, the phy generates an extcon but being behind the port manager it doesn't matter because it won't know the state the port should be in, and the dual role controller stays stuck in device mode
<macromorgan>
let me check the code again though
<dsimic>
mort: yes, the other endpoint on that DAI should be some "raw header" dummy codec, which should receive its configuration from somewhere
<mort>
(I mean as correct as abusing spdif-dit can be)
<dsimic>
mort: what I wrote above are all assumptions about what should be an upstreamable approach
<dsimic>
I'd also suggest that you send your patch(es) upstream as "RFC PATCH"
<mort>
I'll keep that in mind, thanks!
smaeul has quit [Remote host closed the connection]
<mort>
by the way, what do you think would be most upstreamable, setting the bit depth/sample rate/format in the dts or via sysfs?
<dsimic>
well, if the goal is to have an "open port", only /sysfs would make sense
<dsimic>
because it would have no fixed configuration
<macromorgan>
yeah, the port manager consumes an extcon to see what type of charger it's dealing with (standard downstream port, charging downstream port, etc etc)
<dsimic>
maybe some defaults could be in the DT as well
<mort>
that makes sense
<dsimic>
mort: I hope it will make sense to the maintainers as well :)
<dsimic>
please, send the patch to me first, so I can read it and possibly suggest some improvements
<mort>
will do!
<dsimic>
thanks
<dsimic>
have a look at f78bf2c933c9 (ASoC: pcm: perform power-down delay checks a bit faster, 2024-04-09) for my email address :)
smaeul has joined #linux-rockchip
<mort>
dsimic: if I may bother you again: wrt the devicetree overlay I linked earlier, I should have everything I need to at least get a device to show up with 'aplay --list-devices' right?
<mort>
and in /sys/class/sound
<mort>
however I don't, I only see HDMI sound. This is even though /sys/devices/platform/spdif-out shows up with a driver which links to spdif-dit, /proc/config.gz makes it clear that spdif-dit is indeed enabled, and /sys/devices/platform/sound exists, and its modalias says "of:NsoundT(null)Csimple-audio-card" (tho there's no 'driver' symlink, I don't
<mort>
know if there should be)
<dsimic>
mort: yes, there should be a new audio card, available for playback
<dsimic>
but it's quite strange that there isn't... I assume you've made sure that the DT additions are in effect?
<mort>
yeah; I see u-boot loading it during boot, and the nodes show up in /sys/devices/platform
<mort>
is there some place I should check for errors?
<dsimic>
it might be that you're missing simple-audio-card,widgets and simple-audio-card,routing
<dsimic>
but I'm not sure should there be any error messages emitted if those are found to be missing
<dsimic>
perhaps this is also a good opportunity to improve the error handling
<dsimic>
and possibly submit those patches upstream as well
<mort>
I understand the general idea that "a route is a source and a sink", but I don't know what the relevant sources and sinks should be. Maybe "Playback" is a sink and the source is a name I give it? This stuff is hard to understand based on the documentation I'm reading
<dsimic>
yes, that area is blurry to me as well
<dsimic>
I Once grasped it pretty well, but it's been a while ago, so I forgot the details :/
<dsimic>
s/Once/once/
<mort>
spdif-dit has routes = { { .sink = "spdif-out", .control = NULL, .source = "Playback" } } and widgets = { { SND_SOC_DAPM_OUTPUT("spdif-out") } }, I wonder if the spdif-out in the sink and the spdif-out in the widget should be connected explicitly
<mort>
but none of the example uses I see of spdif-dit don't seem to?
<mort>
sorry for double negative
<dsimic>
no worries
<dsimic>
I think that the sink of spdif-out should be connected to the CPU's source
<dsimic>
but let me check an example in rk3399-pinebook-pro.dts
<mort>
oh that sounds vaguely logical
<dsimic>
yeah, it's rather vague
<dsimic>
that seems to be the case in rk3399-pinebook-pro.dts
<dsimic>
you've gotta love all the complexity of the audio subsystem :)
<dsimic>
it's insanely convoluted and extremely poorly documented
<mort>
:S
<dsimic>
there are also some weird bugs
<mort>
at least it's not just me who's stupid then
<dsimic>
ah, it isn't about being stupid or smart, it just takes time and effort
<mort>
I have rarely felt more like a moron than when I've spent days on end trying to just get my computer to output audio
<dsimic>
I know the feeling, I also spent a lot of time figuring out why the headphone detection doesn't work
<dsimic>
and it turned out to be a really bad bug in one of the drivers
<mort>
ouch
<dsimic>
for which I should actually submit a bugfix upstream :/
<dsimic>
I just had a look at that driver a minute ago :)
<mort>
but the string "Speaker" doesn't even occur :S
<dsimic>
there are a lot of other strings :)
<mort>
yeah but I hoped to build an understanding, like "oh this widget gets routed to this sink" or something
<dsimic>
I'd say that struct snd_soc_dapm_route es8316_dapm_routes[] is a good starting point
<dsimic>
it's also almost funny how much stuff is in struct snd_soc_dapm_widget es8316_dapm_widgets[]
<mort>
I'm trying to understand the connection between "Speaker Amplifier INL" -> "HPOL" and "Speaker" -> "Speaker Amplifier OUTL"
<mort>
is " INL" and " OUTL" some magic string which alsa knows what means so it knows to connect "Speaker Amplifier OUTL" to "Speaker Amplifier INL", and then the "Speaker Amplifier" part of the name is an arbitrary name with no meaning? I have no idea T_T
<mort>
sound-name-prefix = "Speaker Amplifier"; -- this is certainly relevant isn't it
<mort>
AAAAAAA dsimic do you know what I have forgotten about
<mort>
status = "okay";
<mort>
I probably need that in both the codec and the card don't I
<dsimic>
hmm, I don't think so, the default is to be okay
<mort>
huh really? I saw other people's overlays adding it even when adding new nodes
<dsimic>
regarding "Speaker Amplifier", yes, sound-name-prefix and sound/soc/codecs/simple-amplifier.c's struct snd_soc_dapm_widget simple_amp_dapm_widgets[] do the trick together
<dsimic>
maybe I'm wrong about okay being the default
<dsimic>
it's certainly worth a try to add 'status = "okay";'
<dsimic>
IDK, I'd make sure that everything is correct for the board you're using
<mort>
I don't know if the slot width is correct, but I do want 2 channels which makes slot-num=2 seem roughly correct
<mort>
the name i2s_clk_consumer worries me a bit but it seems to be an alias of i2s, not some weird clock consumer node
<dsimic>
just checking, are you sure that the DAC should act as the clock master?
<mort>
yes
<mort>
wait
<mort>
opposite
<dsimic>
that makes more sense
<dsimic>
you can also remove the dai-tdm-slot-num and dai-tdm-slot-width parameters initially
<dsimic>
the worst that can happen is no playback working
<dsimic>
while you keep the number of parameters to start with as low as possible
<mort>
but that results in a kernel which doesn't boot
<mort>
maybe it's time to dig into that crash...
<mort>
who knows, could be a driver bug
<mort>
I'm guessing that if I add a ton of debug prints throughout the path from asoc_simple_probe to dmaengine_trcm_new, I find something that's null that shouldn't be or something silly like that
<dsimic>
maybe also try writing the overlay from scratch
<mort>
that's what I did for the previous one which crashed on boot
<dsimic>
ah, I see
System_Error has quit [Remote host closed the connection]
<mort>
I need hdmi output and it's an rk3588s based SBC so I don't have much choice
<dsimic>
... for now :)
<dsimic>
there should be basic HDMI output available in mainline... rather soon, hopefully
<dsimic>
it might be good to test the audio stuff on mainline kernel, just in case there's some weirdness in the downstream kernel
<mort>
Yeah I've seen there has been decent progress on that frown lately, I even tried to get some patches which were being upstreamed working a while ago but couldn't get it to work
<dsimic>
or in case some bugs have eedn fixed since the downstream froze itself
<dsimic>
s/eedn/been/
<mort>
At least downstream kernels are using panthor now tho
<dsimic>
diederik: I missed that somehow
<mort>
earlier in the year I was using the proprietary Mali drivers and man do they suck to deal with