Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Sep 2001 07:26:18 -0700
From:      John Merryweather Cooper <john_m_cooper@yahoo.com>
To:        Mike Bruins <bruins@hal9000.net.au>
Cc:        freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org, Mike Bruins <bruins@hal9000.net.au>
Subject:   Re: health chip driver - vt82c686 - finishing off
Message-ID:  <20010924072618.C677@johncoop.MSHOME>
In-Reply-To: <20010924221149.A4971@wall.hal9000.net.au>; from bruins@hal9000.net.au on Mon, Sep 24, 2001 at 07:11:49 -0700
References:  <20010924221149.A4971@wall.hal9000.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2001.09.24 07:11 Mike Bruins wrote:
> Hello,
> 
> I have put together most of a device driver for the health
> monitoring chip via technologies vt82c686 function 4 (PCI 3057:1106).
> All the kernel loadable module, device probe/attach code,
> temperature/fan/voltage conversion routines are there.
> I can read the device registers for PCI Vendor/Device, chip enable,
> class, subclass etc.
> 
> Basically what I am not able to do is read the values 
> hardware offset registers.  The call to bus_alloc_resource
> fails (returns null) and I can't work out why.
> 
> If anyone could please help with the following questions:
> 
> 1. It looks like bus_alloc_resource() gets resources from it's parent
>    device driver.
>    Does the vt82c686 function 4, talk I2C to it's parent to get
> resources?  
>    If so, do I need a device driver for this parent?
>    Anyone know it's PCI vendor/device chip code?
> 
> 2. Perhaps I am going down the wrong path.  Ideas, example code 
>    references appreciated.  I have looked at many examples of 
>    code, but can't work out what is relevent/required for the 686a/b,
>    in terms of resources and how it communicates.
> 
> 3.  The bit of my code that is actually failing is below.
>   Like I said, I am pretty much sure the code to this point
>   is correct and working as I can print any of the registers
>   and they have sane values.
> 
>   I have tried every conbination I can think of for hwm_io_base_reg
>   and the type of resource I am asking for.
>   I have read the 686a.pdf file many times, tried all I can think of.
>   According to the 686a.pdf the data size is 0x80 bytes.
> 
> 
>         via->mem_rid = hwm_io_base_reg;
>         via->res_mem = bus_alloc_resource(dev, SYS_RES_MEMORY,
> &(via->mem_rid),
>                 0ul, ~0ul, 0x80, RF_ACTIVE);
>         if (!via->res_mem) {
>                 device_printf(dev, "could not map memory\n");
>                 goto bad;
>         }
>         via->memt = rman_get_bustag(via->res_mem);
>         via->memh = rman_get_bushandle(via->res_mem);
> 
>   Ultimately I need the memt and memh values, so I can make calls
> like:
> 
>    val =  bus_space_read_1(via->memt, via->memh, regno);
> 
> 
> 
> My system:
> Motherboard: Gigabyte 6vxd7 
> CPU        : dual 866
> OS         : 4.3-RELEASE free-bsd
> 
> I have altered chip_match() so no driver is loaded at boot time for
> 0x30571106.
> 
> chip0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x06911106
> rev=0xc4 hdr=0x00
> pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0x85981106
> rev=0x00 hdr=0x01
> isab0@pci0:7:0: class=0x060100 card=0x06861106 chip=0x06861106
> rev=0x22 hdr=0x00
> uhci0@pci0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106
> rev=0x10 hdr=0x00
> uhci1@pci0:7:3: class=0x0c0300 card=0x12340925 chip=0x30381106
> rev=0x10 hdr=0x00
> none0@pci0:7:4: class=0x0c0500 card=0x00000000 chip=0x30571106
> rev=0x30 hdr=0x00
> sym0@pci0:9:0:  class=0x010000 card=0x00000000 chip=0x00201000
> rev=0x01 hdr=0x00
> sym1@pci0:9:1:  class=0x010000 card=0x00000000 chip=0x00201000
> rev=0x01 hdr=0x00
> rl0@pci0:10:0:  class=0x020000 card=0x0027a0a0 chip=0x813910ec
> rev=0x10 hdr=0x00
> pcm0@pci0:13:0: class=0x040100 card=0x13711274 chip=0x13711274
> rev=0x08 hdr=0x00
> none1@pci0:14:0: class=0x040100 card=0x20601458 chip=0x13711274
> rev=0x07 hdr=0x00
> none2@pci1:0:0: class=0x030000 card=0x00000000 chip=0x002c10de
> rev=0x15 hdr=0x00
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hardware" in the body of the message
> 

xmbmon works great (for temperature sorts of things) on my VIA 686B. 
You
might want to take a look at that code (it's in ports).

-- 
jmc

MacroHard -- the perfection of form over
             substance, marketing over
             performance, and greed over
             design . . .

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010924072618.C677>