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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 19709C433EF for ; Fri, 4 Mar 2022 18:58:08 +0000 (UTC) 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 D73B81EED; Fri, 4 Mar 2022 19:57:16 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D73B81EED DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1646420286; bh=CanmrYx0gIKI2ZjWXu8YbnZHqsyurgXB+77JJ0oD/sk=; h=Date:Subject:To:References:From:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=EchcYeiGJx/T8SmJpmyjSp0DwTjvaFuOcueBKFjAe8+MlePumnD9/GpR8/A+k+KVE d1u2CNyjlKRJevjzVDbYszvLxLH8u/WJyqkCLzqKON1hH/gIkps7D1sbzpz/pbs66e 8swdxcFy1bebHuWvE/+uLimseWQB5oB8SsmV5WSA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 6B5A6F80139; Fri, 4 Mar 2022 19:57:16 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 292DEF800F0; Fri, 4 Mar 2022 19:57:15 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 CAAD7F800F0 for ; Fri, 4 Mar 2022 19:57:09 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz CAAD7F800F0 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="IAq3Io1i" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646420233; x=1677956233; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=CanmrYx0gIKI2ZjWXu8YbnZHqsyurgXB+77JJ0oD/sk=; b=IAq3Io1iPkfXV8avVDe6e1KqP55lFxPawBczGyFBZxcoX0HC8HFqw4ir cTAzLhklnEPM+6pwaoTm9WEhokix/xVPzd6ftiUcuAwaBXtiGFEVYKDMR 2PMObOwiEf6Imk4ftLOQczaiCATHGSdVd/D2fFgTeQtAVdhLGc4VkAgFr b6u+b70zPvSWrvXYUoRUqW4aqiM3qa42+coKwsQA6Qfm2cEOXIILojD7I o344/p56bX7F9B2u3x2FOx+ztwTCwzv4U7a0LScxlXS9SZApwhXDP/xUd QymAdZ/jQnfugeag15o0uM3J/kNQq/fLf65bcY3B3V24ZqRly40XyqZAH g==; X-IronPort-AV: E=McAfee;i="6200,9189,10276"; a="253974828" X-IronPort-AV: E=Sophos;i="5.90,155,1643702400"; d="scan'208";a="253974828" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 10:56:46 -0800 X-IronPort-AV: E=Sophos;i="5.90,155,1643702400"; d="scan'208";a="642599590" Received: from padmashr-mobl.amr.corp.intel.com (HELO [10.251.24.125]) ([10.251.24.125]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2022 10:56:45 -0800 Message-ID: Date: Fri, 4 Mar 2022 12:56:44 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: [PATCH v3 17/17] ASoC: Intel: avs: Code loading over HDA Content-Language: en-US To: Cezary Rojewski , Ranjani Sridharan , alsa-devel@alsa-project.org References: <20220304145755.2844173-1-cezary.rojewski@intel.com> <20220304145755.2844173-18-cezary.rojewski@intel.com> <2b75e00683d7f7c33ecdf78a9889748aeb50555a.camel@linux.intel.com> <9d8381af-aa03-743f-7ed6-93dfc18e5a54@intel.com> From: Pierre-Louis Bossart In-Reply-To: <9d8381af-aa03-743f-7ed6-93dfc18e5a54@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com, tiwai@suse.com, hdegoede@redhat.com, broonie@kernel.org, amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org, lma@semihalf.com 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" >>> Compared to SKL and KBL, younger cAVS platforms are meant to re-use >>> one >> Younger? you mean newer? > > > Isn't the meaning of the two quite similar in this context? younger doesn't sound quite right to me. 'cAVS platforms more recent that SKL and KBL...' > >>> of HDAudio streams during boot procedure causing CLDMA to become >>> obsolete. Once transferred, given stream is returned to pool >>> available >>> for audio streaming. >>> >>> Module loading handler is dummy as library and module code became >>> inseparable in later firmware generations. >> replace dummy with "stub" maybe? lets use inclusive terms > > > Is 'dummy' categorized as non-inclusive? We have several usages of > 'dummy' even within /sound (e.g. soc-utils.c). Intel and plenty of other companies recommend a different wording. mock-up, stub, placeholder, etc. see e.g. https://developers.google.com/style/inclusive-documentation Yes we have plenty of existing uses of 'dummy', but that doesn't mean we should add new ones. >>> +static int >>> +avs_hda_init_rom(struct avs_dev *adev, unsigned int dma_id, bool >>> purge) >>> +{ >>> +    const struct avs_spec *const spec = adev->spec; >>> +    unsigned int corex_mask, reg; >>> +    int ret; >>> + >>> +    corex_mask = spec->core_init_mask & ~AVS_MAIN_CORE_MASK; >>> + >>> +    ret = avs_dsp_op(adev, power, spec->core_init_mask, true); >>> +    if (ret < 0) >>> +        goto err; >>> + >>> +    ret = avs_dsp_op(adev, reset, AVS_MAIN_CORE_MASK, false); >>> +    if (ret < 0) >>> +        goto err; >>> + >>> +    reinit_completion(&adev->fw_ready); >>> +    avs_dsp_op(adev, int_control, true); >>> + >>> +    /* set boot config */ >>> +    ret = avs_ipc_set_boot_config(adev, dma_id, purge); >>> +    if (ret) { >>> +        ret = AVS_IPC_RET(ret); >>> +        goto err; >>> +    } >>> + >>> +    /* await ROM init */ >>> +    ret = snd_hdac_adsp_readq_poll(adev, spec->rom_status, reg, >>> +                       (reg & 0xF) == AVS_ROM_INIT_DONE >>> || >>> +                       (reg & 0xF) == >>> APL_ROM_FW_ENTERED, >>> +                       AVS_ROM_INIT_POLLING_US, >>> APL_ROM_INIT_TIMEOUT_US); >>> +    if (ret < 0) { >>> +        dev_err(adev->dev, "rom init timeout: %d\n", ret); >>> +        goto err; >>> +    } >>> + >>> +    /* power down non-main cores */ >>> +    if (corex_mask) >>> +        avs_dsp_op(adev, power, corex_mask, false); >> What if this fails? > > > We are still in happy path, worst thing could happen here is increased > power consumption. 'happy path'?