[PATCH v2 0/4] media: FM radio for the Hauppauge WinTV-HVR-1950

[Ext745 <stealth3m@yahoo.com>]

The HVR-1950 (pvrusb2, 75xxx) has an FM tuner, but Linux has never
offered radio on it ("no FM support on HVR-1950 ... requires some
enhancements to the cx25840 chip-level driver and possibly also the
pvrusb2 driver", pvrusb2 web page). This series adds it.

The cause: in FM mode the TDA8295 hands FM radio to the cx25843 as a
5.5 MHz sound IF, and the cx25840 radio setting (0x808 = 0xf9) never
locks onto that with the audio firmware in linux-firmware.

 1/4 cx25840: on boards that say so (new platform data flag), demodulate
     radio as forced 5.5 MHz FM: mono, 50 us de-emphasis, works with the
     existing firmware.
 2/4 cx25840: FM stereo when Hauppauge's HVR-1950 audio firmware is
     installed as v4l-cx25840-fmstereo.fw (optional, loaded with
     firmware_request_nowarn). Radio then uses the Windows driver's
     setting, 0x808 = 0xfa (audio system 0xa, not in the data sheet),
     reports stereo and switches mono/stereo through the tuner audio
     mode; de-emphasis is 75 us. Without the file nothing changes from 1/4.
 3/4 tda8290: FM signal strength from the TDA8295 IF AGC (the H-PLL lock
     bit used today is always off in FM mode).
 4/4 pvrusb2: radio input, routing and cx25840 platform data for the
     750xx/751xx models.

About the firmware: the image is Driver73/Hcw73MlC.rom (16382 bytes,
sha256 a6505aee99fa71768daece0a7ced1ac1f60bf7f8d823707640778fe0a4fd0a81)
from Hauppauge's WinTV packages. It is the same file on the original
2007 driver CD and in the current WinTV v7, v8.5 and v10 installers
from hauppauge.com. It is not redistributable as far as I know, so it
can't go into linux-firmware, and the series doesn't depend on it. A
user can extract it from the WinTV installer; I have a small script that
does that and checks the hash, and can send it (e.g. for
Documentation/admin-guide/media) if that is wanted. The 0xfa setting
was found by looking at the register writes of Hauppauge's Windows
driver for this board (hcw73bda.sys).

Testing, on an HVR-1950 model 75111 (kernel 7.0 with these changes
backported; this series is compile-tested on media/next, every patch):
 - radio across the FM band; signal meter 30-84 % on local stations,
   0-26 % where the band is empty, but it stays high between closely
   spaced stations too (IF AGC over the whole passband, see 3/4)
 - the low end of the 65-108 MHz range, where I have no stations: an RF
   modulator's channel 4 sound carrier (71.75 MHz FM) on the FM input
   quiets the audio by about 55 dB against the empty channels around it
 - with the firmware file: stereo on 20 of 20 starts on two stations,
   live mono/stereo switching; without it: mono, as in 1/4
 - de-emphasis measured on the hiss of an empty channel: 50 us (1/4),
   75 us (2/4), both within 0.5 dB of the model curves
 - switching between radio, analog TV (BTSC), composite and ATSC, with
   v4l2-ctl, dvbv5-zap and tvheadend
 - v4l2-compliance 1.32: no new failures. The video node gives the same
   result as the stock driver (48 tests, 11 failed, identical fail and
   warning lines); the radio node (new on this card) fails 7, all in
   pvrusb2-v4l2.c, which this series doesn't touch: the radio node
   advertising read() I/O (how pvrusb2 streams radio), an empty tuner
   name, VIDIOC_S_EXT_CTRLS error_idx, and the control enumeration fixed
   by the separate patch below
 - unplugging the card during an FM capture: the reader gets -EIO, the
   driver tears down cleanly, no warnings
 - radio and video open at the same time: whichever node streams first
   keeps streaming without a gap, and read() on the other gets -EBUSY.
   Opening the radio node while TV is streaming still switches the
   input to radio (pvr2_channel_limit_inputs() in pvrusb2-v4l2.c, not
   changed here; the card just had no radio node before), and the input
   stays on radio after the radio node is closed
 - rmmod pvrusb2 while /dev/radio0 is streaming: refused ("in use"), the
   capture carries on, and the module unloads once it is closed
 - a 72 h soak with the firmware file and another 72 h without it.
   Every hour: 30 min of ATSC (dvbv5-zap), then FM on two stations
   (stereo, and once forced mono), analog TV and composite. Both runs
   finished 72 of 72 cycles with no failed step: the ATSC lock was
   never lost (314 GB in each run), every radio capture had audio
   (with the file, 133 of 144 stereo captures had separated channels;
   the rest were near-mono programme material) and every TV capture
   had video. The card never re-enumerated and there were no oopses.
   The only kernel warning was the existing cx2341x "encoder appears
   to be stuck" message, about 3 per cycle. The stock driver prints it
   too, and it recovered every time with no failed firmware reload
   (the soaks ran on v1; the v2 changes are covered by the run below)
 - v2, with the firmware file: a 4 h soak in 15 min cycles (5 min of
   ATSC, then FM on two stations, stereo and once forced mono, analog
   TV and composite). 16 of 16 cycles with no failed step: the ATSC
   lock was never lost, every radio capture had audio (26 of 32 stereo
   captures had separated channels, the rest near-mono programme
   material; the 16 forced-mono captures had L = R) and every TV
   capture had video. The encoder "stuck" warning came about 3 times per
   cycle, as on v1, and recovered every time with no failed firmware
   reload; no oopses. The pvrusb2 module in this run was a local test
   build with an extra encoder power-cycle recovery path (for a card
   problem I hit between the v1 and v2 runs, also with v1); that path
   never triggered

Not covered: the 73xxx models (HVR-1900, same chips as far as I know)
are left as they are because I can't test them. 4/4 enables radio on
both 750xx and 751xx, but only a 751xx was tested; the 750xx has the same
tuner, IF demodulator and cx25843 (only its ATSC demodulator differs,
s5h1409), so it gets the same routing. The other cx25840 users (ivtv,
cx23885, cx231xx) are untested on hardware: 2/4 moves the tuner
audio-mode switch into a helper, and everything new is gated by the
new platform data flag, so their code paths are unchanged by
inspection. Suspend/resume with the radio running wasn't tested.

Not supported: RDS and hardware seek. The cx25843 has an RDS
demodulator, but its registers only give raw I/Q, polled over I2C,
and the audio reaches the host through the cx2341x encoder at 48 kHz,
which loses the 57 kHz RDS subcarrier, so the radio node doesn't
advertise RDS. The data sheet also lists an RDS output that can be
routed to the audio path; I haven't tried that yet. For seek, the
TDA8295's AFC reads 0 on every station in FM mode and the signal meter
(3/4) is too broad to stop on one. A read-only sweep of the band did
turn up two cx25843 registers in the reserved 0x81c-0x9c8 range (0x9b8
and 0x94f) that dip over about 0.3 MHz around each of the 18 local
stations and recover between closely spaced ones, with and without
the firmware file. Seek could be built on those, but as they are
undocumented I'd rather leave that for a follow-up.

How this was made: I used an AI coding assistant (Claude Opus 5.5) to
analyse the problem, look at the Windows driver's register writes, run
and evaluate the experiments on my card, and write the code and the
changelogs. I reviewed the changes, ran the hardware tests and am
responsible for the result; each patch carries an Assisted-by tag.

Two separate patches don't depend on this series: one (now at v2,
https://lore.kernel.org/r/20261022231728.517427-1-stealth3m@yahoo.com)
fixes "s5h1411_writereg: writereg error ... -5" when an analog open follows
closing the DVB frontend on this card, the other fixes pvrusb2 control
enumeration with V4L2_CTRL_FLAG_NEXT_COMPOUND (v4l2-ctl -l lists only the
user class controls today).

Two more patches that report the fixed FM de-emphasis (75 us with the
stereo firmware, 50 us without) through V4L2_CID_TUNE_DEEMPHASIS are
tested and ready; I'll send them as a follow-up once this series is
settled.

Changes in v2 (all from the Sashiko review of v1; no functional change
intended on the tested paths):
- 2/4 cx25840: radio keeps its own audio mode (radio_audmode, mono or
  stereo) instead of overwriting the TV audmode, so a VIDIOC_S_TUNER on
  the radio node no longer changes what TV restores in 0x809 or what
  TV's G_TUNER reports; radio audmode values other than mono are taken
  as stereo instead of being stored unchecked.
- 2/4 cx25840: set fm_stereo only after check_fw_load() succeeds, so a
  failed firmware download doesn't leave the stereo setting (0x808 =
  0xfa) in use without the stereo firmware.
- 3/4 tda8290: return -EREMOTEIO when the IF AGC read fails instead of
  computing the signal strength from an uninitialised byte.
- 4/4 pvrusb2: keep the cx25840 platform data in struct pvr2_hdw (like
  ir_init_data) instead of on the stack: the I2C core keeps the
  platform_data pointer, and cx25840_probe() reads it again if the
  driver is rebound.
- 1/4: unchanged.

Link to v1: https://lore.kernel.org/r/20261021115747.1864231-1-stealth3m@yahoo.com

Ext745 (4):
  media: cx25840: demodulate FM radio from a 5.5 MHz sound IF
  media: cx25840: FM stereo with an optional HVR-1950 audio firmware
  media: tda8290: report FM signal strength on the TDA8295
  media: pvrusb2: enable FM radio on the HVR-1950

 drivers/media/i2c/cx25840/cx25840-core.c      | 152 +++++++++++++-----
 drivers/media/i2c/cx25840/cx25840-core.h      |   9 ++
 drivers/media/i2c/cx25840/cx25840-firmware.c  |  30 +++-
 drivers/media/tuners/tda8290.c                |  15 ++
 .../media/usb/pvrusb2/pvrusb2-cx2584x-v4l.c   |  26 +++
 drivers/media/usb/pvrusb2/pvrusb2-devattr.c   |   8 +-
 drivers/media/usb/pvrusb2/pvrusb2-devattr.h   |   4 +
 .../media/usb/pvrusb2/pvrusb2-hdw-internal.h  |   2 +
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c       |  27 +++-
 include/media/drv-intf/cx25840.h              |   8 +-
 10 files changed, 230 insertions(+), 51 deletions(-)

-- 
2.53.0