EHCI and Config flag

[rdos]

I think your searching skills are lacking:

Buggy video drivers: https://devtalk.nvidia.com/default/topi ... nd-laggy-/

This is the recommended skills of device driver developers (seems like they don't need to know anything about multitasking or spinlocks): http://www.freesoftwaremagazine.com/art ... vers_linux

With such recommendations, I cannot see a large base of stable Linux device drivers in the near future. About the only hope is if hardware manufacturers do them instead, and put down enough effort on it.

BTW, here is the PCI information for the USB devices:

Code: Select all

ACPI Name                     Vendor/dev Class  Bus  Dev Func  IRQ
\_SB_.PCI0.USB0               1002 4397  0C03     0   18    0   18
\_SB_.PCI0.USB2               1002 4397  0C03     0   22    0   18
\_SB_.PCI0.USB3               1002 4399  0C03     0   20    5   18
\_SB_.PCI0.USB4               1002 4396  0C03     0   18    2   17
\_SB_.PCI0.USB6               1002 4396  0C03     0   22    2   17

USB4 and USB6 is the EHCI controller.

[tom9876543]

I think your searching skills are lacking:

Buggy video drivers: https://devtalk.nvidia.com/default/topi ... nd-laggy-/

This is the recommended skills of device driver developers (seems like they don't need to know anything about multitasking or spinlocks): http://www.freesoftwaremagazine.com/art ... vers_linux

With such recommendations, I cannot see a large base of stable Linux device drivers in the near future. About the only hope is if hardware manufacturers do them instead, and put down enough effort on it.

Your first link relates to the Nvidia BINARY drivers. This makes your later comment "the only hope is if hardware manufacturers do them instead" look silly.

The second link is a beginner's tutorial on how Linux drivers work. You can easily find more detailed information about Linux: http://www.linuxjournal.com/article/5833

The fact is Linux and FreeBSD are correctly running today on your EHCI controller.
Your attitude is simply incompetent.

They set it, but due to really lousy coding (it's a parameter with unknown origin) it is more or less impossible to know what they set it to.

That statement by rdos would have to be one of the stupidest statements ever written on the osdev forum. This statement proves rdos is incompetent.
I looked at the Linux code and it is clear how it works. Summary below.

Code: Select all

static int ehci_run (struct usb_hcd *hcd):
 ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);

Doing a search:

Code: Select all

#define FLAG_CF         (1<<0)          /* true: we'll support "high speed" */

Rdos, if you looked at the Linux or FreeBSD code, you would know how the CONFIGFLAG works.
It is obvious your code has more critical problems than simply the CONFIGFLAG. This osdev question shows your incompetence.
Look more carefully at your code and good luck.