From patchwork Mon Jun 25 15:18:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Klinger X-Patchwork-Id: 10486691 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1781E60230 for ; Mon, 25 Jun 2018 15:19:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E4AD2818A for ; Mon, 25 Jun 2018 15:19:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0326028514; Mon, 25 Jun 2018 15:19:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6D87C2818A for ; Mon, 25 Jun 2018 15:19:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934701AbeFYPTO (ORCPT ); Mon, 25 Jun 2018 11:19:14 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:48989 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934725AbeFYPTM (ORCPT ); Mon, 25 Jun 2018 11:19:12 -0400 Received: from localhost ([83.135.237.7]) by mrelayeu.kundenserver.de (mreue104 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MFKXk-1fLQ3D3Nf2-00EKUv; Mon, 25 Jun 2018 17:18:28 +0200 Date: Mon, 25 Jun 2018 17:18:24 +0200 From: Andreas Klinger To: jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, robh+dt@kernel.org, mark.rutland@arm.com, mchehab@kernel.org, davem@davemloft.net, gregkh@linuxfoundation.org, akpm@linux-foundation.org, linus.walleij@linaro.org, rdunlap@infradead.org, devicetree@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 2/4] iio: hx711: add delay until DOUT is ready Message-ID: <20180625151824.GA6380@arbeit> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K1:PBwqrmFS+/jSJl7YqKzej7uxocDP4s2zDk3pziOtqs6Z2MrGbWi BsYAVKC45FwhW83Emzjipb0q/FuMnwWR7gbC1PZsCfMvLNJeGE7wqthC905nxKkoo35dkAM LgdNP4Xry2DdRH8mA0OJapKZ08TL3in3B5O5D006InNrgq7dbx9kTlacBZHK8WB+n1ZmQ0U vwfOh/+M755P9Z8UgstKA== X-UI-Out-Filterresults: notjunk:1; V01:K0:UasnbnSetNU=:vFNnkh9nRxPRARIN+Qpi+Q Uzg+8qOfEiVtE1LaTOYYPWxA1gAA7XdnA6biaxsg4b8kkAn5BFvqfuc2oiP/qK9HD3k/AhZIY PmHCrT7OIZ8rRepMY0G5CMar3BlTTqCLn5S2WmUHkPmJv7EmUvN86flBd2mrhLj6/H3qKDD29 CAv3o8KGxMQGRF+gmJyLyQGiPOpErSWU+8T7p87BKgurbCMRQqv9WJo+W9zbEEgDB/rDptiHT qJ3edt3dSNmGbnSNa/+3V9R50O4W+jA5yC6q08hGqgj1n4XiL12Ky5xU49bB63OY7Lo69uQZA NuDEiVawq48L+FHw91tyvtg3FOXbz3Y/b0zR9FVeBfU6Uq3Z5MgttYUDX6fvA/r/WowDk9j6t AZJtxetQ6NF9gVW4Lf4peKs+0EHKmL78sLZLMiiOLzIb9ZEy4n2wxPhwbdCazWryDAIs7rSVZ ehktZixuxdAwGUAVwir8YjB5IpIEPE2Vz5Y+YJXNlscpbEu4Xi6wQqlnKJVzGF1x+ghRAZGy+ rMgivzBPaS98PYktuYQgfJL9k2h4Nu1MccEEl8L1g4UFz5QGX5RXtv7ZhGRMkjTbWc8xB6Br1 tAvP72KsNZAXB8DAUmHgabRGEoyNekhOY+LtSM/jMpA6RN0uArtJhdz76dkUm7A7AgUQFTgR8 fwhZfMz1efjKsAkHTnMVDb+V5xoTxcWHEvI58kij5OipcqQK91d0GXBAL94zvXm3S9TE= Sender: linux-iio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On a system with parasitic capacities it turned out that DOUT is not ready after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns until DOUT has reached its correct value. With this patch its now possible to wait until data is ready. The wait time should not be higher than the maximum PD_SCK high time which is corresponding to the datasheet 50000 ns. Signed-off-by: Andreas Klinger --- drivers/iio/adc/hx711.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c index 9430b54121e0..41e26ef324ee 100644 --- a/drivers/iio/adc/hx711.c +++ b/drivers/iio/adc/hx711.c @@ -97,6 +97,13 @@ struct hx711_data { * 2x32-bit channel + 64-bit timestamp */ u32 buffer[4]; + /* + * delay after a rising edge on SCK until the data is ready DOUT + * this is dependent on the hx711 where the datasheet tells a + * maximum value of 100 ns + * but also on potential parasitic capacities on the wiring + */ + u32 data_ready_delay_ns; }; static int hx711_cycle(struct hx711_data *hx711_data) @@ -110,6 +117,14 @@ static int hx711_cycle(struct hx711_data *hx711_data) */ preempt_disable(); gpiod_set_value(hx711_data->gpiod_pd_sck, 1); + + /* + * wait until DOUT is ready + * it turned out that parasitic capacities are extending the time + * until DOUT has reached it's value + */ + ndelay(hx711_data->data_ready_delay_ns); + val = gpiod_get_value(hx711_data->gpiod_dout); /* * here we are not waiting for 0.2 us as suggested by the datasheet, @@ -458,6 +473,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = { static int hx711_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; + struct device_node *np = dev->of_node; struct hx711_data *hx711_data; struct iio_dev *indio_dev; int ret; @@ -530,6 +546,13 @@ static int hx711_probe(struct platform_device *pdev) hx711_data->gain_set = 128; hx711_data->gain_chan_a = 128; + ret = of_property_read_u32(np, "data-ready-delay-ns", + &hx711_data->data_ready_delay_ns); + if (ret < 0) { + dev_warn(dev, "data-ready-delay-ns not set - assuming 0 ns\n"); + hx711_data->data_ready_delay_ns = 0; + } + platform_set_drvdata(pdev, indio_dev); indio_dev->name = "hx711";