History log of /linux-master/drivers/media/test-drivers/vidtv/vidtv_s302m.c
Revision Date Author Comments
# 298cf3df 08-Mar-2022 Yihao Han <hanyihao@vivo.com>

media: vidtv: use vfree() for memory allocated with vzalloc()

It is allocated with vzalloc(), the corresponding release function
should not be kfree(), use vfree() instead.

Generated by: scripts/coccinelle/api/kfree_mismatch.cocci

Signed-off-by: Yihao Han <hanyihao@vivo.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>


# e6a21a14 13-Jan-2022 Jiasheng Jiang <jiasheng@iscas.ac.cn>

media: vidtv: Check for null return of vzalloc

As the possible failure of the vzalloc(), e->encoder_buf might be NULL.
Therefore, it should be better to check it in order
to guarantee the success of the initialization.
If fails, we need to free not only 'e' but also 'e->name'.
Also, if the allocation for ctx fails, we need to free 'e->encoder_buf'
else.

Fixes: f90cf6079bf6 ("media: vidtv: add a bridge driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>


# 3d1387b3 07-Dec-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix some warnings

As reported by sparse:

drivers/media/test-drivers/vidtv/vidtv_ts.h:47:47: warning: array of flexible structures
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54: warning: incorrect type in argument 3 (different base types)
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54: expected unsigned short [usertype] service_id
drivers/media/test-drivers/vidtv/vidtv_channel.c:458:54: got restricted __be16 [usertype] service_id
drivers/media/test-drivers/vidtv/vidtv_s302m.c:471 vidtv_s302m_encoder_init() warn: possible memory leak of 'e'

Address such warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# a8bd461c 22-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: do some cleanups at the driver

Do some cleanups at the coding style of the driver:
- remove "inline" declarations;
- use reverse xmas-tree for local var declarations;
- Adjust some indent to avoid breaking 80-cols;
- Cleanup some comments.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 0d271a79 19-Nov-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix some notes at the tone generator

The sheet music used to generate the tones had a few
polyphonic notes. Due to that, its conversion to a
tones sequence had a few errors.

Also, due to a bug at the tone generator, it was missing
the pause at the initial compass.

Fix them.

While here, reduce the compass to 100bpm.

The music was converted from a Music XML file using
this small script:

<snip>
my $count = 0;
my $silent = 0;
my $note;
my $octave;
print "\t";
while (<>) {
$note = $1 if (m,\<step\>(.*)\</step\>,);
$octave = "_$1" if (m,\<octave\>(.*)\</octave\>,);
if (m,\<alter\>1\</alter\>,) {
$note .= "S";
$sharp = 1;
}
if (m,\<rest/\>,) {
$note = "SILENT";
$silent = 1;
}
if (m,\<duration\>(.*)\</duration\>,) {
printf "{ NOTE_${note}${octave}, %d},", $1 * 128 / 480;
$count++;
if ($silent || $count >= 3) {
print "\n\t";
$count = 0;
$silent = 0;
} else {
print " ";
print " " if (!$sharp);
}
$sharp = 0;
$note = "";
$octave = "";
};
};
print "\n";
</snip>

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# ab6bad0a 19-Nov-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix the tone generator logic

The tone generator logic were repeating the song after the
first silent. There's also a wrong logic at the note
offset calculus, which may create some noise.

Fix it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# af66e03e 19-Nov-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix the name of the program

While the original plan was to use the first movement of
the 5th Symphony, it was opted to use the Für Elise song,
instead.

Fix it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 3be80379 21-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: add error checks

Currently, there are not checks if something gets bad during
memory allocation: it will simply use NULL pointers and
crash.

Add error path at the logic which allocates memory for the
MPEG-TS generator code, propagating the errors up to the
vidtv_bridge. Now, if something wents bad, start_streaming
will return an error that userspace can detect:

ERROR DMX_SET_PES_FILTER failed (PID = 0x2000): 12 Cannot allocate memory

and the driver doesn't crash.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 8922e393 21-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: reorganize includes

- Place the includes on alphabetical order;
- get rid of asm/byteorder.h;
- add bug.h at vidtv_s302m.c, as it is needed by
inux/fixp-arith.h

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 99b99d13 31-Oct-2020 Daniel W. S. Almeida <dwlsalmeida@gmail.com>

media: vidtv: Move s302m specific fields into encoder context

A few fields used only by the tone generator in the s302m encoder
are stored in struct vidtv_encoder. Move them into
struct vidtv_s302m_ctx instead. While we are at it: fix a
checkpatch warning for long lines.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 37b288f5 16-Sep-2020 Daniel W. S. Almeida <dwlsalmeida@gmail.com>

media: vidtv: fix build on 32bit architectures

Fix the following error for builds on 32bit architectures:

ERROR: modpost: "__udivdi3"
[drivers/media/test-drivers/vidtv/dvb-vidtv-bridge.ko] undefined!

Which is due to 64bit divisions that did not go through the helpers
in linux/math64.h

As vidtv_mux_check_mux_rate was not operational in its current form,
drop the entire function while it is not fixed properly.

For now, call vidtv_mux_pad_with_nulls with a constant number of packets
to avoid warnings due to unused functions when building this driver.

The 64bit division used in the s302m is not needed, remove them and use
a fixed number of frames and a constant PTS increment instead.

Fixes: f90cf6079bf67988 ("media: vidtv: add a bridge driver")
Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# c5d83ba2 15-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: Add a music instead of playing a single tone

Keep playing a single tone is not too nice, and prevents
checking some weird things.

So, instead, implement a simple tone generator, changing
the code to play a public domain song (5th Symphony of
Beethoven), using sinusoidal waves.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# c2a9baf9 15-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: get rid of its own sinusoidal waveform

Instead, use the code from linux/fixp-arith.h.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# a6abe2f3 12-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: remove a wrong endiannes check from s302m generator

The code there is already doing the right thing, as it uses
value & 0xff, value & 0xff00, which already ensures the
expected endiannes.

So, it doesn't make any sense to touch the order depending on
the CPU endiannes.

Yet, as pointed by Daniel at the mailing list:
https://lore.kernel.org/linux-media/e614351c-215c-c048-52af-7c200b164f41@xs4all.nl/T/#m8d221684a151833966359c2ed8bdce0f0ee4e5fd

The reverse code is needed by the decoder. So, keep it
no matter the endiannes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# 2e2fa2c5 12-Sep-2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidtv: fix 32-bit warnings

There are several warnings produced when the driver is built
for 32-bit archs. Solve them.

Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>


# f90cf607 21-Aug-2020 Daniel W. S. Almeida <dwlsalmeida@gmail.com>

media: vidtv: add a bridge driver

Digital TV devices consist of several independent hardware components
which are controlled by different drivers.
Each media device is controlled by a group of cooperating drivers with the
bridge driver as the main driver.

This patch adds a bridge driver for the Virtual Digital TV driver [vidtv].

The bridge driver binds to the other drivers, that is, vidtv_tuner and
vidtv_demod and implements the digital demux logic, providing userspace
with a MPEG Transport Stream.

The MPEG related code is split in the following way:

- vidtv_ts: code to work with MPEG TS packets, such as TS headers,
adaptation fields, PCR packets and NULL packets.

- vidtv_psi: this is the PSI generator.
PSI packets contain general information about a MPEG Transport Stream.
A PSI generator is needed so userspace apps can retrieve information
about the Transport Stream and eventually tune into a (dummy) channel.

Because the generator is implemented in a separate file, it can be
reused elsewhere in the media subsystem.

Currently vidtv supports working with 3 PSI tables:
PAT, PMT and SDT.

- vidtv_pes: implements the PES logic to convert encoder data into
MPEG TS packets. These can then be fed into a TS multiplexer and
eventually into userspace.

- vidtv_s302m: implements a S302M encoder to make it possible to
insert PCM audio data in the generated MPEG Transport Stream.

This shall enable passing an audio signal into userspace so it can be
decoded and played by media software.

- vidtv_channels: Implements a 'channel' abstraction

When vidtv boots, it will create some hardcoded channels:

Their services will be concatenated to populate the SDT.
Their programs will be concatenated to populate the PAT
For each program in the PAT, a PMT section will be created
The PMT section for a channel will be assigned its streams.
Every stream will have its corresponding encoder polled to produce TS
packets
These packets may be interleaved by the mux and then delivered to the
bridge

- vidtv_mux - Implements a MPEG TS mux, loosely based on the ffmpeg
implementation

The multiplexer is responsible for polling encoders,
interleaving packets, padding the resulting stream with NULL packets if
necessary and then delivering the resulting TS packets to the bridge
driver so it can feed the demux.

Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>