Re: [PATCH v2 00/11] CODA encoder/decoder device split
Hi, Am Freitag, den 18.07.2014, 12:22 +0200 schrieb Philipp Zabel: Hi, the following patches add a few fixes and cleanups and split the coda video4linux2 device into encoder and decoder. Following the principle of least surprise, this way the format enumeration on the output and capture sides is fixed and does not change depending on whether the given instance is currently configured as encoder or decoder. Changes since v1: - Fixed [media] coda: delay coda_fill_bitstream(), taking into account [media] v4l: vb2: Fix stream start and buffer completion race. - Added Hans' acks. is there still a chance to still get this series merged for v3.17? Most of it got acked by Hans right away, and I have received no other feedback. The split into separate encoder and decoder devices (patch 08/11) is necessary for this driver to work with the GStreamer v4l2videodec element. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On Tue, 29 Jul 2014 07:37:44 +0200
Matthias Schwarzott z...@gentoo.org wrote:
On 23.07.2014 22:10, Antonio Ospite wrote:
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Hi Antonio,
I tried jacksum on the complete firmware and on parts - but it never
matched the results from the chip.
I now found out, that the crc register changes after every 32bit write
to the data register - the fw control registers do not affect it.
So I can try what crc results from writing 32bit portions of data.
But even that did not help in guessing the algorithm, because I do not
want to do 100s of experiments.
some of my experiments:
crc=0x, data=0x - crc=0x
crc=0x, data=0x0001 - crc=0x1021
crc=0x, data=0x0002 - crc=0x2042
crc=0x, data=0x0004 - crc=0x4084
crc=0x, data=0x0008 - crc=0x8108
crc=0x, data=0x0010 - crc=0x1231
Is there some systematic way to get the formula?
I don't know much about crc, but the values you are getting look like
the entries in the table in lib/crc-itu-t.c so maybe compare the crc
you are getting with the ones calculated with crc_itu_t() from
include/linux/crc-itu-t.h
I just did a quick test with jacksum, the crc-itu-t parameters can
be expressed like this:
jacksum -x -a crc:16,1021,0,false,false,0 -q 0010
and the output is the expected 0x1231 for the 0x0010 sequence.
[...]
Ciao,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] driver:gpio remove all usage of gpio_remove retval in driver
On 22/07/14 18:08, Linus Walleij wrote: On Sat, Jul 12, 2014 at 10:30 PM, abdoulaye berthe berthe...@gmail.com wrote: Heads up. Requesting ACKs for this patch or I'm atleast warning that it will be applied. We're getting rid of the return value from gpiochip_remove(). drivers/video/fbdev/via/via-gpio.c | 10 +++--- Tomi can you ACK this? Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On 07/29/2014 11:53 AM, Antonio Ospite wrote:
On Tue, 29 Jul 2014 07:37:44 +0200
Matthias Schwarzott z...@gentoo.org wrote:
On 23.07.2014 22:10, Antonio Ospite wrote:
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Hi Antonio,
I tried jacksum on the complete firmware and on parts - but it never
matched the results from the chip.
I now found out, that the crc register changes after every 32bit write
to the data register - the fw control registers do not affect it.
So I can try what crc results from writing 32bit portions of data.
But even that did not help in guessing the algorithm, because I do not
want to do 100s of experiments.
some of my experiments:
crc=0x, data=0x - crc=0x
crc=0x, data=0x0001 - crc=0x1021
crc=0x, data=0x0002 - crc=0x2042
crc=0x, data=0x0004 - crc=0x4084
crc=0x, data=0x0008 - crc=0x8108
crc=0x, data=0x0010 - crc=0x1231
Is there some systematic way to get the formula?
I don't know much about crc, but the values you are getting look like
the entries in the table in lib/crc-itu-t.c so maybe compare the crc
you are getting with the ones calculated with crc_itu_t() from
include/linux/crc-itu-t.h
I just did a quick test with jacksum, the crc-itu-t parameters can
be expressed like this:
jacksum -x -a crc:16,1021,0,false,false,0 -q 0010
and the output is the expected 0x1231 for the 0x0010 sequence.
maybe crc = crc + crc(val)
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello
I want to keep up with you with hope for friendship if you are interested. If you don't mind i will like you to write me back. I am waiting to read from you, because i have something important and urgent to discuss with you. I will also send some of my beautiful photos to you. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: s5p_mfc: remove unnecessary calling to function video_devdata()
On 23/07/14 06:06, Zhaowei Yuan wrote: Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Applied to my tree, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: s5p_mfc: Check the right pointer after allocation
On 23/07/14 06:05, Zhaowei Yuan wrote: It should be bank2_virt to be checked after dma allocation instead of dev-fw_virt_addr. This patch is not applicable to the media master branch [1]. Additionally, AFAICS dma_alloc_coherent return value should be tested for NULL, rather than for ERR_PTR() value. It seems you have some incorrect changes in your tree, which this patch depends on. [1] http://git.linuxtv.org/cgit.cgi/media_tree.git -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] s5p-jpeg/s5p-mfc updates
Hi Mauro, The following changes since commit 7f196789b3ffee243b681d3e7dab8890038db856: si2135: Declare the structs even if frontend is not enabled (2014-07-28 10:37:08 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.17 for you to fetch changes up to 42bb855f82fc4f8ddbae8d614c2c187e1d824ba8: s5p-mfc: remove unnecessary calling to function video_devdata() (2014-07-29 15:29:14 +0200) I assume patch s5p-jpeg: Document sclk-jpeg clock for Exynos3250 SoC is correct, since I didn't get any more DT mainainer's review comments. Jacek Anaszewski (8): [media] s5p-jpeg: Document sclk-jpeg clock for Exynos3250 SoC s5p-jpeg: Add support for Exynos3250 SoC s5p-jpeg: return error immediately after get_byte fails s5p-jpeg: Adjust jpeg_bound_align_image to Exynos3250 needs s5p-jpeg: fix g_selection op s5p-jpeg: Assure proper crop rectangle initialization s5p-jpeg: Prevent erroneous downscaling for Exynos3250 SoC s5p-jpeg: add chroma subsampling adjustment for Exynos3250 Zhaowei Yuan (1): s5p-mfc: remove unnecessary calling to function video_devdata() .../bindings/media/exynos-jpeg-codec.txt | 12 +- drivers/media/platform/Kconfig |5 +- drivers/media/platform/s5p-jpeg/Makefile |2 +- drivers/media/platform/s5p-jpeg/jpeg-core.c| 660 ++-- drivers/media/platform/s5p-jpeg/jpeg-core.h| 32 +- .../media/platform/s5p-jpeg/jpeg-hw-exynos3250.c | 487 +++ .../media/platform/s5p-jpeg/jpeg-hw-exynos3250.h | 60 ++ drivers/media/platform/s5p-jpeg/jpeg-regs.h| 247 +++- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 9 files changed, 1447 insertions(+), 60 deletions(-) create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c create mode 100644 drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.h -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: select default keytable based on vendor
Em Tue, 29 Jul 2014 07:45:29 +0200 Matthias Schwarzott z...@gentoo.org escreveu: On 27.07.2014 22:47, Mauro Carvalho Chehab wrote: Some vendors have their on keymap table that are used on all (or almost all) models for that vendor. So, instead of specifying the keymap table per USB ID, let's use the Vendor ID's table by default. At the end, this will mean less code to be added when newer devices for those vendors are added. I also did prepare something to add mceusb support, but with this only vendor dependant rc_map selection, it definitly is less code. Your mceusb patches work correctly for my 930C-HD (b130) and PCTV 522e devices. Thanks for testing! Btw, do you have plans to add DVB-C support to the frontend too? I think that this is the only big feature missing. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c: use correct structure type name in sizeof
From: Julia Lawall julia.law...@lip6.fr
Correct typo in the name of the type given to sizeof. Because it is the
size of a pointer that is wanted, the typo has no impact on compilation or
execution.
This problem was found using Coccinelle (http://coccinelle.lip6.fr/). The
semantic patch used can be found in message 0 of this patch series.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
index cda8388..255590f 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
@@ -227,7 +227,7 @@ static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
return 0;
vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
- sizeof(struct clock *), GFP_KERNEL);
+ sizeof(struct clk *), GFP_KERNEL);
if (vpfe_dev-clks == NULL) {
v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
return -ENOMEM;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] use correct structure type name in sizeof
These patches fix typos in the name of a type referenced in a sizeof
command. These problems are not caught by the compiler, because they have
no impact on execution - the size of a pointer is independent of the size
of the pointed value.
The semantic patch that finds these problems is shown below
(http://coccinelle.lip6.fr/). This semantic patch distinguishes between
structures that are defined in C files, and thus are expected to be visible
in only that file, and structures that are defined in header files, which
could potential be visible everywhere. This distinction seems to be
unnecessary in practice, though.
smpl
virtual after_start
@initialize:ocaml@
@@
type fl = C of string | H
let structures = Hashtbl.create 101
let restarted = ref false
let add_if_not_present _ =
if not !restarted
then
begin
restarted := true;
let it = new iteration() in
it#add_virtual_rule After_start;
it#register()
end
let hashadd str file =
let cell =
try Hashtbl.find structures str
with Not_found -
let cell = ref [] in
Hashtbl.add structures str cell;
cell in
if not (List.mem file !cell) then cell := file :: !cell
let get_file fl =
if Filename.check_suffix fl .c
then C fl
else H
@script:ocaml depends on !after_start@
@@
add_if_not_present()
@r depends on !after_start@
identifier nm;
position p;
@@
struct nm@p { ... };
@script:ocaml@
nm r.nm;
p r.p;
@@
hashadd nm (get_file (List.hd p).file)
// -
@sz depends on after_start@
identifier nm;
position p;
@@
sizeof(struct nm@p *)
@script:ocaml@
nm sz.nm;
p sz.p;
@@
try
let allowed = !(Hashtbl.find structures nm) in
if List.mem H allowed or List.mem (get_file (List.hd p).file) allowed
then ()
else print_main nm p
with Not_found - print_main nm p
/smpl
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960
Hi Philipp, On Tue, Jul 22, 2014 at 02:50:33PM +0200, Philipp Zabel wrote: The firmware-imx packages referenced in the Freescale meta-fsl-arm repository on github.com contain VPU firmware files. Their use is restricted by an EULA. For example: http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-3.0.35-4.0.0.bin This contains the files vpu_fw_imx6q.bin and vpu_fw_imx6d.bin, which can be converted into v4l-coda960-imx6q.bin and v4l-coda960-imx6dl.bin, respectively, by dropping the headers and reordering the rest. I described this for i.MX53 earlier here: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181101.html I followed the step to generate the firmware v4l-coda960-imx6q, and tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960 VPU' applied on top of it. But I got the error of 'Wrong firmwarel' as below. [2.582837] coda 204.vpu: requesting firmware 'v4l-coda960-imx6q.bin' for CODA960 [2.593344] coda 204.vpu: Firmware code revision: 0 [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: (0x), Version: 0.0.0 What am I missing here? Shawn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp with DM3730 not working?!
Am 29.07.2014 02:53, schrieb Laurent Pinchart: You're right. Maybe that's the first problem to be fixed though ;-) Michael, could you try using the official (and under development) BT.656 support code for the OMAP3 ISP driver ? I've just pushed the branch to git://linuxtv.org/pinchartl/media.git omap3isp/bt656 I will try with your official kernel and report back. Thanks, Michael -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960
Hi Shawn, On Tue, Jul 29, 2014 at 5:30 PM, Shawn Guo shawn@linaro.org wrote: Hi Philipp, On Tue, Jul 22, 2014 at 02:50:33PM +0200, Philipp Zabel wrote: The firmware-imx packages referenced in the Freescale meta-fsl-arm repository on github.com contain VPU firmware files. Their use is restricted by an EULA. For example: http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-3.0.35-4.0.0.bin This contains the files vpu_fw_imx6q.bin and vpu_fw_imx6d.bin, which can be converted into v4l-coda960-imx6q.bin and v4l-coda960-imx6dl.bin, respectively, by dropping the headers and reordering the rest. I described this for i.MX53 earlier here: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181101.html I followed the step to generate the firmware v4l-coda960-imx6q, and tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960 VPU' applied on top of it. But I got the error of 'Wrong firmwarel' as below. [2.582837] coda 204.vpu: requesting firmware 'v4l-coda960-imx6q.bin' for CODA960 [2.593344] coda 204.vpu: Firmware code revision: 0 [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: (0x), Version: 0.0.0 I just tried with the same kernel, and the above download, converted with the program in the referenced mail, and I get this: coda 204.vpu: Firmware code revision: 36350 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 2.1.9 coda 204.vpu: codec registered as /dev/video0 md5sum of /lib/firmware/v4l-coda960-imx6q.bin: af4971a37c7a3a50c99f7dfd36104c63 Note that I so far tested the kernel driver with the older firmware version 2.1.5: coda 204.vpu: Firmware code revision: 32515 coda 204.vpu: Initialized CODA960. coda 204.vpu: Firmware version: 2.1.5 md5sum of /lib/firmware/v4l-coda960-imx6q.bin: f58119103d94adcd5c2d5070d65ebd26 I was under the impression that I had obtained this version from the very same URI previously, but I am not 100% sure about that. Also there is yet another version available from http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-3.10.17-1.0.0.bin, which currently contains firmware version 3.1.1: coda 204.vpu: Firmware code revision: 46056 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 3.1.1 md5sum of /lib/firmware/v4l-coda960-imx6q.bin: 2a087c2e4043c3c3a4104765a33b12aa regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx vb2 warnings
Am 28.07.2014 um 17:27 schrieb Hans Verkuil: ... OK, I looked at it: the problem is in get_next_buf() and finish_field_prepare_next(). In get_next_buf() the driver gets a buffer from the active list and deletes it from that list. In finish_field_prepare_next() that buffer is given back to vb2 via finish_buffer(). But if you stop streaming and em28xx_stop_streaming() is called, then that buffer that is being processed isn't part of the active list anymore and so it is never given back. em28xx_stop_streaming() should give that buffer back as well, and that will keep everything in balance. The easiest solution seems to be to move the list_del() call from get_next_buf() to finish_buffer(). It seemed to work in a quick test, but I haven't looked at vbi support or corner cases. I leave that to you :-) Ok, thank you so far Hans ! I will see what I can do. Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: select default keytable based on vendor
On 29.07.2014 16:06, Mauro Carvalho Chehab wrote: Em Tue, 29 Jul 2014 07:45:29 +0200 Matthias Schwarzott z...@gentoo.org escreveu: On 27.07.2014 22:47, Mauro Carvalho Chehab wrote: Some vendors have their on keymap table that are used on all (or almost all) models for that vendor. So, instead of specifying the keymap table per USB ID, let's use the Vendor ID's table by default. At the end, this will mean less code to be added when newer devices for those vendors are added. I also did prepare something to add mceusb support, but with this only vendor dependant rc_map selection, it definitly is less code. Your mceusb patches work correctly for my 930C-HD (b130) and PCTV 522e devices. Thanks for testing! Testing IR is fast to do :) Btw, do you have plans to add DVB-C support to the frontend too? I think that this is the only big feature missing. Yes, adding DVB-C Support is my next large goal. Regards Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On 29.07.2014 13:34, Antti Palosaari wrote:
On 07/29/2014 11:53 AM, Antonio Ospite wrote:
On Tue, 29 Jul 2014 07:37:44 +0200
Matthias Schwarzott z...@gentoo.org wrote:
On 23.07.2014 22:10, Antonio Ospite wrote:
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of
output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Hi Antonio,
I tried jacksum on the complete firmware and on parts - but it never
matched the results from the chip.
I now found out, that the crc register changes after every 32bit write
to the data register - the fw control registers do not affect it.
So I can try what crc results from writing 32bit portions of data.
But even that did not help in guessing the algorithm, because I do not
want to do 100s of experiments.
some of my experiments:
crc=0x, data=0x - crc=0x
crc=0x, data=0x0001 - crc=0x1021
crc=0x, data=0x0002 - crc=0x2042
crc=0x, data=0x0004 - crc=0x4084
crc=0x, data=0x0008 - crc=0x8108
crc=0x, data=0x0010 - crc=0x1231
Is there some systematic way to get the formula?
I don't know much about crc, but the values you are getting look like
the entries in the table in lib/crc-itu-t.c so maybe compare the crc
you are getting with the ones calculated with crc_itu_t() from
include/linux/crc-itu-t.h
I just did a quick test with jacksum, the crc-itu-t parameters can
be expressed like this:
jacksum -x -a crc:16,1021,0,false,false,0 -q 0010
and the output is the expected 0x1231 for the 0x0010 sequence.
maybe crc = crc + crc(val)
It worked to apply crc_itu_t to the written data in 32bit blocks,
but starting with the last byte:
crc = crc_itu_t_byte(crc, *(data+offset+3));
crc = crc_itu_t_byte(crc, *(data+offset+2));
crc = crc_itu_t_byte(crc, *(data+offset+1));
crc = crc_itu_t_byte(crc, *(data+offset+0));
It would also have worked without knowing the crc because it is only
actively read and compared in the driver - but better to know if upload
did work.
Now I am still not sure if it is worth to change the firmware file to
now have the crc explicitly.
Counting blocks is also easy todo.
But the firmware version is not inside the data I think.
So there will still remain something to be added to the raw data.
Regards
Matthias
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On 07/29/2014 10:22 PM, Matthias Schwarzott wrote:
On 29.07.2014 13:34, Antti Palosaari wrote:
On 07/29/2014 11:53 AM, Antonio Ospite wrote:
On Tue, 29 Jul 2014 07:37:44 +0200
Matthias Schwarzott z...@gentoo.org wrote:
On 23.07.2014 22:10, Antonio Ospite wrote:
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of
output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Hi Antonio,
I tried jacksum on the complete firmware and on parts - but it never
matched the results from the chip.
I now found out, that the crc register changes after every 32bit write
to the data register - the fw control registers do not affect it.
So I can try what crc results from writing 32bit portions of data.
But even that did not help in guessing the algorithm, because I do not
want to do 100s of experiments.
some of my experiments:
crc=0x, data=0x - crc=0x
crc=0x, data=0x0001 - crc=0x1021
crc=0x, data=0x0002 - crc=0x2042
crc=0x, data=0x0004 - crc=0x4084
crc=0x, data=0x0008 - crc=0x8108
crc=0x, data=0x0010 - crc=0x1231
Is there some systematic way to get the formula?
I don't know much about crc, but the values you are getting look like
the entries in the table in lib/crc-itu-t.c so maybe compare the crc
you are getting with the ones calculated with crc_itu_t() from
include/linux/crc-itu-t.h
I just did a quick test with jacksum, the crc-itu-t parameters can
be expressed like this:
jacksum -x -a crc:16,1021,0,false,false,0 -q 0010
and the output is the expected 0x1231 for the 0x0010 sequence.
maybe crc = crc + crc(val)
It worked to apply crc_itu_t to the written data in 32bit blocks,
but starting with the last byte:
crc = crc_itu_t_byte(crc, *(data+offset+3));
crc = crc_itu_t_byte(crc, *(data+offset+2));
crc = crc_itu_t_byte(crc, *(data+offset+1));
crc = crc_itu_t_byte(crc, *(data+offset+0));
It would also have worked without knowing the crc because it is only
actively read and compared in the driver - but better to know if upload
did work.
Now I am still not sure if it is worth to change the firmware file to
now have the crc explicitly.
Counting blocks is also easy todo.
But the firmware version is not inside the data I think.
So there will still remain something to be added to the raw data.
Do you need to know whole firmware version? How did you obtain it, from
sniff? What happens if you don't tell fw version to chip at all?
Usually, almost 100%, firmware version as well all the other needed
information, is included to firmware image itself. I don't remember many
cases where special handling is needed. One (only one?) of such case is
af9013, where I resolved issues by calculating fw checksum by the
driver. IIRC chip didn't boot if there was wrong checksum for fw.
Own headers and checksums causes troubles if I someone would like to
extract different firmwares from various windows binaries to test.
If windows driver needs to know that kind of things, those are usually
found very near firmware image from the driver binary. Most often just
dump 32 bytes after firmware image and it is somewhere there. Or before
firmware image. That is because those are values are stored to same
source code file = compiler puts that stuff ~same location.
static const unsigned char firmware[] = {
0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,
0x88,0x99,0xaa,0xbb,0xcc,0xdd,0xee,0xff,
};
static const unsigned int firmware_checksum = 0x01234567;
static const unsigned int firmware_version = 0x002b;
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] [media] radio-miropcm20: fix sparse NULL pointer warning
From: Wei Yongjun yongjun_...@trendmicro.com.cn Fixes the following sparse warnings: drivers/media/radio/radio-miropcm20.c:193:33: warning: Using plain integer as NULL pointer Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn --- drivers/media/radio/radio-miropcm20.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/radio-miropcm20.c b/drivers/media/radio/radio-miropcm20.c index ac9915d..998919e 100644 --- a/drivers/media/radio/radio-miropcm20.c +++ b/drivers/media/radio/radio-miropcm20.c @@ -190,7 +190,7 @@ static int pcm20_setfreq(struct pcm20 *dev, unsigned long freq) freql = freq 0xff; freqh = freq 8; - rds_cmd(aci, RDS_RESET, 0, 0); + rds_cmd(aci, RDS_RESET, NULL, 0); return snd_aci_cmd(aci, ACI_WRITE_TUNE, freql, freqh); } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 30 04:00:19 CEST 2014 git branch: test git hash: 488046c237f3b78f91046d45662b318cd2415f64 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: v4l2: make alloction alogthim more robust and flexible
Current algothim relies on the fact that caller will align the size to PAGE_SIZE, otherwise order will be decreased to negative when remain size is less than PAGE_SIZE, it makes the function hard to be migrated. This patch sloves the hidden problem. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index adefc31..40d18aa 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf, order = get_order(size); /* Dont over allocate*/ - if ((PAGE_SIZE order) size) + if (order 0 (PAGE_SIZE order) size) order--; pages = NULL; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: v4l2: make allocation algorithm more robust and flexible
Current algorithm relies on the fact that caller will align the size to PAGE_SIZE, otherwise order will be decreased to negative when remain size is less than PAGE_SIZE, it makes the function hard to be migrated. This patch sloves the hidden problem. Signed-off-by: Zhaowei Yuan zhaowei.y...@samsung.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index adefc31..40d18aa 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf, order = get_order(size); /* Dont over allocate*/ - if ((PAGE_SIZE order) size) + if (order 0 (PAGE_SIZE order) size) order--; pages = NULL; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ddbridge -- kernel 3.15.6
Hello Rudy I use a similar card from Digital Devices with Ubuntu 14.04 and kernel 3.13.0-32-generic. Support for this card was not build into the kernel and I had to compile it myself. I had to use media_build_experimental from Mr. Endriss. http://linuxtv.org/hg/~endriss/media_build_experimental Your card should be supported with this version. Regards, Thomas Hi Rudy, What Thomas writes is absolutely correct... This is unfortunately the worst situation I've ever run across in Linux... There was a kernel driver that worked and was supported by Digital Devices. Then, from what I read, changes to how the V4L drivers have to be written was changed - Digital Devices doesn't like that and they force users to use experimental builds which are the old style. This is total rubbish imo - if this is how it was decided that the drivers have to be nowadays then adjust them. Why am I paying such a lot of money others right, these DD cards are really not cheap? Some attempts have been made by people active here to adapt the drivers and make them work in newer kernels, but so far no one has succeeded. Last attempt was in Jan 2014 iirc, since then - silence. I wish I could help out, I can code but Linux is well just a bit more difficult I guess ;-) Cheers, Bjoern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
