From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars-Peter Clausen Subject: Re: [PATCH] ASoC: dapm: Add support for multi register mux Date: Thu, 03 Apr 2014 15:31:58 +0200 Message-ID: <533D62CE.5040907@metafoo.de> References: <1396494710-20944-1-git-send-email-aruns@nvidia.com> <20140403095330.GS14763@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-out-019.synserver.de (smtp-out-105.synserver.de [212.40.185.105]) by alsa0.perex.cz (Postfix) with ESMTP id E44A6261A80 for ; Thu, 3 Apr 2014 15:31:05 +0200 (CEST) In-Reply-To: <20140403095330.GS14763@sirena.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: Songhee Baek , Arun Shamanna Lakshmi , alsa-devel@alsa-project.org, swarren@wwwdotorg.org, Takashi Iwai , linux-kernel@vger.kernel.org, lgirdwood@gmail.com List-Id: alsa-devel@alsa-project.org On 04/03/2014 11:53 AM, Mark Brown wrote: > On Thu, Apr 03, 2014 at 11:47:15AM +0200, Takashi Iwai wrote: > >> I'm a bit late in the game, but I feel a bit uneasy through looking >> at the whole changes. My primary question is, whether do we really >> need to share the same struct soc_enum for the onehot type? What >> makes hard to use a struct soc_enum_onehot for them? You need >> different individual get/put for each type. We may still need to >> change soc_dapm_update stuff, but it's different from sharing >> soc_enum. > > Indeed, I had thought this was where the discussion was heading - not > looked at this version of the patch yet. > It would be nice, but it also requires some slight restructuring. The issue we have right now is that there is strictly speaking a bit of a layering violation. The DAPM widgets should not need to know how the kcontrols that are attached to the widget do their IO. What we essentially do in dapm_connect_mux() (and also dapm_connect_mixer) is an open-coded version of the controls get handler. Replacing that by calling the get handler instead should allow us to use different structs for enums and onehot enums. - Lars From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752100AbaDCNbL (ORCPT ); Thu, 3 Apr 2014 09:31:11 -0400 Received: from smtp-out-105.synserver.de ([212.40.185.105]:1083 "EHLO smtp-out-019.synserver.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751600AbaDCNbI (ORCPT ); Thu, 3 Apr 2014 09:31:08 -0400 X-SynServer-TrustedSrc: 1 X-SynServer-AuthUser: lars@metafoo.de X-SynServer-PPID: 12092 Message-ID: <533D62CE.5040907@metafoo.de> Date: Thu, 03 Apr 2014 15:31:58 +0200 From: Lars-Peter Clausen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Mark Brown CC: Takashi Iwai , Arun Shamanna Lakshmi , lgirdwood@gmail.com, swarren@wwwdotorg.org, perex@perex.cz, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Songhee Baek Subject: Re: [PATCH] ASoC: dapm: Add support for multi register mux References: <1396494710-20944-1-git-send-email-aruns@nvidia.com> <20140403095330.GS14763@sirena.org.uk> In-Reply-To: <20140403095330.GS14763@sirena.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/03/2014 11:53 AM, Mark Brown wrote: > On Thu, Apr 03, 2014 at 11:47:15AM +0200, Takashi Iwai wrote: > >> I'm a bit late in the game, but I feel a bit uneasy through looking >> at the whole changes. My primary question is, whether do we really >> need to share the same struct soc_enum for the onehot type? What >> makes hard to use a struct soc_enum_onehot for them? You need >> different individual get/put for each type. We may still need to >> change soc_dapm_update stuff, but it's different from sharing >> soc_enum. > > Indeed, I had thought this was where the discussion was heading - not > looked at this version of the patch yet. > It would be nice, but it also requires some slight restructuring. The issue we have right now is that there is strictly speaking a bit of a layering violation. The DAPM widgets should not need to know how the kcontrols that are attached to the widget do their IO. What we essentially do in dapm_connect_mux() (and also dapm_connect_mixer) is an open-coded version of the controls get handler. Replacing that by calling the get handler instead should allow us to use different structs for enums and onehot enums. - Lars