Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp160220ybi; Fri, 26 Jul 2019 07:42:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqw8bk9WyBMf8V/hEJqJ0bU3TgPTa6a0BURWBB1TKg5AtN+Uwah+w0XPH546U1ANUxfd3onM X-Received: by 2002:a17:90a:9bc5:: with SMTP id b5mr99132094pjw.109.1564152160542; Fri, 26 Jul 2019 07:42:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564152160; cv=none; d=google.com; s=arc-20160816; b=onIHyRy+pKflLjNMiphTLVxDwMD6qbsDFa9KLf+BGsga32bIX84mrJVDsFK28Oy0Sj 6p/JxuNUkKaORwqf0coQN1FoGgW1q5o8T2bM3b8wog1YITYu7i/Vm5efuSvSSmkPa8/h aOuLgqgLxWoNJ1bHLvpciHDTUe7HY4d/G3MfPEP2qq1rvYgV5OKafD2qA8uSDBFHgZ9f twMGuEtgWjQ+JenVZ+ySl8mLrkRcMdTHJYVhnBWc9Z8WaXBylX2IbWZkHTM7h2TkyjYA 3qnkPZxRFKokpVdqhmCo4mkJGb34pDSXhO6cvDaqmX6tQOCVra+pALQRMGB9QsAfE4eE WoBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=P6kYpiFGQFUDZ7vnTPGzdsPO/ZTeOvv4n7kU/mOSuPQ=; b=PYGrDcyobP2dRBSwAzCxecAXpACeX+x9Hd18/+3ljj73xzMM9GiJoUBkgv1ivF9wjK R2cgplxrmJFjkXMCwC1xjUlgrOPKhXdugjb9J0XF75K2WcL42wJKPRhQJAqKnVmy9ppC JuICMZcgPqXIrcK35MwtnuwQil94rzaq4250v2tYiIduy+4QCUIDEr2wWvu/UtNVVEuw HV3fIaJC/q3ZWF9+F2/bKVFOgiNiw5rrsfMj2CsjP75V1mLATAyA9BMDbfA22rp7GE8t cE5Lcl3AXTbsBrbkUA4fSN5z63yeXrngmPtnYvi/Zn3uPt4QTA3pHT+kN6GVi/Z+aBlY PfdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id br15si18498812pjb.13.2019.07.26.07.42.25; Fri, 26 Jul 2019 07:42:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387467AbfGZOlF (ORCPT + 99 others); Fri, 26 Jul 2019 10:41:05 -0400 Received: from mga04.intel.com ([192.55.52.120]:45103 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726731AbfGZOlE (ORCPT ); Fri, 26 Jul 2019 10:41:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 07:41:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,311,1559545200"; d="scan'208";a="322055350" Received: from msmall-mobl.amr.corp.intel.com (HELO [10.251.154.62]) ([10.251.154.62]) by orsmga004.jf.intel.com with ESMTP; 26 Jul 2019 07:41:02 -0700 Subject: Re: [alsa-devel] [RFC PATCH 27/40] soundwire: Add Intel resource management algorithm To: Cezary Rojewski Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, tiwai@suse.de, broonie@kernel.org, vkoul@kernel.org, gregkh@linuxfoundation.org, jank@cadence.com, srinivas.kandagatla@linaro.org, slawomir.blauciak@intel.com, Sanyog Kale References: <20190725234032.21152-1-pierre-louis.bossart@linux.intel.com> <20190725234032.21152-28-pierre-louis.bossart@linux.intel.com> <869edbf2-1fdd-6b21-818f-20c39c013c11@intel.com> From: Pierre-Louis Bossart Message-ID: Date: Fri, 26 Jul 2019 09:41:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <869edbf2-1fdd-6b21-818f-20c39c013c11@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/26/19 6:07 AM, Cezary Rojewski wrote: > On 2019-07-26 01:40, Pierre-Louis Bossart wrote: >> This algorithm computes bus parameters like clock frequency, frame >> shape and port transport parameters based on active stream(s) running >> on the bus. >> >> This implementation is optimal for Intel platforms. Developers can >> also implement their own .compute_params() callback for specific >> resource management algorithm. >> >> Credits: this patch is based on an earlier internal contribution by >> Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah. All hard-coded >> values were removed from the initial contribution to use BIOS >> information instead. >> >> FIXME: remove checkpatch report >> WARNING: Reusing the krealloc arg is almost always a bug >> +            group->rates = krealloc(group->rates, >> >> Signed-off-by: Pierre-Louis Bossart >> > > Could you specify the requirements and limitations for this algorithm? > Last year I written calc for Linux based on Windows (please don't burn > me here) equivalent though said requirements/ limitiations might have > changed and nothing is valid any longer. The frame shape typically only changes by doubling the number of columns, and the priority is given to PDM streams which use columns. It's hard to document this on a public mailing list, it'd require making references to a spec that's only available to MIPI members. > > I remember that some parts of specification overcomplicated the > calculator and due to actual, realtime usecases it could be greatly > simplified (that's why I mention that my work is probably no longer > valid). However, these details would help me in reviewing your > implementation and providing suggestions. To the best of my knowledge, the algorithm follows a script that is used for both Windows and Linux. The code was initially written by Vinod and team, and I am not aware of simplifications. There a simplifications that are possible, e.g. we don't support PDM for now and the notion of grouping is not needed, but we have to carefully balance 'optimization' with 'introducing bugs'. if this algorithm craps out then the entire bus operation is in the weeds. If we really want people to experiment and get a feel for the performance of the algorithm, we should really provide a UI where the stream parameters can be entered and visually check what the algorithm is doing. I have a solution that shows the bits based on the stream parameters (need to make it available e.g. in Python), if we connected it with the automatic bit allocation it'd be very useful. > And yes, "Frame shape calculator" probably suits this better. > Though this might be just a preference thingy : ) Resource management is indeed a bit vague. But frame shape calculator is not quite right. The algorithm will find the frame shape that is required for the current bandwidth, but will also allocate the bitSlots in that frame. In MIPI circles we talk about bitSlot allocation.