From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 1/2] ASoC: Add support for Conexant CX2072X CODEC Date: Mon, 06 May 2019 17:26:51 +0200 Message-ID: References: <20190423141336.12568-1-tiwai@suse.de> <20190423141336.12568-2-tiwai@suse.de> <20190427175938.GJ14916@sirena.org.uk> <20190503064729.GF14916@sirena.org.uk> <20190506042625.GK14916@sirena.org.uk> <20190506140506.GQ14916@sirena.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 34B59F80C07 for ; Mon, 6 May 2019 17:26:51 +0200 (CEST) In-Reply-To: <20190506140506.GQ14916@sirena.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Mark Brown Cc: alsa-devel@alsa-project.org, Pierre-Louis Bossart List-Id: alsa-devel@alsa-project.org 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