How to get a device_t

John Birrell jb at cimlogic.com.au
Fri Aug 8 01:02:16 PDT 2003


On Fri, Aug 08, 2003 at 09:44:08AM +0200, Poul-Henning Kamp wrote:
> In message <20030808083617.E7321 at freebsd1.cimlogic.com.au>, John Birrell writes
> :
> 
> >I'm not convinced that any hacking is required other than passing the
> >device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says.
> >I traced the boot on my system and the MMCR is initialised early (when
> >the Timecounter "ELAN" output occurs). Immediately following that
> >initialisation, 'pcib' is added as a child of 'nexus'. I don't see why
> >'mmcr' couldn't be added as a child of 'nexus' too. At this point,
> >nexus isn't walking through it's children so there shouldn't be a problem.
> >Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'.
> >
> >This seems straight forward. Maybe I'm missing something. 8-)
> 
> That's my take too.  And MMCR belongs on nexus not on legacy from an
> architectural point of view.

It turns out that my comment about device_t parent being passed into 
nexus_pcib_is_host_bridge (in STABLE) was a bit off target.

I found that if I created a device elanmmcr that would attach to nexus and
implement a bus, the code in nexus_pcib_is_host_bridge that detects the
host to PCI bridge only needs to warn if there is no elanmmcr device in
the kernel. It doesn't need to initialise the Timecounter since it can
rely on the elanmmcr doing that.

The elanmmcr device can grok the PCI config to see the host to PCI
bridge itself in it's identify method.

Then the GPIO and flash devices can attach to elanmmcr. This all works
fine in my experiment, up to the point where the child devices try
to access their resources. Then it all ends in tears.

I find (using STABLE as a base) that the elanmmcr device needs it's own
add_child method because the nexus one doesn't get called. I guess that's
because add_child methods aren't inherited? I've never implemented a
bus driver before. 8-(

Having decided that an add_child method is required in the elanmmcr device,
all the resource allocation and activation functions break. Grumble.

What I'm not sure of, is how many of the nexus methods (such as those
for resource allocation) can be shared, and how many need to be implemented.
Can anyone suggest a driver that is a suitable example? It's a bit like
the three bears.... this one is too soft... and this one is too hard....
but where is the one that is just right? 8-)

-- 
John Birrell


More information about the freebsd-hackers mailing list