diff options
| author | Mauro Carvalho Chehab | 2020-09-13 07:31:08 +0200 |
|---|---|---|
| committer | Mauro Carvalho Chehab | 2020-09-14 15:59:49 +0200 |
| commit | a6abe2f392163286deba863f56906c3b031a926a (patch) | |
| tree | 160c6ea91c799fb0201f4d2673ba0f49dac871d8 | |
| parent | 1cb23db97ac024a707d34ab321234145807d9f58 (diff) | |
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>
| -rw-r--r-- | drivers/media/test-drivers/vidtv/vidtv_s302m.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.c b/drivers/media/test-drivers/vidtv/vidtv_s302m.c index 5ae2ede951eb..f8049cdf564a 100644 --- a/drivers/media/test-drivers/vidtv/vidtv_s302m.c +++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.c @@ -352,13 +352,11 @@ static u32 vidtv_s302m_write_frame(struct vidtv_encoder *e, f.data[3] = (sample & 0x0FF0) >> 4; f.data[4] = (sample & 0xF000) >> 12; - #ifdef __LITTLE_ENDIAN f.data[0] = reverse[f.data[0]]; f.data[1] = reverse[f.data[1]]; f.data[2] = reverse[f.data[2]]; f.data[3] = reverse[f.data[3]]; f.data[4] = reverse[f.data[4]]; - #endif nbytes += vidtv_memcpy(e->encoder_buf, e->encoder_buf_offset, |