Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1187969ybd; Wed, 26 Jun 2019 12:51:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwNnbLDbTs1P+stC5G2XoHeb7uQIsEH7n9eYIS4HxwoRkTW/IuFQGT8ZYq0HnTbrIeo/7di X-Received: by 2002:a17:902:d897:: with SMTP id b23mr7190983plz.250.1561578682485; Wed, 26 Jun 2019 12:51:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561578682; cv=none; d=google.com; s=arc-20160816; b=z8X9kMzHxZUHS0kFJ/RHiuPXkmz60JHA7jWuzxthk0MQiG+knmtHrp5IA2Viw1Q19d 3gXMuyGB8CID2bboaG4o87D1eJL7JLTh5m6Y3n1KKqvXeXIJuXvclIxa9744r/26TUVv luGsd4u8tKfpxlABYkAEQs9Fb7oUrBjmGIwLRszfEelcslRkEuJOWTNWzVE7QcLEMSxX cCw/SXETcvB9I3fGm3Eg+EyrhTAGC54+dExZXm7pLEZODdLtiIV9ntEWSCeuUjWqt/to LrGUJucWEEyJHEjB/iK9DMPcf8Hru2eNluR3KOxcys9YLRL22EXrAl6sUCpuxGse3QJM F4UQ== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=XMbGTkrCC6Ndu2zQWvlchSs6Q0RqPIxze8tmxFHYQyM=; b=zFgO1rOZOfhd9ODZgwpxp4lhQIxDz/2BtkP2LPeQTjapi7jI0RsuWpjgH6ICU7AM06 t6lv+W5Px+i0tb6Z7TgJNpbGrvWGo3l2rKYWWfJBC0ZiPG06AG7hQwmocaadYAblK+9N Ufq/Gk7Q/Czv+1ueBsKkGfDIXkXS1VsUxBKc6TDzmaphYuc/qnF+SSdOdx8RZj7vyOad C3E4mmct7l38Z/5wBuVnhZkWMuwkxLZ6NmDvg24UZ7Vk/+f+TqQ0OTu8TYTmM3tDiI21 0ku19Z/wx/uCWJnn2Gg0QhPORlTpYjVNIUhtIl5WNV32G/lEWAXjnfcqCq4rWG9hD5yj Q35w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=uVAhQXWG; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x20si57179pll.105.2019.06.26.12.51.05; Wed, 26 Jun 2019 12:51:22 -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; dkim=pass header.i=@kernel.org header.s=default header.b=uVAhQXWG; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726503AbfFZTtn (ORCPT + 99 others); Wed, 26 Jun 2019 15:49:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:33460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726354AbfFZTtm (ORCPT ); Wed, 26 Jun 2019 15:49:42 -0400 Received: from archlinux (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2CBA82085A; Wed, 26 Jun 2019 19:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561578581; bh=i+GHS8wjDU9C3Y0t/ankpvFhnWYCQBIvo0sWjX8gRRM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uVAhQXWGGKt0YXHGepbq/fbxly9qpjStcXu2kwm+aOfN82ru470ia9zXKDL/bzIHk s3XMQ/Cbn43EgEcn95dHMjJNB0j1DoEcmJLvDsXJvPu4Nj097rq6zc4Cos6lLTPtOd PUZGOZdFyyDuI9zawiyjfDgZsMI2MfX/J5Ffm5ls= Date: Wed, 26 Jun 2019 20:49:36 +0100 From: Jonathan Cameron To: =?UTF-8?B?WmJ5bsSbaw==?= Kocur Cc: Andreas Klinger , linux-iio@vger.kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iio: srf04: fix wrong limitation in distance measuring Message-ID: <20190626204936.2756cefd@archlinux> In-Reply-To: <03D5EE82-D6C7-4A03-9404-45B48F1EF5B6@fel.cvut.cz> References: <20190623122909.hhzskp6k5vm4wify@arbad> <20190626192134.4b7aed3c@archlinux> <03D5EE82-D6C7-4A03-9404-45B48F1EF5B6@fel.cvut.cz> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 Jun 2019 20:59:08 +0200 Zbyn=C4=9Bk Kocur wrote: > Hello, Andreas, >=20 > Your patch seems to solve my question. I haven't had time to test it beca= use of holidays. I'll test it as soon as possible. No rush, it's a clear fix anyway so we can queue this up in the rc phase of the next kernel cycle! Thanks, Jonathan >=20 > Zbyn=C4=9Bk > --- > email: zbynek.kocur@fel.cvut.cz > phone: +420 224 354 054 > web: http://www.fel.cvut.cz > Department of Telecommunications Engineering > Faculty of Electrical Engineering >=20 > > On 26 Jun 2019, at 20:21, Jonathan Cameron wrote: > >=20 > > On Sun, 23 Jun 2019 14:29:10 +0200 > > Andreas Klinger wrote: > > =20 > >> The measured time value in the driver is limited to the maximum distan= ce > >> which can be read by the sensor. This limitation was wrong and is fixed > >> by this patch. > >>=20 > >> It also takes into account that we are supporting a variety of sensors > >> today and that the recently added sensors have a higher maximum > >> distance range. > >>=20 > >> Suggested-by: Zbyn=C4=9Bk Kocur > >> Signed-off-by: Andreas Klinger =20 > > Ideally I'm looking for Zbyn=C4=9Bk to confirm that this addresses the > > original question. > >=20 > > Thanks, > >=20 > > Jonathan > > =20 > >> --- > >> drivers/iio/proximity/srf04.c | 29 +++++++++++++++-------------- > >> 1 file changed, 15 insertions(+), 14 deletions(-) > >>=20 > >> diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf= 04.c > >> index 8b50d56b0a03..01eb8cc63076 100644 > >> --- a/drivers/iio/proximity/srf04.c > >> +++ b/drivers/iio/proximity/srf04.c > >> @@ -110,7 +110,7 @@ static int srf04_read(struct srf04_data *data) > >> udelay(data->cfg->trigger_pulse_us); > >> gpiod_set_value(data->gpiod_trig, 0); > >>=20 > >> - /* it cannot take more than 20 ms */ > >> + /* it should not take more than 20 ms until echo is rising */ > >> ret =3D wait_for_completion_killable_timeout(&data->rising, HZ/50); > >> if (ret < 0) { > >> mutex_unlock(&data->lock); > >> @@ -120,7 +120,8 @@ static int srf04_read(struct srf04_data *data) > >> return -ETIMEDOUT; > >> } > >>=20 > >> - ret =3D wait_for_completion_killable_timeout(&data->falling, HZ/50); > >> + /* it cannot take more than 50 ms until echo is falling */ > >> + ret =3D wait_for_completion_killable_timeout(&data->falling, HZ/20); > >> if (ret < 0) { > >> mutex_unlock(&data->lock); > >> return ret; > >> @@ -135,19 +136,19 @@ static int srf04_read(struct srf04_data *data) > >>=20 > >> dt_ns =3D ktime_to_ns(ktime_dt); > >> /* > >> - * measuring more than 3 meters is beyond the capabilities of > >> - * the sensor > >> + * measuring more than 6,45 meters is beyond the capabilities of > >> + * the supported sensors > >> * =3D=3D> filter out invalid results for not measuring echos of > >> * another us sensor > >> * > >> * formula: > >> - * distance 3 m > >> - * time =3D ---------- =3D --------- =3D 9404389 ns > >> - * speed 319 m/s > >> + * distance 6,45 * 2 m > >> + * time =3D ---------- =3D ------------ =3D 40438871 ns > >> + * speed 319 m/s > >> * > >> * using a minimum speed at -20 =C2=B0C of 319 m/s > >> */ > >> - if (dt_ns > 9404389) > >> + if (dt_ns > 40438871) > >> return -EIO; > >>=20 > >> time_ns =3D dt_ns; > >> @@ -159,20 +160,20 @@ static int srf04_read(struct srf04_data *data) > >> * with Temp in =C2=B0C > >> * and speed in m/s > >> * > >> - * use 343 m/s as ultrasonic speed at 20 =C2=B0C here in absence of = the > >> + * use 343,5 m/s as ultrasonic speed at 20 =C2=B0C here in absence o= f the > >> * temperature > >> * > >> * therefore: > >> - * time 343 > >> - * distance =3D ------ * ----- > >> - * 10^6 2 > >> + * time 343,5 time * 106 > >> + * distance =3D ------ * ------- =3D ------------ > >> + * 10^6 2 617176 > >> * with time in ns > >> * and distance in mm (one way) > >> * > >> - * because we limit to 3 meters the multiplication with 343 just > >> + * because we limit to 6,45 meters the multiplication with 106 just > >> * fits into 32 bit > >> */ > >> - distance_mm =3D time_ns * 343 / 2000000; > >> + distance_mm =3D time_ns * 106 / 617176; > >>=20 > >> return distance_mm; > >> } =20 > > =20 >=20