ddbridge: m4: fix ISDB-S TSID handling

[tomiy-0x62]

Summary

This PR fixes ISDB-S DTV_STREAM_ID handling for Max M4/Max M2.

Currently, ddbridge-m4.c passes a valid 16-bit ISDB-S DTV_STREAM_ID to the MCI firmware as a relative stream number. However, according to the Linux DVB API, the valid DTV_STREAM_ID range for ISDB is 1..65535, and userspace applications pass the ISDB-S Transport Stream ID through this property.

The Max M4 MCI API supports both modes:

struct isdbs_search {
        u8   flags;  /* Bit 0:  0 = TSID is Transport Stream ID, 1 = TSID is relative stream number */
        ...
        u16  tsid;
};

However, the current code does this:

cmd.isdbs_search.flags = (p->stream_id & 0xffff0000) ? 0 : 1;
cmd.isdbs_search.tsid = p->stream_id;

For normal ISDB-S TSIDs such as 0x4090, 0x4092, 0x40f1, 0x40f2, or 0x48f3, the upper 16 bits are zero. Therefore, flags becomes 1, causing the firmware to interpret the value as a relative stream number instead of a Transport Stream ID.

This PR changes ISDB-S handling so that a valid DTV_STREAM_ID is passed to the MCI firmware as a Transport Stream ID.

Background

I observed that ISDB-S tuning on DD Max M4/DD Max M2 selected the wrong transport stream when using DTV_STREAM_ID.

For example, userspace requested the following TSIDs:

BS09_0 -> 0x4090 / 16528
BS09_1 -> 0x4092 / 16530
BS15_0 -> 0x40f1 / 16625
BS15_1 -> 0x40f2 / 16626
BS15_2 -> 0x48f3 / 18675

With the current driver, the actual output was:

BS09_0 -> TSID 16528
BS09_1 -> PAT not found
BS15_0 -> TSID 16626
BS15_1 -> TSID 18675
BS15_2 -> PAT not found

This behavior matches the lower bits of the TSID being interpreted as a relative stream number:

0x4090 -> relative stream 0 -> TSID 16528
0x4092 -> relative stream 2 -> no valid stream on BS09
0x40f1 -> relative stream 1 -> TSID 16626
0x40f2 -> relative stream 2 -> TSID 18675
0x48f3 -> relative stream 3 -> no valid stream on BS15

Verification

I added a temporary debug print just before ddb_mci_cmd() in search_isdbs():

pr_info("M4 ISDBS PATCH TEST: p_stream_id=0x%x flags=%u tsid=0x%x freq=%u tuner=%u demod=%u output=%u\n",
        p->stream_id,
        cmd.isdbs_search.flags,
        cmd.isdbs_search.tsid,
        cmd.isdbs_search.frequency,
        cmd.tuner,
        cmd.demod,
        cmd.output);

After applying this fix, the log showed that the Transport Stream ID mode was used:

M4 ISDBS PATCH TEST: p_stream_id=0x4090 flags=0 tsid=0x4090 freq=1202920000 tuner=1 demod=1 output=1
M4 ISDBS PATCH TEST: p_stream_id=0x4092 flags=0 tsid=0x4092 freq=1202920000 tuner=1 demod=1 output=1
M4 ISDBS PATCH TEST: p_stream_id=0x40f1 flags=0 tsid=0x40f1 freq=1318000000 tuner=1 demod=1 output=1
M4 ISDBS PATCH TEST: p_stream_id=0x40f2 flags=0 tsid=0x40f2 freq=1318000000 tuner=1 demod=1 output=1
M4 ISDBS PATCH TEST: p_stream_id=0x48f3 flags=0 tsid=0x48f3 freq=1318000000 tuner=1 demod=1 output=1

The resulting transport streams were then selected correctly:

BS09_0 -> transport_stream_id: 16528
programs: [(0, 16), (211, 257)]

BS09_1 -> transport_stream_id: 16530
programs: [(0, 16), (222, 496)]

BS15_0 -> transport_stream_id: 16625
programs: [(0, 16), (101, 496), (102, 752), (700, 4336), (701, 4592), (707, 6128), (929, 1793)]

BS15_1 -> transport_stream_id: 16626
programs: [(0, 16), (201, 1025), (800, 1185)]

BS15_2 -> transport_stream_id: 18675
programs: [(0, 16), (200, 1025)]

Compatibility notes

This changes the behavior for users who rely on the current dddvb-specific behavior by setting ISDB-S DTV_STREAM_ID / STREAM_ID to relative stream numbers such as 0, 1, or 2.

However, according to the Linux DVB API, the valid DTV_STREAM_ID range for ISDB is 1..65535, and values outside the valid range disable filtering. Therefore, relative stream numbers are not valid Linux DVB API DTV_STREAM_ID values for ISDB-S.

Userspace applications such as recisdb-rs and dvbv5-zap pass actual ISDB-S Transport Stream IDs through DTV_STREAM_ID, so this change makes the driver behavior consistent with the Linux DVB API.

Notes

This PR only changes search_isdbs().

search_isdbc() has similar-looking logic, but I have not tested ISDB-C behavior, so this PR intentionally leaves ISDB-C unchanged.