How to get a device_t

[Bernd Walter]

On Fri, Aug 08, 2003 at 06:03:38PM +1000, John Birrell wrote:
> 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-(

I asume you need a call to bus_generic_attach after adding a bus child.

But this thematic is still full of questions for me.
Under 5.1-RELEASE the following in init_AMD_Elan_sc520():
        devclass_t nexusdc = devclass_find("nexus"); 
	device_t nexus = devclass_get_device(nexusdc, 0);
	device_t dev = device_add_child(nexus, "elanbb", -1);
	bus_generic_attach(dev);

results in:
[...]
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.00
Timecounter "ELAN"  frequency 8333333 Hz
pcib0: <AMD Elan SC520 host to PCI bridge> at pcibus 0 on motherboard
pci0: <PCI bus> on pcib0
elanbb1 at device 0.0 on pci0
hifn0 mem 0xa0001000-0xa0001fff,0xa0000000-0xa0000fff irq 10 at device 16.0 on pci0
hifn0: Hifn 7951, rev 0, 128KB sram, 193 sessions
[...]

# devinfo
nexus0
  legacy0
    pcib0
      pci0
        elanbb1
        hifn0
        ohci0
          usb0
            uhub0
        ohci1
          usb1
            uhub1
        sis0
          miibus0
            ukphy0
        sis1
          miibus1
            ukphy1
        sis2
          miibus2
            ukphy2
    isa0
      ata0
      sio0
  npx0

If someone has an explanation to this.
The full change is available under
http://www.cosmo-project.de/~bernd/elanbb.diff

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

What resources does your elanmmcr device manage?
There is a lots of different stuff to manage: timers, pio pins, ...
Just managing exclusive mmcr adresses will not be enough because
different pio pins share registers.
On the other hand it's questionable if those resources should be
managed anyway.

> 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-)

Nexus can't know about mmcr resource types.
If you manage addresses then you'll need to allow sharing too.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de