Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Nov 2014 20:03:02 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Alexander Kabaev <kabaev@gmail.com>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, "O'Connor, Daniel" <darius@dons.net.au>
Subject:   Re: Newbus question
Message-ID:  <20141115180302.GL17068@kib.kiev.ua>
In-Reply-To: <20141115121730.3a5bac94@kan>
References:  <EE77EB4C-E317-4EAB-9319-18F0B292571F@dons.net.au> <20141115121730.3a5bac94@kan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 15, 2014 at 12:17:30PM -0500, Alexander Kabaev wrote:
> On Sat, 15 Nov 2014 17:32:39 +1030
> "O'Connor, Daniel" <darius@dons.net.au> wrote:
> 
> > Hi,
> > I am trying to write a driver for the EHCI debug port [1]. I found
> > some userland code which I got working (written by the person who did
> > the Linux version) and now I am trying to get it running in the
> > kernel. One problem I have is that it needs to run in parallel with
> > the normal EHCI controller. It uses the same BAR as the EHCI
> > controller but offset (the offset is found in a PCI capability). I
> > think I can bus_alloc_resource() if I change EHCI to allocate with
> > RF_SHAREABLE but my first problem is to add another device so my
> > driver doesn't contest with the EHCI driver.
> > 
> > Currently I have a module which loops over bus/slot/func using
> > find_bsf (is there a way to enumerate all connected PCI devices?) and
> > then check each for the debug capability (I plan on being a bit
> > pickier later but it works so far) then creating a child device. The
> > problem is that the probe routine <missing text>
> > 
> 
> Hi,
> 
> I do not think this can be done without cooperation of the ECHI device.
> You'd have to go the way of the full parent/child relationship between
> ehci parent and debug port child devices. Fortunately, this is not that
> hard to do and you can even define your own devmethod interfaces to make
> communication between debug port decoupled, so that debug port can be
> loaded and unloaded independently. The echi device already manages one
> child usbus device, adding another should not be too hard.

I think that debugging should be available much earlier than the device
tree is explored and devices are attached.  It probably makes sense to
operate the debugging port outside the newbus at all, in particular, before
the pci and acpi machinery is initialized.

You might want a callback from ehci driver when it appropriated the resources,
to handle the case of bar realocation.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141115180302.GL17068>