From mboxrd@z Thu Jan  1 00:00:00 1970
From: Graeme Russ <graeme.russ@gmail.com>
Date: Sun, 17 Jul 2011 11:51:56 +1000
Subject: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
In-Reply-To: <4E1C23B8.6020101@gmail.com>
References: <1309261269-4363-1-git-send-email-graeme.russ@gmail.com>
	<20110711215637.6BC6A1579E14@gemini.denx.de>
	<4E1B7E0C.8000900@gmail.com> <4E1B88EE.9040104@gmail.com>
	<4E1BAED7.3070009@gmail.com>
	<20110712084954.C928C16F7669@gemini.denx.de>
	<4E1C23B8.6020101@gmail.com>
Message-ID: <4E22403C.2040802@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Wolfgang.

On 12/07/11 20:36, Graeme Russ wrote:

> As I said, I will have a closer look at the Linux API...

OK, I've had a look at how the Linux API is used - in particular
time_after(). Here is a typical random example (from drivers/spi/ep93xx_spi.c):

	timeout = jiffies + msecs_to_jiffies(SPI_TIMEOUT);
	while (ep93xx_spi_read_u16(espi, SSPSR) & SSPSR_RNE) {
		if (time_after(jiffies, timeout)) {
			dev_warn(&espi->pdev->dev,
				 "timeout while flushing RX FIFO\n");
			msg->status = -ETIMEDOUT;
			return;
		}
		ep93xx_spi_read_u16(espi, SSPDR);
	}

Now I personally do not like the global 'jiffies' variable for two reasons:

a) It assumes there is some interrupt source updating jiffies which we
cannot guarantee. The discussions of the new API had the background counter
being update by both a background interrupt (if available) or a call to
get_timer()
b) It has no fixed time base

So it looks like the nanosecond clocksource code and the time_after et al
macros are not directly related (as evidenced by time_after being in jiffies.h)

So maybe we should look at something along the lines of:

	timeout = get_ms_count() + SPI_TIMEOUT;
	while (ep93xx_spi_read_u16(espi, SSPSR) & SSPSR_RNE) {
		if (time_after(get_ms_count(), timeout)) {
			dev_warn(&espi->pdev->dev,
				 "timeout while flushing RX FIFO\n");
			msg->status = -ETIMEDOUT;
			return;
		}
		ep93xx_spi_read_u16(espi, SSPDR);
	}

The get_ms_count() name is up for debate

So this would mean minimal timer related code conversion bringing drivers
from Linux, and a namespace which does not match Linux that will hence
generate obvious compile errors.

If you really wanted to we could

#define jiffies			get_ms_count()
#define msecs_to_jiffies(x)	x

But I think that might be dangerous

Now we can use the existing get_timer(0) call (as I already did with this
patch series) now and create the underlying architecture intrusive re-write
of the generic 'clocksource' API later.

And then phase 3 would be to revisit udelay

Regards,

Graeme