Re: [RFC] i2c-omap: Don't wait needlessly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



ext Tony Lindgren wrote:
* Sakari Ailus <sakari.ailus@xxxxxxxxx> [081027 09:22]:
Jarkko Nikula wrote:
I would rather, if there is no need for such a long delay like
OMAP_I2C_TIMEOUT, remove that time_after and msleep(1) stuff and
just loop few iterations with udelay(1). Zero thinked & tested diff
attached.
I just though of allowing the reset to take longer as I have no idea how long it could take, let alone other versions of OMAP.

I would say that ndelay(1) just doesn't look relevant to < 1 GHz
cpus :-)
Good point. On ARM ndelay(1) seems to be equal to udelay(1) at the moment.

I actually just removed the ndelay(1) and again, "delay" won't get past 1 if I print it after the loop.

It'd be nice to know how it works on other OMAP versions before making such changes. :-)

Let me know if you come up with a refreshed patch for this, ignoring
for now.

I think the need for this patch has largely gone away as i2c-omap appears not to do msleep() anymore for every second transfer or so.

--
Sakari Ailus
sakari.ailus@xxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux