On Thu, Aug 28, 2014 at 10:03:55PM +0200, Clemens Ladisch wrote: > Takashi Iwai wrote: > > did anyone test the patch at all...? > > Appears to work. The ymfpci gameport seems to be somewhat unreliable: > > analog.c: 100 out of 17347 reads (0%) on pci0000:06:06.1/gameport0 failed > analog.c: 122 out of 1111 reads (10%) on pci0000:06:07.0/gameport0 failed
The analog.c gameport read routine is unreliable by design. The 558 chip is not an ADC, it's an one-shot timer from 1971. The analog position of the joystick is measured by timing bit changes on the gameport. analog.c does that without disabling interrupts, as the read can take several milliseconds. analog.c instead detects when an interrupt influenced the measurement too much and retries. The retries are counted and reported. 10% is a largeish number, but still something the analog.c driver can cope with and give reliable results. > There is still some dependence of the CPU speed on the loop counts > calculated by gameport_time(), but it's not very high; the following are > for 3200 and 800 MHz, 5 times each: > > gameport gameport7: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport8: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport9: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport10: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport11: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 651kHz > gameport gameport12: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport13: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport14: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 612kHz > gameport gameport15: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 611kHz > gameport gameport16: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed > 612kHz The gameport speed is speed of the i/o to the port. It may change as frequencies in the system change. It's used for timeouts on digital gameport protocols only and thus a variation of less than 20% shouldn't cause trouble. The analog.c driver uses its own timing calibration to make the analog_cooked_read() reliable even when the speed of the i/o operations changes. What is important is that the GET_TIME() macro is fast (0.1 usec or less), precise (sub-microsecond resolution) and reliable. Digital protocols also rely on udelay() and mdelay() waiting precisely for the amount of time specified. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
