On Mon, 06 May 2019 16:05:06 +0200, Mark Brown wrote:
This is rather a question how generic the codec driver should be written. I changed the code in v5 patchset to embed the jack_gpio stuff inside the codec driver side rather than the machine driver, so the whole exported functions can be reduced now. But, of course, it slightly gives more implicit assumption about the hardware implementations, too. Though, the existing code seems to have already fixed gpio / pin setups, so the other setups wouldn't have worked, in anyway.
Like I say if the device is using the fact that the pin is a GPIO there's quite likely something wrong - that shouldn't be something that the user of an interrupt should need to see.
Yeah, unfortunately we have no reference, so the only chance would be to test with another board that has a different setup.
It's unlikely there are *no* default values - you'd kind of have to try to have a specific register range like this with genuinely floating values. Given that the code for configuring the EQ was broken to IIRC never take effect I'd not be 100% surprisd if someone couldn't figure out why their settings weren't taking effect and just bodged something directly in the driver.
Actually I'm fine to drop the whole EQ stuff that brings lots of black magic. Certainly it'll benefit us for code simplification. Let's see.
Probably worth checking to make sure the default EQ setup isn't too awful (though I guess the EQ is just turned off by default so it'll just be an uncorrected speaker/headphone which should be fine if not ideal).
A good point. I checked the status now, and found that actually the EQ and others won't appear in the normal playback / capture via HiFi route, but only through DSP. Since the normal usages with UCM profile goes only via HiFi, EQ/DRC don't play any role. So it's OK to remove them, at least, for normal PC usages, as well as RPi HiFi extensions, as it seems.
thanks,
Takashi