Of course it's 2023 and Linux still doesn't have a solution for multiple peripherals sharing a GPIO.

A patch with a universal solution was proposed in 2019, but was shot down, with the submitter being told that the solution is instead to... fix every driver (hundreds) to use regulators instead of GPIOs.

So here we are, once again, with practical solutions being shot down in the Linux kernel in favor of theoretical code cleanup that takes exponentially more time and is never going to actually happen.

Never mind that there wasn't even one single proposed solution, because the problem being solved could be represented in multiple ways in the Linux kernel. We have raw GPIOs, reset controllers, regulators, and power domains, all of which could arguably represent the concept of "turn an audio amplifier on and off" 🤦‍♂️​

And of course nobody has proposed any common code to at least make this not require changes to every single driver.

So I guess tomorrow morning I'm streaming from my parents' place and adding regulator support to the audio amp drivers we use (no, I'm not going to attempt another generic solution, I'm way too burned out on kernel development to sign up for more yak shaves for free and people want working speakers, not for me to waste time arguing with kernel maintainers).

I swear I wish I could actually fix all these problems, but I just can't. Not with the monumentally fucked up state of the kernel development process. We're going to get the platforms supported, but I've lost all motivation to choose kernel-wide improvements over local hardware-specific solutions where not necessary because it's just more work for me for no personal gain, and I have no hope left of getting people to agree on common solutions and improvements, never mind the pain and yak shaving that always brings.

If Linux wants to actually attain and keep a healthy pace of cleaning up tech debt, especially in the clusterf*ck that is the embedded platform space, it needs to fix the horrible dev and submission workflow. There is no other way.

(I'm still signing up for hard problems that need fixing of course, like all the brokenness in the USB Type C and PCIe subsystems, because we're the only platform aiming for upstream with those use cases right now and there's no easy fix without doing that in that case. I'm just not going to do "nice but not required" cleanups or sign up for extra yak shave where I have an easy solution, like adding a few lines to implement reg support for our 3 amp drivers here).

@marcan I wonder whether that attitude grew out of the concept for demanding "big corp" to not only do their isolated solutions but contribute at large. Which, in general, is probably a good thing.

Shooting down individuals is applying the wrong pressure and demand: Of course it'd be better if one could use that as a lever to improve more as a whole, but you cannot spend that much time.

Also, of course, often you have a small individual who is payed by a large corp but they're by far not representing them.

@ljrk In this case the patch was submitted by a "big corp" employee, but that's already more than most big corps contribute. It got shot down on v2.

@marcan first of all the maillists need to die, they hold back so much by being so foreign compared to most other dev flows nowadays.

@f4grx @ITJamie A forge, like literally every other open source project.

@f4grx @marcan a single instance of something like gitlab, bitbucket etc where all projects that flow up into the kernel must host their codebase and accept issues prs etc in.

@marcan Directly controlling the GPIOs controlling regulators does fall over as soon as someone builds a board with a differently controlled regulator.

There were some efforts at generalising power up sequences but they kept on running into varying requirements creating excessive complexity - devices needing sequencing/delays/handover to runtime PM/whatever and trying to work out how to express that in a manner that’s saving anything over just writing code in the driver.

@broonie I dunno, genpd already has a workable solution: one PD is managed for you, more than one you get to write the code. Seems like a similar solution would work to drive regulators without per-driver code in most cases.

Note that in this case this isn't even a regulator. It's just a shutdown input to the amps themselves, so perfectly sensible to drive as a GPIO. It's just that sharing the same GPIO for more than one amp blows up because there is no refcounting.

@marcan Ah, from what you were saying about people being told to solve the problem with the regulator API I thought this was a regulator, that’s not a sensible fit for non-regulators. Is there not something similar in the reset API (not checked, on my phone)? @krzk
did have the same problem with shared reset/shutdown GPIOs just this week with some other amps.

@marcan It’s definitely possible to see where you could slot in an attempt at standard handling for power up, the trick is making sure it doesn’t get in the way and cause trouble when something more complex is needed and/or allowing quirks. Power domains were actually one of the suggestions being kicked around IIRC.

@broonie @marcan @krzk reset controller s have shared resets which ensures the reset is only asserted when no consumer has the reset deasserted: https://docs.kernel.org/driver-api/reset.html

@marcan @broonie Ulf Hansson is considering adding helpers to avoid per driver boilerplate code for the multiple power-domains case. That would at least make cases without complex power sequencing requirements easier.

@janne @broonie @krzk Yes, both reset regulator are roughly equivalent solutions to the same problem. They are both lies (the line is neither a reset line nor a regulator enable line, it is a soft shutdown line).

@marcan @janne @krzk We should probably librify the discovery and refcounting parts so that drivers like yours can just pick it up - that would I think fit fine in the GPIO API.

@marcan I have been wondering; if the Linux kernel upstream is so terrible, have you ever considered doing Asahi BSD instead? I guess you probably have but their base hardware support is much lower than Linux's?

@RyuKurisu OpenBSD on Apple Silicon is a thing already (and beat every Linux distro at officially supporting the platform even), but that software ecosystem is nowhere near what you need for a viable experience for typical end users. We can't push niche OSes on people, that just isn't going to get us anywhere. People want Linux (and things like Steam and games etc).

Plus they don't have Rust in their kernel, and until that happens sadly they're going to be stuck without a GPU driver for these GPUs (our licensing is compatible otherwise, but they need to bite the Rust bullet).

@janne @broonie @marcan As Janne points, reset controller framework solves this problem ("Shared resets behave similarly to clocks in the kernel clock framework. They provide reference counted deassertion..."), but, now wearing DT maintainer hat, "resets" property points to a reset controller not to a GPIO. It is something else than a reset-gpio. Representing reset-gpio as a reset controller would be an overkill and a workaround for limitations of a specific OS implementation. Thus it would not make me happy as a DT maintainer...

As far as Linux kernel is concerned, I was thinking of stuffing this feature into the GPIO lib: https://lore.kernel.org/alsa-devel/84f9f1c4-0627-4986-8160-b4ab99469b81@linaro.org/

@krzk @broonie @janne This is how I ended up doing it for now. Comments welcome.

https://github.com/AsahiLinux/linux/commit/5427e7fcfd4db6371c59b20d42d694551b92fdf8

@marcan @broonie @janne That's a way to solve your use case. Might not get pass upstream review, though. DTS should represent real hardware and you created there a virtual regulator. What's more, do your devices have a SDZ supply? Probably not, so also not a true hardware representation. IOW, this is a work-around for the limitations of current OS implementation, so wearing DT maintainer hat: does not looks upstreamable.

@krzk @broonie @janne

*Sigh*.

Someone tried to fix this in GPIO in 2019:

https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/

And among other things got told to use reset controllers or regulators:

https://lore.kernel.org/lkml/3c384b40-f353-eaec-b1d6-ba74f5338ce1@metux.net/

I honestly have very little energy left for giant bikesheds on LKML. *Please* figure out what we should do with Linus Walleij. I'm happy to implement $whatever, but I need to know it will be accepted. Otherwise, I guess audio codec sleep will be broken upstream on our platforms for the foreseeable future. I can't personally handle driving the bikeshedding of every years-old trivial Linux subsystem problem that hasn't been solved yet for stupid reasons. Sorry.

@marcan @krzk @janne It’s one of the problems with using DT - it makes lots of stuff visible in ABI which often adds complications. OTOH DT systems also don’t have the endless stream of quirks that frustrates everyone using ACPI systems 🤷.

Hopefully you’ll be able to adopt whatever @krzk comes up with for his systems. For now I’d suggest using a GPIO in the binding with a local patch for non-exclusive usage, that sounds closest to what he’s thinking.

@broonie @krzk @janne Brute force non-exclusive doesn't work, I need wired-OR signaling. The line needs to stay high until the last codec powers down and go high when the first codec powers up, otherwise it all goes wrong.

@marcan @krzk @janne Ah, of course - it’s not actually a reset line so has more complicated sequencing (a simple share of a reset line would be dodgy and broken in some cases but tends to actually work out fine in practice as people rarely power up only one channel and the sequencing tends to work out).