NPE with atmel-isc when using the ov5640 driver
Hi,
Apologies if this is the wrong mailing list and if so could you advise
me on the correct one.
I'm trying to use the OmniVision ov5640 camera sensor with the ATMEL
SAMA5D2 using it's Image Sensor Controller (ISC). I've seen a link
where they have this controller working with the ov7670 and ov7740.
But when I try and use with the OV5640 I get a NULL pointer
dereference on boot. After debugging I found that it was due to the
atmel ISC driver assuming that isc->raw_fmt would be set. It looks
like it should be set in isc_formats_init but the OV5640 doesn't have
any formats that match the formats in ISC where FMT_FLAG_RAW_FORMAT is
set and hence isc->raw_fmt is NULL.
In the OV5640 driver it has the following list
static const struct ov5640_pixfmt ov5640_formats[] = {
{ MEDIA_BUS_FMT_JPEG_1X8, V4L2_COLORSPACE_JPEG, },
{ MEDIA_BUS_FMT_UYVY8_2X8, V4L2_COLORSPACE_SRGB, },
{ MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_SRGB, },
{ MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, },
{ MEDIA_BUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB, },
};
and ISC matches MEDIA_BUS_FMT_YUYV8_2X8
{
.fourcc = V4L2_PIX_FMT_YUYV,
.mbus_code = MEDIA_BUS_FMT_YUYV8_2X8,
.flags = FMT_FLAG_FROM_CONTROLLER |
FMT_FLAG_FROM_SENSOR,
.bpp = 16,
},
but that seems about all it does match. Then in the ISC driver there
are quite a few cases where sensor_is_preferred is called but it goes
down the RAW format case
e.g.
if (sensor_is_preferred(isc_fmt))
fse.code = isc_fmt->mbus_code;
else
fse.code = isc->raw_fmt->mbus_code;
would run fse.code = isc->raw_fmt->mbus_code; and raise a NPE. I
debugged sensor_is_preferred and it was because isc_fmt->sd_support is
false.
I notice that the ov7760 driver matches a format that has
FMT_FLAG_RAW_FROM_SENSOR so this is probably why it works.
My question is should the ov5640 driver be modified to include a
format where FMT_FLAG_RAW_FROM_SENSOR is set, or should the Atmel ISC
driver be modified to handle drivers where there is no match for a Raw
Format?
Many Thanks in Advance,
Martin.
Re: [RFC 4/4] dt-bindings: media: add Amlogic Meson Video Decoder Bindings
Hi Maxime,
many thanks for your work!
On Wed, Aug 1, 2018 at 9:34 PM Maxime Jourdan wrote:
>
> Add documentation for the meson vdec dts node.
>
> Signed-off-by: Maxime Jourdan
> ---
> .../bindings/media/amlogic,meson-vdec.txt | 60 +++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/amlogic,meson-vdec.txt
>
> diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-vdec.txt
> b/Documentation/devicetree/bindings/media/amlogic,meson-vdec.txt
> new file mode 100644
> index ..120b135e6bb5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/amlogic,meson-vdec.txt
> @@ -0,0 +1,60 @@
> +Amlogic Meson Video Decoder
> +
> +
> +The VDEC IP is composed of the following blocks :
> +
> +- ESPARSER is a bitstream parser that outputs to a VIFIFO. Further VDEC
> blocks
> +then feed from this VIFIFO.
> +- VDEC_1 can decode MPEG-1, MPEG-2, MPEG-4 part 2, H.263, H.264.
> +- VDEC_2 is used as a helper for corner cases like H.264 4K on older SoCs.
> +It is not handled by this driver.
is it currently not handled or will it never be?
> +- VDEC_HCODEC is the H.264 encoding block. It is not handled by this driver.
> +- VDEC_HEVC can decode HEVC and VP9.
> +
> +Device Tree Bindings:
> +-
> +
> +VDEC: Video Decoder
> +--
> +
> +Required properties:
> +- compatible: value should be different for each SoC family as :
> + - GXBB (S905) : "amlogic,meson-gxbb-vdec"
> + - GXL (S905X, S905D) : "amlogic,meson-gxl-vdec"
> + - GXM (S912) : "amlogic,meson-gxm-vdec"
> +- reg: base address and size of he following memory-mapped regions :
> + - dos
> + - esparser
> + - dmc
> +- reg-names: should contain the names of the previous memory regions
any reason why you are not using the DMC syscon (as added in your
patch "dt-bindings: soc: amlogic: add meson-canvas documentation")
instead of mapping the DMC region again?
> +- interrupts: should contain the vdec and esparser IRQs.
are these two IRQs the "currently supported" ones or are there more
for the whole IP block (but just not implemented yet)?
> +- clocks: should contain the following clocks :
> + - dos_parser
> + - dos
> + - vdec_1
> + - vdec_hevc
> +- clock-names: should contain the names of the previous clocks
> +- resets: should contain the parser reset.
> +- reset-names: should be "esparser".
> +
> +Example:
> +
> +vdec: video-decoder@0xd005 {
> + compatible = "amlogic,meson-gxbb-vdec";
> + reg = <0x0 0xc882 0x0 0x1
> + 0x0 0xc110a580 0x0 0xe4
> + 0x0 0xc8838000 0x0 0x60>;
AFAIK the "correct" format is (just like you've done for the clocks below):
reg = <0x0 0xc882 0x0 0x1>,
<0x0 0xc110a580 0x0 0xe4>,
<0x0 0xc8838000 0x0 0x60>;
> + reg-names = "dos", "esparser", "dmc";
> +
> + interrupts = + GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
AFAIK the "correct" format is (just like you've done for the clocks below):
interrupts = ,
;
> + interrupt-names = "vdec", "esparser";
> +
> + amlogic,ao-sysctrl = <_AO>;
this is not documented above - is it needed?
Regards
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-August/008034.html
Webcam produces error on Dell XPS 9370, but seems to work
Using my webcom on my Dell XPS 9370, running latest Debian buster/sid produces a error in dmesg when running guvcview, though it seems the camera works fine from a user perspective. Full dmesg is: [0.00] Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-1-amd64 root=UUID=8f621675-b0e5-4ac7-8ef1-604cb643d57d ro loglevel=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x2d6d8fff] usable [0.00] BIOS-e820: [mem 0x2d6d9000-0x2d6d9fff] ACPI NVS [0.00] BIOS-e820: [mem 0x2d6da000-0x2d6dafff] reserved [0.00] BIOS-e820: [mem 0x2d6db000-0x3ecdcfff] usable [0.00] BIOS-e820: [mem 0x3ecdd000-0x3f09afff] reserved [0.00] BIOS-e820: [mem 0x3f09b000-0x3f0e7fff] ACPI data [0.00] BIOS-e820: [mem 0x3f0e8000-0x3f79] ACPI NVS [0.00] BIOS-e820: [mem 0x3f7a-0x3ff26fff] reserved [0.00] BIOS-e820: [mem 0x3ff27000-0x3fffefff] type 20 [0.00] BIOS-e820: [mem 0x3000-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x47ff] reserved [0.00] BIOS-e820: [mem 0x4800-0x48df] usable [0.00] BIOS-e820: [mem 0x48e0-0x4f7f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0004ae7f] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.40 by American Megatrends [0.00] efi: ACPI=0x3f0ab000 ACPI 2.0=0x3f0ab000 SMBIOS=0xf SMBIOS 3.0=0xf0020 ESRT=0x3fdd9018 MEMATTR=0x3c2a1298 [0.00] secureboot: Secure boot could not be determined (mode 0) [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.3.2 05/07/2018 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x4ae800 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 008000 mask 7F8000 uncachable [0.00] 1 base 006000 mask 7FE000 uncachable [0.00] 2 base 005000 mask 7FF000 uncachable [0.00] 3 base 004C00 mask 7FFC00 uncachable [0.00] 4 base 004B00 mask 7FFF00 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] e820: last_pfn = 0x48e00 max_arch_pfn = 0x4 [0.00] esrt: Reserving ESRT space from 0x3fdd9018 to 0x3fdd9050. [0.00] Base memory trampoline at [(ptrval)] 98000 size 24576 [0.00] Using GB pages for direct mapping [0.00] BRK [0x15e2c000, 0x15e2cfff] PGTABLE [0.00] BRK [0x15e2d000, 0x15e2dfff] PGTABLE [0.00] BRK [0x15e2e000, 0x15e2efff] PGTABLE [0.00] BRK [0x15e2f000, 0x15e2] PGTABLE [0.00] BRK [0x15e3, 0x15e30fff] PGTABLE [
compile error media-build on 4.15 because of 'device_get_match_data'
I tried to compile media-build on Ubuntu 18.04. (gcc 7.3.0) with Kernel 4.15 and get this error: /home/martin/media_build/v4l/video-i2c.c: In function 'video_i2c_probe': /home/martin/media_build/v4l/video-i2c.c:456:16: error: implicit declaration of function 'device_get_match_data'; did you mean 'of_device_get_match_data'? [-Werror=implicit-function-declaration] data->chip = device_get_match_data(>dev); ^ of_device_get_match_data /home/martin/media_build/v4l/video-i2c.c:456:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->chip = device_get_match_data(>dev); ^ cc1: some warnings being treated as errors scripts/Makefile.build:339: recipe for target '/home/martin/media_build/v4l/video-i2c.o' failed make[3]: *** [/home/martin/media_build/v4l/video-i2c.o] Error 1 Makefile:1552: recipe for target '_module_/home/martin/media_build/v4l' failed make[2]: *** [_module_/home/martin/media_build/v4l] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic' Makefile:51: recipe for target 'default' failed make[1]: *** [default] Error 2 make[1]: Verzeichnis „/home/martin/media_build/v4l“ wird verlassen Makefile:26: recipe for target 'all' failed make: *** [all] Error 2 build failed at ./build line 526 I hope it is possible to integrate a patch for Kernel 4.15
Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Sorry for resurrecting this thread but I'm still quite interested on making this scenario work: > OK, I've performed some tests with several resolutions and gop sizes, here is the table with the results: > > Always playing 3 streams > > | Resolution | QP | GopSize | Kind of content | Result | > | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS| > | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | > | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| > > * The issues always happens in the first stream, the other 2 streams are fine. > * With GopSize = 0 I can even decode 4 720p streams with no artifacts > > It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. > > For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. > Philipp, you mentioned some possible issue with context switches in a previous e-mail: > I fear this may be some interaction between coda context switches and > bitstream reader unit state. Philipp, do these results confirm your theory? Are there any more tests I could prepare to help get to the bottom of this or this is something that belongs entirely to the coda firmware domain? Does anyone know if the official BSP from NXP is able to decode 4 flows without issues?
Re: [linux-sunxi] [PATCH v9 0/2] Initial Allwinner V3s CSI Support
On 03/28/2018 06:02 PM, Yong wrote: AFAIK, there is no document about MIPI CSI-2. You can take a look at the source code in BSP: https://github.com/friendlyarm/h3_lichee/tree/master/linux-3.4/drivers/media/video/sunxi-vfe/mipi_csi And try to port it to mainline. Yep, I see there's lots of magic constants in that code. I might try to forward-port it, but it won't be very maintainable or easy to change without a datasheet. That's too bad. Thanks for the information, Yong.
Re: [linux-sunxi] [PATCH v9 0/2] Initial Allwinner V3s CSI Support
On 03/05/2018 05:51 PM, Yong Deng wrote: This patchset add initial support for Allwinner V3s CSI. Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 interface and CSI1 is used for parallel interface. This is not documented in datasheet but by test and guess. This patchset implement a v4l2 framework driver and add a binding documentation for it. Currently, the driver only support the parallel interface. And has been tested with a BT1120 signal which generating from FPGA. The following fetures are not support with this patchset: - ISP - MIPI-CSI2 - Master clock for camera sensor - Power regulator for the front end IC Hi Yong, Thanks so much, this driver is a great contribution! Unfortunately the board I'm working with (nanopi neo air) uses the MIPI CSI-2 CSI0 interface rather than CSI1. Do you have any plans to support the MIPI CSI-2 interface at some point? If not, do you know the scope of what would be involved?
Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC
Hi Neil, On Sat, Mar 24, 2018 at 2:41 PM, Neil Armstrong <narmstr...@baylibre.com> wrote: > Hi Martin, > >> Le 24 mars 2018 à 12:00, Martin Blumenstingl >> <martin.blumensti...@googlemail.com> a écrit : >> >> Hello Hans, Hi Neil, >> >> (apologies in advance if any of this is wrong, I don't have any CEC >> capable TV so I can't test it) >> >> On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: >>> From: Hans Verkuil <hans.verk...@cisco.com> >>> >>> Some boards (amlogic) have two CEC controllers: the DesignWare controller >>> and their own CEC controller (meson ao-cec). >> as far as I understand the Amlogic Meson SoCs have two domains: >> - AO (always-on, powered even in suspend mode) where meson-ao-cec can >> wake up the system from suspend >> - EE (everything else, not powered during suspend) where dw-hdmi-cec lives >> > > Exact, except … the EE CEC is not hooked to the DW-HDMI TX but the RX, and > thus cannot be used on GXBB/GXL/GXM. I see, thank you for the explanation >> this far everything is OK >> >>> Since the CEC line is not hooked up to the DW controller we need a way >>> to disable that controller. This patch series adds the cec-disable >>> property for that purpose. >> drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and >> ee_cec_pins, both use GPIOAO_12 >> drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and >> ee_cec_pins, both use GPIOAO_8 >> >> @Neil: do you know if the CEC signal routing is: >> ao_cec_pins -> meson-ao-cec >> ee_cec_pins -> dw-hdmi-cec > > It’s hooked to the DW-HDMI RX IP used in the TV SoCs. > >> >> I'm curious because if both CEC controllers can be used then it might >> be worth mentioning this in the cover-letter and patch description >> > > Initially I thought it was hooked to the DW-HDMI TX, but no, I guess I should > remove the ee_cec pinmux… right, or rename it to ee_cec_rx (or something similar) Regards Martin
Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC
Hello Hans, Hi Neil, (apologies in advance if any of this is wrong, I don't have any CEC capable TV so I can't test it) On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil <hverk...@xs4all.nl> wrote: > From: Hans Verkuil <hans.verk...@cisco.com> > > Some boards (amlogic) have two CEC controllers: the DesignWare controller > and their own CEC controller (meson ao-cec). as far as I understand the Amlogic Meson SoCs have two domains: - AO (always-on, powered even in suspend mode) where meson-ao-cec can wake up the system from suspend - EE (everything else, not powered during suspend) where dw-hdmi-cec lives this far everything is OK > Since the CEC line is not hooked up to the DW controller we need a way > to disable that controller. This patch series adds the cec-disable > property for that purpose. drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and ee_cec_pins, both use GPIOAO_12 drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and ee_cec_pins, both use GPIOAO_8 @Neil: do you know if the CEC signal routing is: ao_cec_pins -> meson-ao-cec ee_cec_pins -> dw-hdmi-cec I'm curious because if both CEC controllers can be used then it might be worth mentioning this in the cover-letter and patch description Regards Martin
Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Hello Philipp, On 14/03/18 16:11, Philipp Zabel wrote: Hi Javier, On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote: [...] The encoder is running on a different system with an older 4.1.0 kernel. Altough the firmware version in the code is 3.1.1 as well. Do you think I should try updating the system in the encoder to kernel 4.15 too and see if that makes any difference? I don't think that should matter. It'd be more interesting if GOP size has a significant influence. Does the Problem also appear in I-frame only streams? OK, I've performed some tests with several resolutions and gop sizes, here is the table with the results: Always playing 3 streams | Resolution | QP | GopSize | Kind of content | Result | | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| * The issues always happens in the first stream, the other 2 streams are fine. * With GopSize = 0 I can even decode 4 720p streams with no artifacts It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. Regards, Javier.
Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Hello,
On 14/03/18 14:57, Philipp Zabel wrote:
On Wed, 2018-03-14 at 13:05 +0100, Javier Martin wrote:
Sorry everyone about my previous e-mail with all the HTML garbage. Here
is the plain text answer instead.
Hi Philipp,
thanks for your answer.
On 13/03/18 12:20, Philipp Zabel wrote:
> Hi Javier,
>
> On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>> Hi,
>> we have an i.MX6 Solo based board running the latest mainline kernel
>> (4.15.3).
>>
>> As part of our development we were measuring the decoding
performance of
>> the i.MX6 coda chip.
>>
>> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
>> streams that have been generated by another i.MX6 coda encoder
>> configured with fixed qp = 25 and gopsize = 16.
Those are the defaults. Is the encoder running on the same system, at
the same time? Or are you decoding a previously encoded stream (multiple
previously encoded streams)?
The encoder is running on a different system with an older 4.1.0 kernel.
Altough the firmware version in the code is 3.1.1 as well.
Do you think I should try updating the system in the encoder to kernel
4.15 too and see if that makes any difference?
[...]
I'm currently using 3.1.1 both for encoding and decoding. I think I got
it from the latest BSP provided by NXP. Now that you mention it the
driver is printing these messages at probe time which I had ignored so far:
coda 204.vpu: Firmware code revision: 46056
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 3.1.1
coda 204.vpu: codec registered as /dev/video[3-4]
That is strange, commit be7f1ab26f42 ("media: coda: mark CODA960
firmware versions 2.3.10 and 3.1.1 as supported") was merged
in v4.14.
You are right, those messages where taken from an old 4.1 kernel and not
from the latest 4.15 where they don't appear any longer. Sorry for the
noise.
Do you think I should use an older version instead?
Unfortunately I have no indication that this would help.
Also, do you think it would be worth trying different parameters in the
encoder to see how the decoder responds in those cases?
Possibly. It would be interesting to know if this happens more often for
low resolutions / low quality / static frames than high resolutions /
high quality / high movement.
I can easily prepare a test matrix with several resolutions, QPs and
content and let you know the results. Although first I'd like to know
your opinion on whether I should update the encoder to kernel 4.15 too.
Regards,
Javier.
Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Sorry everyone about my previous e-mail with all the HTML garbage. Here is the plain text answer instead. Hi Philipp, thanks for your answer. On 13/03/18 12:20, Philipp Zabel wrote: > Hi Javier, > > On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote: >> Hi, >> we have an i.MX6 Solo based board running the latest mainline kernel >> (4.15.3). >> >> As part of our development we were measuring the decoding performance of >> the i.MX6 coda chip. >> >> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264 >> streams that have been generated by another i.MX6 coda encoder >> configured with fixed qp = 25 and gopsize = 16. >> >> For 1-2 streams it works smoothly. However, when adding the 3rd stream >> the first decoder instance starts to output these kind of errors: >> >> DEC_PIC_SUCCESS = 2097153 -> 0x21 >> DEC_PIC_SUCCESS = 2621441 -> 0x280001 > I think these might be (recoverable?) error flags, but so far I have > never seen them myself. > I've had reports of those occurring occasionally with certain streams > (not encoded by coda, regardless of the number of running decoder > instances) though. > > What is the coda firmware version you are using? I'm currently using 3.1.1 both for encoding and decoding. I think I got it from the latest BSP provided by NXP. Now that you mention it the driver is printing these messages at probe time which I had ignored so far: coda 204.vpu: Firmware code revision: 46056 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 3.1.1 coda 204.vpu: codec registered as /dev/video[3-4] Do you think I should use an older version instead? Also, do you think it would be worth trying different parameters in the encoder to see how the decoder responds in those cases? Regards, Javier.
coda: i.MX6 decoding performance issues for multi-streaming
Hi, we have an i.MX6 Solo based board running the latest mainline kernel (4.15.3). As part of our development we were measuring the decoding performance of the i.MX6 coda chip. For that purpose we are feeding the decoder with 640x368 @ 30fps H.264 streams that have been generated by another i.MX6 coda encoder configured with fixed qp = 25 and gopsize = 16. For 1-2 streams it works smoothly. However, when adding the 3rd stream the first decoder instance starts to output these kind of errors: DEC_PIC_SUCCESS = 2097153 -> 0x21 DEC_PIC_SUCCESS = 2621441 -> 0x280001 Every time one of these errors appears we can observe a weird artifact in the decoded video (pixelated macroblocks and/or jumps back in time). I tried looking at the original VPU lib implementation by Freescale [1] but they don't seem to handle these errors either. As I don't have access to any kind of Coda IP documentation it's quite hard to me to perform any additional debugging. Has anyone experienced these kind of performance issues too? I'm open to any suggestions and willing to perform extra tests to get to the bottom of this. Regards, Javier. [1] https://github.com/genesi/imx-lib/blob/master/vpu/vpu_lib.c#L2926
Kredit? so schnell wie möglich?
Kredit? so schnell wie möglich? unkompliziert und seriös ? Bei uns genau richtig. Wir arbeiten europaweit. Wir vermitteln Kredite und Darlehen zu fairen Konditionen. Durch unsere seriöse, kompetente und ehrliche Kreditberatung haben wir über Jahre eine starke Position auf dem Markt.
Re: [trivial PATCH] treewide: Align function definition open/close braces
Joe, > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. SCSI bits look OK. Acked-by: Martin K. Petersen <martin.peter...@oracle.com> -- Martin K. Petersen Oracle Linux Engineering
[PATCH Resend] staging: media: cxd2099: style fix - replace hard-coded function names
This patch fixes the remaining coding style warnings in the cxd2099
module. Instead of hard coding the function name the __func__ variable
should be used.
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using 'i2c_read_reg', this
function's name, in a string
Signed-off-by: Martin Homuth <martin.hom...@martinhomuth.de>
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 3e30f48..6641dd2 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -101,7 +101,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter,
u8 adr,
.buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read_reg\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
@@ -116,7 +116,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
--
2.10.0
Re: [PATCH Resend] staging: media: cxd2099: style fix - replace hard-coded function names
This patch fixes the remaining coding style warnings in the cxd2099
module. Instead of hard coding the function name the __func__ variable
should be used.
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using 'i2c_read_reg', this
function's name, in a string
Signed-off-by: Martin Homuth <martin.hom...@martinhomuth.de>
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 3e30f48..6641dd2 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -101,7 +101,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter,
u8 adr,
.buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read_reg\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
@@ -116,7 +116,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
--
2.10.0
[PATCH] staging: media: cxd2099: style fix - replace hard-coded function names
This patch fixes the remaining coding style warnings in the lirc module.
Instead of hard coding the function name the __func__ variable
should be used.
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using 'read', this
function's name, in a string
Signed-off-by: Martin Homuth <martin.hom...@martinhomuth.de>
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 3e30f48..6641dd2 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -101,7 +101,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter,
u8 adr,
.buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read_reg\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
@@ -116,7 +116,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- dev_err(>dev, "error in i2c_read\n");
+ dev_err(>dev, "error in %s\n", __func__);
return -1;
}
return 0;
--
2.10.0
[PATCH Resend] staging: media: lirc: style fix - replace hard-coded function names
This patch fixes the remaining coding style warnings in the lirc module.
Instead of hard coding the function name the __func__ variable
should be used.
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using 'read', this
function's name, in a string
Signed-off-by: Martin Homuth <mar...@martinhomuth.de>
---
drivers/staging/media/lirc/lirc_zilog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 6bd0717bf76e..be68ee652071 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -888,9 +888,9 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
unsigned int m;
DECLARE_WAITQUEUE(wait, current);
- dev_dbg(ir->dev, "read called\n");
+ dev_dbg(ir->dev, "%s called\n", __func__);
if (n % rbuf->chunk_size) {
- dev_dbg(ir->dev, "read result = -EINVAL\n");
+ dev_dbg(ir->dev, "%s result = -EINVAL\n", __func__);
return -EINVAL;
}
@@ -949,7 +949,7 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
retries++;
}
if (retries >= 5) {
- dev_err(ir->dev, "Buffer read failed!\n");
+ dev_err(ir->dev, "%s failed!\n", __func__);
ret = -EIO;
}
}
@@ -959,7 +959,7 @@ static ssize_t read(struct file *filep, char __user
*outbuf, size_t n,
put_ir_rx(rx, false);
set_current_state(TASK_RUNNING);
- dev_dbg(ir->dev, "read result = %d (%s)\n", ret,
+ dev_dbg(ir->dev, "%s result = %d (%s)\n", __func__, ret,
ret ? "Error" : "OK");
return ret ? ret : written;
--
2.13.6
[PATCH] staging/media: lirc: style fix - replace hard-coded function names
This patch fixes the remaining coding style warnings in the lirc module.
It fixes the following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using 'read', this
function's name, in a string
>From f11f24667ba6696cb71ac33a67fc0c7d3b4cd542 Mon Sep 17 00:00:00 2001
From: Martin Homuth <martin.hom...@emlix.com>
Date: Sun, 26 Nov 2017 20:14:33 +0100
Subject: [PATCH] lirc: style fix - replace hard-coded function names
Instead of hard coding the function name the __func__ variable
should be used.
Signed-off-by: Martin Homuth <martin.hom...@emlix.com>
---
drivers/staging/media/lirc/lirc_zilog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c
index 6bd0717bf76e..be68ee652071 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -888,9 +888,9 @@ static ssize_t read(struct file *filep, char __user *outbuf, size_t n,
unsigned int m;
DECLARE_WAITQUEUE(wait, current);
- dev_dbg(ir->dev, "read called\n");
+ dev_dbg(ir->dev, "%s called\n", __func__);
if (n % rbuf->chunk_size) {
- dev_dbg(ir->dev, "read result = -EINVAL\n");
+ dev_dbg(ir->dev, "%s result = -EINVAL\n", __func__);
return -EINVAL;
}
@@ -949,7 +949,7 @@ static ssize_t read(struct file *filep, char __user *outbuf, size_t n,
retries++;
}
if (retries >= 5) {
-dev_err(ir->dev, "Buffer read failed!\n");
+dev_err(ir->dev, "%s failed!\n", __func__);
ret = -EIO;
}
}
@@ -959,7 +959,7 @@ static ssize_t read(struct file *filep, char __user *outbuf, size_t n,
put_ir_rx(rx, false);
set_current_state(TASK_RUNNING);
- dev_dbg(ir->dev, "read result = %d (%s)\n", ret,
+ dev_dbg(ir->dev, "%s result = %d (%s)\n", __func__, ret,
ret ? "Error" : "OK");
return ret ? ret : written;
--
2.13.6
Re: [PATCH] media: coda: fix comparision of decoded frames' indexes
Am 22.11.2017 14:43 schrieb Philipp Zabel:
Hi Martin,
On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote:
At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).
Now what is saved in ctx->display_idx is an older value at this point!
Yes. The rotator that copies out the decoded frame runs in parallel
with
the decoding of the next frame. So the decoder signals with display_idx
which decoded frame should be presented next, but it is only copied out
into the vb2 buffer during the following run. The same happens with the
VDOA, but manually, in prepare_decode.
That means that at this point display_idx is the index of the
previously
decoded internal frame that should be presented next, and ctx-
display_idx is the index of the internal frame that was just copied
into the externally visible vb2 buffer.
The logic reads someting like this:
if (no frame was decoded) {
if (a frame will be copied out next time) {
adapt sequence number offset;
} else if (no frame was copied out this time) {
hold until further input;
}
}
Basically, it will just wait one more run until it stops the stream,
assuming that there is really nothing useful in the bitstream
ringbuffer.
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.
display_idx is already checked later in the same function.
According to the i.MX6 VPU API document, it can be -2 (never seen) or
-3
during sequence start (if there is frame reordering, depending on
whether decoder skip is enabled), and I think I've seen -3 as prescan
failure on i.MX5. -1 means EOS according to that document, that's why
we
always hold in that case.
ctx->display_idx is updated later in the same function.
Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---
Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!
Maybe it would be less confusing to move this into the display_idx
checks below, given that we already hold unconditionally
on display_idx == -1.
I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.
I think this shouldn't happen at all if you feed it a well formed h.264
stream. But if you have a skip because of broken data while there is
still no display frame at the beginning of the stream or after an IDR,
this might be hit.
Right. Let's leave it this way. In case of real changes, one can think
about
cleanup.
Thanks for clarification and helping to understand this thing! I
appreciate it.
martin
Re: media: coda: sources of coda_regs.h?
Am 22.11.2017 11:40 schrieb Philipp Zabel: Hi Martin, On Thu, 2017-11-09 at 23:14 +0100, Martin Kepplinger wrote: Hi Philipp, As I'm reading up on the coda driver a little, I can't seem to find the vendor's sources for the coda_regs.h definitions. Could you point me to them? I don't know for sure what information Javier based the CodaDx6 register names on, but I assume that he used the old LGPLed i.MX VPU libraries that Freescale once distributed. At least that's what I looked at for the CODA960 additions: The BSP "L3.0.35_12.09.01.01_GA_source.tar.gz" contained a tarball "pkgs/imx-lib-12.09.01.tar.gz" with a header file "imx-lib-12.09.01/vpu/vpu_reg.h" inside. I believe the current BSP versions distributed by NXP do not include this library anymore. Great! Thanks for the details.
[PATCH] media: coda: fix comparision of decoded frames' indexes
At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).
Now what is saved in ctx->display_idx is an older value at this point!
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.
ctx->display_idx is updated later in the same function.
Signed-off-by: Martin Kepplinger <mart...@posteo.de>
---
Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!
I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.
thanks
martin
drivers/media/platform/coda/coda-bit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index bfc4ecf6f068..fe38527a90e2 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2089,7 +2089,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
/* no frame was decoded, but we might have a display frame */
if (display_idx >= 0 && display_idx < ctx->num_internal_frames)
ctx->sequence_offset++;
- else if (ctx->display_idx < 0)
+ else if (display_idx < 0)
ctx->hold = true;
} else if (decoded_idx == -2) {
/* no frame was decoded, we still return remaining buffers */
--
2.11.0
media: coda: sources of coda_regs.h?
Hi Philipp, As I'm reading up on the coda driver a little, I can't seem to find the vendor's sources for the coda_regs.h definitions. Could you point me to them? As they don't seem to be in the imx reference manual nor the vpu API manual, I think it would be worth including a comment about the source in the header file. and thanks for this driver. It seems to make the best possible use of this remaining firmware binary, really :) martin
[PATCH] media: coda: remove definition of CODA_STD_MJPG
According to i.MX VPU API Reference Manuals the MJPG video codec is refernced to by number 7, not 3. Also Philipp pointed out that this value is only meant to fill in CMD_ENC_SEQ_COD_STD for encoding, only on i.MX53. It was never written to any register, and even if defined correctly, wouldn't be needed for i.MX6. So avoid confusion and remove this definition. Signed-off-by: Martin Kepplinger <mart...@posteo.de> --- drivers/media/platform/coda/coda_regs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/coda/coda_regs.h b/drivers/media/platform/coda/coda_regs.h index 38df5fd9a2fa..35e620c7f1f4 100644 --- a/drivers/media/platform/coda/coda_regs.h +++ b/drivers/media/platform/coda/coda_regs.h @@ -254,7 +254,6 @@ #defineCODA9_STD_H264 0 #defineCODA_STD_H263 1 #defineCODA_STD_H264 2 -#defineCODA_STD_MJPG 3 #defineCODA9_STD_MPEG4 3 #define CODA_CMD_ENC_SEQ_SRC_SIZE 0x190 -- 2.11.0
[PATCH] media: coda: Fix definition of CODA_STD_MJPG
According to i.MX 6 VPU API Reference Manual Rev. L3.0.35_1.1.0, 01/2013 chapter 3.2.1.5, the MJPG video codec is refernced to by number 7, not 3. So change this accordingly. This isn't yet being used right now and therefore probably hasn't been noticed. Fixing this avoids causing trouble in the future. Signed-off-by: Martin Kepplinger <mart...@posteo.de> --- drivers/media/platform/coda/coda_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/coda/coda_regs.h b/drivers/media/platform/coda/coda_regs.h index 38df5fd9a2fa..8d726faaf86e 100644 --- a/drivers/media/platform/coda/coda_regs.h +++ b/drivers/media/platform/coda/coda_regs.h @@ -254,7 +254,7 @@ #defineCODA9_STD_H264 0 #defineCODA_STD_H263 1 #defineCODA_STD_H264 2 -#defineCODA_STD_MJPG 3 +#defineCODA_STD_MJPG 7 #defineCODA9_STD_MPEG4 3 #define CODA_CMD_ENC_SEQ_SRC_SIZE 0x190 -- 2.11.0
Wir bieten jedem ein GÜNSTIGES Darlehnen zu TOP Konditionen an
Sehr geehrte Damen und Herren, Sie brauchen Geld? Sie sind auf der suche nach einem Darlehnen? Seriös und unkompliziert? Dann sind Sie hier bei uns genau richtig. Durch unsere jahrelange Erfahrung und kompetente Beratung sind wir Europaweit tätig. Wir bieten jedem ein GÜNSTIGES Darlehnen zu TOP Konditionen an. Darlehnen zwischen 5000 CHF/Euro bis zu 20 Millionen CHF/Euro möglich. Wir erheben dazu 2% Zinssatz. Lassen Sie sich von unserem kompetenten Team beraten. Zögern Sie nicht und kontaktieren Sie mich unter für weitere Infos & Anfragen unter der eingeblendeten Email Adresse: Ich freue mich von Ihnen zu hören.
Re: platform: coda: how to use firmware-imx binary releases?
On 2017-10-05 17:45, Philipp Zabel wrote:
> On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
>> Hi,
>>
>> Commit
>>
>> be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
>> and
>> 3.1.1 as supported
>>
>> says firmware version 3.1.1 revision 46072 is contained in
>> "firmware-imx-5.4.bin", that's probably
>>
>> sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-
>> 5.4.bin
>>
>> How do I use this in order to get a VPU firmware blob that the coda
>> platform driver can work with?
>>
>>
>>
>> (Maybe it'd be worth adding some short documentation on this. There
>> doesn't seem to be a devicetree bindings doc for coda in
>> Documentation/devicetree/bindings/media
>
> I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
> It was added in commit 657eee7d25fb ("media: coda: use genalloc API").
Right. Not greppable with "coda". If you've also missed it because of
that, it might likely help others when "coda" is mendtioned in it :)
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 16:10 schrieb Nicolas Dufresne: Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit : > This message is most likely just a result of the VDOA not supporting > the > selected capture format. In vdoa_context_configure, you can see that > the > VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink A bit unrelated, but kmssink remains a better choice here. True, but I'm currently not yet interested in the other end of the pipe :) Decoding works in principal. VDOA is still disabled however :( I don't see what I can do about this right now, which is a bit odd. It is definitely probed (and not removed). I see at least a few frames of the video, so I guess the video file is fine? Or could it be a file (or pixel) format that isn't supported? Again, ffprobe says Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc thanks After this, I want to have video conversion (color space) via a v4l2 interface that in turn uses the imx6 IPU. I guess gst-inspect-1.0 should see a V4L2 Converter, which it currently doesn't here: # gst-inspect-1.0 | grep v4l2 video4linux2: v4l2video1dec: V4L2 Video Decoder video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2src: Video (video4linux2) Source # dmesg | grep ipu [1.394717] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 0xc07d4b60) [1.402258] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 0xc07d4b60) [1.514984] imx-ipuv3 240.ipu: IPUv3H probed should imx-ipuv3 provide a video4linux2 interface for video conversion? At least I don't see it yet. (or other V4L2 Linux config options than I already have enabled)
Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?
Am 05.10.2017 10:19 schrieb Philipp Zabel: Hi Martin, On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote: I'm running a little off-topic here, but with the newest firmware too, my coda driver says "Video Data Order Adapter: Disabled" when started by video playback via v4l2. This message is most likely just a result of the VDOA not supporting the selected capture format. In vdoa_context_configure, you can see that the VDOA only writes YUYV or NV12. ok. I'll have to look into it, and just in case you see a problem on first sight: this is what coda says with debug level 1, when doing gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 video-sink=fbdevsink with the video file being (ffprobe) Input #0, h264, from 'test2_hd480.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 24 tbr, 1200k tbn, 48 tbc after some s_ctrl: id/val printings: [ 98.833023] coda 204.vpu: Created instance 0 (cefc5000) [ 98.837550] coda 204.vpu: Releasing instance cefc5000 [ 98.839080] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.839091] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.839100] coda 204.vpu: Created instance 0 (ceeb2000) [ 98.842867] coda 204.vpu: Releasing instance ceeb2000 [ 98.845435] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 98.845447] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 98.845458] coda 204.vpu: Created instance 0 (cefc5000) [ 98.851652] coda 204.vpu: Setting format for type 2, wxh: 852x480, fmt: H264 L [ 98.851670] coda 204.vpu: Setting format for type 1, wxh: 852x480, fmt: NV12 T [ 98.854800] coda 204.vpu: get 2 buffer(s) of size 819200 each. [ 99.022191] coda 204.vpu: get 2 buffer(s) of size 622080 each. [ 99.025904] coda 204.vpu: Video Data Order Adapter: Disabled [ 99.025922] coda 204.vpu: H264 Profile/Level: High L3 [ 99.026214] coda 204.vpu: __coda_start_decoding instance 0 now: 864x480 [ 99.036277] coda 204.vpu: 0: not ready: need 2 buffers available (1, 0) [ 99.063157] coda 204.vpu: job ready so while the video is shown, the VDOA is "disabled". thanks a lot for your help (it's shown far from fluent yet, almost frame by frame, but that's ok for now... I'll still need to took into the v4l2 interface for the imx6 IPU) (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed, a dev_info "probed" would maybe be useful for others too?) It supsequently fails with cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12 That is -ENOMEM. Is CMA enabled and sufficiently large? For example, CONFIG_CMA=y CONFIG_CMA_DEBUGFS=y CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=256 CONFIG_CMA_SIZE_SEL_MBYTES=y My cma buffer size was indeed just too small.
Re: platform: coda: how to use firmware-imx binary releases?
Am 04.10.2017 11:22 schrieb Philipp Zabel:
Hi Martin,
On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
Hi,
Commit
be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
and 3.1.1 as supported
says firmware version 3.1.1 revision 46072 is contained in
"firmware-imx-5.4.bin", that's probably
sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-5.4.bin
Yes.
How do I use this in order to get a VPU firmware blob that the coda
platform driver can work with?
These are self-extracting shell scripts with an attached compressed tar
archive. This particular file can be extracted by skipping the first
34087 bytes:
dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv
thanks!
(Maybe it'd be worth adding some short documentation on this. There
doesn't seem to be a devicetree bindings doc for coda in
Documentation/devicetree/bindings/media which would
be a good place for documenting how to use these binaries too)
Thank you for pointing this out, the device tree binding docs for coda
are indeed missing.
I'm not sure the device tree binding docs are the right place to
document driver and firmware though. For that, adding a coda.rst entry
to Documentation/media/v4l-drivers would probably be a better place.
True. That'd be great. Some firmware-handling and maybe even firmware
version changelogs would definitely be useful.
I'm running a little off-topic here, but with the newest firmware too,
my
coda driver says "Video Data Order Adapter: Disabled" when started
by video playback via v4l2.
(imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
a dev_info "probed" would maybe be useful for others too?)
It supsequently fails with
cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12
which may or may not be related to having the vdoa (is it?), but
shouldn't
the VDOA module be active by default?
# cat /sys/module/coda/parameters/disable_vdoa
0
thanks
martin
platform: coda: how to use firmware-imx binary releases?
Hi, Commit be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 3.1.1 as supported says firmware version 3.1.1 revision 46072 is contained in "firmware-imx-5.4.bin", that's probably sha1 78a416ae88ff01420260205ce1d567f60af6847e firmware-imx-5.4.bin How do I use this in order to get a VPU firmware blob that the coda platform driver can work with? (Maybe it'd be worth adding some short documentation on this. There doesn't seem to be a devicetree bindings doc for coda in Documentation/devicetree/bindings/media which would be a good place for documenting how to use these binaries too) thanks martin
Re: [PATCH 13/15] scsi: make device_type const
Bhumika, > Make these const as they are only stored in the type field of a device > structure, which is const. Applied to 4.14/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] hdmi: audio infoframe log: corrected channel count
Audio channel count should start from 2.
Reference: CEA-861-F Table 27.
Cc: Hans Verkuil <hverk...@xs4all.nl>
Reported-by: Ahung Cheng <ahch...@nvidia.com>
Signed-off-by: Martin Bugge <marbu...@cisco.com>
---
drivers/video/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907e..35c0408 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -884,7 +884,7 @@ static void hdmi_audio_infoframe_log(const char *level,
(struct hdmi_any_infoframe *)frame);
if (frame->channels)
- hdmi_log("channels: %u\n", frame->channels - 1);
+ hdmi_log("channels: %u\n", frame->channels + 1);
else
hdmi_log("channels: Refer to stream header\n");
hdmi_log("coding type: %s\n",
--
2.9.4
[PATCH] media: dvb-frontends: drx39xyj: remove obsolete sign extend macros
DRX_S9TOS16 and DRX_S24TODRXFREQ are simply not used. Furthermore, sign_extend32() should be used for sign extension. (Also, the comment describing DRX_S24TODRXFREQ was wrong). So remove these macros. Signed-off-by: Martin Kepplinger <mart...@posteo.de> --- drivers/media/dvb-frontends/drx39xyj/drx_driver.h | 13 - 1 file changed, 13 deletions(-) diff --git a/drivers/media/dvb-frontends/drx39xyj/drx_driver.h b/drivers/media/dvb-frontends/drx39xyj/drx_driver.h index 4442e47..afa702c 100644 --- a/drivers/media/dvb-frontends/drx39xyj/drx_driver.h +++ b/drivers/media/dvb-frontends/drx39xyj/drx_driver.h @@ -450,19 +450,6 @@ MACROS ((u8)u16)x)>>8)&0xFF)) /** -* \brief Macro to sign extend signed 9 bit value to signed 16 bit value -*/ -#define DRX_S9TOS16(x) u16)x)&0x100) ? ((s16)((u16)(x)|0xFF00)) : (x)) - -/** -* \brief Macro to sign extend signed 9 bit value to signed 16 bit value -*/ -#define DRX_S24TODRXFREQ(x) u32) x) & 0x0080UL) ? \ -((s32) \ - (((u32) x) | 0xFF00)) : \ -((s32) x)) - -/** * \brief Macro to convert 16 bit register value to a s32 */ #define DRX_U16TODRXFREQ(x) ((x & 0x8000) ? \ -- 2.1.4
[no subject]
unsubscribe linux-media
Re: Cine CT V6.1 code change request
2017-02-19 14:27 GMT+01:00 Daniel Scheller <d.scheller@gmail.com>: > > Hi Martin, > > For someone who has some knowledge on the stv0367 demods, it's probably > not very hard. > > While I don't have that knowledge, I've started tackling > the "in-kernel" stv0367 module to work as a replacement for DD's > stv0367dd anyway, and while I didn't get very far yet, this is what I > found out so far: > > - stv0367dd always provides multiple delivery systems (DVB-C, DVB-T) > when attached, where stv0367 needs multiple frontends for each > delivery systems, e.g. you need to attach the -T and -C > frontends separately. Basically, this is also the case in the > stv0367dd, but it has some sort of "wrapper" ontop which does the > QAM/OFDM operation mode switch transparently. > - When attaching only one of the two -T/-C code paths, there's still > something more that needs to be done. With the QAM path, I got the > demod to somewhat do some work (it reported signal statistics when > tuned to a frequency) but didn't properly send the transport stream > to the bridge. > - stv0367dd runs at 58MHz IC speed for the QAM mode, but this is rather > easy to add since (what I could find out so far) it just requires > different values poked into the PLLxDIV regs. > - The i2c_gate_ctrl() in stv0367 must not be called from inside the > demod driver (thinking of a config flag to toggle this) since > ddbridge remaps the function pointers to a mutex_lock'ed variant, > which in turn will cause a deadlock when the demod driver triggers > the i2c_gate itself. > > The biggest problem at the moment is 2., e.g. get the transport to the > bridge working. 1. should be fairly easy to do, 3. and 4. are done. See > [1] for my attempt on this. But generally speaking, the stv0367 driver > should work even with DD cards with a few additions. > > The TDA18212 "in-tree" tuner frontend works perfectly with the STV and > also the CXD28xx-based tuners. The work on this was done in around 2013 > or so by Antti Palosaari (see [2]), and it worked out so nicely when I > first started tackling things I never cared to pick up the > tda18212DD :-) > > Best regards, > Daniel Scheller > > [1] > https://github.com/herrnst/dddvb-linux-kernel/compare/attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-cxd...attic/old-0_9_23-0_9_28-mediatree/master-ddbridge-cttesting-stv > [2] > https://github.com/herrnst/dddvb-linux-kernel/commit/905c999f69e58e2c54be24bd7ec6c86ec2ef1e65 Hi Daniel, Thanks for starting this investigation! If I'm understanding correctly, there is some work to do, but it can be done and is not a huge amount of work. (But it is more than just moving something from the old repo and fixing some errors/warnings.) I'm not familiar with the linux-media way of organizing the work, or how priorities are set (on the backlog?). What should be the next step and what can I do to have this feature/enhancement picked up? I'm not a developer, but I own the hardware and thus I am able to test any new code. If there might anything else I can do, please let me know. Thanks, Martin
Re: Cine CT V6.1 code change request
2017-02-15 8:55 GMT+01:00 Hans Verkuil <hverk...@xs4all.nl>: Hi Hans, Thanks for the quick response! > I'm not sure what this media_build directory is. It certainly is > outdated. The latest media_build is here: > https://git.linuxtv.org/media_build.git/ And thanks for sharing! > Can you show that line and the surrounding lines? I.e. the whole menu > entry? Of course, here it is: if STAGING menu "Media devices in staging" config STAGING_BROKEN bool "Enable drivers that are known to not compile" default n --- help --- Say N here, except if you will be fixing the drivers compilation. menuconfig STAGING_MEDIA > Most likely because the media build you use is outdated. I cloned the latest repository and build it, all went fine, however.. (read on) > Which driver? This is my device: 02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter Subsystem: Digital Devices GmbH Cine CT V6.1 DVB adapter Flags: bus master, fast devsel, latency 0, IRQ 32 Memory at fbcf (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+ Capabilities: [90] Express Endpoint, MSI 00 Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c Kernel driver in use: ddbridge Kernel modules: ddbridge I am using the following modules: [htpc@htpc ~]$ lsmod | grep dd tda18212dd 20480 2 stv0367dd 24576 2 ddbridge 90112 29 cxd209920480 1 ddbridge dvb_core 102400 1 ddbridge The ddbridge and cxd2099 are in the latest media_build, but the stv0367dd and tda18212dd are missing (however, the stv0367 and tda18212 are available). How hard is it to add these two? Regards, Martin > Regards, > > Hans >
Cine CT V6.1 code change request
All,
I have a Cine CT V6.1 in my fedora 25 based media center. It is now
running a default fedora 4.9 kernel. I install the driver as follows:
hg clone https://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untar
make menuconfig
make
make install
However, I have to make two changes to the source to make it work.
Change 1: in media_build_experimental/v4l/Kconfig line 6936 I have to
remove the whitespace in '--- help ---', otherwise make menuconfig
fails.
Change 2: during compilation the following error occurs (since about
kernel 4.5?):
make -C /lib/modules/4.9.7-201.fc25.x86_64/build
SUBDIRS=/home/htpc/Downloads/media_build_experimental/v4l modules
make[2]: Entering directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
CC [M] /home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o
In file included from :0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1463:1:
error: redefinition of 'pci_zalloc_consistent'
pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
^
In file included from ./include/linux/pci.h:2145:0,
from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
from :0:
./include/linux/pci-dma-compat.h:23:1: note: previous definition of
'pci_zalloc_consistent' was here
pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
^
In file included from :0:0:
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1552:0:
warning: "DMA_ATTR_SKIP_CPU_SYNC" redefined
#define DMA_ATTR_SKIP_CPU_SYNC 0
In file included from ./include/linux/pci-dma-compat.h:7:0,
from ./include/linux/pci.h:2145,
from
/home/htpc/Downloads/media_build_experimental/v4l/compat.h:1459,
from :0:
./include/linux/dma-mapping.h:47:0: note: this is the location of the
previous definition
#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 5)
scripts/Makefile.build:299: recipe for target
'/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o'
failed
make[3]: *** [/home/htpc/Downloads/media_build_experimental/v4l/tuner-xc2028.o]
Error 1
Makefile:1494: recipe for target
'_module_/home/htpc/Downloads/media_build_experimental/v4l' failed
make[2]: *** [_module_/home/htpc/Downloads/media_build_experimental/v4l] Error 2
make[2]: Leaving directory '/usr/src/kernels/4.9.7-201.fc25.x86_64'
Makefile:51: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/htpc/Downloads/media_build_experimental/v4l'
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2
Which I fix by commenting out lines 1462 up to 1468 in
media_build_experimental/v4l/compat.h:
//static inline void *
//pci_zalloc_consistent(struct pci_dev *hwdev, size_t size,
// dma_addr_t *dma_handle)
//{
// return dma_alloc_coherent(hwdev == NULL ? NULL : >dev,
// size, dma_handle, GFP_ATOMIC | __GFP_ZERO);
//}
Now it compiles and works fine. I still get these warnings:
media_build_experimental/v4l/compat.h:1552:0: warning:
"DMA_ATTR_SKIP_CPU_SYNC" redefined
#define DMA_ATTR_SKIP_CPU_SYNC 0
Which I can easily remove by commenting out the specific line as well.
Now my questions are:
- is this the correct way to fix these compile errors? (I'm definately
not a professional developer)
- what can I do to have this solved in the source?
Besides that, I'm also wondering if these drivers have any change of
getting into kernel mainline?
Regards,
Martin
Re: [PATCH v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported
On Wed, Feb 1, 2017 at 11:14 PM, Martin Blumenstingl
<martin.blumensti...@googlemail.com> wrote:
> The driver already parses the "linux,rc-map-name" property. Add this
> information to the documentation so .dts maintainers don't have to look
> it up in the source-code.
>
> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
> Acked-by: Rob Herring <r...@kernel.org>
> ---
> Changes since v1:
> - removed character which shows up as whitespace from subject
I have verified that I really sent this without a whitespace (I'm
using git send-email, so the patch is not mangled by some webmailer) -
unfortunately it seems to appear again (maybe one of the receiving
mail-servers or the mailing-list software does something weird here).
@Mauro: can you handle this when you merge the patch - or do you want
me to push this to some git repo from which you can pull?
> - added Rob Herring's ACK
>
> Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt
> b/Documentation/devicetree/bindings/media/meson-ir.txt
> index e7e3f3c4fc8f..efd9d29a8f10 100644
> --- a/Documentation/devicetree/bindings/media/meson-ir.txt
> +++ b/Documentation/devicetree/bindings/media/meson-ir.txt
> @@ -8,6 +8,9 @@ Required properties:
> - reg : physical base address and length of the device registers
> - interrupts : a single specifier for the interrupt from the device
>
> +Optional properties:
> + - linux,rc-map-name: see rc.txt file in the same directory.
> +
> Example:
>
> ir-receiver@c8100480 {
> --
> 2.11.0
>
--
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 v2] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported
The driver already parses the "linux,rc-map-name" property. Add this
information to the documentation so .dts maintainers don't have to look
it up in the source-code.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Changes since v1:
- removed character which shows up as whitespace from subject
- added Rob Herring's ACK
Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt
b/Documentation/devicetree/bindings/media/meson-ir.txt
index e7e3f3c4fc8f..efd9d29a8f10 100644
--- a/Documentation/devicetree/bindings/media/meson-ir.txt
+++ b/Documentation/devicetree/bindings/media/meson-ir.txt
@@ -8,6 +8,9 @@ Required properties:
- reg : physical base address and length of the device registers
- interrupts : a single specifier for the interrupt from the device
+Optional properties:
+ - linux,rc-map-name: see rc.txt file in the same directory.
+
Example:
ir-receiver@c8100480 {
--
2.11.0
--
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] Documentation: devicetree: meson-ir: "linux,rc-map-name" is supported
The driver already parses the "linux,rc-map-name" property. Add this
information to the documentation so .dts maintainers don't have to look
it up in the source-code.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
Documentation/devicetree/bindings/media/meson-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt
b/Documentation/devicetree/bindings/media/meson-ir.txt
index e7e3f3c4fc8f..efd9d29a8f10 100644
--- a/Documentation/devicetree/bindings/media/meson-ir.txt
+++ b/Documentation/devicetree/bindings/media/meson-ir.txt
@@ -8,6 +8,9 @@ Required properties:
- reg : physical base address and length of the device registers
- interrupts : a single specifier for the interrupt from the device
+Optional properties:
+ - linux,rc-map-name: see rc.txt file in the same directory.
+
Example:
ir-receiver@c8100480 {
--
2.11.0
--
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] Documentation: devicetree: add the RC map name of the geekbox remote
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- The geekbox keymap was added while the documentation patch was not applied yet (and I wasn't aware of this pending patch). This ensures that the documentation is in sync with the actual keymaps. Documentation/devicetree/bindings/media/rc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt index 0d16d14ccd2a..d3e7a012bfda 100644 --- a/Documentation/devicetree/bindings/media/rc.txt +++ b/Documentation/devicetree/bindings/media/rc.txt @@ -46,6 +46,7 @@ The following properties are common to the infrared remote controllers: * "rc-flyvideo" * "rc-fusionhdtv-mce" * "rc-gadmei-rm008z" + * "rc-geekbox" * "rc-genius-tvgo-a11mce" * "rc-gotview7135" * "rc-hauppauge" -- 2.11.0 -- 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: rc/keymaps: add a keytable for the GeekBox remote control
The GeekBox ships with a 12 button remote control which seems to use the
NEC protocol. The button keycodes were captured with the "ir-keytable"
tool (ir-keytable -p $PROTOCOL -t; human_button_pusher).
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
drivers/media/rc/keymaps/Makefile | 1 +
drivers/media/rc/keymaps/rc-geekbox.c | 55 +++
include/media/rc-map.h| 1 +
3 files changed, 57 insertions(+)
create mode 100644 drivers/media/rc/keymaps/rc-geekbox.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index d7b13fae1267..4578b3454c0b 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-flyvideo.o \
rc-fusionhdtv-mce.o \
rc-gadmei-rm008z.o \
+ rc-geekbox.o \
rc-genius-tvgo-a11mce.o \
rc-gotview7135.o \
rc-imon-mce.o \
diff --git a/drivers/media/rc/keymaps/rc-geekbox.c
b/drivers/media/rc/keymaps/rc-geekbox.c
new file mode 100644
index ..affc4c481888
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-geekbox.c
@@ -0,0 +1,55 @@
+/*
+ * Keytable for the GeekBox remote controller
+ *
+ * Copyright (C) 2017 Martin Blumenstingl <martin.blumensti...@googlemail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+
+static struct rc_map_table geekbox[] = {
+ { 0x01, KEY_BACK },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_UP },
+ { 0x07, KEY_OK },
+ { 0x0b, KEY_VOLUMEUP },
+ { 0x0e, KEY_LEFT },
+ { 0x13, KEY_MENU },
+ { 0x14, KEY_POWER },
+ { 0x1a, KEY_RIGHT },
+ { 0x48, KEY_HOME },
+ { 0x58, KEY_VOLUMEDOWN },
+ { 0x5c, KEY_SCREEN },
+};
+
+static struct rc_map_list geekbox_map = {
+ .map = {
+ .scan= geekbox,
+ .size= ARRAY_SIZE(geekbox),
+ .rc_type = RC_TYPE_NEC,
+ .name= RC_MAP_GEEKBOX,
+ }
+};
+
+static int __init init_rc_map_geekbox(void)
+{
+ return rc_map_register(_map);
+}
+
+static void __exit exit_rc_map_geekbox(void)
+{
+ rc_map_unregister(_map);
+}
+
+module_init(init_rc_map_geekbox)
+module_exit(exit_rc_map_geekbox)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Martin Blumenstingl <martin.blumensti...@googlemail.com>");
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index e1cc14cba391..3db3b63be279 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -219,6 +219,7 @@ struct rc_map *rc_map_get(const char *name);
#define RC_MAP_FLYVIDEO "rc-flyvideo"
#define RC_MAP_FUSIONHDTV_MCE"rc-fusionhdtv-mce"
#define RC_MAP_GADMEI_RM008Z "rc-gadmei-rm008z"
+#define RC_MAP_GEEKBOX "rc-geekbox"
#define RC_MAP_GENIUS_TVGO_A11MCE"rc-genius-tvgo-a11mce"
#define RC_MAP_GOTVIEW7135 "rc-gotview7135"
#define RC_MAP_HAUPPAUGE_NEW "rc-hauppauge"
--
2.11.0
--
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: astrometa device driver
On Mon, Jan 9, 2017 at 1:45 AM, Dieter Miosga <dmiosga6...@gmail.com> wrote: > Here's the result of the lsusb on the HanfTek 15f4:0135 This USB ID is not registered with the cx231xx driver yet - thus the driver simply ignores your device. The basics steps for adding support for your card would be: 1. add new "#define CX231XX_BOARD_..." in cx231xx.h 2. add new entry to cx231xx_boards[] in cx231xx-cards.c with the correct values (NOTE: has to figure out the correct values, maybe Antti can give a hint which of the existing boards could be used as staring point) 3. add a new entry to cx231xx_id_table (with USB vendor/device IDs) in cx231xx-cards.c 4. add r820t_config to cx231xx-dvb.c (maybe you can even copy the one from rtl28xxu.c) 5. add mn88473_config to cx231xx-dvb.c (again, copying the one from rtl28xxu.c may work) 6. add a new case statement to dvb_init in cx231xx-dvb.c and connect the rt820t_config and mn88473_config (you can probably use the code of another board and adapt it accordingly) 7. test + bugfix :) Regards, Martin -- 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: astrometa device driver
Hello Dieter, (I CC'ed the linux-media mailing list so other users can look this up when they run into the same problem) On Sun, Jan 8, 2017 at 7:27 PM, Dieter Miosga <dmiosga6...@gmail.com> wrote: > Happy 2017! > > One of the parts that were placed under my imaginary Christmas tree was an > Astrometa Hybrid TV DVB-T/T2/C/FM/AV USB 2.0 stick with > Conexant CX23102 that should be supported through the cx231xx driver > Rafael Micro R828D supported by the r820t driver > Panasonic MN88473 supported by the mn88473 driver > It was not recognized by the latest kernel versions 4.8-4.10. > If I can ever help you to integrate this device in your work, > I would be happy! can you show us the USB vendor/device ID of this device (please run "lsusb -vv" and paste the whole block which belongs to your device)? it seems that the required card definition is missing in drivers/media/usb/cx231xx/cx231xx-cards.c along with some code that connects the tuner and demodulator in drivers/media/usb/cx231xx/cx231xx-dvb.c (there may be more TODOs: for example fiddling with GPIOs, but if you're lucky this is not required) Regards, Martin -- 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] dib7000p: avoid division by zero
dib7000p_read_word() may return zero on i2c errors, resulting in
dib7000p_get_internal_freq() returning zero.
So don't divide by the result of dib7000p_get_internal_freq()
without checking it for zero in dib7000p_set_dds().
On one of my machines the device
ID 2304:0229 Pinnacle Systems, Inc. PCTV Dual DVB-T 2001e
about once a day/every two days gets into a state, where
most (all?) I2C reads return with an error. Tuning during this
state will result in a divide by zero without this patch.
This patch doesn't fix the root cause for the device getting
into a bad state, but it allows me to unload/reload the drivers,
bringing it back into a usable state.
Signed-off-by: Martin Wache <m.wa...@gmx.net>
---
drivers/media/dvb-frontends/dib7000p.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/dib7000p.c
b/drivers/media/dvb-frontends/dib7000p.c
index a27c000..3815ea5 100644
--- a/drivers/media/dvb-frontends/dib7000p.c
+++ b/drivers/media/dvb-frontends/dib7000p.c
@@ -805,13 +805,19 @@ static int dib7000p_set_agc_config(struct dib7000p_state
*state, u8 band)
return 0;
}
-static void dib7000p_set_dds(struct dib7000p_state *state, s32 offset_khz)
+static int dib7000p_set_dds(struct dib7000p_state *state, s32 offset_khz)
{
u32 internal = dib7000p_get_internal_freq(state);
- s32 unit_khz_dds_val = 67108864 / (internal); /* 2**26 / Fsampling is
the unit 1KHz offset */
+ s32 unit_khz_dds_val;
u32 abs_offset_khz = ABS(offset_khz);
u32 dds = state->cfg.bw->ifreq & 0x1ff;
u8 invert = !!(state->cfg.bw->ifreq & (1 << 25));
+ if (internal == 0) {
+ pr_warn("DIB7000P: dib7000p_get_internal_freq returned 0\n");
+ return -1;
+ }
+ /* 2**26 / Fsampling is the unit 1KHz offset */
+ unit_khz_dds_val = 67108864 / (internal);
dprintk("setting a frequency offset of %dkHz internal freq = %d invert
= %d\n", offset_khz, internal, invert);
@@ -828,6 +834,7 @@ static void dib7000p_set_dds(struct dib7000p_state *state,
s32 offset_khz)
dib7000p_write_word(state, 21, (u16) (((dds >> 16) & 0x1ff) |
(0 << 10) | (invert << 9)));
dib7000p_write_word(state, 22, (u16) (dds & 0x));
}
+ return 0;
}
static int dib7000p_agc_startup(struct dvb_frontend *demod)
@@ -867,7 +874,9 @@ static int dib7000p_agc_startup(struct dvb_frontend *demod)
frequency_offset = (s32)frequency_tuner / 1000 -
ch->frequency / 1000;
}
- dib7000p_set_dds(state, frequency_offset);
+ if (dib7000p_set_dds(state, frequency_offset) < 0)
+ return -1;
+
ret = 7;
(*agc_state)++;
break;
--
2.7.4
--
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 2/2] mn88473: refactor and fix statistics
On Sun, Nov 13, 2016 at 10:29 AM, Antti Palosaari <cr...@iki.fi> wrote: > Remove DVB-T2 BER as it does not work at all and I didn't find > how to fix. > > Fix DVB-T and DVB-C BER. It seems to return new some realistic > looking values. > > Use (1 << 64) base for CNR calculations to keep it in line with > dvb logarithm functions. > > Move all statistic logic to mn88473_read_status() function. > > Use regmap_bulk_read() for reading multiple registers as a one go. > > And many more and less minor changes. > > Cc: Martin Blumenstingl <martin.blumensti...@googlemail.com> > Signed-off-by: Antti Palosaari <cr...@iki.fi> Tested-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> Tested successfully on DVB-C (only, since DVB-T2 is unavailable and DVB-T reception is *very* bad here). -- 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 2/6] ipr: use pci_irq_allocate_vectors
>>>>> "Christoph" == Christoph Hellwig <h...@lst.de> writes: Christoph> Switch the ipr driver to use pci_alloc_irq_vectors. We need Christoph> to two calls to pci_alloc_irq_vectors as ipr only supports Christoph> multiple MSI-X vectors, but not multiple MSI vectors. Christoph> Otherwise this cleans up a lot of cruft and allows to use a Christoph> common request_irq loop for irq types, which happens to only Christoph> iterate over a single line in the non MSI-X case. Applied to 4.10/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- 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/6] arcmsr: use pci_alloc_irq_vectors
>>>>> "Christoph" == Christoph Hellwig <h...@lst.de> writes: Christoph> Switch the arcmsr driver to use pci_alloc_irq_vectors. We Christoph> need to two calls to pci_alloc_irq_vectors as arcmsr only Christoph> supports multiple MSI-X vectors, but not multiple MSI Christoph> vectors. Christoph> Otherwise this cleans up a lot of cruft and allows to use a Christoph> common request_irq loop for irq types, which happens to only Christoph> iterate over a single line in the non MSI-X case. Applied to 4.10/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- 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
[RFC] add DVBv5 statistics support to mn88473
This patch tries to add DVBv5 statistics support to the mn88473 DVB frontend driver. Special thanks to Benjamin Larsson (who has documented the registers in the LinuxTV wiki: [0]) and to a user with the nickname "dongs" in the #linuxtv IRC channel (who provided more details about the MN88473). There are multiple reasons why I decided to send this as RFC: - I do not have any hardware signal generator, so I can only test with what I have available - a quick test on DVB-C and DVB-T shows that CNR seems correct (DVB-T2 is untested because it is not available in my area... yet) - signal strength seems to be too low (compared to my em28xx device) - I am not sure whether my implementation for bit errors and block errors is correct [0] https://www.linuxtv.org/wiki/index.php/Panasonic_MN88472 Martin Blumenstingl (1): media: mn88473: add DVBv5 statistics support drivers/media/dvb-frontends/mn88473.c | 485 ++--- drivers/media/dvb-frontends/mn88473_priv.h | 1 + 2 files changed, 445 insertions(+), 41 deletions(-) -- 2.10.0 -- 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
[RFC] media: mn88473: add DVBv5 statistics support
Implement DVBv5 statistics support for DVB-T, DVB-T2 and DVB-C. All
information was taken from the LinuxTV wiki, where Benjamin Larsson has
documented all registers:
https://www.linuxtv.org/wiki/index.php/Panasonic_MN88472
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
drivers/media/dvb-frontends/mn88473.c | 485 ++---
drivers/media/dvb-frontends/mn88473_priv.h | 1 +
2 files changed, 445 insertions(+), 41 deletions(-)
diff --git a/drivers/media/dvb-frontends/mn88473.c
b/drivers/media/dvb-frontends/mn88473.c
index 451974a..c8dc9d3 100644
--- a/drivers/media/dvb-frontends/mn88473.c
+++ b/drivers/media/dvb-frontends/mn88473.c
@@ -234,13 +234,388 @@ err:
return ret;
}
+static int mn88473_update_ber_stat_t_c(struct dvb_frontend *fe,
+ enum fe_status *status)
+{
+ struct i2c_client *client = fe->demodulator_priv;
+ struct mn88473_dev *dev = i2c_get_clientdata(client);
+ struct dtv_frontend_properties *c = >dtv_property_cache;
+ int ret;
+ u64 total;
+ unsigned int uitmp, value, errors;
+
+ if (*status & FE_HAS_LOCK) {
+ ret = regmap_read(dev->regmap[0], 0x5b, );
+ if (ret)
+ goto err;
+
+ ret = regmap_read(dev->regmap[0], 0xdf, );
+ if (ret)
+ goto err;
+
+ value &= uitmp;
+ ret = regmap_write(dev->regmap[0], 0x5b, value);
+ if (ret)
+ goto err;
+
+ ret = regmap_read(dev->regmap[0], 0x60, );
+ if (ret)
+ goto err;
+
+ value &= 0xf0;
+ value |= 0x5;
+ ret = regmap_write(dev->regmap[0], 0x60, value);
+ if (ret)
+ goto err;
+
+ ret = regmap_read(dev->regmap[0], 0x92, );
+ if (ret)
+ goto err;
+
+ errors = uitmp << 16;
+
+ ret = regmap_read(dev->regmap[0], 0x93, );
+ if (ret)
+ goto err;
+
+ errors |= uitmp << 8;
+
+ ret = regmap_read(dev->regmap[0], 0x94, );
+ if (ret)
+ goto err;
+
+ errors |= uitmp;
+
+ ret = regmap_read(dev->regmap[0], 0x95, );
+ if (ret)
+ goto err;
+
+ total = uitmp << 8;
+
+ ret = regmap_read(dev->regmap[0], 0x96, );
+ if (ret)
+ goto err;
+
+ total |= uitmp;
+
+ /* probably: (bytes -> bit) * (sizeof(TS packet) - 1) */
+ total *= 8 * 203;
+
+ c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_error.stat[0].uvalue += errors;
+ c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+ c->post_bit_count.stat[0].uvalue += total;
+ } else {
+ c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+ }
+
+ return 0;
+
+err:
+ dev_dbg(>dev, "%s failed=%d\n", __func__, ret);
+ return ret;
+}
+
+static int mn88473_update_ber_stat_t2(struct dvb_frontend *fe,
+ enum fe_status *status)
+{
+ struct i2c_client *client = fe->demodulator_priv;
+ struct mn88473_dev *dev = i2c_get_clientdata(client);
+ struct dtv_frontend_properties *c = >dtv_property_cache;
+ int ret;
+ u64 total;
+ unsigned int uitmp, value, berlen, fec_type_m, errors;
+ static u16 fec_type_m_tbl0[] = {
+ 32400, 38880, 43200, 48600, 51840, 54000, 0
+ };
+ static u16 fec_type_m_tbl1[] = {
+ 28800, 38880, 43200, 47520, 50400, 53280, 0
+ };
+
+ if (*status & FE_HAS_LOCK) {
+ ret = regmap_read(dev->regmap[2], 0x82, );
+ if (ret)
+ goto err;
+
+ value |= 0x20;
+ value &= 0xef;
+ ret = regmap_write(dev->regmap[2], 0x82, value);
+ if (ret)
+ goto err;
+
+ ret = regmap_read(dev->regmap[2], 0xba, );
+ if (ret)
+ goto err;
+
+ errors = uitmp << 16;
+
+ ret = regmap_read(dev->regmap[2], 0xbb, );
+ if (ret)
+ goto err;
+
+ errors |= uitmp << 8;
+
+ ret = regmap_read(dev->regmap[2], 0xbc, );
+ if (ret)
+ goto err;
+
+ errors |= uitmp;
+
+ ret = regmap_read(dev->regmap[2], 0x83,
Re: [PATCH 1/6] arcmsr: use pci_alloc_irq_vectors
>>>>> "Christoph" == Christoph Hellwig <h...@lst.de> writes: Christoph> Switch the arcmsr driver to use pci_alloc_irq_vectors. We Christoph> need to two calls to pci_alloc_irq_vectors as arcmsr only Christoph> supports multiple MSI-X vectors, but not multiple MSI Christoph> vectors. Christoph> Otherwise this cleans up a lot of cruft and allows to use a Christoph> common request_irq loop for irq types, which happens to only Christoph> iterate over a single line in the non MSI-X case. Ching: Please test and review. Thanks! -- Martin K. Petersen Oracle Linux Engineering -- 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 2/6] ipr: use pci_irq_allocate_vectors
>>>>> "Christoph" == Christoph Hellwig <h...@lst.de> writes: Christoph> Switch the ipr driver to use pci_alloc_irq_vectors. We need Christoph> to two calls to pci_alloc_irq_vectors as ipr only supports Christoph> multiple MSI-X vectors, but not multiple MSI vectors. Christoph> Otherwise this cleans up a lot of cruft and allows to use a Christoph> common request_irq loop for irq types, which happens to only Christoph> iterate over a single line in the non MSI-X case. Brian, Gabriel: Please test and review. Thanks! -- Martin K. Petersen Oracle Linux Engineering -- 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 v5 1/6] pinctrl: amlogic: gxbb: add the IR remote input pin
This adds the IR remote receiver to the AO domain devices.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Reviewed-by: Kevin Hilman <khil...@baylibre.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index cb4d6ad..ff900d1 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -225,6 +225,8 @@ static const unsigned int i2c_sda_ao_pins[] =
{PIN(GPIOAO_5, 0) };
static const unsigned int i2c_slave_sck_ao_pins[] = {PIN(GPIOAO_4, 0) };
static const unsigned int i2c_slave_sda_ao_pins[] = {PIN(GPIOAO_5, 0) };
+static const unsigned int remote_input_ao_pins[] = {PIN(GPIOAO_7, 0) };
+
static struct meson_pmx_group meson_gxbb_periphs_groups[] = {
GPIO_GROUP(GPIOZ_0, EE_OFF),
GPIO_GROUP(GPIOZ_1, EE_OFF),
@@ -432,6 +434,7 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
GROUP(i2c_sda_ao, 0, 5),
GROUP(i2c_slave_sck_ao, 0, 2),
GROUP(i2c_slave_sda_ao, 0, 1),
+ GROUP(remote_input_ao, 0, 0),
};
static const char * const gpio_periphs_groups[] = {
@@ -521,6 +524,10 @@ static const char * const i2c_slave_ao_groups[] = {
"i2c_slave_sdk_ao", "i2c_slave_sda_ao",
};
+static const char * const remote_input_ao_groups[] = {
+ "remote_input_ao",
+};
+
static struct meson_pmx_func meson_gxbb_periphs_functions[] = {
FUNCTION(gpio_periphs),
FUNCTION(emmc),
@@ -537,6 +544,7 @@ static struct meson_pmx_func meson_gxbb_aobus_functions[] =
{
FUNCTION(uart_ao_b),
FUNCTION(i2c_ao),
FUNCTION(i2c_slave_ao),
+ FUNCTION(remote_input_ao),
};
static struct meson_bank meson_gxbb_periphs_banks[] = {
--
2.9.3
--
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 v5 0/6] Add Meson 8b / GXBB support to the IR driver
Newer Amlogic platforms (Meson 8b and GXBB) use a slightly different register layout for their Infrared Remoete Controller. The decoder mode is now configured in another register. Without the changes to the meson-ir driver we are simply getting incorrect "durations" reported from the hardware (because the hardware is not in time measurement aka software decode mode). This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Changes in v5: - changed pin function and group names to remote_input_ao so they match with the datasheet Tested-by: Neil Armstrong <narmstr...@baylibre.com> [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 Martin Blumenstingl (3): pinctrl: amlogic: gxbb: add the IR remote input pin ARM64: dts: amlogic: add the input pin for the IR remote ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards Neil Armstrong (3): dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings media: rc: meson-ir: Add support for newer versions of the IR decoder ARM64: dts: meson-gxbb: Add Infrared Remote Controller decoder .../devicetree/bindings/media/meson-ir.txt | 5 +++- .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 + .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 14 +++ drivers/media/rc/meson-ir.c| 29 ++ drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 8 ++ 7 files changed, 68 insertions(+), 6 deletions(-) -- 2.9.3 -- 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 v5 0/6] Add Meson 8b / GXBB support to the IR driver
Newer Amlogic platforms (Meson 8b and GXBB) use a slightly different register layout for their Infrared Remoete Controller. The decoder mode is now configured in another register. Without the changes to the meson-ir driver we are simply getting incorrect "durations" reported from the hardware (because the hardware is not in time measurement aka software decode mode). This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Changes in v5: - changed pin function and group names to remote_input_ao so they match with the datasheet Tested-by: Neil Armstrong <narmstr...@baylibre.com> [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 Martin Blumenstingl (3): pinctrl: amlogic: gxbb: add the IR remote input pin ARM64: dts: amlogic: add the input pin for the IR remote ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards Neil Armstrong (3): dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings media: rc: meson-ir: Add support for newer versions of the IR decoder ARM64: dts: meson-gxbb: Add Infrared Remote Controller decoder .../devicetree/bindings/media/meson-ir.txt | 5 +++- .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 + .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 14 +++ drivers/media/rc/meson-ir.c| 29 ++ drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 8 ++ 7 files changed, 68 insertions(+), 6 deletions(-) -- 2.9.3 -- 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 v5 3/6] dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings
From: Neil Armstrong <narmstr...@baylibre.com> New bindings are needed as the register layout on the newer platforms is slightly different compared to Meson6b. Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> Acked-by: Rob Herring <r...@kernel.org> --- Documentation/devicetree/bindings/media/meson-ir.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt index 407848e..e7e3f3c 100644 --- a/Documentation/devicetree/bindings/media/meson-ir.txt +++ b/Documentation/devicetree/bindings/media/meson-ir.txt @@ -1,7 +1,10 @@ * Amlogic Meson IR remote control receiver Required properties: - - compatible : should be "amlogic,meson6-ir" + - compatible : depending on the platform this should be one of: + - "amlogic,meson6-ir" + - "amlogic,meson8b-ir" + - "amlogic,meson-gxbb-ir" - reg : physical base address and length of the device registers - interrupts : a single specifier for the interrupt from the device -- 2.9.3 -- 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 v5 5/6] ARM64: dts: meson-gxbb: Add Infrared Remote Controller decoder
From: Neil Armstrong <narmstr...@baylibre.com>
This adds the Infrared Remote Controller node so boards with an IR
remote can simply enable it.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 96f4574..1cdc059 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -226,6 +226,13 @@
clocks = <>;
status = "disabled";
};
+
+ ir: ir@580 {
+ compatible = "amlogic,meson-gxbb-ir";
+ reg = <0x0 0x00580 0x0 0x40>;
+ interrupts = ;
+ status = "disabled";
+ };
};
periphs: periphs@c8834000 {
--
2.9.3
--
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 v5 2/6] ARM64: dts: amlogic: add the input pin for the IR remote
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 4f42316..96f4574 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -210,6 +210,13 @@
function = "uart_ao";
};
};
+
+ remote_input_ao_pins: remote_input_ao {
+ mux {
+ groups = "remote_input_ao";
+ function = "remote_input_ao";
+ };
+ };
};
uart_AO: serial@4c0 {
--
2.9.3
--
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 v5 6/6] ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards
Enable the Infrared Remote Controller on boards which have an Infrared
receiver.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 6 ++
3 files changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index cba3ea1..d4823f4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -161,3 +161,9 @@
vmmc-supply = <>;
vmmcq-sumpply = <>;
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_input_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index e118754..4538e5a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -143,3 +143,9 @@
vmmc-supply = <_3v3>;
vmmcq-sumpply = <_boot>;
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_input_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 54bb7c7..560770e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -60,3 +60,9 @@
pinctrl-names = "default";
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_input_ao_pins>;
+ pinctrl-names = "default";
+};
--
2.9.3
--
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 v5 4/6] media: rc: meson-ir: Add support for newer versions of the IR decoder
From: Neil Armstrong <narmstr...@baylibre.com>
Newer SoCs (Meson 8b and GXBB) are using REG2 (offset 0x20) instead of
REG1 to configure the decoder mode. This makes it necessary to
introduce new bindings so the driver knows which register has to be
used.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
Acked-by: Kevin Hilman <khil...@baylibre.com>
---
drivers/media/rc/meson-ir.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index fcc3b82..003fff0 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -24,6 +24,7 @@
#define DRIVER_NAME"meson-ir"
+/* valid on all Meson platforms */
#define IR_DEC_LDR_ACTIVE 0x00
#define IR_DEC_LDR_IDLE0x04
#define IR_DEC_LDR_REPEAT 0x08
@@ -32,12 +33,21 @@
#define IR_DEC_FRAME 0x14
#define IR_DEC_STATUS 0x18
#define IR_DEC_REG10x1c
+/* only available on Meson 8b and newer */
+#define IR_DEC_REG20x20
#define REG0_RATE_MASK (BIT(11) - 1)
-#define REG1_MODE_MASK (BIT(7) | BIT(8))
-#define REG1_MODE_NEC (0 << 7)
-#define REG1_MODE_GENERAL (2 << 7)
+#define DECODE_MODE_NEC0x0
+#define DECODE_MODE_RAW0x2
+
+/* Meson 6b uses REG1 to configure the mode */
+#define REG1_MODE_MASK GENMASK(8, 7)
+#define REG1_MODE_SHIFT7
+
+/* Meson 8b / GXBB use REG2 to configure the mode */
+#define REG2_MODE_MASK GENMASK(3, 0)
+#define REG2_MODE_SHIFT0
#define REG1_TIME_IV_SHIFT 16
#define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT)
@@ -158,8 +168,15 @@ static int meson_ir_probe(struct platform_device *pdev)
/* Reset the decoder */
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, REG1_RESET);
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, 0);
- /* Set general operation mode */
- meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, REG1_MODE_GENERAL);
+
+ /* Set general operation mode (= raw/software decoding) */
+ if (of_device_is_compatible(node, "amlogic,meson6-ir"))
+ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK,
+ DECODE_MODE_RAW << REG1_MODE_SHIFT);
+ else
+ meson_ir_set_mask(ir, IR_DEC_REG2, REG2_MODE_MASK,
+ DECODE_MODE_RAW << REG2_MODE_SHIFT);
+
/* Set rate */
meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1);
/* IRQ on rising and falling edges */
@@ -197,6 +214,8 @@ static int meson_ir_remove(struct platform_device *pdev)
static const struct of_device_id meson_ir_match[] = {
{ .compatible = "amlogic,meson6-ir" },
+ { .compatible = "amlogic,meson8b-ir" },
+ { .compatible = "amlogic,meson-gxbb-ir" },
{ },
};
--
2.9.3
--
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 v4 0/6] Add Meson 8b / GXBB support to the IR driver
Newer Amlogic platforms (Meson 8b and GXBB) use a slightly different register layout for their Infrared Remoete Controller. The decoder mode is now configured in another register. Without the changes to the meson-ir driver we are simply getting incorrect "durations" reported from the hardware (because the hardware is not in time measurement aka software decode mode). This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Changes in v4: - added support for pinctrl configuration which makes it possible to use the IR decoder when doing a cold-boot. Without these pinctrl changes the IR decoder was only working when booting into stock Android, then rebooting and booting the mainline kernel (with the other patches from this series). Thanks to Kevin Hilman for spotting this issue. - rebased dts changes to Kevin's v4.8/integ branch As discussed on IRC (thanks Neil): Tested-by: Neil Armstrong <narmstr...@baylibre.com> [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 Martin Blumenstingl (3): pinctrl: amlogic: gxbb: add the IR remote pin ARM64: dts: amlogic: add the pin for the IR remote ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards Neil Armstrong (3): dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings media: rc: meson-ir: Add support for newer versions of the IR decoder ARM64: dts: meson-gxbb: Add Infrared Remote Controller decoder .../devicetree/bindings/media/meson-ir.txt | 5 +++- .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 + .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 6 + arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 14 +++ drivers/media/rc/meson-ir.c| 29 ++ drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 8 ++ 7 files changed, 68 insertions(+), 6 deletions(-) -- 2.9.3 -- 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 v4 1/6] pinctrl: amlogic: gxbb: add the IR remote pin
This adds the IR remote receiver to the AO domain devices.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index cb4d6ad..8fffb31 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -225,6 +225,8 @@ static const unsigned int i2c_sda_ao_pins[] =
{PIN(GPIOAO_5, 0) };
static const unsigned int i2c_slave_sck_ao_pins[] = {PIN(GPIOAO_4, 0) };
static const unsigned int i2c_slave_sda_ao_pins[] = {PIN(GPIOAO_5, 0) };
+static const unsigned int ir_in_ao_pins[] = {PIN(GPIOAO_7, 0) };
+
static struct meson_pmx_group meson_gxbb_periphs_groups[] = {
GPIO_GROUP(GPIOZ_0, EE_OFF),
GPIO_GROUP(GPIOZ_1, EE_OFF),
@@ -432,6 +434,7 @@ static struct meson_pmx_group meson_gxbb_aobus_groups[] = {
GROUP(i2c_sda_ao, 0, 5),
GROUP(i2c_slave_sck_ao, 0, 2),
GROUP(i2c_slave_sda_ao, 0, 1),
+ GROUP(ir_in_ao, 0, 0),
};
static const char * const gpio_periphs_groups[] = {
@@ -521,6 +524,10 @@ static const char * const i2c_slave_ao_groups[] = {
"i2c_slave_sdk_ao", "i2c_slave_sda_ao",
};
+static const char * const ir_in_ao_groups[] = {
+ "ir_in_ao",
+};
+
static struct meson_pmx_func meson_gxbb_periphs_functions[] = {
FUNCTION(gpio_periphs),
FUNCTION(emmc),
@@ -537,6 +544,7 @@ static struct meson_pmx_func meson_gxbb_aobus_functions[] =
{
FUNCTION(uart_ao_b),
FUNCTION(i2c_ao),
FUNCTION(i2c_slave_ao),
+ FUNCTION(ir_in_ao),
};
static struct meson_bank meson_gxbb_periphs_banks[] = {
--
2.9.3
--
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 v4 4/6] media: rc: meson-ir: Add support for newer versions of the IR decoder
From: Neil Armstrong <narmstr...@baylibre.com>
Newer SoCs (Meson 8b and GXBB) are using REG2 (offset 0x20) instead of
REG1 to configure the decoder mode. This makes it necessary to
introduce new bindings so the driver knows which register has to be
used.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
drivers/media/rc/meson-ir.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index fcc3b82..003fff0 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -24,6 +24,7 @@
#define DRIVER_NAME"meson-ir"
+/* valid on all Meson platforms */
#define IR_DEC_LDR_ACTIVE 0x00
#define IR_DEC_LDR_IDLE0x04
#define IR_DEC_LDR_REPEAT 0x08
@@ -32,12 +33,21 @@
#define IR_DEC_FRAME 0x14
#define IR_DEC_STATUS 0x18
#define IR_DEC_REG10x1c
+/* only available on Meson 8b and newer */
+#define IR_DEC_REG20x20
#define REG0_RATE_MASK (BIT(11) - 1)
-#define REG1_MODE_MASK (BIT(7) | BIT(8))
-#define REG1_MODE_NEC (0 << 7)
-#define REG1_MODE_GENERAL (2 << 7)
+#define DECODE_MODE_NEC0x0
+#define DECODE_MODE_RAW0x2
+
+/* Meson 6b uses REG1 to configure the mode */
+#define REG1_MODE_MASK GENMASK(8, 7)
+#define REG1_MODE_SHIFT7
+
+/* Meson 8b / GXBB use REG2 to configure the mode */
+#define REG2_MODE_MASK GENMASK(3, 0)
+#define REG2_MODE_SHIFT0
#define REG1_TIME_IV_SHIFT 16
#define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT)
@@ -158,8 +168,15 @@ static int meson_ir_probe(struct platform_device *pdev)
/* Reset the decoder */
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, REG1_RESET);
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, 0);
- /* Set general operation mode */
- meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, REG1_MODE_GENERAL);
+
+ /* Set general operation mode (= raw/software decoding) */
+ if (of_device_is_compatible(node, "amlogic,meson6-ir"))
+ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK,
+ DECODE_MODE_RAW << REG1_MODE_SHIFT);
+ else
+ meson_ir_set_mask(ir, IR_DEC_REG2, REG2_MODE_MASK,
+ DECODE_MODE_RAW << REG2_MODE_SHIFT);
+
/* Set rate */
meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1);
/* IRQ on rising and falling edges */
@@ -197,6 +214,8 @@ static int meson_ir_remove(struct platform_device *pdev)
static const struct of_device_id meson_ir_match[] = {
{ .compatible = "amlogic,meson6-ir" },
+ { .compatible = "amlogic,meson8b-ir" },
+ { .compatible = "amlogic,meson-gxbb-ir" },
{ },
};
--
2.9.3
--
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 v4 5/6] ARM64: dts: meson-gxbb: Add Infrared Remote Controller decoder
From: Neil Armstrong <narmstr...@baylibre.com>
This adds the Infrared Remote Controller node so boards with an IR
remote can simply enable it.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 72df302..7070719 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -226,6 +226,13 @@
clocks = <>;
status = "disabled";
};
+
+ ir: ir@580 {
+ compatible = "amlogic,meson-gxbb-ir";
+ reg = <0x0 0x00580 0x0 0x40>;
+ interrupts = ;
+ status = "disabled";
+ };
};
periphs: periphs@c8834000 {
--
2.9.3
--
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 v4 3/6] dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings
From: Neil Armstrong <narmstr...@baylibre.com> New bindings are needed as the register layout on the newer platforms is slightly different compared to Meson6b. Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> Acked-by: Rob Herring <r...@kernel.org> --- Documentation/devicetree/bindings/media/meson-ir.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt index 407848e..e7e3f3c 100644 --- a/Documentation/devicetree/bindings/media/meson-ir.txt +++ b/Documentation/devicetree/bindings/media/meson-ir.txt @@ -1,7 +1,10 @@ * Amlogic Meson IR remote control receiver Required properties: - - compatible : should be "amlogic,meson6-ir" + - compatible : depending on the platform this should be one of: + - "amlogic,meson6-ir" + - "amlogic,meson8b-ir" + - "amlogic,meson-gxbb-ir" - reg : physical base address and length of the device registers - interrupts : a single specifier for the interrupt from the device -- 2.9.3 -- 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 v4 2/6] ARM64: dts: amlogic: add the pin for the IR remote
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 4f42316..72df302 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -210,6 +210,13 @@
function = "uart_ao";
};
};
+
+ ir_in_ao_pins: ir_in_ao {
+ mux {
+ groups = "ir_in_ao";
+ function = "ir_in_ao";
+ };
+ };
};
uart_AO: serial@4c0 {
--
2.9.3
--
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 v4 6/6] ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards
Enable the Infrared Remote Controller on boards which have an Infrared
receiver.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 6 ++
3 files changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index cba3ea1..9900b87 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -161,3 +161,9 @@
vmmc-supply = <>;
vmmcq-sumpply = <>;
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_in_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index e118754..dc007fe 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -143,3 +143,9 @@
vmmc-supply = <_3v3>;
vmmcq-sumpply = <_boot>;
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_in_ao_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 54bb7c7..45cd3ae 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -60,3 +60,9 @@
pinctrl-names = "default";
};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_in_ao_pins>;
+ pinctrl-names = "default";
+};
--
2.9.3
--
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: em288xx and lna - how to enable?
> Hi, > > I see that my card 292e has LNA support: > https://patchwork.linuxtv.org/patch/23763/ > > but searching I can't find how to enable this the force option > force_lna_activation=1 that the t500 uses isn't recognised > > Please could someone tell me if this is configurable an if so how to > configure it? Turns out I was looking in the wrong place. I found it after more searching - it's part of the API and can be enabled with the dvbv5-zap --lna=1 Regards, M -- 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
em288xx and lna - how to enable?
Hi, I see that my card 292e has LNA support: https://patchwork.linuxtv.org/patch/23763/ but searching I can't find how to enable this the force option force_lna_activation=1 that the t500 uses isn't recognised Please could someone tell me if this is configurable an if so how to configure it? Thanks, M -- 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 v3 4/4] ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards
Enable the Infrared Remote Controller on boards which have an Infrared
receiver.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 4
3 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index b06bf8a..9a451ce 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -120,3 +120,7 @@
vmmc-supply = <_iv>;
voltage-ranges = <1800 3300>;
};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 5dfd849..2650bb7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -102,3 +102,7 @@
voltage-ranges = <1800 3300>;
vmmc-supply = <_iv>;
};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index 54bb7c7..934deb9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -60,3 +60,7 @@
pinctrl-names = "default";
};
+
+ {
+ status = "okay";
+};
--
2.9.0
--
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 v3 0/4] Add Meson 8b / GXBB support to the IR driver
Newer Amlogic platforms (Meson 8b and GXBB) use a slightly different register layout for their Infrared Remoete Controller. The decoder mode is now configured in another register. Without the changes to the meson-ir driver we are simply getting incorrect "durations" reported from the hardware (because the hardware is not in time measurement aka software decode mode). This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Changes in v3: - based on the patches of Neil Armstrong - depending on the platform either the old (default) or new registers (this has to be enabled explicitly by using "amlogic,meson8b-ir" or "amlogic,meson-gxbb-ir") - the changes to arch/arm/boot/dts/meson.dtsi are not part of this series anymore, because the size specified there is valid for the Meson 6b version of the IR decoder - Add the IR decoder to meson-gxbb.dtsi and enable it on the supported boards [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 Martin Blumenstingl (1): ARM64: dts: meson-gxbb: Enable the the IR decoder on supported boards Neil Armstrong (3): dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings media: rc: meson-ir: Add support for newer versions of the IR decoder ARM64: meson-gxbb: Add Infrared Remote Controller decoder .../devicetree/bindings/media/meson-ir.txt | 5 +++- .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 +++ arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 +++ .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 4 +++ arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 7 ++ drivers/media/rc/meson-ir.c| 29 ++ 6 files changed, 47 insertions(+), 6 deletions(-) -- 2.9.0 -- 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 v3 3/4] ARM64: meson-gxbb: Add Infrared Remote Controller decoder
From: Neil Armstrong <narmstr...@baylibre.com>
This adds the Infrared Remote Controller node so boards with an IR
remote can simply enable it.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 6c23965..fa88f80 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -213,6 +213,13 @@
clocks = <>;
status = "disabled";
};
+
+ ir: ir@580 {
+ compatible = "amlogic,meson-gxbb-ir";
+ reg = <0x0 0x00580 0x0 0x40>;
+ interrupts = ;
+ status = "disabled";
+ };
};
periphs: periphs@c8834000 {
--
2.9.0
--
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 v3 1/4] dt-bindings: media: meson-ir: Add Meson8b and GXBB compatible strings
From: Neil Armstrong <narmstr...@baylibre.com> New bindings are needed as the register layout on the newer platforms is slightly different compared to Meson6b. Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- Documentation/devicetree/bindings/media/meson-ir.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt index 407848e..e7e3f3c 100644 --- a/Documentation/devicetree/bindings/media/meson-ir.txt +++ b/Documentation/devicetree/bindings/media/meson-ir.txt @@ -1,7 +1,10 @@ * Amlogic Meson IR remote control receiver Required properties: - - compatible : should be "amlogic,meson6-ir" + - compatible : depending on the platform this should be one of: + - "amlogic,meson6-ir" + - "amlogic,meson8b-ir" + - "amlogic,meson-gxbb-ir" - reg : physical base address and length of the device registers - interrupts : a single specifier for the interrupt from the device -- 2.9.0 -- 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 v3 2/4] media: rc: meson-ir: Add support for newer versions of the IR decoder
From: Neil Armstrong <narmstr...@baylibre.com>
Newer SoCs (Meson 8b and GXBB) are using REG2 (offset 0x20) instead of
REG1 to configure the decoder mode. This makes it necessary to
introduce new bindings so the driver knows which register has to be
used.
Signed-off-by: Neil Armstrong <narmstr...@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
drivers/media/rc/meson-ir.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index fcc3b82..003fff0 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -24,6 +24,7 @@
#define DRIVER_NAME"meson-ir"
+/* valid on all Meson platforms */
#define IR_DEC_LDR_ACTIVE 0x00
#define IR_DEC_LDR_IDLE0x04
#define IR_DEC_LDR_REPEAT 0x08
@@ -32,12 +33,21 @@
#define IR_DEC_FRAME 0x14
#define IR_DEC_STATUS 0x18
#define IR_DEC_REG10x1c
+/* only available on Meson 8b and newer */
+#define IR_DEC_REG20x20
#define REG0_RATE_MASK (BIT(11) - 1)
-#define REG1_MODE_MASK (BIT(7) | BIT(8))
-#define REG1_MODE_NEC (0 << 7)
-#define REG1_MODE_GENERAL (2 << 7)
+#define DECODE_MODE_NEC0x0
+#define DECODE_MODE_RAW0x2
+
+/* Meson 6b uses REG1 to configure the mode */
+#define REG1_MODE_MASK GENMASK(8, 7)
+#define REG1_MODE_SHIFT7
+
+/* Meson 8b / GXBB use REG2 to configure the mode */
+#define REG2_MODE_MASK GENMASK(3, 0)
+#define REG2_MODE_SHIFT0
#define REG1_TIME_IV_SHIFT 16
#define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT)
@@ -158,8 +168,15 @@ static int meson_ir_probe(struct platform_device *pdev)
/* Reset the decoder */
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, REG1_RESET);
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, 0);
- /* Set general operation mode */
- meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, REG1_MODE_GENERAL);
+
+ /* Set general operation mode (= raw/software decoding) */
+ if (of_device_is_compatible(node, "amlogic,meson6-ir"))
+ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK,
+ DECODE_MODE_RAW << REG1_MODE_SHIFT);
+ else
+ meson_ir_set_mask(ir, IR_DEC_REG2, REG2_MODE_MASK,
+ DECODE_MODE_RAW << REG2_MODE_SHIFT);
+
/* Set rate */
meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1);
/* IRQ on rising and falling edges */
@@ -197,6 +214,8 @@ static int meson_ir_remove(struct platform_device *pdev)
static const struct of_device_id meson_ir_match[] = {
{ .compatible = "amlogic,meson6-ir" },
+ { .compatible = "amlogic,meson8b-ir" },
+ { .compatible = "amlogic,meson-gxbb-ir" },
{ },
};
--
2.9.0
--
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 v2 1/2] media: rc: meson-ir: fix enabling raw/soft-decoding mode
According to the datasheet of Meson8b (S805) and GXBB (S905) the decoding mode is configured in AO_MF_IR_DEC_REG2 (offset 0x20) using bits 0-3. The "duration" field may not be set correctly when any of the hardware decoding modes. This can happen while a "default" decoding mode (either set by the bootloader or the chip's default, which uses NEC as it's default) is used. While here, I also added defines for the protocols which can be decoded by the hardware (more work is needed to be actually able to use them though). Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- changes in v1 -> v2: - fixed subject of the patch to include meson-ir - fixed double-shifting of the decoder mode values drivers/media/rc/meson-ir.c | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index fcc3b82..622a4160 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -32,13 +32,10 @@ #define IR_DEC_FRAME 0x14 #define IR_DEC_STATUS 0x18 #define IR_DEC_REG10x1c +#define IR_DEC_REG20x20 #define REG0_RATE_MASK (BIT(11) - 1) -#define REG1_MODE_MASK (BIT(7) | BIT(8)) -#define REG1_MODE_NEC (0 << 7) -#define REG1_MODE_GENERAL (2 << 7) - #define REG1_TIME_IV_SHIFT 16 #define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT) @@ -51,6 +48,20 @@ #define REG1_RESET BIT(0) #define REG1_ENABLEBIT(15) +#define REG2_DEC_MODE_SHIFT0 +#define REG2_DEC_MODE_MASK GENMASK(3, REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_NEC 0x0 +#define REG2_DEC_MODE_RAW 0x2 +#define REG2_DEC_MODE_THOMSON 0x4 +#define REG2_DEC_MODE_TOSHIBA 0x5 +#define REG2_DEC_MODE_SONY 0x6 +#define REG2_DEC_MODE_RC5 0x7 +#define REG2_DEC_MODE_RC6 0x9 +#define REG2_DEC_MODE_RCMM 0xa +#define REG2_DEC_MODE_DUOKAN 0xb +#define REG2_DEC_MODE_COMCAST 0xe +#define REG2_DEC_MODE_SANYO0xf + #define STATUS_IR_DEC_IN BIT(8) #define MESON_TRATE10 /* us */ @@ -158,8 +169,9 @@ static int meson_ir_probe(struct platform_device *pdev) /* Reset the decoder */ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, REG1_RESET); meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, 0); - /* Set general operation mode */ - meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, REG1_MODE_GENERAL); + /* Enable raw/soft-decode mode */ + meson_ir_set_mask(ir, IR_DEC_REG2, REG2_DEC_MODE_MASK, + REG2_DEC_MODE_RAW << REG2_DEC_MODE_SHIFT); /* Set rate */ meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1); /* IRQ on rising and falling edges */ -- 2.9.0 -- 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 v2 2/2] ARM: dts: meson: fixed size of the meson-ir registers
According to the reference driver (and the datasheet of the newer
Meson8b/S805 and GXBB/S905 SoCs) there are 14 registers, each 32 bit
wide.
Adjust the register size to reflect that, as register offset 0x20 is
now also needed by the meson-ir driver.
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
changes in v1 -> v2:
- new patch, this is needed because we are now trying to read/write
offset 0x20 which is beyond the space which was reserved previously
arch/arm/boot/dts/meson.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 8c77c87..0f5722a 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -147,7 +147,7 @@
ir_receiver: ir-receiver@c8100480 {
compatible= "amlogic,meson6-ir";
- reg = <0xc8100480 0x20>;
+ reg = <0xc8100480 0x34>;
interrupts = <0 15 1>;
status = "disabled";
};
--
2.9.0
--
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
[v2] media: rc: fix Meson IR decoder
The meson-ir driver uses the wrong offset (at least according to Amlogic's reference driver as well as the datasheets of the Meson8b/S805 and GXBB/S905). This means that we are getting incorrect durations (REG1_TIME_IV) reported from the hardware. This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Please note that I was only able to test this on an GXBB/S905 based device (due to lack of other hardware). [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 -- 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: rc: use the correct register offset and bits to enable raw mode
According to the datasheet of Meson8b (S805) and GXBB (S905) the decoding mode is configured in AO_MF_IR_DEC_REG2 (offset 0x20) using bits 0-3. The "duration" field may not be set correctly when any of the hardware decoding modes. This can happen while a "default" decoding mode (either set by the bootloader or the chip's default, which uses NEC as it's default) is used. While here, I also added defines for the protocols which can be decoded by the hardware (more work is needed to be actually able to use them though). Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/media/rc/meson-ir.c | 24 ++-- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c index fcc3b82..662d065 100644 --- a/drivers/media/rc/meson-ir.c +++ b/drivers/media/rc/meson-ir.c @@ -32,13 +32,10 @@ #define IR_DEC_FRAME 0x14 #define IR_DEC_STATUS 0x18 #define IR_DEC_REG10x1c +#define IR_DEC_REG20x20 #define REG0_RATE_MASK (BIT(11) - 1) -#define REG1_MODE_MASK (BIT(7) | BIT(8)) -#define REG1_MODE_NEC (0 << 7) -#define REG1_MODE_GENERAL (2 << 7) - #define REG1_TIME_IV_SHIFT 16 #define REG1_TIME_IV_MASK ((BIT(13) - 1) << REG1_TIME_IV_SHIFT) @@ -51,6 +48,20 @@ #define REG1_RESET BIT(0) #define REG1_ENABLEBIT(15) +#define REG2_DEC_MODE_SHIFT0 +#define REG2_DEC_MODE_MASK GENMASK(3, REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_NEC (0x0 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_RAW (0x2 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_THOMSON (0x4 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_TOSHIBA (0x5 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_SONY (0x6 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_RC5 (0x7 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_RC6 (0x9 << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_RCMM (0xa << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_DUOKAN (0xb << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_COMCAST (0xe << REG2_DEC_MODE_SHIFT) +#define REG2_DEC_MODE_SANYO(0xf << REG2_DEC_MODE_SHIFT) + #define STATUS_IR_DEC_IN BIT(8) #define MESON_TRATE10 /* us */ @@ -158,8 +169,9 @@ static int meson_ir_probe(struct platform_device *pdev) /* Reset the decoder */ meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, REG1_RESET); meson_ir_set_mask(ir, IR_DEC_REG1, REG1_RESET, 0); - /* Set general operation mode */ - meson_ir_set_mask(ir, IR_DEC_REG1, REG1_MODE_MASK, REG1_MODE_GENERAL); + /* Enable raw/soft-decode mode */ + meson_ir_set_mask(ir, IR_DEC_REG2, REG2_DEC_MODE_MASK, + REG2_DEC_MODE_RAW << REG2_DEC_MODE_SHIFT); /* Set rate */ meson_ir_set_mask(ir, IR_DEC_REG0, REG0_RATE_MASK, MESON_TRATE - 1); /* IRQ on rising and falling edges */ -- 2.9.0 -- 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
media: rc: fix Meson IR decoder
The meson-ir driver uses the wrong offset (at least according to Amlogic's reference driver as well as the datasheets of the Meson8b/S805 and GXBB/S905). This means that we are getting incorrect durations (REG1_TIME_IV) reported from the hardware. This problem was also noticed by some people trying to use this on an ODROID-C1 and ODROID-C2 - the workaround there (probably because the datasheets were not publicy available yet at that time) was to switch to ir_raw_event_store_edge (which leaves it up to the kernel to measure the duration of a pulse). See [0] and [1] for the corresponding patches. Please note that I was only able to test this on an GXBB/S905 based device (due to lack of other hardware). [0] https://github.com/erdoukki/linux-amlogic-1/commit/969b2e2242fb14a13cb651f9a1cf771b599c958b [1] http://forum.odroid.com/viewtopic.php?f=135=20504 -- 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 v3] [media] rtl2832: add support for slave ts pid filter
The rtl2832 demod has 2 sets of PID filters. This patch enables
the filter support when using a slave demod.
Signed-off-by: Benjamin Larsson <benja...@southpole.se>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
changes since v2:
- rebased to make the patch apply again
- removed explicit initialization of dev->slave_ts as
rtl2832_slave_ts_ctrl is always called when activating the frontend
This patch was originally written by Benjamin Larsson, all I did was
rebasing the patch and to extend the dev_dbg statements with the
slave_ts information.
This also supersedes the following patch:
https://patchwork.linuxtv.org/patch/34358/
drivers/media/dvb-frontends/rtl2832.c | 25 +++--
drivers/media/dvb-frontends/rtl2832_priv.h | 1 +
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index bfb6bee..c16c69e 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -947,6 +947,8 @@ static int rtl2832_slave_ts_ctrl(struct i2c_client *client,
bool enable)
goto err;
}
+ dev->slave_ts = enable;
+
return 0;
err:
dev_dbg(>dev, "failed=%d\n", ret);
@@ -960,7 +962,7 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend *fe,
int onoff)
int ret;
u8 u8tmp;
- dev_dbg(>dev, "onoff=%d\n", onoff);
+ dev_dbg(>dev, "onoff=%d, slave_ts=%d\n", onoff, dev->slave_ts);
/* enable / disable PID filter */
if (onoff)
@@ -968,7 +970,10 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend
*fe, int onoff)
else
u8tmp = 0x00;
- ret = regmap_update_bits(dev->regmap, 0x061, 0xc0, u8tmp);
+ if (dev->slave_ts)
+ ret = regmap_update_bits(dev->regmap, 0x021, 0xc0, u8tmp);
+ else
+ ret = regmap_update_bits(dev->regmap, 0x061, 0xc0, u8tmp);
if (ret)
goto err;
@@ -986,8 +991,8 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8
index, u16 pid,
int ret;
u8 buf[4];
- dev_dbg(>dev, "index=%d pid=%04x onoff=%d\n",
- index, pid, onoff);
+ dev_dbg(>dev, "index=%d pid=%04x onoff=%d slave_ts=%d\n",
+ index, pid, onoff, dev->slave_ts);
/* skip invalid PIDs (0x2000) */
if (pid > 0x1fff || index > 32)
@@ -1003,14 +1008,22 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe,
u8 index, u16 pid,
buf[1] = (dev->filters >> 8) & 0xff;
buf[2] = (dev->filters >> 16) & 0xff;
buf[3] = (dev->filters >> 24) & 0xff;
- ret = regmap_bulk_write(dev->regmap, 0x062, buf, 4);
+
+ if (dev->slave_ts)
+ ret = regmap_bulk_write(dev->regmap, 0x022, buf, 4);
+ else
+ ret = regmap_bulk_write(dev->regmap, 0x062, buf, 4);
if (ret)
goto err;
/* add PID */
buf[0] = (pid >> 8) & 0xff;
buf[1] = (pid >> 0) & 0xff;
- ret = regmap_bulk_write(dev->regmap, 0x066 + 2 * index, buf, 2);
+
+ if (dev->slave_ts)
+ ret = regmap_bulk_write(dev->regmap, 0x026 + 2 * index, buf, 2);
+ else
+ ret = regmap_bulk_write(dev->regmap, 0x066 + 2 * index, buf, 2);
if (ret)
goto err;
diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h
b/drivers/media/dvb-frontends/rtl2832_priv.h
index c1a8a69..9a6d01a 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -44,6 +44,7 @@ struct rtl2832_dev {
bool sleeping;
struct delayed_work i2c_gate_work;
unsigned long filters; /* PID filter */
+ bool slave_ts;
};
struct rtl2832_reg_entry {
--
2.8.3
--
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/2] [media] rtl28xxu: auto-select more DVB-frontends and tuners
This adds the missing auto-select bits for DVB-frontends and tuners (if MEDIA_SUBDRV_AUTOSELECT is enabled) which are used by the various rtl28xxu devices. The driver itself probes for three more tuners, but it's not actually using any of them: - MEDIA_TUNER_MT2063 - MEDIA_TUNER_MT2266 - MEDIA_TUNER_MXL5007T Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/media/usb/dvb-usb-v2/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig b/drivers/media/usb/dvb-usb-v2/Kconfig index 3dc8ef0..fcecbf7 100644 --- a/drivers/media/usb/dvb-usb-v2/Kconfig +++ b/drivers/media/usb/dvb-usb-v2/Kconfig @@ -127,9 +127,12 @@ config DVB_USB_MXL111SF config DVB_USB_RTL28XXU tristate "Realtek RTL28xxU DVB USB support" depends on DVB_USB_V2 && I2C_MUX + select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT + select DVB_MN88473 if MEDIA_SUBDRV_AUTOSELECT select DVB_RTL2830 select DVB_RTL2832 select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT) + select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT @@ -138,6 +141,8 @@ config DVB_USB_RTL28XXU select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_R820T if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_TUA9001 if MEDIA_SUBDRV_AUTOSELECT help Say Y here to support the Realtek RTL28xxU DVB USB receiver. -- 2.8.2 -- 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 2/2] [media] rtl28xxu: sort the config symbols which are auto-selected
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com> --- drivers/media/usb/dvb-usb-v2/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig b/drivers/media/usb/dvb-usb-v2/Kconfig index fcecbf7..524533d 100644 --- a/drivers/media/usb/dvb-usb-v2/Kconfig +++ b/drivers/media/usb/dvb-usb-v2/Kconfig @@ -133,13 +133,13 @@ config DVB_USB_RTL28XXU select DVB_RTL2832 select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT) select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT - select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT - select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT - select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_FC0012 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_FC0013 if MEDIA_SUBDRV_AUTOSELECT - select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_R820T if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_TUA9001 if MEDIA_SUBDRV_AUTOSELECT -- 2.8.2 -- 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
rtl28xxu: improve DVB-frontend and tuner auto-selection
Hello, my "Astrometa AMDVB-T2 v2" is not working on Arch Linux because their kernel config does not select CONFIG_DVB_MN88473. This is because the maintainers simply rely on MEDIA_SUBDRV_AUTOSELECT to choose the required drivers. This patchset depends on Antti Palosaari's patch "mn88472: move out of staging to media" because we will now automatically enable CONFIG_DVB_MN88472 when CONFIG_DVB_USB_RTL28XXU is enabled. -- 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 v2] [media] rtl2832: add support for slave ts pid filter
The rtl2832 demod has 2 sets of PID filters. This patch enables
the filter support when using a slave demod.
Signed-off-by: Benjamin Larsson <benja...@southpole.se>
Signed-off-by: Martin Blumenstingl <martin.blumensti...@googlemail.com>
---
This patch was originally written by Benjamin Larsson, all I did was
rebasing the patch and to extend the dev_dbg statements with the
slave_ts information.
This also supersedes the following patch:
https://patchwork.linuxtv.org/patch/34358/
drivers/media/dvb-frontends/rtl2832.c | 26 --
drivers/media/dvb-frontends/rtl2832_priv.h | 1 +
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index 7c96f76..ba67fb4 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -409,6 +409,7 @@ static int rtl2832_init(struct dvb_frontend *fe)
c->post_bit_count.len = 1;
c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
dev->sleeping = false;
+ dev->slave_ts = false;
return 0;
err:
@@ -1103,6 +1104,8 @@ static int rtl2832_slave_ts_ctrl(struct i2c_client
*client, bool enable)
goto err;
}
+ dev->slave_ts = enable;
+
return 0;
err:
dev_dbg(>dev, "failed=%d\n", ret);
@@ -1116,7 +1119,7 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend
*fe, int onoff)
int ret;
u8 u8tmp;
- dev_dbg(>dev, "onoff=%d\n", onoff);
+ dev_dbg(>dev, "onoff=%d, slave_ts=%d\n", onoff, dev->slave_ts);
/* enable / disable PID filter */
if (onoff)
@@ -1124,7 +1127,10 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend
*fe, int onoff)
else
u8tmp = 0x00;
- ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
+ if (dev->slave_ts)
+ ret = rtl2832_update_bits(client, 0x021, 0xc0, u8tmp);
+ else
+ ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
if (ret)
goto err;
@@ -1142,8 +1148,8 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8
index, u16 pid,
int ret;
u8 buf[4];
- dev_dbg(>dev, "index=%d pid=%04x onoff=%d\n",
- index, pid, onoff);
+ dev_dbg(>dev, "index=%d pid=%04x onoff=%d slave_ts=%d\n",
+ index, pid, onoff, dev->slave_ts);
/* skip invalid PIDs (0x2000) */
if (pid > 0x1fff || index > 32)
@@ -1159,14 +1165,22 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe,
u8 index, u16 pid,
buf[1] = (dev->filters >> 8) & 0xff;
buf[2] = (dev->filters >> 16) & 0xff;
buf[3] = (dev->filters >> 24) & 0xff;
- ret = rtl2832_bulk_write(client, 0x062, buf, 4);
+
+ if (dev->slave_ts)
+ ret = rtl2832_bulk_write(client, 0x022, buf, 4);
+ else
+ ret = rtl2832_bulk_write(client, 0x062, buf, 4);
if (ret)
goto err;
/* add PID */
buf[0] = (pid >> 8) & 0xff;
buf[1] = (pid >> 0) & 0xff;
- ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
+
+ if (dev->slave_ts)
+ ret = rtl2832_bulk_write(client, 0x026 + 2 * index, buf, 2);
+ else
+ ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
if (ret)
goto err;
diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h
b/drivers/media/dvb-frontends/rtl2832_priv.h
index 6b875f4..8eb2e0b 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -45,6 +45,7 @@ struct rtl2832_dev {
bool sleeping;
struct delayed_work i2c_gate_work;
unsigned long filters; /* PID filter */
+ bool slave_ts;
};
struct rtl2832_reg_entry {
--
2.8.2
--
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 Dear One
My name is Barr. Martin William and i am writing to you about the death of my late client whom I believe to be one of your relatives and some fund($US9,500,000,00)he left behind before his death. And I want you to stand as his next of kin since you have the same surname with him and claim this money before the bank confiscates it. Contact me for more information (barr.martinwill...@outlook.com) Barrister Martin William Esq. -- 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 Dear One
My name is Barr. Martin William and i am writing to you about the death of my late client whom I believe to be one of your relatives and some fund($US9,500,000,00)he left behind before his death. And I want you to stand as his next of kin since you have the same surname with him and claim this money before the bank confiscates it. Contact me for more information (barr.martinwill...@outlook.com) Barrister Martin William Esq. -- 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-dv-timings.h: CEA-861-F 4K timings have positive sync polarities
Corrected sync polarities for CEA-861-F timings
3840x2160p24/25/30/50/60 and 4096x2160p24/25/30/50/60.
Cc: Hans Verkuil <hans.verk...@cisco.com>
Signed-off-by: Martin Bugge <marbu...@cisco.com>
---
include/uapi/linux/v4l2-dv-timings.h | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/v4l2-dv-timings.h
b/include/uapi/linux/v4l2-dv-timings.h
index c039f1d..086168e 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -183,7 +183,8 @@
#define V4L2_DV_BT_CEA_3840X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -191,14 +192,16 @@
#define V4L2_DV_BT_CEA_3840X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_3840X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -206,14 +209,16 @@
#define V4L2_DV_BT_CEA_3840X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_3840X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -221,7 +226,8 @@
#define V4L2_DV_BT_CEA_4096X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -229,14 +235,16 @@
#define V4L2_DV_BT_CEA_4096X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_4096X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -244,14 +252,16 @@
#define V4L2_DV_BT_CEA_4096X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_4096X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
--
2.4.11
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord..
Questions about dvbv5-scan (missing fields)
Hi I hope this is the right list to ask. I am looking at using dvbv5 for one of my projects. However there are some fields that I cant seem to get, in particular tsid pmt service_type (TV?Radio etc) net netid example output in VDR format CBS Drama:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14640:0:0:0: Showcase TV:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15296:0:0:0: Box Nation:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14416:0:0:0: Horror Channel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6129:6130,6131:0:0:14480:0:0:0: 365 Travel:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:14784:0:0:0: Television X:538000:S0B8C34D12I1M64T8G32Y0:T:27500:0:0:0:0:15232:0:0:0: 5 USA:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6689:6690,6691:0:0:12992:0:0:0: 5*:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6673:6674,6675:0:0:12928:0:0:0: QUEST:538000:S0B8C34D12I1M64T8G32Y0:T:27500:6929:6930,6931:0:0:14498:0:0:0: A can be seen there is loads of zeros where entries should be 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
[PATCH] media: Add a driver for the ov5640 sensor.
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
- {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- h
Re: [PATCH] media: Add a driver for the ov5640 sensor.
Sorry for the unrelated patches,
I will submit this again.
On 30/09/15 09:34, Javier Martin wrote:
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
- {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vb
[PATCH v2] media: Add a driver for the ov5640 sensor.
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin <javiermar...@by.com.es>
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
4 files changed, 1462 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+{
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <_ov5640 _csi0>;
+ reg = <0x3c>;
+
+ clocks = < 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = < 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 6f30ea7..8c6689b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -488,6 +488,17 @@ config VIDEO_OV7640
To compile this driver as a module, choose M here: the
module will be called ov7640.
+config VIDEO_OV5640
+ tristate "OmniVision OV5640 sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5640 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5640.
+
config VIDEO_OV7670
tristate "OmniVision OV7670 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 34e7da2..65b224f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
new file mode 100644
index 000..e06b812
--- /dev/null
+++ b/drivers/media/i2c/ov5640.c
@@ -0,0 +1,1403 @@
+/*
+ * Driver for the OV5640 sensor from Omnivision CSI interface only.
+ *
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on the MT9P031 driver and an out of tree ov5640 driver by Freescale:
+ * https://github.com/varigit/linux-2.6-imx/blob/imx_3.14.38_6qp_beta-var02/
+ * drivers/media/platform/mxc/capture/ov5640.c
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be us
RFC: ov5640 kernel driver.
Hi, we want to a v4l2 driver for the ov5640 sensor from Omnivision. AFAIK, there was an attempt in the past to mainline that driver [1] but it didn't make it in the end. Some people were asking for the code for the ov5640 and the ov5642 to be merged [2] as well but IMHO both sensors are not that similar so that it's worth a common driver. The approach we had in mind so far was creating a new, independent, v4l2-subdev driver for the ov5640 with mbus support. I've found several sources out there with code for the ov5640 but, surprisingly, few attempts to mainline it. I would whether it is just people didn't take the effort or there was something wrong with the code. Has anyone got some comments/advices on this before we start coding? Is anyone already working on this and maybe we can collaborate instead of having two forks of the same driver? Regards, Javier. [1] https://lwn.net/Articles/470643/ [2] http://www.spinics.net/lists/linux-omap/msg69611.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
imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
Hi, I am using mainline kernel 4.1 and I was writing a small application that uses double buffering to read YUV420 frames from a file at 30fps and displays them using the overlay plane in the imx-drm driver. The first issue I noticed is that the image was green so I had to apply the following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- 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: imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
Sorry for sending this to the wrong list. On 07/08/15 09:25, Javier Martin wrote: Hi, I am using mainline kernel 4.1 and I was writing a small application that uses double buffering to read YUV420 frames from a file at 30fps and displays them using the overlay plane in the imx-drm driver. The first issue I noticed is that the image was green so I had to apply the following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- 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 -- 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: coda: Problems with encoding in i.MX6DL.
Hi Philipp, thanks for your fast answer. Apparently, the firmware is being loaded properly although it complains about that version not being supported. After queuing some YUV420 buffers with a simple application I perform a VIDIOC_STREAMON in both the CAPTURE and the OUTPUT interfaces but I get the following error: coda 204.vpu: coda is not initialized. ... but then suddenly it's not. (coda_is_initialized just checks whether PC != 0) Could this have something to do with the PU power domain? Do all coda registers read 0x0 ? Do you have CONFIG_PM disabled? Check if d438462c20a3 (ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set) makes a difference. I think that patch hasn't made it into stable yet. Indeed, I was having problems with the runtime PM from the beginning and hacked up the code in the gpmc a bit to make sure the coda was always enabled but somehow I forgot to comment the poweroff callback and the codas was being powered off and never turned on again. Just in case it is useful for someone else these are the functions in arch/arm/mach-imx/gpc.c whose code I completely commented out: _imx6q_pm_pu_power_off imx6q_pm_pu_power_off Anyway, it looks like power management for the coda is a bit broken in the i.MX6D. I'll leave it disabled for now so that I continue with my development but I plan to have a look at it later on to see if I can fix it properly. [ cut here ] WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792 vb2_start_streaming+0xe0/0x15c() That is because after copying buffers to the bitstream, the driver currently marks them as done. When start_streaming fails, videobuf2 expects drivers to re-queue them. So we'd have to flush the bitstream and re-queue the buffers so they can be copied to the bitstream all over during the next try. This warning is a result of incomplete error handling in the coda start_streaming implementation. I see, I might look into this if I manage to get some spare time. Regards, Javier. -- 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
coda: Problems with encoding in i.MX6DL.
Hello, I am running kernel 4.1 in a var-dvk-solo-linux evaluation board from Variscite. This is what I get at system start-up: coda 204.vpu: Firmware code revision: 34588 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 2.1.8 coda 204.vpu: codec registered as /dev/video[0-1] Apparently, the firmware is being loaded properly although it complains about that version not being supported. After queuing some YUV420 buffers with a simple application I perform a VIDIOC_STREAMON in both the CAPTURE and the OUTPUT interfaces but I get the following error: coda 204.vpu: coda is not initialized. [ cut here ] WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792 vb2_start_streaming+0xe0/0x15c() Modules linked in: CPU: 0 PID: 91 Comm: wmip_bsp_tests Tainted: GW 4.1.0-4-g192a113-dirty #96 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [c0012cb4] (dump_backtrace) from [c0012ecc] (show_stack+0x18/0x1c) r6:c0815888 r5: r4:c08d3764 r3: [c0012eb4] (show_stack) from [c061ab8c] (dump_stack+0x8c/0x9c) [c061ab00] (dump_stack) from [c002775c] (warn_slowpath_common+0x88/0xb8) r5:0700 r4: [c00276d4] (warn_slowpath_common) from [c0027830] (warn_slowpath_null+0x24/0x2c) r8:edc35000 r7: r6:ee1ee408 r5:ee1ee4d8 r4:fff2 [c002780c] (warn_slowpath_null) from [c0489734] (vb2_start_streaming+0xe0/0x15c) [c0489654] (vb2_start_streaming) from [c048bc50] (vb2_internal_streamon+0x118/0x164) r7: r6:edc1614c r5:ee1ee400 r4:ee1ee408 [c048bb38] (vb2_internal_streamon) from [c048bcd4] (vb2_streamon+0x38/0x58) r5:ee1ee400 r4:0001 [c048bc9c] (vb2_streamon) from [c0485670] (v4l2_m2m_streamon+0x38/0x54) [c0485638] (v4l2_m2m_streamon) from [c04856a4] (v4l2_m2m_ioctl_streamon+0x18/0x1c) r5:ee82f068 r4:40045612 [c048568c] (v4l2_m2m_ioctl_streamon) from [c0474ea0] (v4l_streamon+0x20/0x24) [c0474e80] (v4l_streamon) from [c0477810] (__video_do_ioctl+0x264/0x2cc) [c04775ac] (__video_do_ioctl) from [c0477294] (video_usercopy+0x190/0x48c) r10:ee1ebe20 r9:0001 r8:be916b74 r7: r6: r5:c04775ac r4:40045612 [c0477104] (video_usercopy) from [c04775a8] (video_ioctl2+0x18/0x1c) r10:eea7dd88 r9:be916b74 r8:ee82fcf0 r7:40045612 r6:be916b74 r5:edc35000 r4:ee82f068 [c0477590] (video_ioctl2) from [c0473a4c] (v4l2_ioctl+0xac/0xc8) [c04739a0] (v4l2_ioctl) from [c00f8334] (do_vfs_ioctl+0x430/0x624) r8:0003 r7:be916b74 r6:0003 r5:edc35000 r4:edc35000 r3:c04739a0 [c00f7f04] (do_vfs_ioctl) from [c00f8564] (SyS_ioctl+0x3c/0x64) r10: r9:ee1ea000 r8:0003 r7:be916b74 r6:40045612 r5:edc35000 r4:edc35000 [c00f8528] (SyS_ioctl) from [c000f720] (ret_fast_syscall+0x0/0x3c) r8:c000f8c4 r7:0036 r6:8aa8 r5: r4: r3:be916b74 ---[ end trace 2b0ba71bfb12fec4 ]--- As anyone seen the same issue? Could be related to the Unsupported firmware version complaint? Do you know where to get the 2.1.5 firmware for the i.MX6D? Regards, Javier. -- 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
i.MX6 video capture support in mainline
Hello, we have an BD-SL-i.MX6 platform (compatible with the Nitrogen6X) where we are currently running the BSP from Freescale, which is based on kernel 3.10 if I recall properly. We are aware that those drivers have some issues, specially when it comes to compliance with the V4L2 frameworks like the media controller API, stability, etc... Furthermore, we need to use the mainline kernel because some of the drivers that we need to use are not available in the Freescale kernel. The biggest problem that we have found so far for switching to the mainline kernel is the video capture support in the I.MX6 IPU. I've been following some old e-mail threads (from 2014) and I eventually found Philipp Zabel's repository branch 'nitrogen6x-ipu-media' which has what seems to be an early version of an i.MX6 IPU capture driver via the CSI interface. We've got here the same setup with an ov5642 sensor connected to the CSI interface and we have been giving a try to the driver. This is what we have tried so far: cat /dev/video0 # This is needed so that open gets called and the csi links are created media-ctl -l 'ov5642 1-003c:0-mipi_ipu1_mux:1[1], /soc/ipu@0240/port@0:1-IPU0 SMFC0:0[1]' media-ctl -l 'IPU0 SMFC0:1-imx-ipuv3-camera.2:0[1]' The last command will fail like this: imx-ipuv3 240.ipu: invalid link 'IPU0 SMFC0'(5):1 - 'imx-ipuv3-camera.2'(2):0 Unable to parse link: Invalid argument (22) The reason it fails, apparently, is that the links that have been created when opening /dev/video0 are not included in the ipu_links[] static table defined in drivers/gpio/ipu-v3/ipu-media.c which is where the ipu_smfc_link_setup() function tries to find a valid link. I've got some questions regarding this driver and iMX6 video capture support in general that someone here may gladly answer: a) Is anyone currently working on mainlining iMX6 video capture support? I know about Steve's and Philipp's work but I haven't seen any progress since September 2014. b) Does anyone know whether it's possible to capture YUV420P video using the driver in Philipp's repository? If so could you please provide the pipeline setup that you used with media-ctl? c) If we were willing to help with mainline submission of this driver what issues should we focus on? Regards, Javier. [1] git://git.pengutronix.de/git/pza/linux.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
Disappearing dvb-usb stick IT9137FN (Kworld 499-2T)
Hi I have the above usb stick (dual frontend) which works fine for a while then just vanishes. ie: frontend just goes eg ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 /dev/dvb/adapter1 /dev/dvb/adapter2 goes to ls /dev/dvb (I have a permanent DVB card as well) /dev/dvb/adapter0 To get it back I have plug/unplug several times (rebooting the box seems to make no difference) I am currently on fedora 21, but this seems to be a continual issue , through at least fedora 18 to date I cant see anything obvious in dmesg or the logs Any ideas -- 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
