From owner-freebsd-drivers@FreeBSD.ORG  Mon Oct  6 17:15:28 2014
Return-Path: <owner-freebsd-drivers@FreeBSD.ORG>
Delivered-To: freebsd-drivers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 621588C7;
 Mon,  6 Oct 2014 17:15:28 +0000 (UTC)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id CA06DBAB;
 Mon,  6 Oct 2014 17:15:27 +0000 (UTC)
Received: from tom.home (kostik@localhost [127.0.0.1])
 by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s96HFM9w024016
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Mon, 6 Oct 2014 20:15:22 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s96HFM9w024016
Received: (from kostik@localhost)
 by tom.home (8.14.9/8.14.9/Submit) id s96HFMwt024015;
 Mon, 6 Oct 2014 20:15:22 +0300 (EEST)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Mon, 6 Oct 2014 20:15:22 +0300
From: Konstantin Belousov <kostikbel@gmail.com>
To: Martin Galvan <omgalvan.86@gmail.com>
Subject: Re: A few questions about SD/MMC drivers
Message-ID: <20141006171521.GD26076@kib.kiev.ua>
References: <CAN19L9ENsuAR6_aXwJSRdfDz6UgE6kU+rCkGGsdK7tRcUes+0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN19L9ENsuAR6_aXwJSRdfDz6UgE6kU+rCkGGsdK7tRcUes+0w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.0
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home
Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org
X-BeenThere: freebsd-drivers@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Writing device drivers for FreeBSD <freebsd-drivers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-drivers>, 
 <mailto:freebsd-drivers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-drivers/>
List-Post: <mailto:freebsd-drivers@freebsd.org>
List-Help: <mailto:freebsd-drivers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-drivers>,
 <mailto:freebsd-drivers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2014 17:15:28 -0000

On Sun, Oct 05, 2014 at 07:05:16PM -0300, Martin Galvan wrote:
> 3) Finally, I noticed in the Linux driver they sometimes wrap a
> register read operation around a do-while loop waiting on both the
> result of that read and a timer, like this:
> 
> do {
>     read_value = read_a_register(some_register);
> } while ((read_value != desired_value) && (time_before(jiffies, expire));
> 
> where "expire" is an unsigned long whose value is computed as the sum
> of a global called "jiffies" and the result of a call to
> msecs_to_jiffies(). This is done so after the loop they can check
> whether the register holds the desired value or a timeout occurred. Do
> we have something similar on BSD? If not, what would be a safer way to
> implement a timeout mechanism than simply decreasing a counter?

Look at the _intel_wait_for() in the sys/dev/drm2/i915/intel_drv.h.
There is improved version of the macro in the i915 update I posted
several days ago.