From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B28E6C433E2 for ; Fri, 11 Sep 2020 16:48:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B2D0221E7 for ; Fri, 11 Sep 2020 16:48:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726303AbgIKQs0 (ORCPT ); Fri, 11 Sep 2020 12:48:26 -0400 Received: from mga04.intel.com ([192.55.52.120]:11836 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726365AbgIKPHt (ORCPT ); Fri, 11 Sep 2020 11:07:49 -0400 IronPort-SDR: bKHopU7epsl1YDVPUUxC7cjPNg0tZAofEr/+Ckvk0PqZKiUYVB0T8+zk2xHDAQYuod2LWItiRr +D3p3BclEo1g== X-IronPort-AV: E=McAfee;i="6000,8403,9740"; a="156169574" X-IronPort-AV: E=Sophos;i="5.76,416,1592895600"; d="scan'208";a="156169574" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2020 08:07:25 -0700 IronPort-SDR: 4KNDny10BFkK+iQr+jUnPuRNxmW38V+91ARLv0S5o0x27rJZE6uaJy/wazA7H7JwpmBuamyGOO UV+MIBei0Lcg== X-IronPort-AV: E=Sophos;i="5.76,416,1592895600"; d="scan'208";a="481354710" Received: from basudipt-mobl1.gar.corp.intel.com (HELO [10.212.223.238]) ([10.212.223.238]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2020 08:07:24 -0700 Subject: Re: [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls To: Vinod Koul Cc: alsa-devel@alsa-project.org, tiwai@suse.de, broonie@kernel.org, gregkh@linuxfoundation.org, Bard liao , Rander Wang , Guennadi Liakhovetski , Kai Vehmanen , Sanyog Kale , open list References: <20200901162225.33343-1-pierre-louis.bossart@linux.intel.com> <20200901162225.33343-3-pierre-louis.bossart@linux.intel.com> <20200904050244.GT2639@vkoul-mobl> <20200909075555.GK77521@vkoul-mobl> <184867c2-9f0c-bffe-2eb7-e9c5735614b0@linux.intel.com> <20200910062223.GQ77521@vkoul-mobl> <20200911070649.GU77521@vkoul-mobl> From: Pierre-Louis Bossart Message-ID: <21606609-8aaf-c7b2-ffaf-c7d37de1fa3f@linux.intel.com> Date: Fri, 11 Sep 2020 09:50:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200911070649.GU77521@vkoul-mobl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vinod, >>>>>>>> + * 25 0 (Reserved) >>>>>>>> + * 24:22 Function Number [2:0] >>>>>>>> + * 21 Entity[6] >>>>>>>> + * 20:19 Control Selector[5:4] >>>>>>>> + * 18 0 (Reserved) >>>>>>>> + * 17:15 Control Number[5:3] >>>>>>>> + * 14 Next >>>>>>>> + * 13 MBQ >>>>>>>> + * 12:7 Entity[5:0] >>>>>>>> + * 6:3 Control Selector[3:0] >>>>>>>> + * 2:0 Control Number[2:0] [...] >>>> >>>> #define SDCA_CONTROL_DEST_MASK1 GENMASK(20, 19) >>>> #define SDCA_CONTROL_ORIG_MASK1 GENMASK(5, 4) >>>> #define SDCA_CONTROL_DEST_MASK2 GENMASK(6, 3) >>>> #define SDCA_CONTROL_ORIG_MASK2 GENMASK(3, 0) > > I think I missed ORIG and DEST stuff, what does this mean here? If you missed this, it means my explanations are not good enough and I need to make it clearer in the commit log/documentation. Point taken, I'll improve this for the next version. > Relooking at the bit definition, for example 'Control Number' is defined > in both 17:15 as well as 2:0, why is that. Is it split? > > How does one program a control number into this? A Control Number is represented on 6 bits. See the documentation above. 17:15 Control Selector[5:3] 2:0 Control Selector[2:0] The 3 MSBs for into bits 17:15 of the address, and the 3 LSBs into bits 2:0 of the address. The second part is simpler for Control Number but for entities and control selectors the LSB positions don't match. Yes it's convoluted but it was well-intended: in most cases, there is a limited number of entities, control selectors, channel numbers, and putting the LSBs together in the 16-LSB of the address helps avoid reprogramming paging registers: all the addresses for a given function typically map into the same page. That said, I am not sure the optimization is that great in the end, because we end-up having to play with bits for each address. Fewer changes of the paging registers but tons of operations in the core. I wasn't around when this mapping was defined, and it is what is is now. There's hardware built based on this formula so we have to make it work. Does this clarify the usage? If you have a better suggestion that the FIELD_PREP/FIELD_GET use, I am all ears. At the end of the day, the mapping is pre-defined and we don't have any degree of freedom. What I do want is that this macro/inline function is shared by all codec drivers so that we don't have different interpretations of how the address is constructed. Thanks, -Pierre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DAB9DC433E2 for ; Fri, 11 Sep 2020 15:08:38 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EB52E208FE for ; Fri, 11 Sep 2020 15:08:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="UTK17csb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB52E208FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 79B28820; Fri, 11 Sep 2020 17:07:45 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 79B28820 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1599836915; bh=haWnPufh9ckeb4AOwdBXLbLUphdQ0AhB8WMlrBk7HDI=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=UTK17csbLmNVKs3pAq8nRG2ziey4Rs3fyTwaPSxIoHunyczadsfczyRrSc9bNv9bH lmUgzyIWYiEWHQ2eprqGN4xsHW3ekrEDj6aodDNYdKyEzzB3PI+liFTNuFeoQvW3Ob 18hkoH7R63g3Pl+dkDlYkViDZ/oEWxz+EreGagBQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0901EF80240; Fri, 11 Sep 2020 17:07:45 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8EE21F80274; Fri, 11 Sep 2020 17:07:43 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id BA3BCF80115 for ; Fri, 11 Sep 2020 17:07:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BA3BCF80115 IronPort-SDR: z7LLeZVGyCpACynQPtbdhVAveqstyuLaawZDSh4G1adEAJFfYOMZRtmjPDFpS5D5cIJde+JUSl E93QO9Bo38rw== X-IronPort-AV: E=McAfee;i="6000,8403,9740"; a="146464770" X-IronPort-AV: E=Sophos;i="5.76,415,1592895600"; d="scan'208";a="146464770" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2020 08:07:25 -0700 IronPort-SDR: 4KNDny10BFkK+iQr+jUnPuRNxmW38V+91ARLv0S5o0x27rJZE6uaJy/wazA7H7JwpmBuamyGOO UV+MIBei0Lcg== X-IronPort-AV: E=Sophos;i="5.76,416,1592895600"; d="scan'208";a="481354710" Received: from basudipt-mobl1.gar.corp.intel.com (HELO [10.212.223.238]) ([10.212.223.238]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2020 08:07:24 -0700 Subject: Re: [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls To: Vinod Koul References: <20200901162225.33343-1-pierre-louis.bossart@linux.intel.com> <20200901162225.33343-3-pierre-louis.bossart@linux.intel.com> <20200904050244.GT2639@vkoul-mobl> <20200909075555.GK77521@vkoul-mobl> <184867c2-9f0c-bffe-2eb7-e9c5735614b0@linux.intel.com> <20200910062223.GQ77521@vkoul-mobl> <20200911070649.GU77521@vkoul-mobl> From: Pierre-Louis Bossart Message-ID: <21606609-8aaf-c7b2-ffaf-c7d37de1fa3f@linux.intel.com> Date: Fri, 11 Sep 2020 09:50:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200911070649.GU77521@vkoul-mobl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: Guennadi Liakhovetski , alsa-devel@alsa-project.org, Kai Vehmanen , tiwai@suse.de, gregkh@linuxfoundation.org, open list , broonie@kernel.org, Sanyog Kale , Bard liao , Rander Wang X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi Vinod, >>>>>>>> + * 25 0 (Reserved) >>>>>>>> + * 24:22 Function Number [2:0] >>>>>>>> + * 21 Entity[6] >>>>>>>> + * 20:19 Control Selector[5:4] >>>>>>>> + * 18 0 (Reserved) >>>>>>>> + * 17:15 Control Number[5:3] >>>>>>>> + * 14 Next >>>>>>>> + * 13 MBQ >>>>>>>> + * 12:7 Entity[5:0] >>>>>>>> + * 6:3 Control Selector[3:0] >>>>>>>> + * 2:0 Control Number[2:0] [...] >>>> >>>> #define SDCA_CONTROL_DEST_MASK1 GENMASK(20, 19) >>>> #define SDCA_CONTROL_ORIG_MASK1 GENMASK(5, 4) >>>> #define SDCA_CONTROL_DEST_MASK2 GENMASK(6, 3) >>>> #define SDCA_CONTROL_ORIG_MASK2 GENMASK(3, 0) > > I think I missed ORIG and DEST stuff, what does this mean here? If you missed this, it means my explanations are not good enough and I need to make it clearer in the commit log/documentation. Point taken, I'll improve this for the next version. > Relooking at the bit definition, for example 'Control Number' is defined > in both 17:15 as well as 2:0, why is that. Is it split? > > How does one program a control number into this? A Control Number is represented on 6 bits. See the documentation above. 17:15 Control Selector[5:3] 2:0 Control Selector[2:0] The 3 MSBs for into bits 17:15 of the address, and the 3 LSBs into bits 2:0 of the address. The second part is simpler for Control Number but for entities and control selectors the LSB positions don't match. Yes it's convoluted but it was well-intended: in most cases, there is a limited number of entities, control selectors, channel numbers, and putting the LSBs together in the 16-LSB of the address helps avoid reprogramming paging registers: all the addresses for a given function typically map into the same page. That said, I am not sure the optimization is that great in the end, because we end-up having to play with bits for each address. Fewer changes of the paging registers but tons of operations in the core. I wasn't around when this mapping was defined, and it is what is is now. There's hardware built based on this formula so we have to make it work. Does this clarify the usage? If you have a better suggestion that the FIELD_PREP/FIELD_GET use, I am all ears. At the end of the day, the mapping is pre-defined and we don't have any degree of freedom. What I do want is that this macro/inline function is shared by all codec drivers so that we don't have different interpretations of how the address is constructed. Thanks, -Pierre