Date: Fri, 30 Jun 2006 10:41:42 +0200 From: Gerald Heinig <gheinig@syskonnect.de> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: freebsd-hackers@freebsd.org, hongz@promisechina.com Subject: Re: ????: Help:why bus resource shortage? Message-ID: <1151656903.28501.5.camel@sk-dt-018.skd.de> In-Reply-To: <20060630081646.GS82074@funkthat.com> References: <20060629223618.GR82074@funkthat.com> <1151648790$67280$13400385@hongz@promisechina.com> <20060630081646.GS82074@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Guys, On Fri, 2006-06-30 at 01:16 -0700, John-Mark Gurney wrote: > hongz@promisechina.com wrote this message on Fri, Jun 30, 2006 at 14:26 +0800: > > I found the problem! It was caused by an existed ata driver in FreeBSD. I > > have mentioned before that the existed ata driver can take over the > > management of our HBA card, leading to our driver can not probe our card! By > > getting rid of the ID in ata-chipset.c,we can probe the HBA card, but we > > still can not get the pci resources! Instead, I can get rid of the effects > > of the existed ata driver by only getting rid of the ID in probe function of > > ata-pci.c! > > This has now been fixed by making the built in driver return a negative > value for the probe.. so your probe routine can return 0, and it will > win the probe for the device... Minor nitpick: it may perhaps be better to return a smaller negative value (eg. -5) rather than 0. IIRC -10 is the default score used by standard system drivers and 0 is the highest score available. If someone wants to use an alternative driver to Hong's and the standard system's it won't attach. > > > In summon, the problems (probe failure and bus resource short) lie in the > > hmm. that seems wierd, are you trying to allocate the resource in the > _probe function? You shouldn't need to unless you need to do special > munging of the resources to properly identify the device.. and unless > you return 0 from your _probe function, you will have to release the > resrouce at the end of the _probe function... > > > ata driver in FreeBSD, which can recognize our HBA card because it records > > the ID of this HBA. By getting rid of the switch case of this ID in probe > > function of ata-pci.c, you can take over the HBA completely. > > > > Here, I would like to report my solution (not tested yet) on a previous > > question about how to transfer physical address into kernel virtual address > > in FreeBSD: > > That is what the bus_space api is for... The method you propose is a > hack and not very useful for ensuring that your driver run on other > platforms... > > > -----????????----- > > ??????: John-Mark Gurney [mailto:gurney_j@resnet.uoregon.edu] > > ????????: 2006??6??30?? 6:36 > > ??????: hongz@promisechina.com > > ????: freebsd-hackers@freebsd.org > > ????: Re: Help:why bus resource shortage? > > > > hongz@promisechina.com wrote this message on Thu, Jun 15, 2006 at 14:55 > > +0800: > > > I failed to get the pci bus resource after the driver is loaded (sc->r_mem > > > is NULL after bus_alloc_resource_any is called). Is it because bus > > resources > > > have been consumed by other drivers? Or other something happened? Please > > > help me on this! > > > > Please provide a verbose boot (boot -v) output of the pci card... > > > > > rid = 0x10; > > > > You really should be using PCIR_BAR macro instead of hard coding it... > > > > > sc->r_mem = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY, &rid, > > > RF_ACTIVE); > > > > > > if (!sc->r_mem) return ENOMEM; > > > > > > > > > > > > The pci resources on our cards: > > > > > > shasta0: <Promise FastTrak 4310/579/779 Driver> port 0x2400-0x247f, > > > 0x2000-0x20ff mem 0xe9021000-0xe9021fff, 0xe9000000-0xe901ffff irq 17 at > > > device 5.0 on pci2 > > > > The resources could be in a different order than listed... Are you > > sure the memory resource is in the first bar possition? >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1151656903.28501.5.camel>