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