How to get a device_t

[Bernd Walter]

I need to add I2C support for a Elan520 based soekris system.
The system has the required GPIO pins and there is the iicbb driver
to handle generic bitbang code - just needing a simple layer driver to
enable, disable and read pins.
But unlike normal isa/pci hardware probing the existence of the GPIO
line is a bit difficult.
The current elan-mmcr.c gets started from i386/pci/pci_bus.c at
host bridge probing, because that's seems to be the only place to
safely detect this special CPU.
>From the logicaly standpoint the extensions had to be attached to
nexus, but nowhere is the current code path there is a handle for
nexus or any other device_t.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >I need to add I2C support for a Elan520 based soekris system.
> >The system has the required GPIO pins and there is the iicbb driver
> >to handle generic bitbang code - just needing a simple layer driver to
> >enable, disable and read pins.
> >But unlike normal isa/pci hardware probing the existence of the GPIO
> >line is a bit difficult.
> >The current elan-mmcr.c gets started from i386/pci/pci_bus.c at
> >host bridge probing, because that's seems to be the only place to
> >safely detect this special CPU.
> 
> That's my doing, based on my reading of the datasheet from AMD.
> 
> It would be better if we could detect the Elan in the normal CPU
> identification stuff, but I couldn't seem to find a reliable way.

I could reread the datasheet, but don't give it much hope if you
hadn't find anything usefull.

> >>From the logicaly standpoint the extensions had to be attached to
> >nexus, but nowhere is the current code path there is a handle for
> >nexus or any other device_t.
> 
> In fact what you may want to do is hang the entire MMCR off the nexus
> as a bus, and hang the various drivers off that bus.

What needs to be in *_probe() to conditionalize on elan existence?

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[John Birrell]

On Wed, Aug 06, 2003 at 05:50:45PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
> : In fact what you may want to do is hang the entire MMCR off the nexus
> : as a bus, and hang the various drivers off that bus.

I have a card based on the SC520 too. (Note to Warner: this is the card I
needed the higher port numbers for)

I need to access the GPIO pins too. But before that, I need to get flash
drivers working. Access to the flash chips also requires the MMCR. Does
it really make sense to hang the flash devices off the MMCR "bus" when they
are mapped into ISA bus space?

> That certainly makes sense.  nexus is for things that hang off of the
> CPU or things directly connected to the cpu...

>From my reading of the AMD docs, only the CPU core is identifiable via the CPUID
instruction. The docs say that the first two bytes of the MMCR are the
REVID and those can be used to "identify the device itself". The second
byte is set to zero to "identify the product as the ElanSC520 microcontroller".
So if you know the MMCR is there, you can go to that byte and get confirmation!
Thanks AMD. It seems that the discovery via the host to PCI bridge is the only
reliable way to go.

My local hack is to make my flash drivers require the elan_mmcr option and then
they can just go use the elan_mmcr global variable. I just need the elan device
to be initialised earlier.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Birrell]

On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote:
> Well, I don't know.  The PC Cards that we have in the system are
> mapped into the I/O and memory ranges traditionally reserved for the
> ISA bus.  In ISA systems, this made sense because pccard was attached
> to pcic was attached to isa.  However, now we have situations where
> pccard is attached to cbb which is attached to pci.  There may be a
> isab device with isa bus hanging off of it that makes the relationship
> between the pccard devices cousins rather than nephews in the tree.
> And there isn't any harm from that.  Wouldn't this be a similar
> situation?

The flash I'm talking about is not pccard related. Sorry if I gave that
impression. The SC520 has onboard support to control 3 flash chips.
The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS
file system (at the moment) where I keep a copy of an etherboot
executable. The board also has a 64Mb NAND flash chip which I've
written a FreeBSD UFS image into. Our standard bootloader happily
loads the kernel from that. Now I need to get a flash driver working
for the root file system. I've got an existing read-only flash driver
that I used to use on an Intel 386EX board, but that had the entire
flash chip memory mapped. This new board maps the NAND flash in 4K
pages.

> : >From my reading of the AMD docs, only the CPU core is identifiable
> : via the CPUID instruction. The docs say that the first two bytes of
> : the MMCR are the REVID and those can be used to "identify the device
> : itself". The second byte is set to zero to "identify the product as
> : the ElanSC520 microcontroller".  So if you know the MMCR is there,
> : you can go to that byte and get confirmation!  Thanks AMD. It seems
> : that the discovery via the host to PCI bridge is the only reliable
> : way to go.
> 
> Can you send me a URL for that document?  I thought I understood
> things, but making sure by reading it would sure help.

This URL lists the relevent docs:



The ones you want are the "ElanSC520 Users Manual" and "ElanSC520
Register Set Manual"

>From what I can see, all the SC520 specific things are accessed via
the MMCR registers. The direct mapped registers are only for PC/AT
compatible stuff, so they are of no help. Then there are the PCI
things. To be PCI compatible, AMD *had* to give the host bridge a
device ID. That is the _only_ thing given an ID.

> But adding it as a child of nexus in the host bridge code wouldn't
> make it probe any earlier.  To do that you'd need to make it a true
> child of nexus with a identify routine that would go out and try to
> find the host bridge at a certain address and use the right kind of
> bridge there to add the device.  You could then map the mmcr space to
> a convenient location, and then dole it out to child drivers such that
> the bus_space macros would do the right thing.  Since it is memory
> mapped, this would be relatively easy to do.  This would also allow
> you to make it known earlier in the boot process.  This is also very
> much analygous to what pccard and cardbus does.  You wouldn't have the
> problems that we have with picking resources in the cardbus bridge
> code because it looks like the mmcr is at a fixed address (either by
> design of the chip or by phk's big stick).
> 
> If you'd like, I can sketch out in code what I'm trying to say in
> words here.

If you have time, I'd be interested. This is a hot topic for me because
it is exactly where I'm up to. I have everything else working on the
board.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: In fact what you may want to do is hang the entire MMCR off the nexus
: as a bus, and hang the various drivers off that bus.

That certainly makes sense.  nexus is for things that hang off of the
CPU or things directly connected to the cpu...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Baldwin]

On 07-Aug-2003 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Bernd Walter <[EMAIL PROTECTED]> writes:
>: The host bridge is not available yet at probing time of the host bridge.
>: What we have is the host bridges parent (nexus) in the calling function.
>: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
>: we find it out later.
> 
> Don't you mean legacy_pcib_is_host_bridge?  That's where the matching
> is done in current right now (well, at least as of my last sync) If
> so, passing the host bridge's device down to it would be trivial to
> add.  It would also allow other CPUs with builtin host bridges to do
> similar tricks to the one that is done for the ELAN.  These sorts of
> features have been very common in other CPU families, and there's no
> reason to think that there won't be more of them in the x86 family as
> time goes on.
> 
> I'm not sure that adding it to nexus at this stage of the boot would
> truly work.  Since the legacy device has decided to attach, the nexus
> bus is already walking through its children.  Adding a child during
> that walk strikes me as dangerous, since we have no locking on the
> children element of the device_t.  Hmmm, looks I just found a source
> of problems in my newbus locking code that might explain some weird
> things happening when I enable it  Thanks for making me go look :-)

You would add it to legacy, not nexus.  What you probably really want
to do is to write a host-PCI bridge driver that attaches to the actual
PCI device like 'hostb' and 'agp' do that creates a suitable child bus
for the MMCR stuff.  This works for both ACPI and non-ACPI and doesn't
require hacking the legacy_pcib stuff.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Birrell]

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

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

Re: How to get a device_t

[John Baldwin]

On 08-Aug-2003 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.

Well, that would be a major pain on current since nexus is already
finished attaching many of its drivers by the time it gets to here.
Also, if you use ACPI and if ACPI exists, then this function _won't_
_ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
work both for ACPI and legacy.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Bernd Walter]

On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
> 
> On 08-Aug-2003 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.
> 
> Well, that would be a major pain on current since nexus is already
> finished attaching many of its drivers by the time it gets to here.
> Also, if you use ACPI and if ACPI exists, then this function _won't_
> _ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
> work both for ACPI and legacy.

I agree with this point and if I understood correct this is what
John Birrel already had done.

However - I would still like to know why
device_add_child(nexus, "elanbb", -1);
results in an elanbb instance numer 1 connected to pci0.
And why I don't get any iicbb childs.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[John Baldwin]

On 08-Aug-2003 Bernd Walter wrote:
> On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
>> 
>> On 08-Aug-2003 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.
>> 
>> Well, that would be a major pain on current since nexus is already
>> finished attaching many of its drivers by the time it gets to here.
>> Also, if you use ACPI and if ACPI exists, then this function _won't_
>> _ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
>> work both for ACPI and legacy.
> 
> I agree with this point and if I understood correct this is what
> John Birrel already had done.

No, he is still working in the nexus/pcib driver's identify routine,
not in a separate 'hostb' PCI driver.

> However - I would still like to know why
> device_add_child(nexus, "elanbb", -1);
> results in an elanbb instance numer 1 connected to pci0.
> And why I don't get any iicbb childs.

I would have to see your code changes in order to try to tell you that.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Bernd Walter]

On Fri, Aug 08, 2003 at 04:32:43PM -0400, John Baldwin wrote:
> On 08-Aug-2003 Bernd Walter wrote:
> > On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote:
> >> On 08-Aug-2003 Bernd Walter wrote:
> >> > However - I would still like to know why
> >> > device_add_child(nexus, "elanbb", -1);
> >> > results in an elanbb instance numer 1 connected to pci0.
> >> > And why I don't get any iicbb childs.
> >> 
> >> I would have to see your code changes in order to try to tell you that.
> > 
> > http://www.cosmo-project.de/~bernd/elanbb.diff
> 
> First off, the iicbb driver does not know have an elanbb attachment.
> You need a set of driver methods and corresponding
> 
> DRIVER_MODULE(iicbb, elanbb, ...)

I really should have known, because I made the same mistake in one of
my first versions for ehci and hunted for the usb bus not coming up...

> For the iicbb child of elanbb to get a driver that probes it and attaches
> to it.

OK.

> Hmm, what you want to do is not hijack the legacy/pcib identify
> routine I think, but add an identify routine to your elanbb driver
> and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus))
> and have its identify routine use pci_cfgreg() to get the devid for
> device 0 and if it is the right one call init_AMD_Elan_sc520() and
> add it's probe routine.  Or rather.  I've fixed all this and you can

Agreed - it was just the quick and dirty - get it running way.
I also might want new files for a new driver as well...

> get the changes (whcih should fix bogus elanbb0 and make iicbb0 show
> up) at http://www.freebsd.org/~jhb/patches/elan.patch  It includes
> your patch above but fixes a few things.  One other bug I fixed is
> that since yout elan was hung off of pci and had an empty probe
> routine, any unclaimed PCI device got "claimed" by your elanbb driver,
> hence your bogus elanbb0.  Note that the version of elanbb in

OK - I still don't now the exact bug, but I got an idea.
The elanbb part was build with viapm as sample.

> elan.patch uses a private identify routine that calls
> init_AMD_Elan_sc250(), so it will work both with and without ACPI.

Thank you for the work.
Well elanbb is the wrong driver for calling init_AMD_Elan_sc250.
It is just one of many possible users of elan mmcr extensions.

> However, the warning printf about CPU_ELAN won't show up with ACPI.
> I left the printf in pci_bus.c for now.  A better place to put it would
> be in the hostb driver itself.  Well, I went ahead and did that too,
> so now the warning will show up both for ACPI and non-ACPI systems.

:)

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Sat, Aug 09, 2003 at 01:38:05PM +0200, Bernd Walter wrote:
> After adding you patch and some includes (,
> )
> 
> [...]
> pci_open(1):mode 1 addr port (0x0cf8) is 0x
> pci_open(1a):   mode1res=0x8000 (0x8000)
> pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=30001022)
> pcibios: BIOS version 2.00
> Doing h0h0magic for AMD Elan sc520
> sysctl machdep.i8254_freq=1189161 returns 0
> Timecounter "ELAN"  frequency 833 Hz
> 
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x78363029
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc029d05b
> stack pointer   = 0x10:0xc03cdcc4
> frame pointer   = 0x10:0xc03cdcd4
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 0 (swapper)
> kernel: type 12 trap, code=0
> Stopped at  BUS_ADD_CHILD+0x2b: pushl   0x4(%eax)
> db> trace

The number of arguments to elanbb_identify was wrong.
Now things work better.

I will now split it into elanmmcr and elanbb driver and then publish
the finished work.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 03:34:01PM -0400, Eric Jacobs wrote:
> On Wed, 6 Aug 2003 13:00:13 +0200
> Bernd Walter <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Back to the original question:
> > How do I get the device_t from nexus?
> > Is there a get_nexus() function somewhere?
> 
> You can do it this way:
> 
> devclass_t nexusdc = devclass_find("nexus");
> device_t nexus = devclass_get_device(nexusdc, 0);
> 
> It is in fact in the code path as "parent" in nexus_pcib_identify,
> but not in the special PCI bridge identification function. If you
> call BUS_ADD_CHILD at that time, you don't need to probe or attach
> your device; it will be automatically probed and attached later and
> you can whatever logic you want in your probe and attach routines.

Thank you - I think that were they key parts missing.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
> >> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >> >>From the logicaly standpoint the extensions had to be attached to
> >> >nexus, but nowhere is the current code path there is a handle for
> >> >nexus or any other device_t.
> >> 
> >> In fact what you may want to do is hang the entire MMCR off the nexus
> >> as a bus, and hang the various drivers off that bus.
> >
> >What needs to be in *_probe() to conditionalize on elan existence?
> 
> Well, my idea was to hang the mmcr bus on nexus when we find out it
> is an elan.

Back to the original question:
How do I get the device_t from nexus?
Is there a get_nexus() function somewhere?

> It may be that you are not allowed to attach a bus to the nexus when
> we find out it is an elan in the host/pci bridge probe, but then I guess
> you could just hang it off that instead.

There is also no other device_t in the code path available.
The last function knowing a device_t is nexus_pcib_identify.
We then have to pass this as an argument to nexus_pcib_is_host_bridge().

> Pressumably some newbus magic will then probe that bus.  If its not
> an elan, there is no mmcr bus and nothing will get probed.

Yes - that part is clear.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Eric Jacobs]

On Wed, 6 Aug 2003 13:00:13 +0200
Bernd Walter <[EMAIL PROTECTED]> wrote:

> 
> Back to the original question:
> How do I get the device_t from nexus?
> Is there a get_nexus() function somewhere?

You can do it this way:

devclass_t nexusdc = devclass_find("nexus");
device_t nexus = devclass_get_device(nexusdc, 0);

It is in fact in the code path as "parent" in nexus_pcib_identify,
but not in the special PCI bridge identification function. If you
call BUS_ADD_CHILD at that time, you don't need to probe or attach
your device; it will be automatically probed and attached later and
you can whatever logic you want in your probe and attach routines.

Eric
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Poul-Henning Kamp]

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.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>I need to add I2C support for a Elan520 based soekris system.
>The system has the required GPIO pins and there is the iicbb driver
>to handle generic bitbang code - just needing a simple layer driver to
>enable, disable and read pins.
>But unlike normal isa/pci hardware probing the existence of the GPIO
>line is a bit difficult.
>The current elan-mmcr.c gets started from i386/pci/pci_bus.c at
>host bridge probing, because that's seems to be the only place to
>safely detect this special CPU.

That's my doing, based on my reading of the datasheet from AMD.

It would be better if we could detect the Elan in the normal CPU
identification stuff, but I couldn't seem to find a reliable way.

>>From the logicaly standpoint the extensions had to be attached to
>nexus, but nowhere is the current code path there is a handle for
>nexus or any other device_t.

In fact what you may want to do is hang the entire MMCR off the nexus
as a bus, and hang the various drivers off that bus.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Bernd Walter <[EMAIL PROTECTED]> writes:
: Back to the original question:
: How do I get the device_t from nexus?

You don't.  You are assigned one.

: Is there a get_nexus() function somewhere?

No.  You don't need it.

Chances are you could create an identify routine that would attach the
bus to.  The identify routine should be all you need.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Birrell]

On Thu, Aug 07, 2003 at 10:23:03AM -0400, John Baldwin wrote:
> 
> On 07-Aug-2003 M. Warner Losh wrote:
> > In message: <[EMAIL PROTECTED]>
> > Bernd Walter <[EMAIL PROTECTED]> writes:
> >: The host bridge is not available yet at probing time of the host bridge.
> >: What we have is the host bridges parent (nexus) in the calling function.
> >: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
> >: we find it out later.
> > 
> > Don't you mean legacy_pcib_is_host_bridge?  That's where the matching
> > is done in current right now (well, at least as of my last sync) If
> > so, passing the host bridge's device down to it would be trivial to
> > add.  It would also allow other CPUs with builtin host bridges to do
> > similar tricks to the one that is done for the ELAN.  These sorts of
> > features have been very common in other CPU families, and there's no
> > reason to think that there won't be more of them in the x86 family as
> > time goes on.
> > 
> > I'm not sure that adding it to nexus at this stage of the boot would
> > truly work.  Since the legacy device has decided to attach, the nexus
> > bus is already walking through its children.  Adding a child during
> > that walk strikes me as dangerous, since we have no locking on the
> > children element of the device_t.  Hmmm, looks I just found a source
> > of problems in my newbus locking code that might explain some weird
> > things happening when I enable it  Thanks for making me go look :-)
> 
> You would add it to legacy, not nexus.  What you probably really want
> to do is to write a host-PCI bridge driver that attaches to the actual
> PCI device like 'hostb' and 'agp' do that creates a suitable child bus
> for the MMCR stuff.  This works for both ACPI and non-ACPI and doesn't
> require hacking the legacy_pcib stuff.

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

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Bernd Walter <[EMAIL PROTECTED]> writes:
> : Back to the original question:
> : How do I get the device_t from nexus?
> 
> You don't.  You are assigned one.
> 
> : Is there a get_nexus() function somewhere?
> 
> No.  You don't need it.
> 
> Chances are you could create an identify routine that would attach the
> bus to.  The identify routine should be all you need.

The point is that this special CPU can only be identified by its
host bridge.
That's the place were the MMCR bus has to be attached to nexus, so
we need the handle within this function.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Fri, Aug 08, 2003 at 04:32:43PM -0400, John Baldwin wrote:
> 
> On 08-Aug-2003 Bernd Walter wrote:
> > On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote:
> >> 
> >> On 08-Aug-2003 Bernd Walter wrote:
> >> > On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
> >> >> Well, that would be a major pain on current since nexus is already
> >> >> finished attaching many of its drivers by the time it gets to here.
> >> >> Also, if you use ACPI and if ACPI exists, then this function _won't_
> >> >> _ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
> >> >> work both for ACPI and legacy.
> >> > 
> >> > I agree with this point and if I understood correct this is what
> >> > John Birrel already had done.
> >> 
> >> No, he is still working in the nexus/pcib driver's identify routine,
> >> not in a separate 'hostb' PCI driver.
> >> 
> >> > However - I would still like to know why
> >> > device_add_child(nexus, "elanbb", -1);
> >> > results in an elanbb instance numer 1 connected to pci0.
> >> > And why I don't get any iicbb childs.
> >> 
> >> I would have to see your code changes in order to try to tell you that.
> > 
> > http://www.cosmo-project.de/~bernd/elanbb.diff
> 
> First off, the iicbb driver does not know have an elanbb attachment.
> You need a set of driver methods and corresponding
> 
> DRIVER_MODULE(iicbb, elanbb, ...)
> 
> For the iicbb child of elanbb to get a driver that probes it and attaches
> to it.
> 
> Hmm, what you want to do is not hijack the legacy/pcib identify
> routine I think, but add an identify routine to your elanbb driver
> and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus))
> and have its identify routine use pci_cfgreg() to get the devid for
> device 0 and if it is the right one call init_AMD_Elan_sc520() and
> add it's probe routine.  Or rather.  I've fixed all this and you can
> get the changes (whcih should fix bogus elanbb0 and make iicbb0 show
> up) at http://www.freebsd.org/~jhb/patches/elan.patch  It includes
> your patch above but fixes a few things.  One other bug I fixed is
> that since yout elan was hung off of pci and had an empty probe
> routine, any unclaimed PCI device got "claimed" by your elanbb driver,
> hence your bogus elanbb0.  Note that the version of elanbb in
> elan.patch uses a private identify routine that calls
> init_AMD_Elan_sc250(), so it will work both with and without ACPI.
> However, the warning printf about CPU_ELAN won't show up with ACPI.
> I left the printf in pci_bus.c for now.  A better place to put it would
> be in the hostb driver itself.  Well, I went ahead and did that too,
> so now the warning will show up both for ACPI and non-ACPI systems.

After adding you patch and some includes (,
)

[...]
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=30001022)
pcibios: BIOS version 2.00
Doing h0h0magic for AMD Elan sc520
sysctl machdep.i8254_freq=1189161 returns 0
Timecounter "ELAN"  frequency 833 Hz


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78363029
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc029d05b
stack pointer   = 0x10:0xc03cdcc4
frame pointer   = 0x10:0xc03cdcd4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at  BUS_ADD_CHILD+0x2b: pushl   0x4(%eax)
db> trace
BUS_ADD_CHILD(c0307fb8,0,c02c9f2f,) at BUS_ADD_CHILD+0x2b
elanbb_identify(c0307fb8,c05ad800,c05a72b0,c05ad800,c03cdd1c) at elanbb_identify+0x3b
DEVICE_IDENTIFY(c0307fb8,c05ad800) at DEVICE_IDENTIFY+0x3e
bus_generic_probe(c05ad800,c0db7098,c03cdd40,c01b24da,c05ad800) at 
bus_generic_probe+0x28
nexus_attach(c05ad800,c05ad800,c05adb80,c03cdd5c,c01b0f01) at nexus_attach+0xd
DEVICE_ATTACH(c05ad800,1,c05ad800,c0305efc,3d2000) at DEVICE_ATTACH+0x3a
device_probe_and_attach(c05ad800) at device_probe_and_attach+0x81
root_bus_configure(c05adb80,c02e4cb8,0,4) at root_bus_configure+0x16
configure(0,3cac00,3ca000,0,c0123825) at configure+0x22
mi_startup() at mi_startup+0xb2
begin() at begin+0x2c
db> 


c029d030 :
typedef device_t bus_add_child_t(device_t _dev, int _order, const char *_name,
 int _unit);
static __inline device_t BUS_ADD_CHILD(device_t _dev, int _order,
   const char *_name, int _unit)
{
c029d030:   55  push   %ebp
c029d031:   89 e5   mov%esp,%ebp
c029d033:   56  push   %esi
c029d034:   53  push   %ebx
c029d035:   8b 75 08mov0x8(%ebp),%esi
kobjop_t _m;
KOBJOPLOOKUP(((kobj_t)_dev)->ops,bus_add_child)

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 07:27:42PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Bernd Walter <[EMAIL PROTECTED]> writes:
> : The host bridge is not available yet at probing time of the host bridge.
> : What we have is the host bridges parent (nexus) in the calling function.
> : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
> : we find it out later.
> 
> Don't you mean legacy_pcib_is_host_bridge?  That's where the matching

Yes - I looked at 5.1-RELEASE code.
Layering seems to have been changed since then.

> is done in current right now (well, at least as of my last sync) If
> so, passing the host bridge's device down to it would be trivial to
> add.  It would also allow other CPUs with builtin host bridges to do

How?
legacy_pcib_is_host_bridge is called before BUS_ADD_CHILD.

> similar tricks to the one that is done for the ELAN.  These sorts of
> features have been very common in other CPU families, and there's no
> reason to think that there won't be more of them in the x86 family as
> time goes on.

point taken.

> I'm not sure that adding it to nexus at this stage of the boot would
> truly work.  Since the legacy device has decided to attach, the nexus
> bus is already walking through its children.  Adding a child during
> that walk strikes me as dangerous, since we have no locking on the
> children element of the device_t.  Hmmm, looks I just found a source
> of problems in my newbus locking code that might explain some weird
> things happening when I enable it  Thanks for making me go look :-)

OK - that's an argument to avoid nexus.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Birrell <[EMAIL PROTECTED]> writes:
: On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote:
: > Well, I don't know.  The PC Cards that we have in the system are
: > mapped into the I/O and memory ranges traditionally reserved for the
: > ISA bus.  In ISA systems, this made sense because pccard was attached
: > to pcic was attached to isa.  However, now we have situations where
: > pccard is attached to cbb which is attached to pci.  There may be a
: > isab device with isa bus hanging off of it that makes the relationship
: > between the pccard devices cousins rather than nephews in the tree.
: > And there isn't any harm from that.  Wouldn't this be a similar
: > situation?
: 
: The flash I'm talking about is not pccard related. Sorry if I gave that
: impression.

No.  The pccard mention was to argue by analogy only :-)

: The SC520 has onboard support to control 3 flash chips.
: The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS
: file system (at the moment) where I keep a copy of an etherboot
: executable. The board also has a 64Mb NAND flash chip which I've
: written a FreeBSD UFS image into. Our standard bootloader happily
: loads the kernel from that. Now I need to get a flash driver working
: for the root file system. I've got an existing read-only flash driver
: that I used to use on an Intel 386EX board, but that had the entire
: flash chip memory mapped. This new board maps the NAND flash in 4K
: pages.

That would be very very cool.  There's a number of new SBCs that I've
seen that have this sort of setup.  Timing Solutions might be very
interesting in something like this because we're currently buying CF
cards to do our OS.

: This URL lists the relevent docs:
: 
: 

: 
: The ones you want are the "ElanSC520 Users Manual" and "ElanSC520
: Register Set Manual"

Downloading now.

: If you have time, I'd be interested. This is a hot topic for me because
: it is exactly where I'm up to. I have everything else working on the
: board.

I'm thinking that it wouldn't take too long.  Lemme see what I can
throw together.  It would be a sketch only...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 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 <[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:  on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.00
Timecounter "ELAN"  frequency 833 Hz
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
elanbb1 at device 0.0 on pci0
hifn0 mem 0xa0001000-0xa0001fff,0xa000-0xafff 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   BWCThttp://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]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
John Birrell <[EMAIL PROTECTED]> writes:
: On Wed, Aug 06, 2003 at 05:50:45PM -0600, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
: > : In fact what you may want to do is hang the entire MMCR off the nexus
: > : as a bus, and hang the various drivers off that bus.
: 
: I have a card based on the SC520 too. (Note to Warner: this is the card I
: needed the higher port numbers for)

I gotta get me one of these :-)...

: I need to access the GPIO pins too. But before that, I need to get flash
: drivers working. Access to the flash chips also requires the MMCR. Does
: it really make sense to hang the flash devices off the MMCR "bus" when they
: are mapped into ISA bus space?

Well, I don't know.  The PC Cards that we have in the system are
mapped into the I/O and memory ranges traditionally reserved for the
ISA bus.  In ISA systems, this made sense because pccard was attached
to pcic was attached to isa.  However, now we have situations where
pccard is attached to cbb which is attached to pci.  There may be a
isab device with isa bus hanging off of it that makes the relationship
between the pccard devices cousins rather than nephews in the tree.
And there isn't any harm from that.  Wouldn't this be a similar
situation?

: >From my reading of the AMD docs, only the CPU core is identifiable
: via the CPUID instruction. The docs say that the first two bytes of
: the MMCR are the REVID and those can be used to "identify the device
: itself". The second byte is set to zero to "identify the product as
: the ElanSC520 microcontroller".  So if you know the MMCR is there,
: you can go to that byte and get confirmation!  Thanks AMD. It seems
: that the discovery via the host to PCI bridge is the only reliable
: way to go.

Can you send me a URL for that document?  I thought I understood
things, but making sure by reading it would sure help.

: My local hack is to make my flash drivers require the elan_mmcr
: option and then they can just go use the elan_mmcr global
: variable. I just need the elan device to be initialised earlier.

But adding it as a child of nexus in the host bridge code wouldn't
make it probe any earlier.  To do that you'd need to make it a true
child of nexus with a identify routine that would go out and try to
find the host bridge at a certain address and use the right kind of
bridge there to add the device.  You could then map the mmcr space to
a convenient location, and then dole it out to child drivers such that
the bus_space macros would do the right thing.  Since it is memory
mapped, this would be relatively easy to do.  This would also allow
you to make it known earlier in the boot process.  This is also very
much analygous to what pccard and cardbus does.  You wouldn't have the
problems that we have with picking resources in the cardbus bridge
code because it looks like the mmcr is at a fixed address (either by
design of the chip or by phk's big stick).

If you'd like, I can sketch out in code what I'm trying to say in
words here.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> >I need to add I2C support for a Elan520 based soekris system.
>> >The system has the required GPIO pins and there is the iicbb driver
>> >to handle generic bitbang code - just needing a simple layer driver to
>> >enable, disable and read pins.
>> >But unlike normal isa/pci hardware probing the existence of the GPIO
>> >line is a bit difficult.
>> >The current elan-mmcr.c gets started from i386/pci/pci_bus.c at
>> >host bridge probing, because that's seems to be the only place to
>> >safely detect this special CPU.
>> 
>> That's my doing, based on my reading of the datasheet from AMD.
>> 
>> It would be better if we could detect the Elan in the normal CPU
>> identification stuff, but I couldn't seem to find a reliable way.
>
>I could reread the datasheet, but don't give it much hope if you
>hadn't find anything usefull.
>
>> >>From the logicaly standpoint the extensions had to be attached to
>> >nexus, but nowhere is the current code path there is a handle for
>> >nexus or any other device_t.
>> 
>> In fact what you may want to do is hang the entire MMCR off the nexus
>> as a bus, and hang the various drivers off that bus.
>
>What needs to be in *_probe() to conditionalize on elan existence?

Well, my idea was to hang the mmcr bus on nexus when we find out it
is an elan.

It may be that you are not allowed to attach a bus to the nexus when
we find out it is an elan in the host/pci bridge probe, but then I guess
you could just hang it off that instead.

Pressumably some newbus magic will then probe that bus.  If its not
an elan, there is no mmcr bus and nothing will get probed.

I'm not the worlds greatest newbus specialist, so check this concept
with somebody who know what they are talking about before you do it.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Baldwin]

On 08-Aug-2003 Bernd Walter wrote:
> On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote:
>> 
>> On 08-Aug-2003 Bernd Walter wrote:
>> > On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
>> >> Well, that would be a major pain on current since nexus is already
>> >> finished attaching many of its drivers by the time it gets to here.
>> >> Also, if you use ACPI and if ACPI exists, then this function _won't_
>> >> _ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
>> >> work both for ACPI and legacy.
>> > 
>> > I agree with this point and if I understood correct this is what
>> > John Birrel already had done.
>> 
>> No, he is still working in the nexus/pcib driver's identify routine,
>> not in a separate 'hostb' PCI driver.
>> 
>> > However - I would still like to know why
>> > device_add_child(nexus, "elanbb", -1);
>> > results in an elanbb instance numer 1 connected to pci0.
>> > And why I don't get any iicbb childs.
>> 
>> I would have to see your code changes in order to try to tell you that.
> 
> http://www.cosmo-project.de/~bernd/elanbb.diff

First off, the iicbb driver does not know have an elanbb attachment.
You need a set of driver methods and corresponding

DRIVER_MODULE(iicbb, elanbb, ...)

For the iicbb child of elanbb to get a driver that probes it and attaches
to it.

Hmm, what you want to do is not hijack the legacy/pcib identify
routine I think, but add an identify routine to your elanbb driver
and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus))
and have its identify routine use pci_cfgreg() to get the devid for
device 0 and if it is the right one call init_AMD_Elan_sc520() and
add it's probe routine.  Or rather.  I've fixed all this and you can
get the changes (whcih should fix bogus elanbb0 and make iicbb0 show
up) at http://www.freebsd.org/~jhb/patches/elan.patch  It includes
your patch above but fixes a few things.  One other bug I fixed is
that since yout elan was hung off of pci and had an empty probe
routine, any unclaimed PCI device got "claimed" by your elanbb driver,
hence your bogus elanbb0.  Note that the version of elanbb in
elan.patch uses a private identify routine that calls
init_AMD_Elan_sc250(), so it will work both with and without ACPI.
However, the warning printf about CPU_ELAN won't show up with ACPI.
I left the printf in pci_bus.c for now.  A better place to put it would
be in the hostb driver itself.  Well, I went ahead and did that too,
so now the warning will show up both for ACPI and non-ACPI systems.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[John Birrell]

On Fri, Aug 08, 2003 at 02:35:36PM +0200, Bernd Walter wrote:
> 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.

My main focus is on the flash drivers. For them I need ISA hints. The MMCR
registers are required to access the flash controller. The flash maps into
the same memory space as the ISA devices, so I keep asking myself why they
can't _just_ _be_ _ISA_ _devices_.

I'm still working on a STABLE source base because I need the stability that
provides. So the legacy device isn't an option.

I've looked at what I need to do to support the ISA style resources that
the flash drivers need if the mmcr is implemented as a bus. I don't see the
need to cobble up code for managing the resources in an MMCR pseudo-bus when
they are perfectly well implemented in the ISA code.

For my purposes, I find that I can leave PHK's elan-mmcr stuff virtually
as it is and just get my flash drivers to check the MMCR map pointer in
their probes to determine if on an Elan SC520. When it comes to writing
to the MMCR, the option CPU_ELAN code can just provide a function to do that.

I see no need to write more code than is absolutely required. The bus stuff
is neat when it works in your favour, but in this case it's just a hassle.
The SC520 is intended as a chip for embedded systems. I don't want/need
any bells and whistles when I've only got 2 executables in the entire
operating system (the kernel and init). I'll go the simple way.

-- 
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Bernd Walter]

On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote:
> 
> On 08-Aug-2003 Bernd Walter wrote:
> > On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
> >> Well, that would be a major pain on current since nexus is already
> >> finished attaching many of its drivers by the time it gets to here.
> >> Also, if you use ACPI and if ACPI exists, then this function _won't_
> >> _ever_ _be_ _called_.  If you use a hostb PCI driver, then it will
> >> work both for ACPI and legacy.
> > 
> > I agree with this point and if I understood correct this is what
> > John Birrel already had done.
> 
> No, he is still working in the nexus/pcib driver's identify routine,
> not in a separate 'hostb' PCI driver.
> 
> > However - I would still like to know why
> > device_add_child(nexus, "elanbb", -1);
> > results in an elanbb instance numer 1 connected to pci0.
> > And why I don't get any iicbb childs.
> 
> I would have to see your code changes in order to try to tell you that.

http://www.cosmo-project.de/~bernd/elanbb.diff

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Bernd Walter <[EMAIL PROTECTED]> writes:
: On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Bernd Walter <[EMAIL PROTECTED]> writes:
: > : Back to the original question:
: > : How do I get the device_t from nexus?
: > 
: > You don't.  You are assigned one.
: > 
: > : Is there a get_nexus() function somewhere?
: > 
: > No.  You don't need it.
: > 
: > Chances are you could create an identify routine that would attach the
: > bus to.  The identify routine should be all you need.
: 
: The point is that this special CPU can only be identified by its
: host bridge.
: That's the place were the MMCR bus has to be attached to nexus, so
: we need the handle within this function.

Then why not just hang the bus off the host bridge?  There's really no
compelling reason to have it on the nexus.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 06:37:10PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Bernd Walter <[EMAIL PROTECTED]> writes:
> : On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote:
> : > In message: <[EMAIL PROTECTED]>
> : > Bernd Walter <[EMAIL PROTECTED]> writes:
> : > : Back to the original question:
> : > : How do I get the device_t from nexus?
> : > 
> : > You don't.  You are assigned one.
> : > 
> : > : Is there a get_nexus() function somewhere?
> : > 
> : > No.  You don't need it.
> : > 
> : > Chances are you could create an identify routine that would attach the
> : > bus to.  The identify routine should be all you need.
> : 
> : The point is that this special CPU can only be identified by its
> : host bridge.
> : That's the place were the MMCR bus has to be attached to nexus, so
> : we need the handle within this function.
> 
> Then why not just hang the bus off the host bridge?  There's really no
> compelling reason to have it on the nexus.

The host bridge is not available yet at probing time of the host bridge.
What we have is the host bridges parent (nexus) in the calling function.
Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
we find it out later.
I thought it would be cleaner to not extend nexus_pcib_is_host_bridge
arguments for a specialised case.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[Bernd Walter]

On Wed, Aug 06, 2003 at 08:39:37PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Birrell <[EMAIL PROTECTED]> writes:
> : On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote:
> : The SC520 has onboard support to control 3 flash chips.
> : The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS
> : file system (at the moment) where I keep a copy of an etherboot
> : executable. The board also has a 64Mb NAND flash chip which I've
> : written a FreeBSD UFS image into. Our standard bootloader happily
> : loads the kernel from that. Now I need to get a flash driver working
> : for the root file system. I've got an existing read-only flash driver
> : that I used to use on an Intel 386EX board, but that had the entire
> : flash chip memory mapped. This new board maps the NAND flash in 4K
> : pages.
> 
> That would be very very cool.  There's a number of new SBCs that I've
> seen that have this sort of setup.  Timing Solutions might be very
> interesting in something like this because we're currently buying CF
> cards to do our OS.

The soekris board seems to be designed to boot from soldered flash too.
At least there is PCB place under the CF socket that looks like flash
pads.

> : If you have time, I'd be interested. This is a hot topic for me because
> : it is exactly where I'm up to. I have everything else working on the
> : board.
> 
> I'm thinking that it wouldn't take too long.  Lemme see what I can
> throw together.  It would be a sketch only...

That would be great.

-- 
B.Walter   BWCThttp://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]"

Re: How to get a device_t

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Bernd Walter <[EMAIL PROTECTED]> writes:
: The host bridge is not available yet at probing time of the host bridge.
: What we have is the host bridges parent (nexus) in the calling function.
: Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or
: we find it out later.

Don't you mean legacy_pcib_is_host_bridge?  That's where the matching
is done in current right now (well, at least as of my last sync) If
so, passing the host bridge's device down to it would be trivial to
add.  It would also allow other CPUs with builtin host bridges to do
similar tricks to the one that is done for the ELAN.  These sorts of
features have been very common in other CPU families, and there's no
reason to think that there won't be more of them in the x86 family as
time goes on.

I'm not sure that adding it to nexus at this stage of the boot would
truly work.  Since the legacy device has decided to attach, the nexus
bus is already walking through its children.  Adding a child during
that walk strikes me as dangerous, since we have no locking on the
children element of the device_t.  Hmmm, looks I just found a source
of problems in my newbus locking code that might explain some weird
things happening when I enable it  Thanks for making me go look :-)

Warner

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: How to get a device_t

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> >On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
>> >> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> >> >>From the logicaly standpoint the extensions had to be attached to
>> >> >nexus, but nowhere is the current code path there is a handle for
>> >> >nexus or any other device_t.
>> >> 
>> >> In fact what you may want to do is hang the entire MMCR off the nexus
>> >> as a bus, and hang the various drivers off that bus.
>> >
>> >What needs to be in *_probe() to conditionalize on elan existence?
>> 
>> Well, my idea was to hang the mmcr bus on nexus when we find out it
>> is an elan.
>
>Back to the original question:
>How do I get the device_t from nexus?
>Is there a get_nexus() function somewhere?

That's were I don't know enough newbus :-)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"