From patchwork Thu Feb 18 11:40:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Nuno Sa X-Patchwork-Id: 12093455 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=-11.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=ham 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 BCCEAC433E0 for ; Thu, 18 Feb 2021 11:55:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 75AFC64D79 for ; Thu, 18 Feb 2021 11:55:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230194AbhBRLzE (ORCPT ); Thu, 18 Feb 2021 06:55:04 -0500 Received: from mx0a-00128a01.pphosted.com ([148.163.135.77]:31900 "EHLO mx0a-00128a01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231792AbhBRLjZ (ORCPT ); Thu, 18 Feb 2021 06:39:25 -0500 Received: from pps.filterd (m0167089.ppops.net [127.0.0.1]) by mx0a-00128a01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11IBUHvd031168; Thu, 18 Feb 2021 06:38:30 -0500 Received: from nwd2mta3.analog.com ([137.71.173.56]) by mx0a-00128a01.pphosted.com with ESMTP id 36pcjaxkwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2021 06:38:30 -0500 Received: from SCSQMBX11.ad.analog.com (SCSQMBX11.ad.analog.com [10.77.17.10]) by nwd2mta3.analog.com (8.14.7/8.14.7) with ESMTP id 11IBcSbi054472 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=FAIL); Thu, 18 Feb 2021 06:38:29 -0500 Received: from SCSQMBX10.ad.analog.com (10.77.17.5) by SCSQMBX11.ad.analog.com (10.77.17.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Thu, 18 Feb 2021 03:38:27 -0800 Received: from zeus.spd.analog.com (10.66.68.11) by scsqmbx10.ad.analog.com (10.77.17.5) with Microsoft SMTP Server id 15.2.721.2 via Frontend Transport; Thu, 18 Feb 2021 03:38:27 -0800 Received: from nsa.sphairon.box ([10.44.3.52]) by zeus.spd.analog.com (8.15.1/8.15.1) with ESMTP id 11IBcOqw013165; Thu, 18 Feb 2021 06:38:25 -0500 From: Nuno Sa To: , CC: Jonathan Cameron , Rob Herring , Lars-Peter Clausen , Michael Hennerich Subject: [PATCH v2 0/4] Fix/Improve sync clock mode handling Date: Thu, 18 Feb 2021 12:40:35 +0100 Message-ID: <20210218114039.216091-1-nuno.sa@analog.com> X-Mailer: git-send-email 2.30.1 MIME-Version: 1.0 X-ADIRuleOP-NewSCL: Rule Triggered X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761 definitions=2021-02-18_04:2021-02-18,2021-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 spamscore=0 bulkscore=0 mlxscore=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1011 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102180103 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org The first patch in this series is just a simple helper to lock/unlock the device. Having these helpers make the code slightly neater (IMHO). The following patches introduces changes in the sampling frequency calculation when sync scale/pps modes are used. First, it's important to understand the purpose of this mode and how it should be used. Let's say our part has an internal rate of 4250 (e.g adis1649x family) and the user wants an output rate of 200SPS. Obviously, we can't use this sampling rate and divide back down to get 200 SPS with decimation on. Hence, we can use this mode to give an input clock of 1HZ, scale it to something like 4200 or 4000 SPS and then use the decimation filter to get the exact desired 200SPS. There are also some limits that should be taken into account when scaling: * For the devices in the adis16475 driver: - Input sync frequency range is 1 to 128 Hz - Native sample rate: 2 kSPS. Optimal range: 1900-2100 sps * For the adis1649x family (adis16480 driver): - Input sync frequency range is 1 to 128 Hz - Native sample rate: 4.25 kSPS. Optimal range: 4000-4250 sps I'm not 100% convinced on how to handle the optimal minimum. For now, I'm just throwing a warning saying we might get into trouble if we get a value lower than that. I was also tempted to just return -EINVAL or clamp the value. However, I know that there are ADI customers that (for some reason) are using a sampling rate lower than the minimum advised. That said, the patch for the adis16480 driver is a fix as this mode was being wrongly handled. There should not be a "separation" between using the sync_scale and the dec_rate registers. The way things were being done, we could easily get into a situation where the part could be running with an internal rate way lower than the optimal minimum. For the adis16475 drivers, things were not really wrong. They were just not optimal as we were forcing users to specify the IMU scaled internal rate once in the devicetree. Calculating things at runtime gives much more flexibility to choose the output rate. Changes in v2: * Moved the lock helper patch to the end of the series. * Changed all the users of the lock to use the helper functions. * Added a module parameter to allow users to run the IMUs at lower rates than the advisable. Nuno Sa (3): iio: adis16480: fix pps mode sampling frequency math iio: adis16475: improve sync scale mode handling iio: adis: add helpers for locking Nuno Sá (1): dt-bindings: adis16475: remove property .../bindings/iio/imu/adi,adis16475.yaml | 9 -- drivers/iio/imu/adis16400.c | 22 ++- drivers/iio/imu/adis16475.c | 118 ++++++++++++---- drivers/iio/imu/adis16480.c | 133 +++++++++++++----- include/linux/iio/imu/adis.h | 10 ++ 5 files changed, 206 insertions(+), 86 deletions(-)