Implement a complete Linux kernel DVB frontend driver based on generic templates and reference hardware

[chewitt]

Summary

Create a new Linux kernel DVB frontend driver using the structure of the generic DVB frontend and software demux templates, with reference to established hardware combinations:

• ATSC: mn88436 + mxl603
• DVB-S: avl6211 + mxl603
• DVB-T: cxd2841er + ascot3 + mxl603

Reference code and architecture should be drawn from the "dvb-sucks" branch and the following directories:

• drivers/media/dvb-core/: core, demux, and frontend templates
• drivers/media/dvb-frontends/: existing frontend and tuner drivers for the above hardware

Goals

• Develop a modular, maintainable frontend driver suitable for integration into upstream Linux.
• Follow coding and documentation standards seen in dvb_frontend.c and related files.
• Ensure support for software demux patterns as implemented in dvb_demux.c and dmxdev.c.
• Use established driver pairings as practical templates for frontend+tuner initialization, I2C handling, and state management.

References

• dvb-core directory
• dvb-frontends directory
• Example drivers: cxd2841er.c, mn88443x.c, avl6211.c, mxl603.c

Acceptance Criteria

• New driver builds and loads as a kernel module.
• Driver supports initialization for at least one of the reference hardware pairings listed above.
• Conforms to the DVB subsystem's modular frontend/tuner pattern.
• Well-documented code and Kconfig entry.
• Integration tested with DVB core and demux infrastructure.

---

Partial directory listings shown; see full dvb-frontends for all drivers.

[mczerski]

Hi @chewitt , I don't have a lot of spare time but I would like to help with this topic. I have some experience with amlogic vendor kernel on CoreELEC. I managed to bring back dvb support in CoreELEC 22.

What is the current state of this topic ? I something working already ? I cas see two branches related to dvb.

I would like to start by building LibreELEC with the current state of the DVB driver, is there a branch of LibreELEC ready to build with this driver ?

[chewitt]

@mczerski I did some code archaeology a couple of years ago to see if I can cleanup (drop old Meson6/8 code) and compile the drivers used with the WeTek Play2 box against a modern kernel, and this can be found in the https://github.com/chewitt/linux/commits/dvb-sucks branch.

I can't see an LE buildsystem branch anywhere now, but all I did at the time is build an AMLGX nightly with packages/linux/package.mk pointed at one of the branch and matching defconfig changes to build the modules:

--- a/projects/Amlogic/linux/linux.aarch64.conf                                           
+++ b/projects/Amlogic/linux/linux.aarch64.conf                                           
@@ -3711,6 +3711,16 @@ CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m                                 
 # Amlogic media platform drivers                                                         
 #                                                                                        
 # CONFIG_VIDEO_MESON_GE2D is not set                                                     
+CONFIG_DVB_WETEK=m                                                                       
+CONFIG_DVB_AVL6211=m                                                                     
+CONFIG_DVB_MN99436=m                                                                     
+CONFIG_DVB_NIMDETECT=m                                                                   
+CONFIG_DVB_ASCOT3=m                                                                      
+# CONFIG_DVB_CXD2837 is not set                                                          
+CONFIG_DVB_CXD2841ER_WETEK=m                                                             
+CONFIG_MEDIA_TUNER_MXL603=m                                                              
+CONFIG_MEDIA_TUNER_MXL608=m                                                              
+CONFIG_MEDIA_TUNER_R848=m                                                                
                                                                                          
 #                                                                                        
 # Amphion drivers                                                                        
@@ -4138,7 +4148,7 @@ CONFIG_DVB_AS102_FE=m                                               
 # CONFIG_DVB_CX22700 is not set                                                          
 CONFIG_DVB_CX22702=m                                                                     
 CONFIG_DVB_CXD2820R=m                                                                    
-CONFIG_DVB_CXD2841ER=m                                                                   
+# CONFIG_DVB_CXD2841ER is not set                                                        
 CONFIG_DVB_DIB3000MB=m                                                                   
 CONFIG_DVB_DIB3000MC=m                                                                   
 CONFIG_DVB_DIB7000M=m  

^ The upstream CONFIG_DVB_CXD2841ER and CONFIG_DVB_CXD2841ER_WETEK clash.

In the resulting image the modules could be loaded manually, which was a miracle given my general lack of coding knowledge, but beyond that nothing happened; other than sometime last year? seeing if things could be rebased, which is why the second branch https://github.com/chewitt/linux/commits/dvb-sucks-more exists. I'm not aware of any difference between the two branches other than dvb-sucks-more being a newer kernel.

The original driver code that you see hacked into vendor kernel images builds some kind of monolithic driver with token refs to device-tree (as was normal in the Linux 3.10 era) whereas the modern kernel needs each driver to be fully independent with the inter-driver plumbing entirely described in device-tree not in code. The upstream kernel also lacks drivers for Amlogic's hardware demux IP, which the current drivers have some assumptions around. I do see generic demux support of some kind and assume this is perhaps what's used with USB devices that also lack hardware demuxing, so perhaps the tuner/demod combos could be (re)wired up to that instead (or someone needs to author the demux driver), but at that point I'm deeply ignorant of how things should be done.

I'm more of a project managing distro maintainer than software developer and that was all done long before AI tools came on the scene. I've semi-recently thought about revisiting the topic to see what current Claude Opus might be able to come up with; but unless you give it a really accurate prompt it's likely to come up with some BS code that looks very convincing but does entirely the wrong thing; and although I'm not completely dumb, I'll struggle to tell the difference :)

To mildly complicate things: where I live local TV is an encrypted IPTV feed and I am unable to use any kind of DVB hardware; although I do have a WeTek Play2 (S905) with a full set of the removable modules, and the DVB-T box used by O2 Czech (S905D) for a while.

Around the time I did the original kernel module experiments I also reached out to the Availink devs and persuaded them to release their sources to https://github.com/availink with a GPLv2 license, along with some basic documentation. From those discussions I'm aware they have newer/better versions of some drivers, but the provenance of driver code is often poor. Most of the drivers in 3.10 era BSP dumps have no license marking, and then the 'newer' 3.14 sources on GitHub are the same code but someone (unknown) slapped a GPL license header on the file. As the long-term goal must always be to upstream drivers for the benefit of all there might be some challenges there; although I think "ask for forgiveness not permission" and pleading ignorance (not hard for me) is the way forwards on that topic.

NB: The #libreelec channel on Libera.Chat IRC is linked to the LibreELEC team Slack instance if you want to chat about things in person (I'm GMT+4). I'll be happy to support in any way that I can, but those ways will be rather limited :)

[mczerski]

Ok thanks, unfortunately the crucial part is to port the demux driver. Those frontend chips are connected to TS input which is a part of the hw demux. So without this driver there is no way to use dvb frontend drivers.

I will give a try with Al and see what we come up with ;) but I think it would be a huge amount of work ...

[chewitt]

Claude Opus managed to author a Rockchip hardware deinterlace (IEP2) driver for me in ~2 attempts and about 45 mins total a few weeks ago, so it's not impossible that AI has moments of brilliance. The Rockchip BSP codebase is a lot prettier and closer to modern Linux than Amlogic's homebrew DRM though. NB: I will go ask Amlogic devs if the demux IP was licensed, but it's probably from their AMRISC homebrew days.

[mczerski]

Just to let You know, I managed to port the demux driver from 5.15 to mainline 6.16 (LE12.2) and hardwired it with cxd2878 + mxl603 frontend drivers. It works on my s905d box (gtmedia gtt-2). Fortunately it did not required a lot of changes but it required some dirty hacks :) But it is a very good starting point in my opinion.

[chewitt]

@mczerski please fork https://github.com/torvalds/linux to your account and push a branch with the changes as it will be easier to look at commits there than the patch file(s) in your LE repo. It doesn't matter how hacky and disorganised things are to start with; Rome wasn't built in a day :)

[chewitt]

@mczerski I've picked the files from your all-in-one patch into the dvb-7.0.y branch in this repo. I've done a little cleanup to break the dts into separate commits for adding the base device, then addition of VFD, then addition of DVB in prep, as this is likely to be the sequence for sending things upstream. I also renamed the dts to align with the preferred vendor-name format and added the missing bindings changes. That was the end of all the familiar/easy stuff that I'm good at :)

I've then done some minor renaming of files to meson-demux and I've started to run files through clang-format to see what changes would be made, and to make formatting a little more consistent. After comparing files again I can see MxL603/608 are 99% the same so could be refactored into a single MxL60x driver. Similar refactoring(s) should be possible with some of the other drivers; perhaps a task for Claude. In theory these changes are entirely cosmetic, but I didn't compile test anything yet.

The demux driver looks like a huge/compliacted ifdef mess (typical BSP code) but how that might/could be refactored or improved upon is rather above my knowledge and skills level. One of the obvious cleanups is switching to the upstream SoC info file in drivers/soc/amlogic/meson-gx-socinfo.c so that cpu_version.c can be dropped.

[chewitt]

Some info on Ascot2e vs Ascot3:

Here's a detailed comparison. The ascot3 driver is clearly based on ascot2e (it says so in the header) but has several noteworthy differences — it's not a pure copy-paste rename.

Structural / API differences

1. Simpler config — no tuner callback (ascot3.h)

• ascot3_config drops set_tuner_priv and set_tuner_callback. The ascot2e config had these to notify a parent driver which tuner is active; ascot3 doesn't need them.
• Correspondingly, ascot3_priv (line 29-34) has no set_tuner_data/set_tuner fields, and set_params never calls priv->set_tuner().

2. No #if IS_REACHABLE guard in the header (ascot3.h:31)

• ascot2e.h properly provides a stub when CONFIG_DVB_ASCOT2E is disabled. ascot3.h unconditionally declares ascot3_attach as extern — this is a quality gap; it'll fail to link if someone includes the header without building the module.

3. EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL (ascot3.c:566 vs ascot2e.c:536)

• ascot2e uses EXPORT_SYMBOL_GPL, ascot3 uses EXPORT_SYMBOL. This is a licensing choice difference.

4. I2C address handling (ascot3.c:480 vs ascot2e.c:483)

• ascot2e does config->i2c_address >> 1 (converts 8-bit to 7-bit address)
• ascot3 uses config->i2c_address directly — the caller must pass the 7-bit address.

Hardware register differences (the real meat)

5. Completely different register map in set_params

• ascot2e writes to registers 0x05, 0x06–0x0F, 0x45–0x47, 0x49–0x4A, 0x0C, 0x03–0x04, 0x10–0x14
• ascot3 writes to registers 0x74, 0x87–0x88, 0x91–0x92, 0x9C–0x9D, 0x5E–0x66, 0x68–0x78
• This is a fundamentally different chip — different register offsets, different initialization sequences.

6. Different power save sequences

• ascot2e: writes 0x14/0x15 + reg 0x50
• ascot3: writes 0x67, 0x74, 0x5E–0x60, 0x88, 0x87 — completely different register set with additional loop-through and IF output disable steps.

7. Different band settings structure

• ascot2e_band_sett has 10 fields: if_out_sel, agc_sel, mix_oll, rf_gain, if_bpf_gc, fif_offset, bw_offset, bw, rf_oldet, if_bpf_f0
• ascot3_band_sett has 16 fields: adds outlmt, rfovld_det_lv1_vl/vh/u, ifovld_det_lv_vl/vh/u, is_lowerlocal; drops mix_oll, rf_oldet, agc_sel, if_out_sel (the last
  two are moved into the settings table but handled differently)

8. Chip detection in ascot3_attach (ascot3.c:487-492)

• ascot3 reads register 0x7F and checks the chip ID (0xC0 or 0xD0). ascot2e does no chip detection at all.

9. Much more complex initialization (ascot3_attach)

• ascot3 writes a 20-byte burst to 0x81, does VCO calibration (reads 0x19, writes 0x95), sets crystal load capacitance (0x80), etc. ascot2e's init is much simpler (4 bytes to 0x01, 3 bytes to 0x22, then a few single-register writes).

10. ascot3_init() is a no-op (line 237)

• ascot2e's init calls leave_power_save; ascot3's init does nothing. There's no ascot3_leave_power_save function at all — the wake-up is done inline within set_params.

11. I2C gate control in sleep

• ascot3's sleep wraps the power-save call with i2c_gate_ctrl open/close. ascot2e's sleep does not.

Minor differences

• MAX_WRITE_REGSIZE is 32 in ascot3 vs 10 in ascot2e (needed for the 20-byte burst writes)
• ascot3 drops the ascot2e_i2c_debug helper and the debug call in write_regs/read_regs
• ascot3's write_reg passes &val directly instead of using a temp variable (ascot2e had a workaround for a GCC bug)
• Size check in write_regs uses >= instead of > (off-by-one fix)
• ascot3's get_tv_system debug print still says "ASCOT2E" — looks like a copy-paste bug on line 304

Verdict

This is not a trivial duplication. While the driver skeleton (I2C read/write helpers, get_tv_system logic, dvb_tuner_ops structure) is clearly copied from ascot2e, the register map, initialization sequence, power management, tuning procedure, and band settings are substantially different — consistent with this being a genuinely different (newer generation) tuner chip. The copy-paste debug string "ASCOT2E" on line 304 of ascot3.c is a bug worth fixing.

[chewitt]

I've pushed some wider changes and fixes for compile issues into my branch. It get me to the point where I can modprobe the (newly renamed) meson_demux driver and e.g. nimdetect on the WeTek Play2 (with the DVB-T module) but there's no dvb-frontend device, and I've no clue what I'm doing now :)

WP2:~ # lsmod | sort
8021q                  65536  0
Module                  Size  Used by
ascot3                 24576  1 nimdetect
avl6211                61440  1 nimdetect
bluetooth            1777664  25 btrtl,btqca,hci_uart,btbcm
brcmfmac              876544  1 brcmfmac_wcc
brcmfmac_wcc           12288  0
brcmutil               32768  1 brcmfmac
btbcm                  32768  1 hci_uart
btqca                  53248  1 hci_uart
btrtl                  61440  1 hci_uart
cfg80211             1171456  1 brcmfmac
crc_ccitt              12288  1 hci_uart
cxd2841er_wetek       126976  1 nimdetect
drm_shmem_helper       53248  1 lima
ecc                    69632  1 ecdh_generic
ecdh_generic           16384  2 bluetooth
fuse                  405504  1
governor_simpleondemand    12288  0
gpio_keys_polled       20480  0
hci_uart              233472  0
ir_nec_decoder         16384  0
lima                  131072  3
meson_demux           327680  0
meson_ir               20480  0
meson_vdec            196608  0
mn88436                24576  1 nimdetect
mxl603                 12288  1 nimdetect
mxl60x                 28672  1 mxl603
nfnetlink              28672  1
nimdetect              16384  0
pkcs8_key_parser       12288  0
rc_wetek_play2         12288  0
rfkill                 53248  5 bluetooth,cfg80211
rtc_meson_vrtc         20480  1

[mczerski]

@chewitt I pushed my commits to https://github.com/mczerski/linux/tree/amlogic-dvb

My main focus is on the demux driver. Besides the code mess there are couple of fundamental issues:

• cpu_version as You mentioned, currently it is hardcoded to GXL. I think that the better approach here would be to use struct of_device_id and of_device_get_match_data. then there could be dts nodes lile amlogic,meson-gxl-demux or amlogic,meson-sm1-demux
• register maps, currently it is very hacky. There is a couple of register address spaces. For each of them there should be separate functions for writing / reading registers so each one would use differnet base address. Of caurse address spaces should be defined in dts
• dvb frontend registration - with this I have the biggest problem. To register a dvb frontend you need a dvb_adapter which is supplied by the demux driver and a dvb_frontend which is supplied by a demod driver. In the vendor kernel there was other module called dvb-extern for this purpose, but it is 10x bigger mes that the demux code ... and still it was not so flexible. Of course there is always a solution to write special code for each box to register a frontend but it will be not practical. Making things generic is not trivial on the other hand, there is a lot of combinations to take into account (like one demod for each TS input, one demod for two TS inputs, one demod and two tuners).

[mczerski]

I've pushed some wider changes and fixes for compile issues into my branch. It get me to the point where I can modprobe the (newly renamed) meson_demux driver and e.g. nimdetect on the WeTek Play2 (with the DVB-T module) but there's no dvb-frontend device, and I've no clue what I'm doing now :)

is there dvb adapter device (/dev/dvb/adapter0/demux?) ?
the /dev/dvb/adapter0/frontend0 device should come up after successfull call to dvb_register_frontend.
Did you checked dmesg logs ?

[chewitt]

Claude and I (mostly Claude) have managed to come up with something that appears to work!

See https://paste.libreelec.tv/moving-lab.log and below is from Tvheadend on an LE13 image:

Running a DVB-T scan in Tvheadend fails, but as the UAE no longer has terrestrial TV broadcasts (and no aerial exists in the apartment) that's an expected result. I also have the DVB-S module for WeTek Play2 and will start poking that next, but the building I'm living in doesn't allow residents to errect Satellite dishes (else it would be covered in them) and our local TV is done through a DRM infested IPTV platform, so the final step of testing Claude's labours isn't going to be possible :(

I also want to go back and cleanup dead code from the branch; the WeTek cxd2841er driver and nimdetect drivers are no longer used. The cxd2841er_wetek one was almost identical to the upstream one so I've switched to the upstream one. I've also refactored MxL603/608 into a modular driver as those were mostly identical too.

I also need to reinstate support for the cxd2878+mxl603 combo you have as Claude removed your hardcoding hacks. I have an S905D box with another DVB-T tuner around to experiment with too.

[mczerski]

there are errors in the log (second line):

Mar 24 10:58:49 WP2 tvheadend[1002]: subscription: 0001: "scan" subscribing to mux "602MHz", weight: 5, adapter: "Sony CXD2837ER DVB-T/T2/C demodulator #0 : DVB-T #0", network: "DVB-T Network", service: "Raw PID Subscription"
Mar 24 10:58:49 WP2 kernel: i2c i2c-0: I2C rw failed=-6 addr=60 reg=74

The ascot3 driver attaches properly but then it cannot communicate with the tuner during tuning.
I suppose this is due:

	if ((priv->flags & CXD2841ER_USE_GATECTRL) && fe->ops.i2c_gate_ctrl)
		fe->ops.i2c_gate_ctrl(fe, 1);
	if (fe->ops.tuner_ops.set_params)
		fe->ops.tuner_ops.set_params(fe);
	if ((priv->flags & CXD2841ER_USE_GATECTRL) && fe->ops.i2c_gate_ctrl)
		fe->ops.i2c_gate_ctrl(fe, 0);

CXD2841ER_USE_GATECTRL should be passed to te cxd2841 config to enable i2c gate control. The tuner is behind the demod chip on the i2c bus and the demod chip is gating the i2c signals to it (i2c line goes out from the cpu and goes in into the demod, then on the other pins of the demod chip another set of i2c lines goes out and goes into the tuner chip). I wonder why such desing :) maybe to reduce digital noise at the tuner chip ?

[chewitt]

This patch a502b32 seems to have cleared up the error? https://paste.libreelec.tv/bright-mustang.log .. scans still fail of course, because there's no antenna attached :)