Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jan 2004 01:29:40 -0500
From:      Gary Corcoran <garycor@comcast.net>
To:        "Rick C. Petty" <rick@megan.kiwi-computer.com>
Cc:        freebsd-hardware@freebsd.org
Subject:   Re: Conexant HCF 56k PCI modem help
Message-ID:  <40136254.7000708@comcast.net>
In-Reply-To: <20040125044712.GA20903@megan.kiwi-computer.com>
References:  <20040125044712.GA20903@megan.kiwi-computer.com>

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

> For a project, our customer wants to use these 56k PCI modems from
> Creative.  Although not my first choice, I did some research and discovered
> that the modems use a Conexant Systems, Inc. (vendor id 0x14F1) SmartHCF
> 56k chip (device id 0x1059).  It is not a "winmodem"; the HCF family is
> "Controllerless" vs. the HSF "software" chipsets.

I can't help you directly with your problem, but perhaps a clarification
might help you or someone else understand the problem better.  If the modem
you have is "controllerless", then it *IS* a "winmodem".  It needs a "windows"
(or equivalent) driver to emulate the missing controller.  If it's both
controllerless *and* DSP-less, then it's a "softmodem".  That is, a softmodem
is one that does *everything* (except the actual Analog-to-Digital and Digital
-to-Analog conversions) in software.  So a softmodem needs realtime Digital
Signal Processing code (as well as the controller emulation code) that runs
on your host CPU.

Gary

> Under a vanilla 5.2-RELEASE, pciconf showed:
> 
> none9@pci1:7:0:	class=0x078000 card=0x1059 chip=0x105914F1 rev=0x08 hdr=0x00
>     vendor   = 'Conexant Systems, Inc.'
>     device   = 'HCF 56k Data/Fax/Voice Modem (Worldwide)'
>     class    = simple comms
> 
> I started by adding the following entry to the top of src/dev/puc/pucdata.c:
> 
> 	{   "HCF 56k Data/Fax/Voice Modem (Worldwide)",
> 	    NULL,
> 	    {	0x14F1, 0x1059, 0x148D, 0x1059 },
> 	    {	0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF },
> 	    {
> 		{ PUC_PORT_TYPE_UART, 0x10, 0x00, 0, 0 },
> 	    },
> 	},
> 
> and the kernel detected the device (puc0) an bootup, but was unable to
> attach because it "could not get resource".  That last line in the struct
> was pure guesswork, based on many other entries.  I tried it with
> PUC_PORT_TYPE_COM and had the same error.  Digging through puc.c I tried
> adding PUC_FLAGS_ALTRES to the flags and it found the device, although
> sometimes would hang on boot [I guessed various numbers for the "bar"
> parameter with varying levels of bootability],  so I tried another
> approach..
> 
> Further internet investigation revealed a linux driver from linuxant:
> http://www.linuxant.com/drivers/hcf/downloads-license.php
> 
> They provide two versions of their drivers-- one binary-only "full" version
> (at a "modest price") and a free (limited) version with source code.  The
> code generates a few [linux] kernel modules via some shims to access the
> binary-only modules.  I am hoping someone else of more kernel/driver/puc(4)
> experience has the time to help get this ported...  please let me know
> ASAP.
> 
> Alternatively, if someone could suggest a better solution (PCI-only) for
> not much more than US$25/ea. that works well in FreeBSD 5.x I would be
> quite grateful!  Thanks in advance,
> 
> -- Rick C. Petty
> Senior Software Engineer
> KIWI Computer




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