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 <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED] [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
