Hi Torsten! Torsten Duwe writes: > > > > > > But we need a way to control the mux from userspace and aside from > > > > > > unbinding the ideas proposed thus far are: > > > > > > > > > > > > a) control the gpio directly > > > > > > b) control the gpio via leds-gpio > > > > > > > > > > > > (a) was dismissed because we can't set a default from DT > > > > > > (b) was dismissed because some rogue app might try to blink it > > Hey, this is a debugging hack. If some rogue app tries to blink it, so be it. > > > I suspect some distributions will pick up the patch I posted anyway, if > > it doesn't get merged mainline. (This is how I forgot missing backlight > > support - it just worked for too many people ...) If we ship > > sun50i-a64-teres-i.dts with the proper nodes (but disabled), their > > patches will be much easier to maintain as the official DT evolves. > > As I wrote (held by the list admin), I consider the whole console mux > GPIO an U-Boot hack, and would put it into sun50i-a64-teres-i-u-boot.dtsi. > (As a LED, see above :-) The thing is, one of the quite strict rules in kernel development is: Never break userspace. That means: If we provide a way to userspace to do something (ie switch between debug and audio), we are expected to keep it around forever. So since there is a decent chance that someday somebody might write a driver that handles this situation properly, we don't want chain ourselves to some dirty hack. (I'm not totally against writing such a driver myself, if there are enough use cases. However, I think that TERES alone is not enough.) > Would you care to submit a patch version without that GPIO handled? > I think it's very useful and has the potential to be agreed upon. That would enable audio from the internal speakers but select debug output on the HP jack by default. I would be okay with that, despite still thinking that audio on the head phones should be the default. Maxime and Wens are the maintainers, so it's their call in the end. HTE, Harald
