Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2887978ybb; Mon, 30 Mar 2020 15:18:16 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuEE2lWSW/qNwxsJgvymdVhY0iRcutLM+iPoffijfH1fAw7MmkwbuNe95HkqxXBuaTmDhUF X-Received: by 2002:a05:6830:8d:: with SMTP id a13mr10971207oto.321.1585606695968; Mon, 30 Mar 2020 15:18:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585606695; cv=none; d=google.com; s=arc-20160816; b=yHbAecb8rYXT87PltJydJdf+6MkJcYBbmcdrQnOfoi09Tk9ZbRqxvkkoZk/Ufkf6MY N+Bif81rWvJH/McSDxl0/RVgpxb+QZ73+4CnrpBkgZt36flWaV0aNt789hJzbWcwCr0n 8sE1e0TSZ6GxyWxcY4+zGLeMVZt9l+GyFuHArZoVI0wtDEyuaMHK3hc9wTCG6FhAh2nr fwZ/zonxYXCCjqX+Ax78vIgkr6CtbvrHOAOtjf+d2FMG2cjnIf3gtft50hhJJIp+0mds yA0vv9aN5x8Jvejwb8ieiptcnJimaAZueJTWmkbyKHGWmOmae021iMskI0yYMeeyp58H rV9Q== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature; bh=kFxQ6sa3As6Jtugci2z3HRdxNU4LPCC1zzYUuabLxUU=; b=qdgQ/Gv3xaXyjwyyFWKi9YIRPx8wZNUOtviQrq0Mpn3xiugAzzOlMI+4DLZ/smeTUQ EXwP/2SeKQRowKm/rxZy6Y0TD8S0RxPbjD08/0j+uTUeLX7tgCNXRXfVCcJhah9oC7E0 wgf6pM1p0BXOTLqq8bRVkm7AjFTOfHQi9nLrTX8eL5ZiWr9pyTWzdDHMzeybOqTNIpYE XTcfPFEop9edU3mfKscAUtzbQ8RlMLetHVaVxf/grRdwpFjN6MeeMAMKkuWWoseOCiMq yXYpwAeFGA5BqdsjiEGZLrB5761JV7de4/4DggGu1pVxdYn3e1rrS8Su8yzmVi+rn9WB KxlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SwpXIY2K; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si6874143otj.223.2020.03.30.15.18.02; Mon, 30 Mar 2020 15:18:15 -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=@redhat.com header.s=mimecast20190719 header.b=SwpXIY2K; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729430AbgC3WQ6 (ORCPT + 99 others); Mon, 30 Mar 2020 18:16:58 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:40360 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728857AbgC3WQ6 (ORCPT ); Mon, 30 Mar 2020 18:16:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585606617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kFxQ6sa3As6Jtugci2z3HRdxNU4LPCC1zzYUuabLxUU=; b=SwpXIY2KsCtxK80s4Xiouq9O6YVlCYPI2SU1UyAhe+frHyJfECOq9NZcIK8GonWmh9CMG5 VTKeKuNJwiTgAjtljg1NT1ahx8xESp56FBdawcDqAonrWBE3/XG6MRFsbfL9NdsrFEfmCm nNTuGrB8HPFIfwa7I4ZYiKO2iO49IsI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-445-L_lh2rRnM8uuiqNlMRll3Q-1; Mon, 30 Mar 2020 18:16:51 -0400 X-MC-Unique: L_lh2rRnM8uuiqNlMRll3Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AEB1A18A5500; Mon, 30 Mar 2020 22:16:49 +0000 (UTC) Received: from elisabeth (unknown [10.36.110.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 180CF5C1BB; Mon, 30 Mar 2020 22:16:43 +0000 (UTC) Date: Tue, 31 Mar 2020 00:16:37 +0200 From: Stefano Brivio To: "John B. Wyatt IV" Cc: Julia Lawall , Soumyajit Deb , outreachy-kernel@googlegroups.com, Greg Kroah-Hartman , Payal Kshirsagar , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [Outreachy kernel] [PATCH] staging: fbtft: Replace udelay with preferred usleep_range Message-ID: <20200331001637.6bf108ed@elisabeth> In-Reply-To: <53befe00af657428b591200b31b5349a4a462eb1.camel@gmail.com> References: <20200329092204.770405-1-jbwyatt4@gmail.com> <2fccf96c3754e6319797a10856e438e023f734a7.camel@gmail.com> <20200330194043.56c79bb8@elisabeth> <53befe00af657428b591200b31b5349a4a462eb1.camel@gmail.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Mar 2020 15:03:55 -0700 "John B. Wyatt IV" wrote: > On Mon, 2020-03-30 at 19:40 +0200, Stefano Brivio wrote: > > On Sun, 29 Mar 2020 12:37:18 +0200 (CEST) > > Julia Lawall wrote: > > =20 > > > On Sun, 29 Mar 2020, Soumyajit Deb wrote: > > > =20 > > > > I had the same doubt the other day about the replacement of > > > > udelay() with > > > > usleep_range(). The corresponding range for the single argument > > > > value of > > > > udelay() is quite confusing as I couldn't decide the range. But > > > > as much as I > > > > noticed checkpatch.pl gives warning for replacing udelay() with > > > > usleep_range() by checking the argument value of udelay(). In the > > > > documentation, it is written udelay() should be used for a sleep > > > > time of at > > > > most 10 microseconds but between 10 microseconds and 20 > > > > milliseconds, > > > > usleep_range() should be used.=20 > > > > I think the range is code specific and will depend on what range > > > > is > > > > acceptable and doesn't break the code. > > > > Please correct me if I am wrong. =20 > > >=20 > > > The range depends on the associated hardware. =20 > >=20 > > John, by the way, here you could have checked the datasheet of this > > LCD > > controller. It's a pair of those: > > https://www.sparkfun.com/datasheets/LCD/ks0108b.pdf >=20 > No I have not. This datasheet is a little over my head honestly. >=20 > What would you recommend to get familiar with datasheets like this? Well, you don't necessarily have to, there are many subsystems in the kernel which are almost completely abstracted away from hardware. If you're interested, look around yourself for something simple chip, or get something that you can easily plug on a "maker board", Raspberry Pi, something like that. Perhaps via I=C2=B2C or SPI. Some types of sensors (temperature, pressure) have very simple datasheets. If you are allergic to hardware, try: $ ls -Ssl drivers/iio/* pick the smallest sensor driver in the category that is the most likely to spark your interest, and go through it, checking it against the datasheet, at some point it will make sense. --=20 Stefano