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>