Two drivers sharing a single PCI device

[O'Connor, Daniel]

> On 7 Feb 2015, at 16:37, Hans Petter Selasky <hps at selasky.org> wrote:
>>> You possibly want "D_TRACKCLOSE" in d_flags in your cdevsw.
>> 
>>> What's the advantage of using the debug port over the regular EHCI USB interface?
>> 
>> I don't think that would help. It is supposed to be (largely) separate from the regular EHCI controller - it has it's own register set and it can steal the debug port from the regular controller so it doesn't appear occupied (although there is a bit of messing around on port reset).
>> 
>> The advantage is that it runs separately to the EHCI interface and it is quite simple to talk to, there is more information in appendix C of the USB 2 spec (usb_20.pdf).
>> 
> 
> Hi,
> 
> You know about "sys/boot/usb" ? If you could integrate the USB debug port to use the kernel USB stack HOST API, only limited to BULK, CONTROL and INTERRUPT, then we could easily use it there aswell. The EHCI debug port functions very much resemble those found in "sys/dev/usb/controller/dwc_otg*" for example.

Hmm I am not really sure what it's for.. Is it for the loader?

Basically I would like to be able to run a console and GDB port over USB, although I think it won't be quite as good as a 'real' serial one because it will have to start later (when the PCI bus is up).

FWIW I did get my driver and EHCI to attach at the same time - I iterated over pci_devq and allocated my own softc in MOD_LOAD. The next part is trying to get the EHCI controller from stealing back the debug port - it gets lost on reset I think so I need to work out how to tell it not to touch it (if possible).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C