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=-10.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 23AFFC636CB for ; Fri, 16 Jul 2021 19:17:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0479D613D4 for ; Fri, 16 Jul 2021 19:17:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232355AbhGPTUH (ORCPT ); Fri, 16 Jul 2021 15:20:07 -0400 Received: from esa.microchip.iphmx.com ([68.232.153.233]:21940 "EHLO esa.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230256AbhGPTUF (ORCPT ); Fri, 16 Jul 2021 15:20:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1626463030; x=1657999030; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=F3qFxoWuttwrIoU5MmfRCmTy007uSOQOuWxMKEt4HP0=; b=Rt0erlNJUnUVD9rrU8i/jHEcs1mQmh9TAUPxAzVaGbngQa0P3nUj08d2 lTRRKWqGd+WBRP5j3vmURR2n97Qqtv105R6T3dlavxWYh6eHj5UNckMvB rpy4MBNPiFjjlKpNlr7rEsrWUDA/6s62UDKOKzxPCbOzrLn/rTkRSE+ia 3mbqj4WlJC2XC9/KtQcWya4YZ0rTODr0aejOXtFAoDcQvidccZfEYO0cG tqsmVEVy9q1aPMdYDRG08DN6Fm/fC8istIWNTnwHQipOZ7/0rxvTRJGGD Ms2EpHttzD1DU7zTZvyrv0v5mtCNXYZ9mCY5dYNlOtZoiGE7Qiw8qqNFm w==; IronPort-SDR: Y+Tu3euWzPOM0Dp3/IZ/fHkfQpfauDc2+EcaTM5GKlgAdMj4Bs4uzJXVmHF45XT/zJTtvo1hjQ d3T/MQoyNDwK/Ifvy6oHb//EdCXNytD2U1xhuwfGU1Z/YFB0wi24EMluxyTy/jXA8O4w5mr37h 0HpC3i3ZnlYHb1C7qcjlitpabNkrc1rdscdzeT7QAwqu2lAVFSD5/WmkoeS29HEId8kFd6V5+F gU0MlTLQsZ2RKSCI4I/fUTyhTXRErF3v2/4l57CPVl/EKMWL+CSeyV5t3JIWWVRPLGIq3xrriA fRMCoCvd2F2ZkCpUjLnUTQp9 X-IronPort-AV: E=Sophos;i="5.84,245,1620716400"; d="scan'208";a="136229222" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 16 Jul 2021 12:17:09 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 16 Jul 2021 12:17:09 -0700 Received: from [10.12.72.255] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2176.2 via Frontend Transport; Fri, 16 Jul 2021 12:17:07 -0700 Subject: Re: [PATCH] clk: at91: clk-generated: Limit the requested rate to our range To: Codrin Ciubotariu - M19940 , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" CC: "mturquette@baylibre.com" , "sboyd@kernel.org" , "alexandre.belloni@bootlin.com" , Ludovic Desroches - M43218 , Claudiu Beznea - M18063 References: <20210707131213.3283509-1-codrin.ciubotariu@microchip.com> <7586cf33-078a-cb85-98c8-9969baa0f19d@microchip.com> <25631072-d9a3-0d84-fd47-4d2414f079f6@microchip.com> From: Nicolas Ferre Organization: microchip Message-ID: <4393ec64-3891-a875-b948-516efd08817c@microchip.com> Date: Fri, 16 Jul 2021 21:17:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <25631072-d9a3-0d84-fd47-4d2414f079f6@microchip.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/07/2021 at 11:59, Codrin Ciubotariu - M19940 wrote: > On 09.07.2021 12:21, Nicolas Ferre wrote: >> On 07/07/2021 at 15:12, Codrin Ciubotariu wrote: >>> On clk_generated_determine_rate(), the requested rate could be outside >>> of clk's range. Limit the rate to the clock's range to not return an >>> error. >> >> Isn't it saner for the user to return an error code instead of >> automatically restrain the dynamics requested without notice? >> >> Can you elaborate the use case where returning an error is not convenient? > > The way I see it, if the user requests a rate that is out of clock's > range, the driver's determine_rate() should return min/max, not an > error. That is actually the closest rate supported by the clock, which > is what determine_rate() should accomplish. The user has no clk API to > get clock's range, so there is no way to call clk_round_rate() only for > values within our range. > > The use cause is with sam9x60's I2S driver, which has to try different > rates to get the closest one to what it needs. There is no 'perfect' > rate, because there is no AUDIO PLL and we have to try different values > for our internal dividers to find the closest one. > > https://elixir.bootlin.com/linux/latest/source/sound/soc/atmel/mchp-i2s-mcc.c#L416 Sure, makes sense: Acked-by: Nicolas Ferre Regards, Nicolas -- Nicolas Ferre