Re: [PATCH] media: imx.rst: Update the imx6-sabreauto ADV7180 instructions
On Tue, Oct 15, 2019 at 9:16 AM Fabio Estevam wrote: > > Hi Tim, > > On Tue, Oct 15, 2019 at 1:07 PM Tim Harvey wrote: > > > > Right, I understand there is something else going on with the i.MX53 > > but what about the i.MX6 testing related to these patches? > > I tested it on a imx6 sabreauto board with 5.3.x kernel plus Steve's > patch that discard the 10 initial corrupted frames and I do not get > rolling video. > > I do get rolling video if I remove/insert the cable though. Right, because this re-creates the initial issue. Upon any signal lock you would need to throw away the first few frames. I wish I knew the proper way to deal with this. Tim > > > Regarding the i.MX53 as you have a kernel that does work you could > > start looking for i2c register differences and csi config differences > > between the two kernels. I discovered an issue with the adv7280 by > > comparing i2c register dumps. > > Yes, I am in the process of comparing the two kernels. > > Thanks
Re: [PATCH] media: imx.rst: Update the imx6-sabreauto ADV7180 instructions
On Tue, Oct 15, 2019 at 8:53 AM Fabio Estevam wrote: > > Hi Tim, > > On Tue, Oct 15, 2019 at 12:49 PM Tim Harvey wrote: > > > Fabio, > > > > I assume your seeing the same rolling video issue on capture unless > > you discard the first few 'corrupt' frames? I'm still wondering how we > > can address this properly upstream. > > On i.MX53 I still get the rolling video even if I discard the few > corrupt frames. > > I tested the same i.MX53 hardware with a vendor 2.6.35 kernel and it > captures correctly, no scrolling at all. Right, I understand there is something else going on with the i.MX53 but what about the i.MX6 testing related to these patches? Regarding the i.MX53 as you have a kernel that does work you could start looking for i2c register differences and csi config differences between the two kernels. I discovered an issue with the adv7280 by comparing i2c register dumps. Tim
Re: [PATCH] media: imx.rst: Update the imx6-sabreauto ADV7180 instructions
On Sat, Oct 12, 2019 at 2:19 PM Fabio Estevam wrote: > > Hi Steve, > > On Sat, Oct 12, 2019 at 5:24 PM Steve Longerbeam > wrote: > > > Ah, now I remember. You are using the imx6dl sabreauto, it's IPU-CSI > > Yes, correct. I am using the imx6dl-sabreauto. > > > video muxes have five input pads for each of the four MIPI CSI-2 virtual > > channels (pads 0 - 3) and one parallel input (pad 4). The output mux pad > > is pad 5. > > > > But the doc should clarify which SabreAuto corresponds to the given > > example pipeline config. Can you send a v2 of this patch that clarifies > > the config corresponds to the imx6 quad SabreAuto. If you like you could > > also include the analogous config for the imx6dl. > > Good idea. Will send a v2 that clarifies the example pipeline for each > sabreauto variant. > > Thanks Fabio, I assume your seeing the same rolling video issue on capture unless you discard the first few 'corrupt' frames? I'm still wondering how we can address this properly upstream. Tim
Re: ADV7180 Capture with i.MX53
On Tue, Oct 8, 2019 at 4:48 PM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Tue, Oct 8, 2019 at 6:01 PM Tim Harvey wrote:
>
> > Ok that's strange indeed. I did recently test 5.3 on a Gateworks IMX6
> > board with ADV7180 and the one patch to drop the first few frames and
> > its stable. What does your testing show on an IMX6 and do you know
>
> I will give it a try on a imx6q-sabreauto board for comparison.
>
> > when it may have broken for IMX53?
>
> i.MX53 capture is relatively new and this is my first time trying to
> get it to work with mainline.
>
> I assume I should do something similar to your
> https://raw.githubusercontent.com/Gateworks/media-ctl-setup/master/media-ctl-setup
> script, more especifically the mode 3 setup where you have:
>
I struggled with coming up with a way to easily document all the
variations with our boards as we have several different boards that
have an adv7180 using different CSI ports and then you also have to
deal with the differences between IMX6SDL and IMX6Q. The script was
the best solution I could come up with but if you read through it its
pretty complicated.
> case "$SENS" in
> adv7180)
> fmt "'$SENSOR':0 [fmt:UYVY2X8/$res field:alternate]"
> fmt "'ipu${IPU}_csi${CSI}_mux':$((p+1)) [fmt:UYVY2X8/$res]"
> # rec709 config at CSI pad 0
> fmt "'ipu${IPU}_csi${CSI}':0 [fmt:$fmt field:$field colorspace:rec709
> ycbcr:709]"
> # CSI src pad output is frame height
> h=$((h*2))
> res=${w}x${h}
> fmt "'ipu${IPU}_csi${CSI}':1 [fmt:AYUV32/$res]"
> fmt "'ipu${IPU}_vdic':2 [fmt:AYUV32/$res field:none]"
> fmt "'ipu${IPU}_ic_prp':2 [fmt:AYUV32/$res field:none]"
> fmt "'$EP':1 [fmt:AYUV32/$res]"
> ;;
>
> Why do you multiple h by 2?
The input the the CSI is a field of 240 lines but the vdic will
combine these and have 480 lines. I don't recall exactly why but for
this to propagate properly you need to set the 480 lines on the csi
output.
>
> > I do have a discussion going on here about NEWAVMODE and BT.656-3 vs
> > BT.656-4. I wonder if its something to do with that as that issue
> > causes rolling video on IMX6 with ADV7280:
> > https://patchwork.kernel.org/patch/7579/
>
> Tested this patch, but it did not help.
That patch won't affect adv7180 but I wonder if the issues you are
having have to do with something like this. The adv7180_init function
will set BT.656-4 mode and adjust V bit end position for NTSC... I
don't know if that's consistent with the IMX53 CSI needs? There are
lots of little tweaks that can be made to the EAV/SAV codes and its
not clear to me how to deal with compat issues like i have run into
with the adv7280 config not being compatible with the IMX6 CSI needs.
Tim
Re: ADV7180 Capture with i.MX53
On Tue, Oct 8, 2019 at 1:34 PM Fabio Estevam wrote: > > Hi Tim, > > On Tue, Oct 8, 2019 at 1:55 PM Tim Harvey wrote: > > > I still carry around a patch from Steve for imx-csi that drops first > > few frames from BT656 sources: > > https://github.com/Gateworks/linux-imx6/commit/959fbd42ee6433f49ef4a04fb1abe8f8c78db5ad > > to deal with this. > > Tried this patch and now I see the scrolling happening horizontally > (from right to left). > > Stil trying to get stable video from ADV7180. Ok that's strange indeed. I did recently test 5.3 on a Gateworks IMX6 board with ADV7180 and the one patch to drop the first few frames and its stable. What does your testing show on an IMX6 and do you know when it may have broken for IMX53? I do have a discussion going on here about NEWAVMODE and BT.656-3 vs BT.656-4. I wonder if its something to do with that as that issue causes rolling video on IMX6 with ADV7280: https://patchwork.kernel.org/patch/7579/ Tim
Re: ADV7180 Capture with i.MX53
On Tue, Oct 8, 2019 at 4:21 AM Fabio Estevam wrote: > > On Mon, Oct 7, 2019 at 10:07 PM Fabio Estevam wrote: > > > So now I need to see if I can get Gstreamer to accept a pipeline like: > > > > gst-lauch-1.0 v4l2src ! kmssink > > Ok, so now I decided use the hardware video deinterlacer: > > media-ctl -l "'adv7180 1-0021':0 -> 'ipu1_csi0':0[1]" > media-ctl -l "'ipu1_csi0':1 -> 'ipu1_vdic':0[1]" > media-ctl -l "'ipu1_vdic':2 -> 'ipu1_ic_prp':0[1]" > media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]" > media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]" > > media-ctl -V "'adv7180 1-0021':0 [fmt:UYVY2X8/720x480 field:alternate]" > media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480]" > media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x480 field:none]" > media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x480 field:none]" > media-ctl -V "'ipu1_ic_prpvf':1 [fmt:AYUV32/720x480field:none]" > > And then Gstreamer can be launched: > > # gst-launch-1.0 v4l2src device=/dev/video2 ! kmssink --verbose > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800 > /GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480 > Setting pipeline to PLAYING ... > New clock: GstSystemClock > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = > video/x-raw, format=(string)YUY2, width=(int)720, height=(int)480, > framerate=(fraction)25/1, colorimetry=(string)bt601, > interlace-mode=(string)progressive > /GstPipeline:pipeline0/GstKMSSink:kmssink0.GstPad:sink: caps = > video/x-raw, format=(string)YUY2, width=(int)720, height=(int)480, > framerate=(fraction)25/1, colorimetry=(string)bt601, > interlace-mode=(string)progressive > Fabio, Yes, you need to use the vdic to capture from adv7180 with gstreamer as it can't handle alternate. > However the video looks like a broken old TV scrolling the image horizontally: > https://www.dropbox.com/s/2yef8egn6s8z7ff/mx53_adv7180_capture.mp4?dl=0 > This would be because of the initial corrupt frames that this and many other decoders produce while waiting for proper sync. I added 'g_skip_frames' support in 9483a3f8e1b58ba1d7cd21687d8d0a63a015c36b but I'm not sure how to get gstreamer to use it? I still carry around a patch from Steve for imx-csi that drops first few frames from BT656 sources: https://github.com/Gateworks/linux-imx6/commit/959fbd42ee6433f49ef4a04fb1abe8f8c78db5ad to deal with this. Tim
Re: PureThermal2 UVC video camera: Failed to submit URB 0 (-28)
On Wed, Oct 2, 2019 at 10:58 AM Alan Stern wrote: > > On Wed, 2 Oct 2019, Tim Harvey wrote: > > > On Tue, Oct 1, 2019 at 12:19 PM Alan Stern > > wrote: > > > > > > On Tue, 1 Oct 2019, Tim Harvey wrote: > > > > > > > On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey > > > > wrote: > > > > > > > > > > Greetings, > > > > > > > > > > I'm running into an issue with a USB UVC Full speed camera, the > > > > > PureThermal2 [1] on an IMX6 based ARM board. > > > > > > > > > > What I find is that I get two video devices registered (the first one > > > > > is the expected device, and I'm not clear what the 2nd one is). When I > > > > > try to capture a single frame I get 'Failed to submit URB 0 (-28)' > > > > > which historically has been due to a bandwidth issue. I encounter this > > > > > on the IMX6 EHCI host as well as the OTG host when no other devices > > > > > are connected (no hubs either). I've tested with both a 4.20 kernel > > > > > and a 5.3 kernel. > > > > > > > > > > If I plug this device into another board I have based on an OcteonTX > > > > > ARM64 cpu with a fairly modern 4.14 kernel and I find that a single > > > > > video device gets registered and I can capture just fine. > > > > > > > > > > Here are some details: > > > > > lsusb reports: 1e4e:0100 Cubeternet WebCam > > > > > > > > > > working system with 4.14 kernel hot-inserting the camera: > > > > > [ 495.163276] usb 1-1.2: new full-speed USB device number 6 using > > > > > xhci_hcd > > > > > [ 495.291685] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > > > (1e4e:0100) > > > > > [ 495.300543] input: PureThermal (fw:v1.2.2): PureTh as > > > > > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input1 > > > > > [ 496.731214] usb 1-1.2: USB disconnect, device number 6 > > > > > [ 496.987294] usb 1-1.2: new full-speed USB device number 7 using > > > > > xhci_hcd > > > > > [ 497.115683] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > > > (1e4e:0100) > > > > > [ 497.124182] input: PureThermal (fw:v1.2.2): PureTh as > > > > > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2 > > > > > > ... > > > > > > > > I'm also not clear why the device enumerates then disconnects and > > > > > enumerates again when plugged in but this happens on the system it > > > > > works on as well and I've seen similar things with other devices. > > > > > > Perhaps some process opens the camera's device file, does something to > > > cause the camera to disconnect and reconnect, but then doesn't close > > > the file. > > > > Alan, > > > > I found that the '2 devices' is because of a kernel commit in 4.16 > > that adds support for UVC metadata: 088ead2 media: uvcvideo: Add a > > metadata device node. I can comment out the call to > > uvc_meta_register() and the 2nd device goes away but the first (and > > only) v4l2 capture device still has the same issue. > > Okay, that explains that. > > > > > I have found that if I enumerate the camera through a PCIe based XHCI > > > > host controller it still registers the 2 v4l2 devices but in this case > > > > I can capture fine. So it would appear that this has something to do > > > > with the IMX6 ci_hdrc controller. The -ENOSPC is getting returned from > > > > drivers/usb/host/ehci-sched.c:iso_stream_schedule() > > > > > > > > I feel perhaps this is something basic I don't understand regarding > > > > USB URB scheduling but I don't get why it occurs on the IMX6 ci_hdrc > > > > controller on not an XHCI controller. > > > > > > It's probably related to differences between the drivers. What shows > > > up in /sys/kernel/debug/usb/devices with the camera plugged in? > > > > > > > Here's some more debugging including /sys/kernel/debug/usb/devices: > > ~# cat /sys/kernel/debug/usb/devices > > > > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 > > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso=
Re: PureThermal2 UVC video camera: Failed to submit URB 0 (-28)
On Tue, Oct 1, 2019 at 12:19 PM Alan Stern wrote: > > On Tue, 1 Oct 2019, Tim Harvey wrote: > > > On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey wrote: > > > > > > Greetings, > > > > > > I'm running into an issue with a USB UVC Full speed camera, the > > > PureThermal2 [1] on an IMX6 based ARM board. > > > > > > What I find is that I get two video devices registered (the first one > > > is the expected device, and I'm not clear what the 2nd one is). When I > > > try to capture a single frame I get 'Failed to submit URB 0 (-28)' > > > which historically has been due to a bandwidth issue. I encounter this > > > on the IMX6 EHCI host as well as the OTG host when no other devices > > > are connected (no hubs either). I've tested with both a 4.20 kernel > > > and a 5.3 kernel. > > > > > > If I plug this device into another board I have based on an OcteonTX > > > ARM64 cpu with a fairly modern 4.14 kernel and I find that a single > > > video device gets registered and I can capture just fine. > > > > > > Here are some details: > > > lsusb reports: 1e4e:0100 Cubeternet WebCam > > > > > > working system with 4.14 kernel hot-inserting the camera: > > > [ 495.163276] usb 1-1.2: new full-speed USB device number 6 using > > > xhci_hcd > > > [ 495.291685] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > (1e4e:0100) > > > [ 495.300543] input: PureThermal (fw:v1.2.2): PureTh as > > > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input1 > > > [ 496.731214] usb 1-1.2: USB disconnect, device number 6 > > > [ 496.987294] usb 1-1.2: new full-speed USB device number 7 using > > > xhci_hcd > > > [ 497.115683] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > (1e4e:0100) > > > [ 497.124182] input: PureThermal (fw:v1.2.2): PureTh as > > > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2 > > ... > > > > I'm also not clear why the device enumerates then disconnects and > > > enumerates again when plugged in but this happens on the system it > > > works on as well and I've seen similar things with other devices. > > Perhaps some process opens the camera's device file, does something to > cause the camera to disconnect and reconnect, but then doesn't close > the file. Alan, I found that the '2 devices' is because of a kernel commit in 4.16 that adds support for UVC metadata: 088ead2 media: uvcvideo: Add a metadata device node. I can comment out the call to uvc_meta_register() and the 2nd device goes away but the first (and only) v4l2 capture device still has the same issue. > > > I have found that if I enumerate the camera through a PCIe based XHCI > > host controller it still registers the 2 v4l2 devices but in this case > > I can capture fine. So it would appear that this has something to do > > with the IMX6 ci_hdrc controller. The -ENOSPC is getting returned from > > drivers/usb/host/ehci-sched.c:iso_stream_schedule() > > > > I feel perhaps this is something basic I don't understand regarding > > USB URB scheduling but I don't get why it occurs on the IMX6 ci_hdrc > > controller on not an XHCI controller. > > It's probably related to differences between the drivers. What shows > up in /sys/kernel/debug/usb/devices with the camera plugged in? > Here's some more debugging including /sys/kernel/debug/usb/devices: ~# lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 1e4e:0100 Cubeternet WebCam Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ~# lsusb -d 1e4e:0100 -v Bus 001 Device 002: ID 1e4e:0100 Cubeternet WebCam Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1e4e Cubeternet idProduct 0x0100 WebCam bcdDevice2.00 iManufacturer 1 GroupGets iProduct2 PureThermal (fw:v1.2.2) iSerial 3 801f001c-5102-3038-3835-3934 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 685 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered)
Re: PureThermal2 UVC video camera: Failed to submit URB 0 (-28)
On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey wrote: > > Greetings, > > I'm running into an issue with a USB UVC Full speed camera, the > PureThermal2 [1] on an IMX6 based ARM board. > > What I find is that I get two video devices registered (the first one > is the expected device, and I'm not clear what the 2nd one is). When I > try to capture a single frame I get 'Failed to submit URB 0 (-28)' > which historically has been due to a bandwidth issue. I encounter this > on the IMX6 EHCI host as well as the OTG host when no other devices > are connected (no hubs either). I've tested with both a 4.20 kernel > and a 5.3 kernel. > > If I plug this device into another board I have based on an OcteonTX > ARM64 cpu with a fairly modern 4.14 kernel and I find that a single > video device gets registered and I can capture just fine. > > Here are some details: > lsusb reports: 1e4e:0100 Cubeternet WebCam > > working system with 4.14 kernel hot-inserting the camera: > [ 495.163276] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd > [ 495.291685] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > (1e4e:0100) > [ 495.300543] input: PureThermal (fw:v1.2.2): PureTh as > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input1 > [ 496.731214] usb 1-1.2: USB disconnect, device number 6 > [ 496.987294] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd > [ 497.115683] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > (1e4e:0100) > [ 497.124182] input: PureThermal (fw:v1.2.2): PureTh as > /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2 > root@bionic-newport:~# for i in $(ls -1d > /sys/class/video4linux/video*); do echo $i:$(cat $i/name); done > /sys/class/video4linux/video0:PureThermal (fw:v1.2.2): PureTh > root@bionic-newport:~# v4l2-ctl --device=/dev/video0 --allDriver Info > (not using libv4l2): > Driver name : uvcvideo > Card type : PureThermal (fw:v1.2.2): PureTh > Bus info : usb-:00:10.0-1.2 > Driver version: 4.14.4 > Capabilities : 0x8421 > Video Capture > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x0421 > Video Capture > Streaming > Extended Pix Format > Priority: 2 > Video input : 0 (Camera 1: ok) > Format Video Capture: > Width/Height : 160/120 > Pixel Format : 'UYVY' > Field : None > Bytes per Line: 320 > Size Image: 38400 > Colorspace: sRGB > Transfer Function : Default (maps to sRGB) > YCbCr/HSV Encoding: Default (maps to ITU-R 601) > Quantization : Default (maps to Limited Range) > Flags : > Crop Capability Video Capture: > Bounds : Left 0, Top 0, Width 160, Height 120 > Default : Left 0, Top 0, Width 160, Height 120 > Pixel Aspect: 1/1 > Selection: crop_default, Left 0, Top 0, Width 160, Height 120 > Selection: crop_bounds, Left 0, Top 0, Width 160, Height 120 > Streaming Parameters Video Capture: > Capabilities : timeperframe > Frames per second: 9.000 (9/1) > Read buffers : 0 > brightness 0x00980900 (int): min=0 max=255 > step=1 default=128 value=128 >contrast 0x00980901 (int): min=0 max=255 > step=1 default=128 value=128 > root@bionic-newport:~# v4l2-ctl --device=/dev/video0 --stream-mmap > --stream-to=x.raw --stream-count=1 > < > root@bionic-newport:~# ls -l x.raw > -rw-r--r-- 1 root root 38400 Sep 26 22:25 x.raw > > non-working system with 5.3 kernel hot-inserting the device > [ 54.252434] usb 2-1: new full-speed USB device number 2 using ci_hdrc > [ 54.463017] usb 2-1: New USB device found, idVendor=1e4e, > idProduct=0100, bcdDevice= 2.00 > [ 54.463097] usb 2-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 54.463114] usb 2-1: Product: PureThermal (fw:v1.2.2) > [ 54.463130] usb 2-1: Manufacturer: GroupGets > [ 54.463145] usb 2-1: SerialNumber: 801f001c-5102-3038-3835-3934 > [ 54.470265] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > (1e4e:0100) > [ 54.480219] uvcvideo 2-1:1.0: Entity type for entity Extension 3 > was not initialized! > [ 54.480315] uvcvideo 2-1:1.0: Entity type for entity Processing 2 > was not initialized! > [ 54.480342] uvcvideo 2-1:1.0: Entity type for entity Extension 4 > was not initialized! > [ 54.480366] uvcvideo 2-1:1.0: Entity type for entity Extension 5 > was not initialized! > [ 54.480388] uvcvideo 2-1:1.0: Entity type for entity Extension 6 > was not initialized! > [ 54.480409] uvcvideo 2-1:1.0: Entity type for entity Extension 7 > was not in
PureThermal2 UVC video camera: Failed to submit URB 0 (-28)
Greetings, I'm running into an issue with a USB UVC Full speed camera, the PureThermal2 [1] on an IMX6 based ARM board. What I find is that I get two video devices registered (the first one is the expected device, and I'm not clear what the 2nd one is). When I try to capture a single frame I get 'Failed to submit URB 0 (-28)' which historically has been due to a bandwidth issue. I encounter this on the IMX6 EHCI host as well as the OTG host when no other devices are connected (no hubs either). I've tested with both a 4.20 kernel and a 5.3 kernel. If I plug this device into another board I have based on an OcteonTX ARM64 cpu with a fairly modern 4.14 kernel and I find that a single video device gets registered and I can capture just fine. Here are some details: lsusb reports: 1e4e:0100 Cubeternet WebCam working system with 4.14 kernel hot-inserting the camera: [ 495.163276] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd [ 495.291685] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) (1e4e:0100) [ 495.300543] input: PureThermal (fw:v1.2.2): PureTh as /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input1 [ 496.731214] usb 1-1.2: USB disconnect, device number 6 [ 496.987294] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd [ 497.115683] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) (1e4e:0100) [ 497.124182] input: PureThermal (fw:v1.2.2): PureTh as /devices/platform/soc@0/8480.pci/pci:00/:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2 root@bionic-newport:~# for i in $(ls -1d /sys/class/video4linux/video*); do echo $i:$(cat $i/name); done /sys/class/video4linux/video0:PureThermal (fw:v1.2.2): PureTh root@bionic-newport:~# v4l2-ctl --device=/dev/video0 --allDriver Info (not using libv4l2): Driver name : uvcvideo Card type : PureThermal (fw:v1.2.2): PureTh Bus info : usb-:00:10.0-1.2 Driver version: 4.14.4 Capabilities : 0x8421 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Priority: 2 Video input : 0 (Camera 1: ok) Format Video Capture: Width/Height : 160/120 Pixel Format : 'UYVY' Field : None Bytes per Line: 320 Size Image: 38400 Colorspace: sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Limited Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 160, Height 120 Default : Left 0, Top 0, Width 160, Height 120 Pixel Aspect: 1/1 Selection: crop_default, Left 0, Top 0, Width 160, Height 120 Selection: crop_bounds, Left 0, Top 0, Width 160, Height 120 Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 9.000 (9/1) Read buffers : 0 brightness 0x00980900 (int): min=0 max=255 step=1 default=128 value=128 contrast 0x00980901 (int): min=0 max=255 step=1 default=128 value=128 root@bionic-newport:~# v4l2-ctl --device=/dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1 < root@bionic-newport:~# ls -l x.raw -rw-r--r-- 1 root root 38400 Sep 26 22:25 x.raw non-working system with 5.3 kernel hot-inserting the device [ 54.252434] usb 2-1: new full-speed USB device number 2 using ci_hdrc [ 54.463017] usb 2-1: New USB device found, idVendor=1e4e, idProduct=0100, bcdDevice= 2.00 [ 54.463097] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 54.463114] usb 2-1: Product: PureThermal (fw:v1.2.2) [ 54.463130] usb 2-1: Manufacturer: GroupGets [ 54.463145] usb 2-1: SerialNumber: 801f001c-5102-3038-3835-3934 [ 54.470265] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) (1e4e:0100) [ 54.480219] uvcvideo 2-1:1.0: Entity type for entity Extension 3 was not initialized! [ 54.480315] uvcvideo 2-1:1.0: Entity type for entity Processing 2 was not initialized! [ 54.480342] uvcvideo 2-1:1.0: Entity type for entity Extension 4 was not initialized! [ 54.480366] uvcvideo 2-1:1.0: Entity type for entity Extension 5 was not initialized! [ 54.480388] uvcvideo 2-1:1.0: Entity type for entity Extension 6 was not initialized! [ 54.480409] uvcvideo 2-1:1.0: Entity type for entity Extension 7 was not initialized! [ 54.480431] uvcvideo 2-1:1.0: Entity type for entity Extension 21 was not initialized! [ 54.480452] uvcvideo 2-1:1.0: Entity type for entity Extension 254 was not initialized! [ 54.480473] uvcvideo 2-1:1.0: Entity type for entity Camera 1 was not initialized! [ 54.481802] input: PureThermal (fw:v1.2.2): PureTh as /devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/input/input1 [ 55.733320] usb 2-1: USB disconnect, device number 2 [ 56.252329] usb 2-1: new full-speed USB device number 3 using ci_hdrc [ 56.462977] usb 2-1: New USB device found, idVendor=1e4e, idProduc
Re: coda9 jpeg support?
On Tue, Sep 17, 2019 at 7:33 AM Philipp Zabel wrote: > > Hi Tim, > > On Fri, 2019-09-13 at 09:00 -0700, Tim Harvey wrote: > > Greetings, > > > > What would need to be done to support JPEG enc/dec for coda9? > > here is a WIP that still needs some cleanup for upstreaming: > > https://git.pengutronix.de/cgit/pza/linux/log/?h=coda/jpeg > > Basically I'd like to avoid adding yet another JPEG header parser to the > kernel, as we already have at least three: > drivers/media/platform/rcar_jpu.c > drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c > drivers/media/platform/s5p-jpeg/jpeg-core.c > > I want to allow probing without the BIT processor firmware for blobless > JPEG-only support, and I'd like the JPEG codec to be able to run > concurrently with the BIT processor codec. > > I'm working on this this week. > Philipp, Thanks for this! I'll keep an eye out for your submission and provide testing. I have pulled your branch and boot-tested it. I see the 2 new video devices but noticed that the JPEG decoder shows up as an element for video4linux2 the JPEG encoder doesn't show up (gstreamer v1.14.5) - any idea why that would be? Thanks, Tim Tim
coda9 jpeg support?
Greetings, What would need to be done to support JPEG enc/dec for coda9? Best Regards, Tim
Re: v4l2 mem2mem compose support?
On Sat, Feb 16, 2019 at 1:14 PM Nicolas Dufresne wrote: > > Le sam. 16 févr. 2019 à 13:40, Hans Verkuil a écrit : > > > > On 2/16/19 4:42 PM, Nicolas Dufresne wrote: > > > Le sam. 16 févr. 2019 à 04:48, Hans Verkuil a écrit : > > >> > > >> On 2/16/19 10:42 AM, Hans Verkuil wrote: > > >>> On 2/16/19 1:16 AM, Tim Harvey wrote: > > >>>> Greetings, > > >>>> > > >>>> What is needed to be able to take advantage of hardware video > > >>>> composing capabilities and make them available in something like > > >>>> GStreamer? > > >>> > > >>> Are you talking about what is needed in a driver or what is needed in > > >>> gstreamer? Or both? > > >>> > > >>> In any case, the driver needs to support the V4L2 selection API, > > >>> specifically > > >>> the compose target rectangle for the video capture. > > >> > > >> I forgot to mention that the driver should allow the compose rectangle to > > >> be anywhere within the bounding rectangle as set by S_FMT(CAPTURE). > > >> > > >> In addition, this also means that the DMA has to be able to do > > >> scatter-gather, > > >> which I believe is not the case for the imx m2m hardware. > > > > > > I believe the 2D blitter can take an arbitrary source rectangle and > > > compose it to an arbitrary destination rectangle (a lot of these will > > > in fact use Q16 coordinate, allowing for subpixel rectangle, something > > > that V4L2 does not support). > > > > Not entirely true. I think this can be done through the selection API, > > although it would require some updating of the spec and perhaps the > > introduction of a field or flag. The original VIDIOC_CROPCAP and VIDIOC_CROP > > ioctls actually could do this since with analog video (e.g. S-Video) you > > did not really have the concept of a 'pixel'. It's an analog waveform after > > all. In principle the selection API works in the same way, even though the > > documentation always assumes that the selection rectangles map directly on > > the digitized pixels. I'm not sure if there are still drivers that report > > different crop bounds in CROPCAP compared to actual number of digitized > > pixels. > > The bttv driver is most likely to do that, but I haven't checked. > > > > Doing so made it very hard to understand, though. > > > > I don't think this driver exist in any > > > form upstream on IMX side. The Rockchip dev tried to get one in > > > recently, but the discussion didn't go so well with the rejection of > > > the proposed porter duff controls was probably devoting, as picking > > > the right blending algorithm is the basic of such driver. > > > > I tried to find the reason why the Porter Duff control was dropped in v8 > > of the rockchip RGA patch series back in 2017. > > > > I can't find any discussion about it on the mailinglist, so perhaps it > > was discussed on irc. > > > > Do you remember why it was removed? > > I'll try and retrace what happened, it was not a nack, and I realize > that "rejection" wasn't the right word, but if I remember, the focus > in the review went fully around this and the fact that it was doing > blending which such API, while the original intention with the driver > was to have CSC, so removing this was basically a way forward. > > > > > > > > > I believe a better approach for upstreaming such driver would be to > > > write an M2M spec specific to that type of m2m drivers. That spec > > > would cover scalers and rotators, since unlike the IPUv3 (which I > > > believe you are referring too) a lot of the CSC and Scaler are > > > blitters. > > > > No, I was referring to the imx m2m driver that Phillip is working on. > > I'll need to check what driver Veolab was using, but if it's the > same, then maybe it only do source-over operations using SELECTION as > you described. If I remember their use case, they where doing simple > source-over blending of two video feeds. > > Could it be this ? > https://gitlab.com/veo-labs/linux/tree/veobox/drivers/staging/media/imx6/m2m > Is it an ancester of Philipp's driver ? > It does look like this was an ancestor of Philipp's mem2mem driver which is currently under review (https://patchwork.kernel.org/project/linux-media/list/?series=67977) Hans, can you give me a little more detail about what would be needed in Phillipp's mem2mem driver to do this (or if its already there). I imagine what we are talking about is being able to specify the destination buffer and a rect within it. I will take a look at the gstreamer plugin at https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/308 and see if I can get that building on top of master. It sounds like that's a good path towards hardware accelerated composing. Thanks! Tim
v4l2 mem2mem compose support?
Greetings, What is needed to be able to take advantage of hardware video composing capabilities and make them available in something like GStreamer? Philipp's mem2mem driver [1] exposes the IMX IC and GStreamer's v4l2convert element uses this nicely for hardware accelerated scaling/csc/flip/rotate but what I'm looking for is something that extends that concept and allows for composing frames from multiple video capture devices into a single memory buffer which could then be encoded as a single stream. This was made possible by Carlo's gstreamer-imx [2] GStreamer plugins paired with the Freescale kernel that had some non-mainlined API's to the IMX IPU and GPU. We have used this to take for example 8x analog capture inputs, compose them into a single frame then H264 encode and stream it. The gstreamer-imx elements used fairly compatible properties as the GstCompositorPad element to provide a destination rect within the compose output buffer as well as rotation/flip, alpha blending and the ability to specify background fill. Is it possible that some of this capability might be available today with the opengl GStreamer elements? Best Regards, Tim [1] https://patchwork.kernel.org/patch/10768463/ [2] https://github.com/Freescale/gstreamer-imx
Re: [PATCH v7] media: imx: add mem2mem device
On Fri, Feb 15, 2019 at 8:24 AM Nicolas Dufresne wrote: > > Le vendredi 15 février 2019 à 12:10 +0100, Philipp Zabel a écrit : > > > I'm also not sure how to specify hflip/vflip... I don't think > > > extra-controls parses 'hflip', 'vflip' as ipu_csc_scaler_s_ctrl gets > > > called with V4L2_CID_HFLIP/V4L2_CID_VFLIP but ctrl->val is always 0. > > > > You can use v4l2-ctl -L to list the CID names, they are horizontal_flip > > and vertical_flip, respectively. Again, the input and output formats > > must be different because GStreamer doesn't know about the flipping yet: > > > > gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! > > v4l2video10convert extra-controls=cid,horizontal_flip=1 ! > > video/x-raw,width=640,height=480 ! kmssink can-scale=false > > > > We'd have to add actual properties for rotate/flip to v4l2convert, > > instead of using theextra-controls workaround, probable something > > similar to the video-direction property of the software videoflip > > element. > > Note that we have a disable-passthrough property in master, a trivial > patch to backport if you need it. > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/commit/fe5236be8771ea82c850ebebe19cf1064d112bf0 Nicolas, Yes, this works great on gstreamer-master: gst-launch-1.0 videotestsrc ! v4l2convert extra-controls=cid,vertical_flip=1 ! kmssink ^^^ fails to flip b/c gstreamer bypases the conversion as input and output formats are the same gst-launch-1.0 videotestsrc ! v4l2convert extra-controls=cid,vertical_flip=1 disable-passthrough=1 ! kmssink ^^^ flips as expected Tim
Re: [PATCH v7] media: imx: add mem2mem device
On Fri, Feb 15, 2019 at 3:10 AM Philipp Zabel wrote: > > Hi Tim, > > On Tue, 2019-02-12 at 11:01 -0800, Tim Harvey wrote: > > On Thu, Jan 17, 2019 at 7:50 AM Philipp Zabel > > wrote: > > > > > > Add a single imx-media mem2mem video device that uses the IPU IC PP > > > (image converter post processing) task for scaling and colorspace > > > conversion. > > > On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used. > > > > > > The hardware only supports writing to destination buffers up to > > > 1024x1024 pixels in a single pass, arbitrary sizes can be achieved > > > by rendering multiple tiles per frame. > > > > > > Signed-off-by: Philipp Zabel > > > [slongerb...@gmail.com: use ipu_image_convert_adjust(), fix > > > device_run() error handling, add missing media-device header, > > > unregister and remove the mem2mem device in error paths in > > > imx_media_probe_complete() and in imx_media_remove()] > > > Signed-off-by: Steve Longerbeam > > > --- > > > Changes since v6 [1]: > > > - Change driver name in querycap to imx-media-csc-scaler > > > - Drop V4L2_SEL_TGT_COMPOSE_PADDED from vidioc_g_selection > > > - Simplify error handling in ipu_csc_scaler_init_controls > > > > > > [1] https://patchwork.linuxtv.org/patch/53757/ > > > --- > > > > Hi Philipp, > > > > Thanks for this driver - this is providing support that I need to > > overcome direct CSI->IC limitations. > > > > Can you give me some examples on how your using this? I'm testing this > > on top of linux-media and trying the following gstreamer pipelines > > (gstreamer recent master) and running into trouble but it could very > > likely be me doing something wrong in my pipelines: > > > > # upscale > > gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! > > v4l2convert output-io-mode=dmabuf-import ! > > video/x-raw,width=640,height=480 ! kmssink > > You can't have v4l2convert import dmabufs because videotestsrc doesn't > produce any. I used: > > gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! > v4l2video10convert ! video/x-raw,width=640,height=480 ! kmssink > > That should work, passing dmabufs between v4l2 and kms automatically. > > I usually use kmssink but waylandsink, glimagesink, or v4l2h264enc for > testing though. > Philipp, That makes sense and jives with what Nicolas was saying about alignment. I'm currently testing linux-media/master with your v7 mem2mem patch and 'gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! v4l2video10convert ! video/x-raw,width=640,height=480 ! kmssink' hangs the system. Do you have some other patches queued up? > > # downscale > > gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480 ! > > v4l2convert output-io-mode=dmabuf-import ! > > video/x-raw,width=320,height=280 ! kmssink > > Drop output-io-mode unless your source is capable of producing dmabufs. > I think kmssink is trying to scale in this case, which imx-drm doesn't > support. You may have to either keep aspect ratio, or give kmssink the > can-scale=false parameter. > > > # downscale using videotstsrc defaults > > gst-launch-1.0 videotestsrc ! v4l2convert output-io-mode=dmabuf-import > > ! video/x-raw,width=100,height=200 ! kmssink > > ^^^ works > > That will probably just negotiate 100x200 on the input side and bypass > conversion altogether. > > > # rotation > > gst-launch-1.0 videotestsrc ! v4l2convert output-io-mode=dmabuf-import > > extra-controls=cid,rotate=90 ! kmssink > > This will likely negotiate the same format and dimensions on both sides > and bypass conversion as well. GStreamer has no concept of the rotation > as of yet. Try: > > gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! > v4l2video10convert extra-controls=cid,rotate=90 ! > video/x-raw,width=240,height=320 ! kmssink can-scale=false > > > I'm also not sure how to specify hflip/vflip... I don't think > > extra-controls parses 'hflip', 'vflip' as ipu_csc_scaler_s_ctrl gets > > called with V4L2_CID_HFLIP/V4L2_CID_VFLIP but ctrl->val is always 0. > > You can use v4l2-ctl -L to list the CID names, they are horizontal_flip > and vertical_flip, respectively. Again, the input and output formats > must be different because GStreamer doesn't know about the flipping yet: > > gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! > v4l2video10convert extra-controls=cid,horizontal_flip=1 ! &
Re: [PATCH v7] media: imx: add mem2mem device
On Thu, Jan 17, 2019 at 7:50 AM Philipp Zabel wrote: > > Add a single imx-media mem2mem video device that uses the IPU IC PP > (image converter post processing) task for scaling and colorspace > conversion. > On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used. > > The hardware only supports writing to destination buffers up to > 1024x1024 pixels in a single pass, arbitrary sizes can be achieved > by rendering multiple tiles per frame. > > Signed-off-by: Philipp Zabel > [slongerb...@gmail.com: use ipu_image_convert_adjust(), fix > device_run() error handling, add missing media-device header, > unregister and remove the mem2mem device in error paths in > imx_media_probe_complete() and in imx_media_remove()] > Signed-off-by: Steve Longerbeam > --- > Changes since v6 [1]: > - Change driver name in querycap to imx-media-csc-scaler > - Drop V4L2_SEL_TGT_COMPOSE_PADDED from vidioc_g_selection > - Simplify error handling in ipu_csc_scaler_init_controls > > [1] https://patchwork.linuxtv.org/patch/53757/ > --- Hi Philipp, Thanks for this driver - this is providing support that I need to overcome direct CSI->IC limitations. Can you give me some examples on how your using this? I'm testing this on top of linux-media and trying the following gstreamer pipelines (gstreamer recent master) and running into trouble but it could very likely be me doing something wrong in my pipelines: # upscale gst-launch-1.0 videotestsrc ! video/x-raw,width=320,height=240 ! v4l2convert output-io-mode=dmabuf-import ! video/x-raw,width=640,height=480 ! kmssink ^^^ fails with ERROR: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstKMSSink:autovideosink0-actual-sink-kms: GStreamer encountered a general resource error. Additional debug info: gstkmssink.c(1529): gst_kms_sink_show_frame (): /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0/GstKMSSink:autovideosink0-actual-sink-kms: drmModeSetPlane failed: No space left on device (-28) perhaps this is something strange with kmssink or is a buffer size not being set properly in the mem2mem scaler? # downscale gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480 ! v4l2convert output-io-mode=dmabuf-import ! video/x-raw,width=320,height=280 ! kmssink (gst-launch-1.0:15493): GStreamer-CRITICAL **: 18:06:49.029: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data stream error. Additional debug info: gstbasesrc.c(3064): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: streaming stopped, reason error (-5) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... # downscale using videotstsrc defaults gst-launch-1.0 videotestsrc ! v4l2convert output-io-mode=dmabuf-import ! video/x-raw,width=100,height=200 ! kmssink ^^^ works # rotation gst-launch-1.0 videotestsrc ! v4l2convert output-io-mode=dmabuf-import extra-controls=cid,rotate=90 ! kmssink ^^^ shows no rotation in displayed video but kernel debugging shows ipu_csc_scaler_s_ctrl getting called with V4L2_CID_ROTATE, ctrl->val=90 and ipu_degrees_to_rot_mode sets rot_mode=IPU_ROT_BIT_90 and returns no error. I also see that ipu_image_convert_adjust gets called with rot_mode=IPU_ROT_BIT_90 I'm also not sure how to specify hflip/vflip... I don't think extra-controls parses 'hflip', 'vflip' as ipu_csc_scaler_s_ctrl gets called with V4L2_CID_HFLIP/V4L2_CID_VFLIP but ctrl->val is always 0. Thanks, Tim
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Fri, Feb 8, 2019 at 3:22 PM Steve Longerbeam wrote: > > > > On 2/8/19 1:23 PM, Tim Harvey wrote: > > On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam > > wrote: > >> > > > >>> Ok there is definitely something wrong when using the IC with > >>> UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me > >>> like the ipu1_ic_prp isn't negotiating its format properly. You can't > >>> re-create this because you don't have any UYVY8_1X16 (passthrough) > >>> sensors right? > >> Sorry, maybe I didn't mention this, but passthrough cannot go though the > >> IPU, you can only send passthrough pixels out the CSI directly to > >> /dev/videoN interface (the ipu_csi:2 pad). > >> > > crud... this has been my issue all along with that set of UYVY8_1X16 > > pipelines then. So this means the mem2mem driver also won't be able to > > handle 16bit pixel formats as well. > > Ugh, let me rephrase. UYVY8_1X16 incoming on a parallel bus (not MIPI > CSI-2) to the CSI cannot be sent through the IPU, those pixels must be > sent directly to the ipu_csi:2 pad to /dev/videoN. At least according > the the imx6 register manual. > > But that's not a limitation of the mem2mem driver because the pixels are > coming from a memory buffer and not a 16-bi parallel bus via the CSI > (and in any case mem2mem does not deal in media bus codes, it speaks > V4L2_PIX_FMT_* which contains no bus info). So yes, you can receive > UYVY8_1X16 on the CSI parallel bus, routed to ipu_csi:2 pad to > /dev/videoN, and then pipe that to mem2mem v4l2convertN element in a > gstreamer pipeline. > > > > > So while I can downscale this by > > multiples of 2 (independent width/height), CSC convert it from > > srgb/bt.601 to yuv/bt.709, and even pixel reorder it within YUV via > > the ipu_csi entitty I'll never be able to deinterlace, > > that's true, currently you can't use the VDIC to do motion compensated > de-interlacing, but you can still make use of the IDMAC interweave > feature to deinterlace without motion compensation. > > > scale with > > flexibility, flip/rotate or do a RGB->YUV CSC on it as those are all > > features of the IC path. > > mem2mem v4l2convertN element will do those for you (flexible up/down > scaling, flip/rotate, and CSC). > ah... ok right using mem2mem is precisely that 'mem to mem' and not direct CSI to IPU. Ok so i experimented with some pipelines and perhaps am setting them up wrong. I'll respond to the imx-media mem2mem patch with my observations and expiriments. Thanks, Tim
Re: [PATCH v3 3/4] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
On Fri, Feb 8, 2019 at 11:28 AM Steve Longerbeam wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey
> Signed-off-by: Steve Longerbeam
> ---
> Changes in v2:
> - only return "Unsupported YCbCr encoding" error if inf != outf,
> since if inf == outf, the identity matrix can be used. Reported
> by Tim Harvey.
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 71 +++--
> drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
> drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
> include/video/imx-ipu-v3.h | 5 +-
> 4 files changed, 71 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index e459615a49a1..0d57ca7ba18e 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -212,6 +212,23 @@ static const struct ic_csc_params ic_csc_identity = {
> .scale = 2,
> };
>
> +/*
> + * BT.709 encoding from RGB full range to YUV limited range:
> + *
> + * Y = R * .2126 + G * .7152 + B * .0722;
> + * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
> + * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
> + */
> +static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
> + .coeff = {
> + { 54, 183, 18 },
> + { 483, 413, 128 },
> + { 128, 396, 500 },
> + },
> + .offset = { 0, 512, 512 },
> + .scale = 1,
> +};
> +
> /*
> * Inverse BT.601 encoding from YUV limited range to RGB full range:
> *
> @@ -229,12 +246,31 @@ static const struct ic_csc_params
> ic_csc_ycbcr2rgb_bt601 = {
> .scale = 2,
> };
>
> +/*
> + * Inverse BT.709 encoding from YUV limited range to RGB full range:
> + *
> + * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
> + * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
> + * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
> + */
> +static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
> + .coeff = {
> + { 128, 0, 202 },
> + { 128, 488, 452 },
> + { 128, 238, 0 },
> + },
> + .offset = { -435, 136, -507 },
> + .scale = 2,
> +};
> +
> static int init_csc(struct ipu_ic *ic,
> enum ipu_color_space inf,
> enum ipu_color_space outf,
> + enum v4l2_ycbcr_encoding encoding,
> int csc_index)
> {
> struct ipu_ic_priv *priv = ic->priv;
> + const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
> const struct ic_csc_params *params;
> u32 __iomem *base;
> const u16 (*c)[3];
> @@ -244,12 +280,30 @@ static int init_csc(struct ipu_ic *ic,
> base = (u32 __iomem *)
> (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>
> + switch (encoding) {
> + case V4L2_YCBCR_ENC_601:
> + params_rgb2yuv = &ic_csc_rgb2ycbcr_bt601;
> + params_yuv2rgb = &ic_csc_ycbcr2rgb_bt601;
> + break;
> + case V4L2_YCBCR_ENC_709:
> + params_rgb2yuv = &ic_csc_rgb2ycbcr_bt709;
> + params_yuv2rgb = &ic_csc_ycbcr2rgb_bt709;
> + break;
> + default:
> + if (inf != outf) {
> + dev_err(priv->ipu->dev,
> + "Unsupported YCbCr encoding\n");
> + return -EINVAL;
> + }
> + break;
> + }
> +
> if (inf == outf)
> params = &ic_csc_identity;
> else if (inf == IPUV3_COLORSPACE_YUV)
> - params = &ic_csc_ycbcr2rgb_bt601;
> + params = &ic_csc_ycbcr2rgb;
Steve,
compile issue...
params = params_yuv2rgb;
> else
> - params = &ic_csc_rgb2ycbcr_bt601;
> + params = &ic_csc_rgb2ycbcr;
params = params_rgb2yuv;
But, I'm still failing when using the mem2mem element (gst-launch-1.0
v4l2src device=/dev/video4 ! v4l2video8convert
output-io-mode=dmabuf-import ! fbdevsink) with 'Unsupported YCbCr
encoding' because of inf=IPU_COLORSPACE_YCBCR outf=IPU_COLORSPACE_RGB
and a seemingly unset encoding being passed in.
It looks like maybe something in the mem2mem driver isn't defaulting
encoding. The call path is (v4l2_m2m_streamon -> device_run ->
ipu_image_convert_queue -> convert_start -> ipu_ic_task_init_rsc ->
init_csc).
Tim
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam wrote: > > > >> > > Ok there is definitely something wrong when using the IC with > > UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me > > like the ipu1_ic_prp isn't negotiating its format properly. You can't > > re-create this because you don't have any UYVY8_1X16 (passthrough) > > sensors right? > > Sorry, maybe I didn't mention this, but passthrough cannot go though the > IPU, you can only send passthrough pixels out the CSI directly to > /dev/videoN interface (the ipu_csi:2 pad). > crud... this has been my issue all along with that set of UYVY8_1X16 pipelines then. So this means the mem2mem driver also won't be able to handle 16bit pixel formats as well. So while I can downscale this by multiples of 2 (independent width/height), CSC convert it from srgb/bt.601 to yuv/bt.709, and even pixel reorder it within YUV via the ipu_csi entitty I'll never be able to deinterlace, scale with flexibility, flip/rotate or do a RGB->YUV CSC on it as those are all features of the IC path. I'm still struggling with what mbus format to configure the sensor<->csi interconnect in the device-tree. I was leaning towards 16bit but now that I realize that can't be used with the IPU I'm thinking the bt656 is more flexible (accept it has the limitation of not being able to do 1080p60 due to pixel clock and also can't handle interlaced due bt656 codes). If I end up wanting to switch between tda1997x sensor bus formats I'm not even sure the best way to deal with that (two dts I suppose and allowing user to select which one they use). Tim
Re: [PATCH 2/3] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
On Sun, Feb 3, 2019 at 11:48 AM Steve Longerbeam wrote:
>
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey
> Signed-off-by: Steve Longerbeam
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 67 ++---
> drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
> drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
> include/video/imx-ipu-v3.h | 5 +-
> 4 files changed, 67 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index 35ae86ff0585..63362b4fff81 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -199,6 +199,23 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601
> = {
> .scale = 1,
> };
>
> +/*
> + * BT.709 encoding from RGB full range to YUV limited range:
> + *
> + * Y = R * .2126 + G * .7152 + B * .0722;
> + * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
> + * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
> + */
> +static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
> + .coeff = {
> + { 54, 183, 18 },
> + { 483, 413, 128 },
> + { 128, 396, 500 },
> + },
> + .offset = { 0, 512, 512 },
> + .scale = 1,
> +};
> +
> /* transparent RGB->RGB matrix for graphics combining */
> static const struct ic_csc_params ic_csc_rgb2rgb = {
> .coeff = {
> @@ -226,12 +243,31 @@ static const struct ic_csc_params
> ic_csc_ycbcr2rgb_bt601 = {
> .scale = 2,
> };
>
> +/*
> + * Inverse BT.709 encoding from YUV limited range to RGB full range:
> + *
> + * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
> + * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
> + * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
> + */
> +static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
> + .coeff = {
> + { 128, 0, 202 },
> + { 128, 488, 452 },
> + { 128, 238, 0 },
> + },
> + .offset = { -435, 136, -507 },
> + .scale = 2,
> +};
> +
> static int init_csc(struct ipu_ic *ic,
> enum ipu_color_space inf,
> enum ipu_color_space outf,
> + enum v4l2_ycbcr_encoding encoding,
> int csc_index)
> {
> struct ipu_ic_priv *priv = ic->priv;
> + const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
> const struct ic_csc_params *params;
> u32 __iomem *base;
> const u16 (*c)[3];
> @@ -241,10 +277,24 @@ static int init_csc(struct ipu_ic *ic,
> base = (u32 __iomem *)
> (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>
> + switch (encoding) {
> + case V4L2_YCBCR_ENC_601:
> + params_rgb2yuv = &ic_csc_rgb2ycbcr_bt601;
> + params_yuv2rgb = &ic_csc_ycbcr2rgb_bt601;
> + break;
> + case V4L2_YCBCR_ENC_709:
> + params_rgb2yuv = &ic_csc_rgb2ycbcr_bt709;
> + params_yuv2rgb = &ic_csc_ycbcr2rgb_bt709;
> + break;
> + default:
> + dev_err(priv->ipu->dev, "Unsupported YCbCr encoding\n");
> + return -EINVAL;
> + }
> +
Steve,
This will fail for RGB to RGB with 'Unsupported YCbCr encoding. We
need to account for the RGB->RGB case.
How about something like:
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
- const struct ic_csc_params *params;
+ const struct ic_csc_params *params = NULL;
u32 __iomem *base;
const u16 (*c)[3];
const u16 *a;
@@ -241,13 +276,18 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
- if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = &ic_csc_ycbcr2rgb_bt601;
- else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = &ic_csc_rgb2ycbcr_bt601;
+ if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB) {
+ params = (encoding == V4L2_YCBCR_ENC_601) ?
+ &ic_csc_ycbcr2rgb_bt601 : &ic_csc_ycbcr2rgb_bt709;
+ }
+ else if (inf == IPUV3_COLORSPACE_RGB &&
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Wed, Feb 6, 2019 at 8:31 AM Tim Harvey wrote: > > On Tue, Feb 5, 2019 at 3:54 PM Steve Longerbeam wrote: > > > > > > > > On 2/5/19 11:16 AM, Tim Harvey wrote: > > > On Sat, Feb 2, 2019 at 11:10 AM Steve Longerbeam > > > wrote: > > > > > > > > >> The *real* way to fix this would be to allow programmable encodings in > > >> ipu-ic.c. But unfortunately the encodings are hardcoded (grep for > > >> ic_csc_rgb2ycbcr in ipu-ic.c). > > >> > > > Ok, I saw that you went ahead and worked on this (thanks!) and that > > > you have a bt.709.v2 branch... is that one ready for testing? > > > > Yes. I tried to test it too, but there is some regression in captured > > images, it could be something in ov5640.c (I'm testing with the SabreSD > > and the OV5640), or something else recently added. The regression looks > > like a stride problem, I'm hoping it wasn't the recently introduced > > compose window changes to relax width alignment. Have you tested with > > those commits and a prpenc/vf pipeline? > > I have been testing v4.20 with: > media: imx: lift CSI and PRP ENC/VF width alignment restriction > media: imx: set compose rectangle to mbus format > media: imx: add capture compose rectangle > imx: imx-media: register mem2mem device with media controller > media: imx: add mem2mem device > media: imx-csi: Skip first few frames from a BT.656 source > media: imx.rst: Update doc to reflect fixes to interlaced capture > media: imx: Allow interweave with top/bottom lines swapped > media: imx-csi: Move crop/compose reset after filling default mbus fields > media: imx: vdic: rely on VDIC for correct field order > media: imx-csi: Allow skipping odd chroma rows for YVU420 > media: imx: interweave and odd-chroma-row skip are incompatible > media: imx-csi: Double crop height for alternate fields at sink > media: imx: Fix field negotiation > gpu: ipu-v3: Add planar support to interlaced scan > gpu: ipu-csi: Swap fields according to input/output field types > media: videodev2.h: Add more field helper macros > media: imx: prpencvf: Stop upstream before disabling IDMA channel > media: imx: csi: Stop upstream before disabling IDMA channel > media: imx: csi: Disable CSI immediately after last EOF > media: imx-csi: Input connections to CSI should be optional > > What kind of artifacts are you seeing? > > I noticed your 'media: imx: Add support for BT.709 encoding' series > don't apply cleanly to 4.20 that I'm working with so perhaps its > something else. I'll bump up to linux-media, apply your bt.709.v2 and > see what I get. The BT.709 support is critical for me otherwise I > can't use coda with any pipelines that go through the IC with the > tda1997x HDMI decoder. > Steve, I'm testing your bt.709.v2 branch and it works great! I can now request ycbcr=709 at the CSI input pad and rec709 propagates all the way through the rest of the pipeline and works with coda. I don't see any artifacts so I'm still curious what your seeing? I did notice it adds a regression in that RGB->RGB ends up erroring out with 'Unsupported YCbCr encoding' in ipu_ic_task_init. I'll respond to your patch with details and a fix. > > > > > > > >>> # imx6q-gw54xx tda19971 720p 16bit YUV IPU1_CSI0 > > >>> MODE1:sensor->mux->csi->ic_prp->ic_prpenc > > >>> # set sensor output pad to sensor source format > > >>> v4l2-ctl -d /dev/v4l-subdev15 --set-dv-bt-timings=query > > >>> # sensor format > > >>> media-ctl --get-v4l2 '"tda19971 2-0048":0' > > >>> [fmt:UYVY8_1X16/1280x720 field:none colorspace:rec709] > > >>> # get framerate > > >>> v4l2-ctl --device /dev/v4l-subdev15 --get-dv-timings > > >>> DV timings: > > >>> Active width: 1280 > > >>> Active height: 720 > > >>> Total width: 1650 > > >>> Total height: 750 > > >>> Frame format: progressive > > >>> Polarities: +vsync +hsync > > >>> Pixelclock: 7425 Hz (60.00 frames per second) > > >>> Horizontal frontporch: 110 > > >>> Horizontal sync: 40 > > >>> Horizontal backporch: 220 > > >>> Vertical frontporch: 5 > > >>> Vertical sync: 5 > > >>> Vertical backporch: 20 > > >>> Standards: CTA-861 > > >>
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Tue, Feb 5, 2019 at 3:54 PM Steve Longerbeam wrote: > > > > On 2/5/19 11:16 AM, Tim Harvey wrote: > > On Sat, Feb 2, 2019 at 11:10 AM Steve Longerbeam > > wrote: > > > > > >> The *real* way to fix this would be to allow programmable encodings in > >> ipu-ic.c. But unfortunately the encodings are hardcoded (grep for > >> ic_csc_rgb2ycbcr in ipu-ic.c). > >> > > Ok, I saw that you went ahead and worked on this (thanks!) and that > > you have a bt.709.v2 branch... is that one ready for testing? > > Yes. I tried to test it too, but there is some regression in captured > images, it could be something in ov5640.c (I'm testing with the SabreSD > and the OV5640), or something else recently added. The regression looks > like a stride problem, I'm hoping it wasn't the recently introduced > compose window changes to relax width alignment. Have you tested with > those commits and a prpenc/vf pipeline? I have been testing v4.20 with: media: imx: lift CSI and PRP ENC/VF width alignment restriction media: imx: set compose rectangle to mbus format media: imx: add capture compose rectangle imx: imx-media: register mem2mem device with media controller media: imx: add mem2mem device media: imx-csi: Skip first few frames from a BT.656 source media: imx.rst: Update doc to reflect fixes to interlaced capture media: imx: Allow interweave with top/bottom lines swapped media: imx-csi: Move crop/compose reset after filling default mbus fields media: imx: vdic: rely on VDIC for correct field order media: imx-csi: Allow skipping odd chroma rows for YVU420 media: imx: interweave and odd-chroma-row skip are incompatible media: imx-csi: Double crop height for alternate fields at sink media: imx: Fix field negotiation gpu: ipu-v3: Add planar support to interlaced scan gpu: ipu-csi: Swap fields according to input/output field types media: videodev2.h: Add more field helper macros media: imx: prpencvf: Stop upstream before disabling IDMA channel media: imx: csi: Stop upstream before disabling IDMA channel media: imx: csi: Disable CSI immediately after last EOF media: imx-csi: Input connections to CSI should be optional What kind of artifacts are you seeing? I noticed your 'media: imx: Add support for BT.709 encoding' series don't apply cleanly to 4.20 that I'm working with so perhaps its something else. I'll bump up to linux-media, apply your bt.709.v2 and see what I get. The BT.709 support is critical for me otherwise I can't use coda with any pipelines that go through the IC with the tda1997x HDMI decoder. > > >> > >>> Also can we connect the mem2mem driver to the unused VDIC input in the > >>> media controller so that we can use the VDIC to de-interlace content > >>> captured from non IMX sources (ie PCI or USB capture devices)? > >> Exactly! That's something I have been working on. But it's difficult to > >> connect mem2mem to the unused VDIC IDMAC input pad because as of now the > >> v4l2 mem2mem internal API's do not allow connecting to *existing* > >> processing entities, and there are also issues with how sub-devices are > >> to deal with mem2mem contexts. > >> > >> I do have a WIP branch that creates a video output device that connects > >> to the VDIC IDMAC input pad, which doesn't have the above issues. The > >> only drawback with that is how gstreamer can make use of such an output > >> device. > >> > > ok, keep me posted. Is it the output-vdic or mem2mem.v4-mc branch? > > The output-vdic branch. It's almost ready to go, there is only some > strange issue with low and medium motion-compensation modes (captured > images show "snow"). > > > > I also noticed you have a add-fim-to-prpencvf branch... are you > > working on adding FIM to ipu_ic_prp/enc still? That would be nice to > > have to deal with sync loss/regain in analog decoders going through > > VDIC de-interlacing. > > I've been trying to get this working, I ran into some locking issues > when enabling lock debug options. Still trying to find a solution. > > > > >>> This one (480i60Hz YUV via BT656 sensor->mux->csi->ic_prp->ic_prpenc) > >>> still baffles me a bit but I've also found that any bt656 capture that > >>> isn't specifically 720x480 (NTSC) or 720x576 (PAL) fails because of > >>> the resolution checks in ipu_csi_init_interface() resulting in > >>> 'Unsupported interlaced video mode'. I'm not sure if > >>> ipu_csi_set_bt_interlaced_codes() can be modified to support other > >>> resolutions? > >> Well, Bt.656 only defines sta
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Sat, Feb 2, 2019 at 11:10 AM Steve Longerbeam wrote: > > > > > > > But when going through the IC we again run into the issue where the > > output of the IC isn't a suitable colorspace: > > # 720p@60Hz YUV BT656 > > # set sensor output pad to sensor source format > > v4l2-ctl -d /dev/v4l-subdev15 --set-dv-bt-timings=query > > # sensor format > > media-ctl --get-v4l2 '"tda19971 2-0048":0' # fmt:UYVY8_2X8/1280x720 > > field:none colorspace:srgb > > # reset all links > > media-ctl --reset > > # setup links > > media-ctl -l "'tda19971 2-0048':0 -> 'ipu1_csi0_mux':1[1]" > > media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > > media-ctl -l "'ipu1_csi0':1 -> 'ipu1_ic_prp':0[1]" > > media-ctl -l "'ipu1_ic_prp':1 -> 'ipu1_ic_prpenc':0[1]" > > media-ctl -l "'ipu1_ic_prpenc':1 -> 'ipu1_ic_prpenc capture':0[1]" > > # configure pads > > media-ctl -V "'tda19971 2-0048':0 [fmt:UYVY8_2X8/1280x720 field:none]" > > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY8_2X8/1280x720 field:none]" > > media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/640x360 ]" > > # downscale because the IC can't do >1024 > > media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/640x360 ]" > > media-ctl -V "'ipu1_ic_prpenc':1 [fmt:AYUV32/640x360 ]" > > media-ctl --get-v4l2 '"ipu1_ic_prpenc":1' # > > [fmt:AYUV8_1X32/640x360@1/25 field:none colorspace:srgb xfer:srgb > > ycbcr:601 quantization:lim-range] > > # ^^^ note we are itu601 again b/c that's the only format the IC can ouput > > # stream JPEG/RTP/UDP > > gst-launch-1.0 v4l2src device=/dev/video0 ! \ > >video/x-raw,format=UYVY ! \ > >jpegenc ! rtpjpegpay ! udpsink host=172.24.20.19 port=5000 > > # ^^^ works... SW JPEG can handle itu601 > > Ok. > > > # stream upscale via mem2mem then JPEG/RTP/UDP > > gst-launch-1.0 v4l2src device=/dev/video4 ! \ > >v4l2video8convert ! video/x-raw,width=1280,height=720 ! \ > >jpegenc ! rtpjpegpay ! udpsink host=172.24.20.19 port=5000 > > ERROR: from element > > /GstPipeline:pipeline0/v4l2video8convert:v4l2video8convert0: Device > > '/dev/video8' does not support 2:4:7:1 colorimetry > > # ^^^ fails because mem2mem doesn't support itu601 > > # stream H264/RTP/UDP > > gst-launch-1.0 v4l2src device=/dev/video4 ! \ > >v4l2h264enc output-io-mode=dmabuf-import ! \ > >rtph264pay ! udpsink host=172.24.20.19 port=5001 > > ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: > > Device '/dev/video9' does not support 2:4:7:1 colorimetry > > # ^^^ coda has same issue... can't del with itu601 > > Well, just to see things working, try hacking > imx_media_fill_default_mbus_fields() to set Rec. 709 encoding: > > --- a/drivers/staging/media/imx/imx-media-utils.c > +++ b/drivers/staging/media/imx/imx-media-utils.c > @@ -571,7 +571,7 @@ void imx_media_fill_default_mbus_fields(struct > v4l2_mbus_framefmt *tryfmt, > tryfmt->quantization = is_rgb ? > V4L2_QUANTIZATION_FULL_RANGE : > V4L2_QUANTIZATION_LIM_RANGE; > - tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_601; > + tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_709; > } > } > EXPORT_SYMBOL_GPL(imx_media_fill_default_mbus_fields); > > > But of course that's not technically correct because the encoding in > ipu-ic.c is BT.601. > > The *real* way to fix this would be to allow programmable encodings in > ipu-ic.c. But unfortunately the encodings are hardcoded (grep for > ic_csc_rgb2ycbcr in ipu-ic.c). > Ok, I saw that you went ahead and worked on this (thanks!) and that you have a bt.709.v2 branch... is that one ready for testing? > The other option would be to change ic_csc_rgb2ycbcr to use the Rec. 709 > coefficients, and then the above patch is no longer a hack. The inverse > encoding (ic_csc_ycbcr2rgb) would also need to be changed. > > > > > > Am I perhaps missing a capsfilter to get the mem2mem driver to convert > > the colorspace properly? If so, they the mem2mem driver could be used > > to correct the colorspace to get IC output to coda working. > > Well, first I don't think the mem2mem driver is using the correct > encoding. The mem2mem driver is making use of the IC encoding so it > should be reporting and accepting only BT.601. > > Philipp ^^ > > > > > > Also can we connect the mem2mem driver to the unused VDIC input in the > > media controller so that we can use the VDIC to de-interlace content > > captured from non IMX sources (ie PCI or USB capture devices)? > > Exactly! That's something I have been working on. But it's difficult to > connect mem2mem to the unused VDIC IDMAC input pad because as of now the > v4l2 mem2mem internal API's do not allow connecting to *existing* > processing entities, and there are also issues with how sub-devices are > to deal with mem2mem contexts. > > I do have a WIP branch that creates a video output device that connects > to the VDIC IDMAC input pad, which doesn't have the above issues. The > only drawback with that is how gstreamer can make use of such an output > device. > ok, keep
[PATCH] media: tda1997: fix get-edid
Signed-off-by: Tim Harvey --- drivers/media/i2c/tda1997x.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c index c4c2a6134e1e..73451e9bbc41 100644 --- a/drivers/media/i2c/tda1997x.c +++ b/drivers/media/i2c/tda1997x.c @@ -1884,6 +1884,10 @@ static int tda1997x_set_edid(struct v4l2_subdev *sd, struct v4l2_edid *edid) for (i = 0; i < 128; i++) io_write(sd, REG_EDID_IN_BYTE128 + i, edid->edid[i+128]); + /* store state */ + memcpy(state->edid.edid, edid->edid, 256); + state->edid.blocks = edid->blocks; + tda1997x_enable_edid(sd); return 0; -- 2.17.1
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Mon, Jan 28, 2019 at 3:04 PM Steve Longerbeam wrote:
>
>
>
> On 1/28/19 11:03 AM, Tim Harvey wrote:
> > On Fri, Jan 25, 2019 at 3:57 PM Steve Longerbeam
> > wrote:
> >> Hi Tim, cc: Philipp,
> >>
> >> On 1/23/19 3:21 PM, Tim Harvey wrote:
> >>> Steve,
> >>>
> >>> I'm testing IMX6 capture again with the tda1997x HDMI receiver found
> >>> on Gateworks GW54xx and GW551x boards. This is hooked up to the IMX6
> >>> CSI in a way where it can be configured for 8bit BT656 mode
> >>> (UYVY8_2X8) or 16bit YUV mode (UYVY8_1X16). Also I have a Marshall
> >>> Electronics V-SG4K-HDI HDMI signal generator here so I can test a wide
> >>> variety of resolutions, bus formats, interlaced modes, and
> >>> colorspaces.
> >>>
> >>> I'm using the following for testing:
> >>> - Linux 4.20 +
> >>> - media: imx-csi: Input connections to CSI should be optional
> >>> - imx-media: Fixes for interlaced capture
> >>> - media: imx: Stop stream before disabling IDMA channels
> >>> - v4l-utils 1.16.1
> >>> - gstreamer-1.14.1 (with the ability to test master as well)
> >>>
> >>> I have a script that generates the media-ctl/v4l2-ctl commands based
> >>> on providing a sensor ('adv7180' analog decoder or 'tda1997x' HDMI
> >>> decoder) and a 'mode' which I've defined as:
> >>> mode0: sensor -> mux -> csi -> /dev/videoN
> >>> mode1: sensor -> mux -> csi -> ic_prp -> ic_prpenc -> /dev/videoN
> >>> (provides a
> >>> mode2: sensor -> mux -> csi -> ic_prp -> ic_prpvf -> /dev/videoN
> >>> mode3: sensor -> mux -> csi -> vdic -> ic_prp -> ic_prpvf -> /dev/videoN
> >>>
> >>> The media-ctl topologies for each cpu/board combo are at
> >>> http://dev.gateworks.com/docs/linux/media/
> >>>
> >>> I'm trying to test out simple v4l2-ctl based capture of a single frame
> >>> as well as capture and stream via both software JPEG encode and H264
> >>> hardware encode via CODA.
> >>>
> >>> Please let me know of any changes that should be made to the commands
> >>> below even if only to purely help document things through clarity.
> >>>
> >>> One of the issues I run into right away is image size: The imx.rst
> >>> docs state that the ic has a 'resize' limit of 1024x1024 but I think
> >>> I'm mislead by the word 'resize' and this also means you can't push
> >>> say 1080x720 through it (not resizing, just putting that on the src
> >>> pad) as it clips it to 1024x720.
> >> The IC is limited to a resized *output* frame of 1024x1024, no higher.
> >>
> > Ok so this means for anything >1024 I need to either use the csi to
> > downscale it by factors of 2 first, or use mem2mem solution which
> > means I can't use the VDIC (so no interlaced).
>
> Actually that isn't true. You can still use a VDIC pipeline for the
> 1280x720 interlaced tda19971 source. It's just that you would need to
> downscale to <=1024 (either using the CSI /2, and/or using the IC prpvf
> scaler). Then use the mem2mem gstreamer element to upscale the prpvf
> capture output to something >1024.
>
True, that would work and here are my mem2mem testing findings:
I've found that mem2mem from the CSI works well:
- Using the CSI to downscale 720p then going through mem2mem and
upscaling it (works perfectly!)
# 720p@60Hz YUV BT656
# query current timings and set to this
v4l2-ctl -d $(media-ctl -e "tda19971 2-0048") --set-dv-bt-timings=query
# get timings
media-ctl --get-v4l2 '"tda19971 2-0048":0' # [fmt:UYVY8_2X8/1280x720
field:none colorspace:srgb]
# reset media controller links
media-ctl --reset
# create links
media-ctl --link '"tda19971 2-0048":0 -> "ipu1_csi0_mux":1[1]'
media-ctl --link '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
media-ctl --link '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]'
# set pad formats
media-ctl --set-v4l2 '"tda19971 2-0048":0[fmt:UYVY8_2X8/1280x720]'
media-ctl --set-v4l2 '"ipu1_csi0_mux":2[fmt:UYVY8_2X8/1280x720]'
media-ctl --set-v4l2 '"ipu1_csi0":0[fmt:AYUV32/1280x720
colorspace:rec709 ycbcr:709]'
media-ctl --set-v4l2 '"ipu1_csi0":0[compose:(0,0)/640x360]' # 1/2 scale
media-ctl --get-v4l2 '"
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Sun, Jan 27, 2019 at 2:36 PM Steve Longerbeam wrote: > > Hi Tim, > > On 1/25/19 3:57 PM, Steve Longerbeam wrote: > > >> Now lets go back to a 480p60 source but this time include the vdic > >> (which isn't necessary but should still work right?) > > > > No. First, the CSI will only capture in bt.656 mode if it sees > > interlaced fields (bt.656 interlaced sync codes). Well, let me > > rephrase, the CSI does support progressive BT.656 but I have never > > tested that myself. > > One more comment here. It would be great if you could test a progressive > bt.656 sensor (example: imx6q-gw54xx tda19971 480p60Hz YUV via BT656 > IPU1_CSI0) since as I said I've never been able to test this myself. > > Since it is progressive there's no need for the VDIC, so try these > pipelines: > > mode0: sensor -> mux -> csi -> /dev/videoN > mode1: sensor -> mux -> csi -> ic_prp -> ic_prpenc -> /dev/videoN > Steve, These both work fine in all cases for 480p60Hz YUV via BT656. When I use 480p60Hz 'RGB' via BT656 mode0 works fine as the CSI does the colorspace conversion needed for coda but for mode1 I end up with the itu601 colorimetery issue from before that I'm still trying to find a solution for. Tim
Re: IMX CSI capture issues with tda1997x HDMI receiver
On Fri, Jan 25, 2019 at 3:57 PM Steve Longerbeam wrote:
>
> Hi Tim, cc: Philipp,
>
> On 1/23/19 3:21 PM, Tim Harvey wrote:
> > Steve,
> >
> > I'm testing IMX6 capture again with the tda1997x HDMI receiver found
> > on Gateworks GW54xx and GW551x boards. This is hooked up to the IMX6
> > CSI in a way where it can be configured for 8bit BT656 mode
> > (UYVY8_2X8) or 16bit YUV mode (UYVY8_1X16). Also I have a Marshall
> > Electronics V-SG4K-HDI HDMI signal generator here so I can test a wide
> > variety of resolutions, bus formats, interlaced modes, and
> > colorspaces.
> >
> > I'm using the following for testing:
> > - Linux 4.20 +
> >- media: imx-csi: Input connections to CSI should be optional
> >- imx-media: Fixes for interlaced capture
> >- media: imx: Stop stream before disabling IDMA channels
> > - v4l-utils 1.16.1
> > - gstreamer-1.14.1 (with the ability to test master as well)
> >
> > I have a script that generates the media-ctl/v4l2-ctl commands based
> > on providing a sensor ('adv7180' analog decoder or 'tda1997x' HDMI
> > decoder) and a 'mode' which I've defined as:
> > mode0: sensor -> mux -> csi -> /dev/videoN
> > mode1: sensor -> mux -> csi -> ic_prp -> ic_prpenc -> /dev/videoN (provides
> > a
> > mode2: sensor -> mux -> csi -> ic_prp -> ic_prpvf -> /dev/videoN
> > mode3: sensor -> mux -> csi -> vdic -> ic_prp -> ic_prpvf -> /dev/videoN
> >
> > The media-ctl topologies for each cpu/board combo are at
> > http://dev.gateworks.com/docs/linux/media/
> >
> > I'm trying to test out simple v4l2-ctl based capture of a single frame
> > as well as capture and stream via both software JPEG encode and H264
> > hardware encode via CODA.
> >
> > Please let me know of any changes that should be made to the commands
> > below even if only to purely help document things through clarity.
> >
> > One of the issues I run into right away is image size: The imx.rst
> > docs state that the ic has a 'resize' limit of 1024x1024 but I think
> > I'm mislead by the word 'resize' and this also means you can't push
> > say 1080x720 through it (not resizing, just putting that on the src
> > pad) as it clips it to 1024x720.
>
> The IC is limited to a resized *output* frame of 1024x1024, no higher.
>
Ok so this means for anything >1024 I need to either use the csi to
downscale it by factors of 2 first, or use mem2mem solution which
means I can't use the VDIC (so no interlaced). I will try your patch
that adds registration of the mem2mem driver to the media-ctl api.
> > I believe some of Phillip's pending
> > patches may be aimed at rectifying this limitation?
>
> If you mean the mem2mem driver, yes. The mem2mem driver makes use the
> ipu-image-convert APIs which includes tiled resizing, so it will support
> greater-than 1024x1024 output frames. Latest status I've heard is that
> there is some misunderstanding of the behavior of rotation, that will
> require some rework of the mem2mem driver and ipu-image-convert (and
> sigh, the ic-prpencvf sub-device which also supports h/w rotation).
>
> But you could actually grab the last posted version of mem2mem driver
> (v7). It works fine except for the rotation misunderstanding (but even
> that works but doesn't conform to v4l2 expected behavior). You will then
> have a gstreamer element v4l2convertN for >1024 resizing support.
>
Ok, so I've applied that to my kernel and now have a new /dev/video*
device for ipu_ic_pp. I'll start testing with it.
> Also recently merged from Philipp is the work to relax capture width
> alignment, by DMA'ing to padded frames. But that is not related to mem2mem.
>
Ok - I'll merge this one to so I'm testing with it.
> >
> > Another issue I'm running into is colorspace conversion, specifically
> > colorimetry
> >
> > Example: imx6q-gw54xx tda19971 720p60Hz YUV via BT656 IPU1_CSI0
> > MODE1:sensor->mux->csi->ic_prp->ic_prpenc
> > # set sensor output pad to sensor source format
> > v4l2-ctl -d /dev/v4l-subdev15 --set-dv-bt-timings=query
> > # sensor format
> > media-ctl --get-v4l2 '"tda19971 2-0048":0' # fmt:UYVY8_2X8/1280x720
> > field:none colorspace:rec709
> > # reset all links
> > media-ctl --reset
> > # setup links
> > media-ctl -l "'tda19971 2-0048':0 -> 'ipu1_csi0_mux':1[1]"
> > media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0&#x
IMX CSI capture issues with tda1997x HDMI receiver
Steve,
I'm testing IMX6 capture again with the tda1997x HDMI receiver found
on Gateworks GW54xx and GW551x boards. This is hooked up to the IMX6
CSI in a way where it can be configured for 8bit BT656 mode
(UYVY8_2X8) or 16bit YUV mode (UYVY8_1X16). Also I have a Marshall
Electronics V-SG4K-HDI HDMI signal generator here so I can test a wide
variety of resolutions, bus formats, interlaced modes, and
colorspaces.
I'm using the following for testing:
- Linux 4.20 +
- media: imx-csi: Input connections to CSI should be optional
- imx-media: Fixes for interlaced capture
- media: imx: Stop stream before disabling IDMA channels
- v4l-utils 1.16.1
- gstreamer-1.14.1 (with the ability to test master as well)
I have a script that generates the media-ctl/v4l2-ctl commands based
on providing a sensor ('adv7180' analog decoder or 'tda1997x' HDMI
decoder) and a 'mode' which I've defined as:
mode0: sensor -> mux -> csi -> /dev/videoN
mode1: sensor -> mux -> csi -> ic_prp -> ic_prpenc -> /dev/videoN (provides a
mode2: sensor -> mux -> csi -> ic_prp -> ic_prpvf -> /dev/videoN
mode3: sensor -> mux -> csi -> vdic -> ic_prp -> ic_prpvf -> /dev/videoN
The media-ctl topologies for each cpu/board combo are at
http://dev.gateworks.com/docs/linux/media/
I'm trying to test out simple v4l2-ctl based capture of a single frame
as well as capture and stream via both software JPEG encode and H264
hardware encode via CODA.
Please let me know of any changes that should be made to the commands
below even if only to purely help document things through clarity.
One of the issues I run into right away is image size: The imx.rst
docs state that the ic has a 'resize' limit of 1024x1024 but I think
I'm mislead by the word 'resize' and this also means you can't push
say 1080x720 through it (not resizing, just putting that on the src
pad) as it clips it to 1024x720. I believe some of Phillip's pending
patches may be aimed at rectifying this limitation?
Another issue I'm running into is colorspace conversion, specifically
colorimetry
Example: imx6q-gw54xx tda19971 720p60Hz YUV via BT656 IPU1_CSI0
MODE1:sensor->mux->csi->ic_prp->ic_prpenc
# set sensor output pad to sensor source format
v4l2-ctl -d /dev/v4l-subdev15 --set-dv-bt-timings=query
# sensor format
media-ctl --get-v4l2 '"tda19971 2-0048":0' # fmt:UYVY8_2X8/1280x720
field:none colorspace:rec709
# reset all links
media-ctl --reset
# setup links
media-ctl -l "'tda19971 2-0048':0 -> 'ipu1_csi0_mux':1[1]"
media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]"
media-ctl -l "'ipu1_csi0':1 -> 'ipu1_ic_prp':0[1]"
media-ctl -l "'ipu1_ic_prp':1 -> 'ipu1_ic_prpenc':0[1]"
media-ctl -l "'ipu1_ic_prpenc':1 -> 'ipu1_ic_prpenc capture':0[1]"
# configure pads
media-ctl -V "'tda19971 2-0048':0 [fmt:UYVY8_2X8/1280x720 field:none]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY8_2X8/1280x720 field:none]"
media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/1280x720]"
media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/1280x720]"
media-ctl -V "'ipu1_ic_prpenc':1 [fmt:AYUV32/1280x720]"
# capture device
media-ctl -e 'ipu1_ic_prpenc capture' # /dev/video0
v4l2-ctl --device /dev/video0 --get-fmt-video
Format Video Capture:
Width/Height : 1024/720
Pixel Format : 'UYVY' (UYVY 4:2:2)
Field : None
Bytes per Line: 2048
Size Image: 1474560
Colorspace: Rec. 709
Transfer Function : Rec. 709
YCbCr/HSV Encoding: ITU-R 601
Quantization : Limited Range
Flags :
^^^ Note 1080x720 has been reduced to 1024x720 - ouch!
# capture 1 frame
v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=x.raw --stream-count=1
^^^ works
# stream JPEG/RTP/UDP
gst-launch-1.0 v4l2src device=/dev/video0 ! \
video/x-raw,format=UYVY ! \
jpegenc ! rtpjpegpay ! udpsink host=172.24.20.19 port=5000
^^^ works (but of course squashed horizontally because of x=1024)
# stream H264/RTP/UDP (via coda)
# need to make sure we feed coda NV12/rec709
media-ctl --get-v4l2 '"ipu1_ic_prpenc":0' #
fmt:AYUV8_1X32/1280x720@1/25 field:none colorspace:rec709 xfer:709
ycbcr:601 quantization:lim-range
^^^ input colorspace is rec709 but colorimetry needs to be changed to 709
media-ctl --set-v4l2 '"ipu1_ic_prpenc":0[fmt:AYUV32/1280x720
colorspace:rec709 ycbcr:709]'
^^^ no error but doing a get-v4l2 shows no change - is this all
because of trying to deal with 1080 instead of 1024?
gst-launch-1.0 v4l2src device=/dev/video0 ! \
v4l2h264enc output-io-mode=dmabuf-import ! \
rtph264pay ! udpsink host=172.24.20.19 port=5001
v4l2src0: Device '/dev/video0' does not support 2:0:0:0 colorimetry
^^^ fails because of colorimetry not getting set
Let me remove the >1024 issue by using a 480p source...
Example: imx6q-gw54xx tda19971 480p60Hz YUV via BT656 IPU1_CSI0
MODE1:sensor->mux->csi->ic_prp->ic_prpenc
# set sensor output pad to sensor source format
v4l2-ctl -d /dev/v4l-subdev15 --set-dv-bt-timings=query
# sensor format
media-ctl --get-v4l2 '"tda19971 2-0048":
Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Tue, Jan 22, 2019 at 4:10 PM Steve Longerbeam wrote: > > > > On 1/21/19 12:24 PM, Tim Harvey wrote: > > On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam > > wrote: > >> Hi Tim, > >> > >> On 1/15/19 1:58 PM, Tim Harvey wrote: > >>> On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam > >>> wrote: > >>>> Also add an example pipeline for unconverted capture with interweave > >>>> on SabreAuto. > >>>> > >>>> Cleanup some language in various places in the process. > >>>> > >>>> Signed-off-by: Steve Longerbeam > >>>> Reviewed-by: Philipp Zabel > >>>> --- > >>>> Changes since v4: > >>>> - Make clear that it is IDMAC channel that does pixel reordering and > >>>> interweave, not the CSI. Caught by Philipp Zabel. > >>>> Changes since v3: > >>>> - none. > >>>> Changes since v2: > >>>> - expand on idmac interweave behavior in CSI subdev. > >>>> - switch second SabreAuto pipeline example to PAL to give > >>>> both NTSC and PAL examples. > >>>> - Cleanup some language in various places. > >>>> --- > >>>>Documentation/media/v4l-drivers/imx.rst | 103 +++- > >>>>1 file changed, 66 insertions(+), 37 deletions(-) > >>>> > >>> > >>>>Capture Pipelines > >>>>- > >>>> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder > >>>> is connected to the > >>>>parallel bus input on the internal video mux to IPU1 CSI0. > >>>> > >>>>The following example configures a pipeline to capture from the > >>>> ADV7180 > >>>> -video decoder, assuming NTSC 720x480 input signals, with Motion > >>>> -Compensated de-interlacing. Pad field types assume the adv7180 outputs > >>>> -"interlaced". $outputfmt can be any format supported by the > >>>> ipu1_ic_prpvf > >>>> -entity at its output pad: > >>>> +video decoder, assuming NTSC 720x480 input signals, using simple > >>>> +interweave (unconverted and without motion compensation). The adv7180 > >>>> +must output sequential or alternating fields (field type 'seq-bt' for > >>>> +NTSC, or 'alternate'): > >>>> + > >>>> +.. code-block:: none > >>>> + > >>>> + # Setup links > >>>> + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > >>>> + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > >>>> + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > >>>> + # Configure pads > >>>> + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > >>>> + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > >>>> + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > >>>> + # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4) > >>>> + v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt > >>>> + > >>>> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be > >>>> +used to select any supported YUV pixelformat on /dev/video4. > >>>> + > >>> Hi Steve, > >>> > >>> I'm testing 4.20 with this patchset on top. > >>> > >>> I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like > >>> the SabeAuto example above I can't get the simple interveave example > >>> to work: > >>> > >>> media-ctl -r # reset all links > >>> # Setup links (ADV7180 IPU1_CSI0) > >>> media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' > >>> media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' > >>> media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4 > >>> # Configure pads > >>> media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > >>> media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x4
Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Mon, Jan 21, 2019 at 12:24 PM Tim Harvey wrote: > > On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam > wrote: > > > > Hi Tim, > > > > On 1/15/19 1:58 PM, Tim Harvey wrote: > > > On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam > > > wrote: > > >> Also add an example pipeline for unconverted capture with interweave > > >> on SabreAuto. > > >> > > >> Cleanup some language in various places in the process. > > >> > > >> Signed-off-by: Steve Longerbeam > > >> Reviewed-by: Philipp Zabel > > >> --- > > >> Changes since v4: > > >> - Make clear that it is IDMAC channel that does pixel reordering and > > >>interweave, not the CSI. Caught by Philipp Zabel. > > >> Changes since v3: > > >> - none. > > >> Changes since v2: > > >> - expand on idmac interweave behavior in CSI subdev. > > >> - switch second SabreAuto pipeline example to PAL to give > > >>both NTSC and PAL examples. > > >> - Cleanup some language in various places. > > >> --- > > >> Documentation/media/v4l-drivers/imx.rst | 103 +++- > > >> 1 file changed, 66 insertions(+), 37 deletions(-) > > >> > > > > > >> Capture Pipelines > > >> - > > >> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder > > >> is connected to the > > >> parallel bus input on the internal video mux to IPU1 CSI0. > > >> > > >> The following example configures a pipeline to capture from the ADV7180 > > >> -video decoder, assuming NTSC 720x480 input signals, with Motion > > >> -Compensated de-interlacing. Pad field types assume the adv7180 outputs > > >> -"interlaced". $outputfmt can be any format supported by the > > >> ipu1_ic_prpvf > > >> -entity at its output pad: > > >> +video decoder, assuming NTSC 720x480 input signals, using simple > > >> +interweave (unconverted and without motion compensation). The adv7180 > > >> +must output sequential or alternating fields (field type 'seq-bt' for > > >> +NTSC, or 'alternate'): > > >> + > > >> +.. code-block:: none > > >> + > > >> + # Setup links > > >> + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > > >> + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > > >> + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > > >> + # Configure pads > > >> + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > > >> + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > > >> + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > > >> + # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4) > > >> + v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt > > >> + > > >> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be > > >> +used to select any supported YUV pixelformat on /dev/video4. > > >> + > > > Hi Steve, > > > > > > I'm testing 4.20 with this patchset on top. > > > > > > I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like > > > the SabeAuto example above I can't get the simple interveave example > > > to work: > > > > > > media-ctl -r # reset all links > > > # Setup links (ADV7180 IPU1_CSI0) > > > media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' > > > media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' > > > media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4 > > > # Configure pads > > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > > > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]" > > > > This is the reason. The adv7180 is only allowing to configure alternate > > field mode, and thus it reports the field height on the mbus, not the > > full frame height. Imx deals with alternate field
CODA9 (IMX) JPEG support
Philipp, Is there any support for coda9 (imx) JPEG enc/dec support being worked on in the coda driver? I noticed there is support for coda7 but not yet coda9. Best regards, Tim
Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam wrote: > > Hi Tim, > > On 1/15/19 1:58 PM, Tim Harvey wrote: > > On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam > > wrote: > >> Also add an example pipeline for unconverted capture with interweave > >> on SabreAuto. > >> > >> Cleanup some language in various places in the process. > >> > >> Signed-off-by: Steve Longerbeam > >> Reviewed-by: Philipp Zabel > >> --- > >> Changes since v4: > >> - Make clear that it is IDMAC channel that does pixel reordering and > >>interweave, not the CSI. Caught by Philipp Zabel. > >> Changes since v3: > >> - none. > >> Changes since v2: > >> - expand on idmac interweave behavior in CSI subdev. > >> - switch second SabreAuto pipeline example to PAL to give > >>both NTSC and PAL examples. > >> - Cleanup some language in various places. > >> --- > >> Documentation/media/v4l-drivers/imx.rst | 103 +++- > >> 1 file changed, 66 insertions(+), 37 deletions(-) > >> > > > >> Capture Pipelines > >> - > >> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder is > >> connected to the > >> parallel bus input on the internal video mux to IPU1 CSI0. > >> > >> The following example configures a pipeline to capture from the ADV7180 > >> -video decoder, assuming NTSC 720x480 input signals, with Motion > >> -Compensated de-interlacing. Pad field types assume the adv7180 outputs > >> -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf > >> -entity at its output pad: > >> +video decoder, assuming NTSC 720x480 input signals, using simple > >> +interweave (unconverted and without motion compensation). The adv7180 > >> +must output sequential or alternating fields (field type 'seq-bt' for > >> +NTSC, or 'alternate'): > >> + > >> +.. code-block:: none > >> + > >> + # Setup links > >> + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > >> + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > >> + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > >> + # Configure pads > >> + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > >> + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > >> + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > >> + # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4) > >> + v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt > >> + > >> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be > >> +used to select any supported YUV pixelformat on /dev/video4. > >> + > > Hi Steve, > > > > I'm testing 4.20 with this patchset on top. > > > > I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like > > the SabeAuto example above I can't get the simple interveave example > > to work: > > > > media-ctl -r # reset all links > > # Setup links (ADV7180 IPU1_CSI0) > > media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' > > media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' > > media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4 > > # Configure pads > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]" > > This is the reason. The adv7180 is only allowing to configure alternate > field mode, and thus it reports the field height on the mbus, not the > full frame height. Imx deals with alternate field mode by capturing a > full frame, so the CSI entity sets the output pad height to double the > height. > > So the CSI input pad needs to be configured with the field height: > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x240]" > > It should work for you after doing that. And better yet, don't bother > configuring the input pad, because media-ctl will propagate formats from > source to sink pads for you, so it's better to rely on the pro
Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam wrote: > > Also add an example pipeline for unconverted capture with interweave > on SabreAuto. > > Cleanup some language in various places in the process. > > Signed-off-by: Steve Longerbeam > Reviewed-by: Philipp Zabel > --- > Changes since v4: > - Make clear that it is IDMAC channel that does pixel reordering and > interweave, not the CSI. Caught by Philipp Zabel. > Changes since v3: > - none. > Changes since v2: > - expand on idmac interweave behavior in CSI subdev. > - switch second SabreAuto pipeline example to PAL to give > both NTSC and PAL examples. > - Cleanup some language in various places. > --- > Documentation/media/v4l-drivers/imx.rst | 103 +++- > 1 file changed, 66 insertions(+), 37 deletions(-) > > Capture Pipelines > - > @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder is > connected to the > parallel bus input on the internal video mux to IPU1 CSI0. > > The following example configures a pipeline to capture from the ADV7180 > -video decoder, assuming NTSC 720x480 input signals, with Motion > -Compensated de-interlacing. Pad field types assume the adv7180 outputs > -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf > -entity at its output pad: > +video decoder, assuming NTSC 720x480 input signals, using simple > +interweave (unconverted and without motion compensation). The adv7180 > +must output sequential or alternating fields (field type 'seq-bt' for > +NTSC, or 'alternate'): > + > +.. code-block:: none > + > + # Setup links > + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > + # Configure pads > + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > + # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4) > + v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt > + > +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be > +used to select any supported YUV pixelformat on /dev/video4. > + Hi Steve, I'm testing 4.20 with this patchset on top. I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like the SabeAuto example above I can't get the simple interveave example to work: media-ctl -r # reset all links # Setup links (ADV7180 IPU1_CSI0) media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4 # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]" # Configure 'ipu1_csi0 capture' interface (/dev/video4) v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt # streaming can now begin on the raw capture device node at /dev/video4 v4l2-ctl -d4 --stream-mmap --stream-to=/x.raw --stream-count=1 # capture 1 frame [ 5547.354460] ipu1_csi0: pipeline start failed with -32 VIDIOC_STREAMON: failed: Broken pipe Any ideas what is causing this pipeline failure. > +This example configures a pipeline to capture from the ADV7180 > +video decoder, assuming PAL 720x576 input signals, with Motion > +Compensated de-interlacing. The adv7180 must output sequential or > +alternating fields (field type 'seq-tb' for PAL, or 'alternate'). > +$outputfmt can be any format supported by the ipu1_ic_prpvf entity > +at its output pad: > > .. code-block:: none > > @@ -531,11 +560,11 @@ entity at its output pad: > media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]" > media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]" > # Configure pads > - media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480]" > - media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" > - media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480 field:interlaced]" > - media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x480 field:none]" > - media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x480 field:none]" > + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x576 field:seq-tb]" > + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x576]" > + media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x576]" > + media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x576 field:none]" > + media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x576 field:none]" > media-ctl -V "'ipu1_ic_prpvf':1 [fmt:$outputfmt field:none]" > > Streaming can then begin on the capture device node at The above motion-compensation example pipeline does now work with this patch series - thanks for addressing this! Regards, Tim
Re: [PATCH] media: imx-csi: Input connections to CSI should be optional
On Wed, Jan 9, 2019 at 10:34 AM Steve Longerbeam wrote:
>
> Some imx platforms do not have fwnode connections to all CSI input
> ports, and should not be treated as an error. This includes the
> imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
> Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
> endpoint parsing will not treat an unconnected CSI input port as
> an error.
>
> Fixes: c893500a16baf ("media: imx: csi: Register a subdev notifier")
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/imx-media-csi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index 4223f8d418ae..30b1717982ae 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1787,7 +1787,7 @@ static int imx_csi_parse_endpoint(struct device *dev,
> struct v4l2_fwnode_endpoint *vep,
> struct v4l2_async_subdev *asd)
> {
> - return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
> + return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
> }
>
> static int imx_csi_async_register(struct csi_priv *priv)
> --
> 2.17.1
>
Steve,
Thanks, this fixes adv7180 the capture regression on the Gateworks
Ventana boards as well. This should go to stable to fix 4.20 so please
add a 'Cc: sta...@vger.kernel.org' if you re-submit (else we can send
it to sta...@vger.kernel.org later).
Acked-by: Tim Harvey
Tim
[PATCH] media: adv7180: add g_skip_frames support
The adv7180 produces 1 to 2 frames of garbage before proper sync is
established. This allows V4L2 drivers and apps to skip those.
Signed-off-by: Tim Harvey
---
drivers/media/i2c/adv7180.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 99697ba..6f3dc88 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -180,6 +180,9 @@
#define V4L2_CID_ADV_FAST_SWITCH (V4L2_CID_USER_ADV7180_BASE + 0x00)
+/* Initial number of frames to skip to avoid possible garbage */
+#define ADV7180_NUM_OF_SKIP_FRAMES 2
+
struct adv7180_state;
#define ADV7180_FLAG_RESET_POWERED BIT(0)
@@ -769,6 +772,13 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
return 0;
}
+static int adv7180_get_skip_frames(struct v4l2_subdev *sd, u32 *frames)
+{
+ *frames = ADV7180_NUM_OF_SKIP_FRAMES;
+
+ return 0;
+}
+
static int adv7180_g_pixelaspect(struct v4l2_subdev *sd, struct v4l2_fract
*aspect)
{
struct adv7180_state *state = to_state(sd);
@@ -849,10 +859,15 @@ static const struct v4l2_subdev_pad_ops adv7180_pad_ops =
{
.get_fmt = adv7180_get_pad_format,
};
+static const struct v4l2_subdev_sensor_ops adv7180_sensor_ops = {
+ .g_skip_frames = adv7180_get_skip_frames,
+};
+
static const struct v4l2_subdev_ops adv7180_ops = {
.core = &adv7180_core_ops,
.video = &adv7180_video_ops,
.pad = &adv7180_pad_ops,
+ .sensor = &adv7180_sensor_ops,
};
static irqreturn_t adv7180_irq(int irq, void *devid)
--
2.7.4
Re: [PATCH v3 01/16] media: imx: add mem2mem device
On Fri, Oct 19, 2018 at 1:19 PM Steve Longerbeam wrote: > > > On 10/19/18 2:53 AM, Philipp Zabel wrote: > > Hi Tim, > > > > On Thu, 2018-10-18 at 15:53 -0700, Tim Harvey wrote: > > [...] > >> Philipp, > >> > >> Thanks for submitting this! > >> > >> I'm hoping this lets us use non-IMX capture devices along with the IMX > >> media controller entities to so we can use hardware > >> CSC,scaling,pixel-format-conversions and ultimately coda based encode. > >> > >> I've built this on top of linux-media and see that it registers as > >> /dev/video8 but I'm not clear how to use it? I don't see it within the > >> media controller graph. > > It's a V4L2 mem2mem device that can be handled by the GstV4l2Transform > > element, for example. GStreamer should create a v4l2video8convert > > element of that type. > > > > The mem2mem device is not part of the media controller graph on purpose. > > There is no interaction with any of the entities in the media controller > > graph apart from the fact that the IC PP task we are using for mem2mem > > scaling is sharing hardware resources with the IC PRP tasks used for the > > media controller scaler entitites. > > > It would be nice in the future to link mem2mem output-side to the ipu_vdic:1 > pad, to make use of h/w VDIC de-interlace as part of mem2mem operations. > The progressive output from a new ipu_vdic:3 pad can then be sent to the > image_convert APIs by the mem2mem driver for further tiled scaling, CSC, > and rotation by the IC PP task. The ipu_vdic:1 pad makes use of pure > DMA-based > de-interlace, that is, all input frames (N-1, N, N+1) to the VDIC are sent > from DMA buffers, and this VDIC mode of operation is well understood > and produces clean de-interlace output. The risk is that this would require > iDMAC channel 5 for ipu_vdic:3, which IFAIK is not verified to work yet. > > > The other problem with that currently is that mem2mem would have to be > split into > separate device nodes: a /dev/videoN for output-side (linked to > ipu_vdic:1), and > a /dev/videoM for capture-side (linked from ipu_vdic:3). And then it no > longer > presents to userspace as a mem2mem device with a single device node for both > output and capture sides. > > > Or is there another way? I recall work to integrate mem2mem with media > control. > There is v4l2_m2m_register_media_controller(), but that create three > entities: > source, processing, and sink. The VDIC entity would be part of mem2mem > processing but this entity already exists for the current graph. This > function > could however be used as a guide to incorporate the VDIC entity into m2m > device. > I agree - without being able to utilize de-interlace,csc,scaling and rotation it seems fairly limited today (but a great start!). Also, if it were in the media graph wouldn't we be able to use the compose selection subdev API? I've got an AVC8000 minPCIe card here with a TW6869 with 8x analog capture inputs that I'm hoping to someday soon be able to capture, compose into a single frame, and encode. Regards, Tim
Re: [PATCH v3 01/16] media: imx: add mem2mem device
On Tue, Sep 18, 2018 at 2:34 AM Philipp Zabel wrote: > > Add a single imx-media mem2mem video device that uses the IPU IC PP > (image converter post processing) task for scaling and colorspace > conversion. > On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used. > > The hardware only supports writing to destination buffers up to > 1024x1024 pixels in a single pass, arbitrary sizes can be achieved > by rendering multiple tiles per frame. > > Signed-off-by: Philipp Zabel > [steve_longerb...@mentor.com: use ipu_image_convert_adjust(), fix > device_run() error handling] > Signed-off-by: Steve Longerbeam > --- > Changes since v2: > - Rely on ipu_image_convert_adjust() in mem2mem_try_fmt() for format >adjustments. This makes the mem2mem driver mostly a V4L2 mem2mem API >wrapper around the IPU image converter, and independent of the >internal image converter implementation. > - Remove the source and destination buffers on error in device_run(). >Otherwise the conversion is re-attempted apparently over and over >again (with WARN() backtraces). > - Allow subscribing to control changes. > --- > drivers/staging/media/imx/Kconfig | 1 + > drivers/staging/media/imx/Makefile| 1 + > drivers/staging/media/imx/imx-media-dev.c | 11 + > drivers/staging/media/imx/imx-media-mem2mem.c | 873 ++ > drivers/staging/media/imx/imx-media.h | 10 + > 5 files changed, 896 insertions(+) > create mode 100644 drivers/staging/media/imx/imx-media-mem2mem.c > Philipp, Thanks for submitting this! I'm hoping this lets us use non-IMX capture devices along with the IMX media controller entities to so we can use hardware CSC,scaling,pixel-format-conversions and ultimately coda based encode. I've built this on top of linux-media and see that it registers as /dev/video8 but I'm not clear how to use it? I don't see it within the media controller graph. Regards, Tim
Re: i.MX6 IPU CSI analog video input on Ventana
On Wed, Oct 17, 2018 at 4:37 PM Steve Longerbeam wrote: > > > On 10/17/18 4:05 PM, Tim Harvey wrote: > > On Wed, Oct 17, 2018 at 2:33 PM Steve Longerbeam > > wrote: > >> Hi Tim, > >> > >> On 10/17/18 1:38 PM, Tim Harvey wrote: > >> > >> On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: > >> > >> I've just tested the PAL setup: in currect situation (v4.17 + Steve's > >> fix-csi-interlaced.2 + "media: adv7180: fix field type" + a small cheap > >> PAL camera) the following produces bottom-first interlaced frames: > >> > >> media-ctl -r -l '"adv7180 2-0020":0->"ipu2_csi1_mux":1[1], > >> "ipu2_csi1_mux":2->"ipu2_csi1":0[1], > >> "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' > >> > >> media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" > >> media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" > >> media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" > >> > >> "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] > >> "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] > >> "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] > >> "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] > >> "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > >> > >> I think it would be great if these changes make their way upstream. > >> The details could be refined then. > >> > >> Krzysztof / Steve / Philipp, > >> > >> I jumped back onto IMX6 video capture from the adv7180 the other day > >> trying to help out a customer that's using mainline and found things > >> are still not working right. Where is all of this at these days? > >> > >> If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' > >> v3 series (https://patchwork.kernel.org/cover/10626499/) I > >> rolling/split (un-synchronized) video using: > >> > >> # Setup links > >> media-ctl -r > >> media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' > >> media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' > >> media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' > >> media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' > >> media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' > >> # Configure pads > >> media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" > >> media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" > >> media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" > >> media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" > >> media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" > >> # stream JPEG/RTP/UDP > >> gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! > >> jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT > >> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device > >> '/dev/video3' does not support progressive interlacing > >> > >> I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x > >> HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph > >> is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png > >> > >> Are there other patches I need or different field formats above with > >> 4.19? Do any of the other kernels work without patchsets that you know > >> of between 4.16 and 4.19? > >> > >> > >> First, the v3 series is out of date. Please apply the latest v5 posting > >> of that series. See the imx.rst doc regarding field type negotiation, > >> all pads starting at ipu2_csi1:1 should be 'seq-bt' or 'seq-tb' until the > >> capture device, which should be set to 'interlaced' to enable IDMAC > >> interweave. The ADV7180 now correctly sets its field type to alternate, > >> which imx-media-csi.c translates to seq-tb or seq-bt at its output pad. > >> > >> See the SabreAuto examples in the doc. &g
Re: i.MX6 IPU CSI analog video input on Ventana
On Wed, Oct 17, 2018 at 2:33 PM Steve Longerbeam wrote: > > Hi Tim, > > On 10/17/18 1:38 PM, Tim Harvey wrote: > > On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: > > I've just tested the PAL setup: in currect situation (v4.17 + Steve's > fix-csi-interlaced.2 + "media: adv7180: fix field type" + a small cheap > PAL camera) the following produces bottom-first interlaced frames: > > media-ctl -r -l '"adv7180 2-0020":0->"ipu2_csi1_mux":1[1], > "ipu2_csi1_mux":2->"ipu2_csi1":0[1], > "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" > media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > I think it would be great if these changes make their way upstream. > The details could be refined then. > > Krzysztof / Steve / Philipp, > > I jumped back onto IMX6 video capture from the adv7180 the other day > trying to help out a customer that's using mainline and found things > are still not working right. Where is all of this at these days? > > If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' > v3 series (https://patchwork.kernel.org/cover/10626499/) I > rolling/split (un-synchronized) video using: > > # Setup links > media-ctl -r > media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' > media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' > media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' > media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' > media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' > # Configure pads > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" > # stream JPEG/RTP/UDP > gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! > jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device > '/dev/video3' does not support progressive interlacing > > I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x > HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph > is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png > > Are there other patches I need or different field formats above with > 4.19? Do any of the other kernels work without patchsets that you know > of between 4.16 and 4.19? > > > First, the v3 series is out of date. Please apply the latest v5 posting > of that series. See the imx.rst doc regarding field type negotiation, > all pads starting at ipu2_csi1:1 should be 'seq-bt' or 'seq-tb' until the > capture device, which should be set to 'interlaced' to enable IDMAC > interweave. The ADV7180 now correctly sets its field type to alternate, > which imx-media-csi.c translates to seq-tb or seq-bt at its output pad. > > See the SabreAuto examples in the doc. > > For the rolling/split image problem, try the attached somewhat hackish patch. > There used to be code in imx-media-csi.c that searched for the backend sensor > and queries via .g_skip_frames whether the sensor produces bad frames at first > stream-on. But there was push-back on that, so the attached is another > approach that doesn't require searching for a backend sensor. Steve, Thanks - I hadn't noticed the updated series. I've built it on top of linux-media/master and tested with: - Testing linux-media/master + your v5 now: # Use simple interweaving media-ctl -r # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1&quo
Re: i.MX6 IPU CSI analog video input on Ventana
On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: > > I've just tested the PAL setup: in currect situation (v4.17 + Steve's > fix-csi-interlaced.2 + "media: adv7180: fix field type" + a small cheap > PAL camera) the following produces bottom-first interlaced frames: > > media-ctl -r -l '"adv7180 2-0020":0->"ipu2_csi1_mux":1[1], > "ipu2_csi1_mux":2->"ipu2_csi1":0[1], > "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" > media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > I think it would be great if these changes make their way upstream. > The details could be refined then. Krzysztof / Steve / Philipp, I jumped back onto IMX6 video capture from the adv7180 the other day trying to help out a customer that's using mainline and found things are still not working right. Where is all of this at these days? If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' v3 series (https://patchwork.kernel.org/cover/10626499/) I rolling/split (un-synchronized) video using: # Setup links media-ctl -r media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" # stream JPEG/RTP/UDP gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video3' does not support progressive interlacing I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png Are there other patches I need or different field formats above with 4.19? Do any of the other kernels work without patchsets that you know of between 4.16 and 4.19? Steve, I haven't tried your 'media: imx: Switch to subdev notifiers' v7 series yet (https://patchwork.kernel.org/cover/10620967/) but can certainly do so if you need testing. I'm hoping those changes are all internal and won't affect the userspace pipeline configuration between kernel versions? I'm also interested in looking at Philipps' 'i.MX media mem2mem scaler' series (https://patchwork.kernel.org/cover/10603881/) and am wondering if anyone has some example pipelines showing that in use. I'm hoping that is what is needed to be able to use hardware scaling/CSC and coda based encoding on streams from v4l2 PCI capture devices. Lastly, is there any hope to use IMX6 hardware compositing to say stitch together multiple streams from a v4l2 PCI capture device into a single stream for coda based hw encoding? Regards, Tim
Re: i.MX6 IPU CSI analog video input on Ventana
On Mon, May 21, 2018 at 1:09 AM, Krzysztof Hałasa wrote: > Tested with NTSC camera, it's the same as with PAL. > The only case when IPU2_CSI1_SENS_CONF register is set to interlaced > mode (PRCTL=3, CCIR interlaced mode (BT.656)) is when all parts of the > pipeline are set to interlaced: > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > The image is stable and in sync, the "only" problem is that I get two > concatenated field images (in one V4L2 frame) instead of a normal > interlaced frame (all lines in order - 0, 1, 2, 3, 4 etc). > IOW I get V4L2_FIELD_ALTERNATE, V4L2_FIELD_SEQ_TB or V4L2_FIELD_SEQ_BT > (the data format, I don't mean the pixel format.field) while I need to > get V4L2_FIELD_INTERLACED, V4L2_FIELD_INTERLACED_TB or _BT. > > > If I set "ipu2_csi1":2 to field:none, the IPU2_CSI1_SENS_CONF is set to > progressive mode (PRCTL=2). It's the last element of the pipeline I can > configure, it's connected straight to "ipu2_csi1 capture" aka > /dev/videoX. I think CSI can't work with interlaced camera (and ADV7180) > when set to progressive, can it? > > > I wonder... perhaps to get an interlaced frame I need to route the data > through VDIC (ipu2_vdic, the deinterlacer)? Krzysztof, Right, your doing a raw capture where you get both fields in one buffer and I'm not clear what to do with that. Here's what I've used on a GW54xx with IMX6Q and an adv7180 for NTSC. using VDIC to deinterlace: # adv7180 -> vdic -> ic_prpvf -> /dev/video3 # VDIC will de-interlace using motion compensation media-ctl -r # reset all links # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_vdic":0[1]' media-ctl -l '"ipu2_vdic":2 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_vdic':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:none]" media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" # streaming can now begin on /dev/video3 v4l2-ctl -d3 --set-fmt-video=width=720,height=480,pixelformat=UYVY v4l2-ctl -d3 --set-ctrl=deinterlacing_mode=3 # set max motion compensation (default) # this is the default so could be skipped; also its the only value allowed when capturing direct from CSI v4l2-ctl -d3 --stream-mmap --stream-to=/x.raw --stream-count=1 # capture 1 frame convert -size 720x480 -depth 16 uyvy:/x.raw /var/www/html/frame.png # and convert # or stream jpeg's via gst gst-launch-1.0 v4l2src device=/dev/video3 ! "video/x-raw,format=UYVY" ! jpegenc ! queue ! avimux name=mux ! udpsink host=172.24.20.19 port=5000 or de-interlace via IDMAC: # PRPVF will do simple IDMAC line interweaving for de-interlacing, since VDIC is not involved in the pipeline, but it will only enable this in the IDMAC if it sees interlaced input at prpvf media-ctl -r # reset all links # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" # streaming can now begin on /dev/video3 v4l2-ctl -d3 --set-fmt-video=width=720,height=480,pixelformat=UYVY v4l2-ctl -d3 --stream-mmap --stream-to=/x.raw --stream-count=1 # capture gst-launch-1.0 v4l2src device=/dev/video3 ! "video/x-raw,format=UYVY" ! jpegenc ! queue ! avimux name=mux ! udpsink host=172.24.20.19 port=5000 or the following for non deinterlaced: # adv7180 -> ic_prp -> ic_prpenc -> /dev/video2 media-ctl -r # reset all links # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":1 -> "ipu2_ic_prpenc":0[1]' media-ctl -l '"ipu2_ic_prpenc":1 -> "ipu2_ic_prpenc capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_c
Re: i.MX6 IPU CSI analog video input on Ventana
On Fri, May 18, 2018 at 10:28 AM, Krzysztof Hałasa wrote: > Steve Longerbeam writes: > >> Yes, the CSI on i.MX6 does not deal well with unstable bt.656 sync codes, >> which results in vertical sync issues (scrolling or split images). The >> ADV7180 >> will often shift the sync codes around in various situations (initial >> power on, >> see below, also when there is an interruption of the input analog CVBS >> signal). > > I'm not convinced it's the sync code issue. I've compared the key > registers (both 4.2 + your old driver vs 4.16) and this is what I got: > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:none] > > There is H sync but no V sync. The encoding is wrong (I'm using NV12 but > what I get from /dev/video* isn't NV12). > > IPU2_CSI1 registers are: > 048 C 10 14 18 1C > 2a38000: 04000A20 023F02CF 023F02CF 0 0 00040030 00FF > vs the old driver: > 04000A30 027002CF 023F02CF 0 0 01040596 000D07DF 00FF > > 0: CSI1 Sensor Configuration (IPUx_CSI1_SENS_CONF) > The new driver uses progressive mode while the old one - interlaced > mode. > > 4: CSI1 Sense Frame Size Register (IPUx_CSI1_SENS_FRM_SIZE) > The new driver uses 575 lines in place of 624 (this probably needs to be > checked with the ADV7180 docs, though the old version works fine). > > 14, 18: CSI1 CCIR Code Register 1 and 2 (IPUx_CSI1_CCIR_CODE_[12]) > The new driver doesn't use "Error detection and correction" and it seems > the codes are set for progressive mode. I think this can't work. > > > With: > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:none] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:none] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:none] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:none] > > Still, V sync but no H sync. The Y/colors are good, except that > there are two consecutive images on the screen. > 2a38000: 04000A20 023F02CF 023F02CF 0 0 00040030 00FF > CSI set to progressive again. Setting the registers manually (SENS_CONF > and SAV/EAV codes) makes the image stabilize, though there are still two > images (split in the middle). Apparently something is simply appending > the two field images, instead of merging them properly. > > > With: > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:interlaced] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > 2a38000: 04000A30 027002CF 023F02CF 0 0 01040596 000D07DF 00FF > the CSI is set for interlaced mode, and there are two stable images > (both fields concatenated). > > > The first case again (all except ipu2_csi1 set to interlaced). I've > manually set the CSI registers and now the image is synchronized and > stable (one complete frame this time). The problem is it's not NV12 > (nor YUV420), the colors are all green and the Y lines comes in pairs - > valid then invalid (probably color) and so on. > > > Could it be a DTS problem? I'm using imx6q-gw53xx.dtb file, > the 8-bit ADV7180 (40 pin version) is connected to the IPU2 CSI1 DATA, > EIM_EB3 = HSYNC, EIM_A16 = PIXCLK and EIM_D29 = VSYNC. HSYNC and VSYNC > aren't currently used, though. > > I Guess I have to compare all IPU registers. Krzysztof, What version of kernel are you using and what specific board model do you have (full board model and/or serial number so I know if you've got an IMX6DL or an IMX6Q) and have you modified the device-tree? I tested the adv7180 a couple of months ago but I don't know if I hit your specific combination. I was using NTSC but if your not getting VSYNC then yes I would like to make sure the pinmux is correct for your situation. Thanks, Tim
Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component
On Mon, Apr 23, 2018 at 9:52 AM, Mark Brown wrote: > On Mon, Apr 23, 2018 at 09:44:17AM -0700, Tim Harvey wrote: > >> Could you add some detail to the commit explaining why we need to >> replace codec to component? I don't really know what that means. >> Please refer to a commit if the ASoC API is changing in some way we >> need to catch up with. > > This is a big transition in the ASoC API which is nearing completion - > this driver is one of the last users of the CODEC struct, we've (well, > mainly Morimoto-san) been migrating things away from it to the more > general purpose component. There's no one commit to point at really as > the two have coexisted for a while and we won't be able to finally > remove the CODEC struct until all the drivers have transitioned away. Mark, Ok - thanks for the explanation! Kuninori, Sorry this took so long to get to. Tested on a GW5404 Tested-by: Tim Harvey Acked-by: Tim Harvey Regards, Tim
Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component
On Sun, Apr 22, 2018 at 7:10 PM, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Now we can replace Codec to Component. Let's do it. > > Note: > xxx_codec_xxx() -> xxx_component_xxx() > .idle_bias_off = 0 -> .idle_bias_on = 1 > .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 > - -> .endianness = 1 > - -> .non_legacy_dai_naming = 1 > > Signed-off-by: Kuninori Morimoto > --- > Tim, Mauro > > 2 weeks passed. I re-send. > This replace patch is needed for ALSA SoC, otherwise it can't probe anymore. > > v2 -> v3 > > - fixup driver name (= tda1997) > Kuninori, Could you add some detail to the commit explaining why we need to replace codec to component? I don't really know what that means. Please refer to a commit if the ASoC API is changing in some way we need to catch up with. Regards, Tim
Re: [PATCH v13 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
On Thu, Feb 15, 2018 at 10:36 AM, Hans Verkuil wrote: > On 15/02/18 18:55, Tim Harvey wrote: >> The GW54xx has a front-panel microHDMI connector routed to a TDA19971 >> which is connected the the IPU CSI when using IMX6Q. > > I assume that this and the next patch go through another subsystem for arm > and/or imx? > > Regards, > > Hans > Hans, Yes - Shawn should pick up the two dts patches: 0007-ARM-dts-imx-Add-TDA19971-HDMI-Receiver-to-GW54xx.patch 0008-ARM-dts-imx-Add-TDA19971-HDMI-Receiver-to-GW551x.patch Shawn you've seen these before but haven't ack'd them - are they good to merge to your imx tree? Regards, Tim
[PATCH v13 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
[PATCH v13 0/8] TDA1997x HDMI video reciver
ROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
test Active VIDIOC_SUBDEV_G/S_FMT: OK
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 4 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK (Not Supported)
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
test VIDIOC_EXPBUF: OK (Not Supported)
Total: 47, Succeeded: 47, Failed: 0, Warnings: 0
$ v4l2-compliance -M0
v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8
Compliance test for device /dev/media0:
Media Driver Info:
Driver name : imx-media
Model: imx-media
Serial :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version : 4.15.0
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
fail: v4l2-test-media.cpp(96): function ==
MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN
fail: v4l2-test-media.cpp(161): checkFunction(ent.function,
true)
test MEDIA_IOC_G_TOPOLOGY: FAIL
fail: v4l2-test-media.cpp(290): num_data_links != num_links
test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
test MEDIA_IOC_SETUP_LINK: OK
Total: 7, Succeeded: 5, Failed: 2, Warnings: 0
above failures are due to imx/adv7180 not setting a valid entity function
Hans Verkuil (1):
v4l2-dv-timings: add v4l2_hdmi_colorimetry()
Hans Verkuil (1):
v4l2-dv-timings: add v4l2_hdmi_colorimetry()
Tim Harvey (7):
media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
media: add digital video decoder video interface entity functions
MAINTAINERS: add entry for NXP TDA1997x driver
media: dt-bindings: Add bindings for TDA1997X
media: i2c: Add TDA1997x HDMI receiver driver
ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 ++
Documentation/media/uapi/mediactl/media-types.rst | 11 +
MAINTAINERS|8 +
arch/arm/boot/dts/imx6q-gw54xx.dts | 105 +
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 +
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tda1997x.c | 2820
drivers/media/i2c/tda1997x_regs.h | 641 +
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 +
drivers/media/v4l2-core/v4l2-ioctl.c |2 +-
include/dt-bindings/media/tda1997x.h | 74 +
include/media/i2c/tda1997x.h | 42 +
include/media/v4l2-dv-timings.h| 21 +
include/uapi/linux/media.h |5 +
16 files changed, 4222 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 drivers/media/i2c/tda1997x.c
create mode 100644 drivers/media/i2c/tda1997x_regs.h
create mode 100644 include/dt-bindings/media/tda1997x.h
create mode 100644 include/media/i2c/tda1997x.h
--
2.7.4
[PATCH v13 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTEND
[PATCH v13 3/8] media: add digital video decoder entity functions
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v13 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* an
[PATCH v13 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-media@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-media@vger.kernel.org -- 2.7.4
[PATCH v13 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+
[PATCH v13 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v13: - fix coccinelle warnings v12: - fix coccinelle warnings v11: - return -ERANGE from tda1997x_detect_std (Hans) - clean up tda1997x_g_input_status (Hans) - show detected timings on resolution change if debug enabled - fix unitialized ret var in tda1997x_query_dv_timings - update log status to show detected timings v10: - removed unnecessary check for !timings in get/set/query dv timings (Hans) - dropped pointless s_stream handler (Hans) - remove need for detected_timings and always use set timings (Hans) v9: - remove redundant pad bounds check already in v4l2-subdev.c - assign entity function (Hans) - properly assign/check/free ctrl_handler (Hans) - fixed typo 'Rull Range' -> 'Full Range' - update csc after quant range change v8: - fix available formats for tda19971 bt656 bus width >12 - support full range of input modes based on timings_cap - fix set_format (compliance) - fixed get/set edid (compliance) - add init_cfg to setup default pad config (compliance) - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance) - fix alignment of if statement and whitespace in comment (Hans) - move regs to tda1997x_regs.h to clean up (Hans) - add define and sanity check for num of mbus_codes (Hans) v7: - fix interlaced mode - support no AVI infoframe (ie DVI) (Hans) - add support for multiple output formats (Hans) v6: - fix return on regulator enablei in tda1997x_set_power() - replace copyright with SPDX tag - fix colorspace handling v5: - uppercase string constants - use v4l2_hdmi_rx_coloriemtry to fill format - fix V4L2_CID_DV_RX_RGB_RANGE - fix interlaced mode format v4: - move include/dt-bindings/media/tda1997x.h to bindings patch - fix typos - fix default quant range for VGA - fix quant range handling and conv matrix - add additional standards and capabilities to timings_cap v3: - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros - fixed missing break - use only hdmi_infoframe_log for infoframe logging - simplify tda1997x_s_stream error handling - add delayed work proc to handle hotplug enable/disable - fix set_edid (disable HPD before writing, enable after) - remove enabling edid by default - initialize timings - take quant range into account in colorspace conversion - remove vendor/product tracking (we provide this in log_status via infoframes) - add v4l_controls - add more detail to log_status - calculate vhref generator timings - timing detection fixes (rounding errors, hswidth errors) - rename configure_input/configure_conv functions v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - change audio bindings drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile|1 + drivers/media/i2c/tda1997x.c | 2820 + drivers/media/i2c/tda1997x_regs.h | 641 + include/media/i2c/tda1997x.h | 42 + 5 files changed, 3513 insertions(+) create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/media/i2c/tda1997x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cb5d7ff..3522641 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -56,6 +56,15 @@ config VIDEO_TDA9840 To compile this driver as a module, choose M here: the module will be called tda9840. +config VIDEO_TDA1997X + tristate "NXP TDA1997x HDMI receiver" + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + ---help--- + V4L2 subdevice driver for the NXP TDA1997x HDMI receivers. + + To compile this driver as a module, choose M here: the + module will be called tda1997x. + config VIDEO_TEA6415C tristate "Philips TEA6415C audio processor" depends on I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 548a9ef..adfcae9 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o +obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c new file mode 100644 index 000..b25c50a --- /dev/null +++ b/drivers/media/i2c/tda1997x.c @@ -0,0 +1,2820 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Gateworks Corporation + */ +#include +#include +#include +#include +#include +#include +#
[PATCH v13 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0
Re: [PATCH v12 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Thu, Feb 15, 2018 at 9:16 AM, Hans Verkuil wrote:
> On 15/02/18 17:39, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil
>> Signed-off-by: Tim Harvey
>> ---
>> v12:
>> - fix coccinelle warnings
>
> Did you post the right version? I still see the owner being set and the
> other kbuild warning ('note: in expansion of macro 'v4l_dbg'') is also
> still there.
>
> Note that the last one also shows these errors:
>
> drivers/media/i2c/tda1997x.c:387:5-8: WARNING: Unsigned expression compared
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:391:5-8: WARNING: Unsigned expression compared
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:404:5-8: WARNING: Unsigned expression compared
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:408:5-8: WARNING: Unsigned expression compared
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:412:5-8: WARNING: Unsigned expression compared
> with zero: val < 0
> drivers/media/i2c/tda1997x.c:427:6-9: WARNING: Unsigned expression compared
> with zero: val < 0
>
> This is indeed wrong.
>
> Regards,
>
> Hans
oh geez... no I goofed that up. I'll send a v13 now.
Tim
[PATCH v12 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTEND
[PATCH v12 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
[PATCH v12 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+
[PATCH v12 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0
[PATCH v12 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v12: - fix coccinelle warnings v11: - return -ERANGE from tda1997x_detect_std (Hans) - clean up tda1997x_g_input_status (Hans) - show detected timings on resolution change if debug enabled - fix unitialized ret var in tda1997x_query_dv_timings - update log status to show detected timings v10: - removed unnecessary check for !timings in get/set/query dv timings (Hans) - dropped pointless s_stream handler (Hans) - remove need for detected_timings and always use set timings (Hans) v9: - remove redundant pad bounds check already in v4l2-subdev.c - assign entity function (Hans) - properly assign/check/free ctrl_handler (Hans) - fixed typo 'Rull Range' -> 'Full Range' - update csc after quant range change v8: - fix available formats for tda19971 bt656 bus width >12 - support full range of input modes based on timings_cap - fix set_format (compliance) - fixed get/set edid (compliance) - add init_cfg to setup default pad config (compliance) - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance) - fix alignment of if statement and whitespace in comment (Hans) - move regs to tda1997x_regs.h to clean up (Hans) - add define and sanity check for num of mbus_codes (Hans) v7: - fix interlaced mode - support no AVI infoframe (ie DVI) (Hans) - add support for multiple output formats (Hans) v6: - fix return on regulator enablei in tda1997x_set_power() - replace copyright with SPDX tag - fix colorspace handling v5: - uppercase string constants - use v4l2_hdmi_rx_coloriemtry to fill format - fix V4L2_CID_DV_RX_RGB_RANGE - fix interlaced mode format v4: - move include/dt-bindings/media/tda1997x.h to bindings patch - fix typos - fix default quant range for VGA - fix quant range handling and conv matrix - add additional standards and capabilities to timings_cap v3: - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros - fixed missing break - use only hdmi_infoframe_log for infoframe logging - simplify tda1997x_s_stream error handling - add delayed work proc to handle hotplug enable/disable - fix set_edid (disable HPD before writing, enable after) - remove enabling edid by default - initialize timings - take quant range into account in colorspace conversion - remove vendor/product tracking (we provide this in log_status via infoframes) - add v4l_controls - add more detail to log_status - calculate vhref generator timings - timing detection fixes (rounding errors, hswidth errors) - rename configure_input/configure_conv functions v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - change audio bindings drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile|1 + drivers/media/i2c/tda1997x.c | 2822 + drivers/media/i2c/tda1997x_regs.h | 641 + include/media/i2c/tda1997x.h | 42 + 5 files changed, 3515 insertions(+) create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/media/i2c/tda1997x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cb5d7ff..3522641 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -56,6 +56,15 @@ config VIDEO_TDA9840 To compile this driver as a module, choose M here: the module will be called tda9840. +config VIDEO_TDA1997X + tristate "NXP TDA1997x HDMI receiver" + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + ---help--- + V4L2 subdevice driver for the NXP TDA1997x HDMI receivers. + + To compile this driver as a module, choose M here: the + module will be called tda1997x. + config VIDEO_TEA6415C tristate "Philips TEA6415C audio processor" depends on I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 548a9ef..adfcae9 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o +obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c new file mode 100644 index 000..ce6b694 --- /dev/null +++ b/drivers/media/i2c/tda1997x.c @@ -0,0 +1,2822 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Gateworks Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#in
[PATCH v12 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-media@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-media@vger.kernel.org -- 2.7.4
[PATCH v12 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* an
[PATCH v12 3/8] media: add digital video decoder entity functions
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v12 0/8] TDA1997x HDMI video reciver
ctive VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK test Active VIDIOC_SUBDEV_G/S_FMT: OK test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 4 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK (Not Supported) test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) test VIDIOC_EXPBUF: OK (Not Supported) Total: 47, Succeeded: 47, Failed: 0, Warnings: 0 $ v4l2-compliance -M0 v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 Compliance test for device /dev/media0: Media Driver Info: Driver name : imx-media Model: imx-media Serial : Bus info : Media version: 4.15.0 Hardware revision: 0x0000 (0) Driver version : 4.15.0 Required ioctls: test MEDIA_IOC_DEVICE_INFO: OK Allow for multiple opens: test second /dev/media0 open: OK test MEDIA_IOC_DEVICE_INFO: OK test for unlimited opens: OK Media Controller ioctls: fail: v4l2-test-media.cpp(96): function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN fail: v4l2-test-media.cpp(161): checkFunction(ent.function, true) test MEDIA_IOC_G_TOPOLOGY: FAIL fail: v4l2-test-media.cpp(290): num_data_links != num_links test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL test MEDIA_IOC_SETUP_LINK: OK Total: 7, Succeeded: 5, Failed: 2, Warnings: 0 above failures are due to imx/adv7180 not setting a valid entity function Hans Verkuil (1): v4l2-dv-timings: add v4l2_hdmi_colorimetry() Tim Harvey (7): media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP media: add digital video decoder video interface entity functions MAINTAINERS: add entry for NXP TDA1997x driver media: dt-bindings: Add bindings for TDA1997X media: i2c: Add TDA1997x HDMI receiver driver ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x .../devicetree/bindings/media/i2c/tda1997x.txt | 179 ++ Documentation/media/uapi/mediactl/media-types.rst | 11 + MAINTAINERS|8 + arch/arm/boot/dts/imx6q-gw54xx.dts | 105 + arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +- arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 + drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tda1997x.c | 2822 drivers/media/i2c/tda1997x_regs.h | 641 + drivers/media/v4l2-core/v4l2-dv-timings.c | 141 + drivers/media/v4l2-core/v4l2-ioctl.c |2 +- include/dt-bindings/media/tda1997x.h | 74 + include/media/i2c/tda1997x.h | 42 + include/media/v4l2-dv-timings.h| 21 + include/uapi/linux/media.h |5 + 16 files changed, 4224 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/dt-bindings/media/tda1997x.h create mode 100644 include/media/i2c/tda1997x.h -- 2.7.4
[PATCH v11 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTEND
[PATCH v11 0/8] TDA1997x HDMI video reciver
AME_SIZE/FRAME_INTERVAL: OK test Active VIDIOC_SUBDEV_G/S_FMT: OK test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 4 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK (Not Supported) test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) test VIDIOC_EXPBUF: OK (Not Supported) Total: 47, Succeeded: 47, Failed: 0, Warnings: 0 $ v4l2-compliance -M0 v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 Compliance test for device /dev/media0: Media Driver Info: Driver name : imx-media Model: imx-media Serial : Bus info : Media version: 4.15.0 Hardware revision: 0x0000 (0) Driver version : 4.15.0 Required ioctls: test MEDIA_IOC_DEVICE_INFO: OK Allow for multiple opens: test second /dev/media0 open: OK test MEDIA_IOC_DEVICE_INFO: OK test for unlimited opens: OK Media Controller ioctls: fail: v4l2-test-media.cpp(96): function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN fail: v4l2-test-media.cpp(161): checkFunction(ent.function, true) test MEDIA_IOC_G_TOPOLOGY: FAIL fail: v4l2-test-media.cpp(290): num_data_links != num_links test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL test MEDIA_IOC_SETUP_LINK: OK Total: 7, Succeeded: 5, Failed: 2, Warnings: 0 above failures are due to imx/adv7180 not setting a valid entity function Hans Verkuil (1): v4l2-dv-timings: add v4l2_hdmi_colorimetry() Tim Harvey (7): media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP media: add digital video decoder video interface entity functions MAINTAINERS: add entry for NXP TDA1997x driver media: dt-bindings: Add bindings for TDA1997X media: i2c: Add TDA1997x HDMI receiver driver ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x .../devicetree/bindings/media/i2c/tda1997x.txt | 179 ++ Documentation/media/uapi/mediactl/media-types.rst | 11 + MAINTAINERS|8 + arch/arm/boot/dts/imx6q-gw54xx.dts | 105 + arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +- arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 + drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tda1997x.c | 2822 drivers/media/i2c/tda1997x_regs.h | 641 + drivers/media/v4l2-core/v4l2-dv-timings.c | 141 + drivers/media/v4l2-core/v4l2-ioctl.c |2 +- include/dt-bindings/media/tda1997x.h | 74 + include/media/i2c/tda1997x.h | 42 + include/media/v4l2-dv-timings.h| 21 + include/uapi/linux/media.h |5 + 16 files changed, 4224 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/dt-bindings/media/tda1997x.h create mode 100644 include/media/i2c/tda1997x.h -- 2.7.4
[PATCH v11 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
[PATCH v11 3/8] media: add digital video decoder video interface entity functions
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v11 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+
[PATCH v11 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v11: - return -ERANGE from tda1997x_detect_std (Hans) - clean up tda1997x_g_input_status (Hans) - show detected timings on resolution change if debug enabled - fix unitialized ret var in tda1997x_query_dv_timings - update log status to show detected timings v10: - removed unnecessary check for !timings in get/set/query dv timings (Hans) - dropped pointless s_stream handler (Hans) - remove need for detected_timings and always use set timings (Hans) v9: - remove redundant pad bounds check already in v4l2-subdev.c - assign entity function (Hans) - properly assign/check/free ctrl_handler (Hans) - fixed typo 'Rull Range' -> 'Full Range' - update csc after quant range change v8: - fix available formats for tda19971 bt656 bus width >12 - support full range of input modes based on timings_cap - fix set_format (compliance) - fixed get/set edid (compliance) - add init_cfg to setup default pad config (compliance) - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance) - fix alignment of if statement and whitespace in comment (Hans) - move regs to tda1997x_regs.h to clean up (Hans) - add define and sanity check for num of mbus_codes (Hans) v7: - fix interlaced mode - support no AVI infoframe (ie DVI) (Hans) - add support for multiple output formats (Hans) v6: - fix return on regulator enablei in tda1997x_set_power() - replace copyright with SPDX tag - fix colorspace handling v5: - uppercase string constants - use v4l2_hdmi_rx_coloriemtry to fill format - fix V4L2_CID_DV_RX_RGB_RANGE - fix interlaced mode format v4: - move include/dt-bindings/media/tda1997x.h to bindings patch - fix typos - fix default quant range for VGA - fix quant range handling and conv matrix - add additional standards and capabilities to timings_cap v3: - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros - fixed missing break - use only hdmi_infoframe_log for infoframe logging - simplify tda1997x_s_stream error handling - add delayed work proc to handle hotplug enable/disable - fix set_edid (disable HPD before writing, enable after) - remove enabling edid by default - initialize timings - take quant range into account in colorspace conversion - remove vendor/product tracking (we provide this in log_status via infoframes) - add v4l_controls - add more detail to log_status - calculate vhref generator timings - timing detection fixes (rounding errors, hswidth errors) - rename configure_input/configure_conv functions v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - change audio bindings drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile|1 + drivers/media/i2c/tda1997x.c | 2822 + drivers/media/i2c/tda1997x_regs.h | 641 + include/media/i2c/tda1997x.h | 42 + 5 files changed, 3515 insertions(+) create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/media/i2c/tda1997x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cb5d7ff..3522641 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -56,6 +56,15 @@ config VIDEO_TDA9840 To compile this driver as a module, choose M here: the module will be called tda9840. +config VIDEO_TDA1997X + tristate "NXP TDA1997x HDMI receiver" + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + ---help--- + V4L2 subdevice driver for the NXP TDA1997x HDMI receivers. + + To compile this driver as a module, choose M here: the + module will be called tda1997x. + config VIDEO_TEA6415C tristate "Philips TEA6415C audio processor" depends on I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 548a9ef..adfcae9 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o +obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c new file mode 100644 index 000..ce6b694 --- /dev/null +++ b/drivers/media/i2c/tda1997x.c @@ -0,0 +1,2822 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Gateworks Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#in
[PATCH v11 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0
[PATCH v11 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* an
[PATCH v11 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-media@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-media@vger.kernel.org -- 2.7.4
Re: [PATCH v10 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Wed, Feb 14, 2018 at 6:08 AM, Hans Verkuil wrote:
> Hi Tim,
>
> On 12/02/18 23:27, Tim Harvey wrote:
>> On Fri, Feb 9, 2018 at 12:08 AM, Hans Verkuil wrote:
>>> Hi Tim,
>>>
>>> We're almost there. Two more comments:
>>>
>>> On 02/09/2018 07:32 AM, Tim Harvey wrote:
>>>> +static int
>>>> +tda1997x_detect_std(struct tda1997x_state *state,
>>>> + struct v4l2_dv_timings *timings)
>>>> +{
>>>> + struct v4l2_subdev *sd = &state->sd;
>>>> + u32 vper;
>>>> + u16 hper;
>>>> + u16 hsper;
>>>> + int i;
>>>> +
>>>> + /*
>>>> + * Read the FMT registers
>>>> + * REG_V_PER: Period of a frame (or two fields) in MCLK(27MHz)
>>>> cycles
>>>> + * REG_H_PER: Period of a line in MCLK(27MHz) cycles
>>>> + * REG_HS_WIDTH: Period of horiz sync pulse in MCLK(27MHz) cycles
>>>> + */
>>>> + vper = io_read24(sd, REG_V_PER) & MASK_VPER;
>>>> + hper = io_read16(sd, REG_H_PER) & MASK_HPER;
>>>> + hsper = io_read16(sd, REG_HS_WIDTH) & MASK_HSWIDTH;
>>>> + if (!vper || !hper || !hsper)
>>>> + return -ENOLINK;
>>>
>>> See my comment for g_input_status below. This condition looks more like a
>>> ENOLCK.
>>>
>>> Or perhaps it should be:
>>>
>>> if (!vper && !hper && !hsper)
>>> return -ENOLINK;
>>> if (!vper || !hper || !hsper)
>>> return -ENOLCK;
>>>
>>> I would recommend that you test a bit with no signal and a bad signal
>>> (perhaps
>>> one that uses a pixelclock that is too high for this device?).
>>
>> I can't figure out how to produce a signal that can't be locked onto
>> with what I have available.
>
> Are you using a signal generator or just a laptop or something similar as the
> source?
>
> Without a good signal generator it is tricky to test this. A very long HDMI
> cable would likely do it. But for 1080p60 you probably need 20 meters or
> more.
>
I'm using a Marshall V-SG4K-HDI
(http://www.lcdracks.com/racks/DLW/V-SG4K-HDI-signal-generator.php).
It does support 'user defined timings' (see
http://www.lcdracks.com/racks/pdf-pages/instruction_sheets/V-SG4K-HDI_Manual-web.pdf
Timings Details Menu page) and it looks like the max pixel-clock is
300MHz so perhaps I can create a timing that can't be locked onto that
way.
The TDA19971 datasheet
(http://tharvey/src/nxp/tda1997x/TDA19971-datasheet-rev3.pdf) says it
supports:
- All HDTV formats up to 1920x1080p at 50/60 Hz with support for
reduced blanking
- 3D formats including all primary formats up to 1920x1080p at 30 Hz
Frame Packing and 1920x1080p at 60 Hz Side-by-Side and Top-and-Bottom
- PC formats up to UXGA (1600x1200p at 60 Hz) and WUXGA (1920x1200p at 60 Hz)
>>
>>>
>>>> +static int
>>>> +tda1997x_g_input_status(struct v4l2_subdev *sd, u32 *status)
>>>> +{
>>>> + struct tda1997x_state *state = to_state(sd);
>>>> + u32 vper;
>>>> + u16 hper;
>>>> + u16 hsper;
>>>> +
>>>> + mutex_lock(&state->lock);
>>>> + v4l2_dbg(1, debug, sd, "inputs:%d/%d\n",
>>>> + state->input_detect[0], state->input_detect[1]);
>>>> + if (state->input_detect[0] || state->input_detect[1])
>>>
>>> I'm confused. This device has two HDMI inputs?
>>>
>>> Does 'detecting input' equate to 'I see a signal and I am locked'?
>>> I gather from the irq function that sets these values that it is closer
>>> to 'I see a signal' and that 'I am locked' is something you would test
>>> by looking at the vper/hper/hsper.
>>
>> The TDA19972 and/or TDA19973 has an A and B input but only a single
>> output. I'm not entirely clear if/how to select between the two and I
>> don't have proper documentation for the three chips.
>>
>> The TDA19971 which I have on my board only has 1 input which is
>> reported as the 'A' input. I can likely nuke the stuff looking at the
>> B input and/or put some qualifiers around it but I didn't want to
>> remove code that was derived from some vendor code that might help
>> support the other chips in the future. So I would rather like to leave
>> the 'if A or B&#x
Re: [PATCH v10 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Fri, Feb 9, 2018 at 12:08 AM, Hans Verkuil wrote:
> Hi Tim,
>
> We're almost there. Two more comments:
>
> On 02/09/2018 07:32 AM, Tim Harvey wrote:
>> +static int
>> +tda1997x_detect_std(struct tda1997x_state *state,
>> + struct v4l2_dv_timings *timings)
>> +{
>> + struct v4l2_subdev *sd = &state->sd;
>> + u32 vper;
>> + u16 hper;
>> + u16 hsper;
>> + int i;
>> +
>> + /*
>> + * Read the FMT registers
>> + * REG_V_PER: Period of a frame (or two fields) in MCLK(27MHz) cycles
>> + * REG_H_PER: Period of a line in MCLK(27MHz) cycles
>> + * REG_HS_WIDTH: Period of horiz sync pulse in MCLK(27MHz) cycles
>> + */
>> + vper = io_read24(sd, REG_V_PER) & MASK_VPER;
>> + hper = io_read16(sd, REG_H_PER) & MASK_HPER;
>> + hsper = io_read16(sd, REG_HS_WIDTH) & MASK_HSWIDTH;
>> + if (!vper || !hper || !hsper)
>> + return -ENOLINK;
>
> See my comment for g_input_status below. This condition looks more like a
> ENOLCK.
>
> Or perhaps it should be:
>
> if (!vper && !hper && !hsper)
> return -ENOLINK;
> if (!vper || !hper || !hsper)
> return -ENOLCK;
>
> I would recommend that you test a bit with no signal and a bad signal (perhaps
> one that uses a pixelclock that is too high for this device?).
I can't figure out how to produce a signal that can't be locked onto
with what I have available.
>
>> + v4l2_dbg(1, debug, sd, "Signal Timings: %u/%u/%u\n", vper, hper,
>> hsper);
>> +
>> + for (i = 0; v4l2_dv_timings_presets[i].bt.width; i++) {
>> + const struct v4l2_bt_timings *bt;
>> + u32 lines, width, _hper, _hsper;
>> + u32 vmin, vmax, hmin, hmax, hsmin, hsmax;
>> + bool vmatch, hmatch, hsmatch;
>> +
>> + bt = &v4l2_dv_timings_presets[i].bt;
>> + width = V4L2_DV_BT_FRAME_WIDTH(bt);
>> + lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>> + _hper = (u32)bt->pixelclock / width;
>> + if (bt->interlaced)
>> + lines /= 2;
>> + /* vper +/- 0.7% */
>> + vmin = ((2700 / 1000) * 993) / _hper * lines;
>> + vmax = ((2700 / 1000) * 1007) / _hper * lines;
>> + /* hper +/- 1.0% */
>> + hmin = ((2700 / 100) * 99) / _hper;
>> + hmax = ((2700 / 100) * 101) / _hper;
>> + /* hsper +/- 2 (take care to avoid 32bit overflow) */
>> + _hsper = 27000 * bt->hsync / ((u32)bt->pixelclock/1000);
>> + hsmin = _hsper - 2;
>> + hsmax = _hsper + 2;
>> +
>> + /* vmatch matches the framerate */
>> + vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0;
>> + /* hmatch matches the width */
>> + hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0;
>> + /* hsmatch matches the hswidth */
>> + hsmatch = ((hsper <= hsmax) && (hsper >= hsmin)) ? 1 : 0;
>> + if (hmatch && vmatch && hsmatch) {
>> + *timings = v4l2_dv_timings_presets[i];
>> + v4l2_print_dv_timings(sd->name, "Detected format: ",
>> + timings, false);
>> + return 0;
>> + }
>> + }
>> +
>> + v4l_err(state->client, "no resolution match for timings: %d/%d/%d\n",
>> + vper, hper, hsper);
>> + return -EINVAL;
>> +}
>
> -EINVAL isn't the correct error code here. I would go for -ERANGE. It's not
> perfect, but close enough.
>
> -EINVAL indicates that the user filled in wrong values, but that's not the
> case here.
done
>
>> +static int
>> +tda1997x_g_input_status(struct v4l2_subdev *sd, u32 *status)
>> +{
>> + struct tda1997x_state *state = to_state(sd);
>> + u32 vper;
>> + u16 hper;
>> + u16 hsper;
>> +
>> + mutex_lock(&state->lock);
>> + v4l2_dbg(1, debug, sd, "inputs:%d/%d\n",
>> + state->input_detect[0], state->input_detect[1]);
>> + if (state->input_detect[0] || state->input_detect[1])
>
> I'm confused. This device has two HDMI inputs?
>
> Does 'detecting input' equate to
Re: [PATCH v9 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Fri, Feb 9, 2018 at 12:02 AM, Hans Verkuil wrote: > On 02/09/2018 09:00 AM, Tim Harvey wrote: >> On Thu, Feb 8, 2018 at 11:41 PM, Hans Verkuil wrote: >>> On 02/09/2018 07:01 AM, Tim Harvey wrote: >>>> >>>> I don't see v4l2-subdev.c (or anything) ever calling g_input_status. >>>> How do I test this? >>> >>> Huh, that's a very good question! It is meant to be called by bridge >>> drivers implementing VIDIOC_ENUMINPUT. But that doesn't apply to the imx >>> driver since it is expecting userspace to talk directly to the subdev. >>> >>> Now for the DV_TIMINGS API this doesn't matter all that much since >>> QUERY_DV_TIMINGS can do the same job through the returned error code, but >>> for analog TV there is no such option (QUERYSTD doesn't support such >>> detailed feedback). >>> >>> I see that you have an adv7180 in your system. Can you run >>> 'v4l2-compliance -uX' for the adv7180 subdev and post the output here? >>> >> >> >> # v4l2-compliance -u0 >> v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 >> >> Compliance test for device /d[ 2526.153591] adv7180 2-0020: >> = S >> TART STATUS = >> ev/v4l-subdev0: >> >> Media Driver I[ 2526.162531] adv7180 2-0020: == END STATUS >> === >> === >> nfo: >> Driver name : imx-media >> Model: imx-media >> Serial : >> Bus info : >> Media version: 4.15.0 >> Hardware revision: 0x (0) >> Driver version : 4.15.0 >> Interface Info: >> ID : 0x038d >> Type : V4L Sub-Device >> Entity Info: >> ID : 0x0001 (1) >> Name : adv7180 2-0020 >> Function : FAIL: Unknown V4L2 Sub-Device >> Pad 0x0102 : Source >> Link 0x027f: to remote pad 0x167 of entity >> 'ipu2_csi1_mux': Da >> ta >> >> Required ioctls: >> test MC information (see 'Media Driver Info' above): FAIL >> >> Allow for multiple opens: >> test second /dev/v4l-subdev0 open: OK >> test for unlimited opens: OK >> >> Debug ioctls: >> test VIDIOC_LOG_STATUS: OK (Not Supported) >> >> Input ioctls: >> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) >> test VIDIOC_G/S_FREQUENCY: OK (Not Supported) >> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) >> test VIDIOC_ENUMAUDIO: OK (Not Supported) >> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) >> test VIDIOC_G/S_AUDIO: OK (Not Supported) >> Inputs: 0 Audio Inputs: 0 Tuners: 0 >> >> Output ioctls: >> test VIDIOC_G/S_MODULATOR: OK (Not Supported) >> test VIDIOC_G/S_FREQUENCY: OK (Not Supported) >> test VIDIOC_ENUMAUDOUT: OK (Not Supported) >> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) >> test VIDIOC_G/S_AUDOUT: OK (Not Supported) >> Outputs: 0 Audio Outputs: 0 Modulators: 0 >> >> Input/Output configuration ioctls: >> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > > Not Supported! > >> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) >> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) >> test VIDIOC_G/S_EDID: OK (Not Supported) >> >> Sub-Device ioctls (Source Pad 0): >> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK >> fail: v4l2-test-subdevs.cpp(301): fmt.width == 0 || >> fmt.width == ~0U >> fail: v4l2-test-subdevs.cpp(342): >> checkMBusFrameFmt(node, fmt.format) >> test Try VIDIOC_SUBDEV_G/S_FMT: FAIL >> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) >> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: >> OK >> fail: v4l2-test-subdevs.cpp(307): fmt.ycbcr_enc == 0x >> fail: v4l2-test-subdevs.cpp(342): >> checkMBusFrameFmt(node, fmt.format) >> test Active VIDIOC_SUBDEV_G/S_FMT: FAIL >> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) >> test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported) >> >> Control ioctls: >> test VIDIOC_QUERY_EXT_CTRL/QUE
Re: [PATCH v9 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Thu, Feb 8, 2018 at 11:41 PM, Hans Verkuil wrote: > On 02/09/2018 07:01 AM, Tim Harvey wrote: >> >> I don't see v4l2-subdev.c (or anything) ever calling g_input_status. >> How do I test this? > > Huh, that's a very good question! It is meant to be called by bridge > drivers implementing VIDIOC_ENUMINPUT. But that doesn't apply to the imx > driver since it is expecting userspace to talk directly to the subdev. > > Now for the DV_TIMINGS API this doesn't matter all that much since > QUERY_DV_TIMINGS can do the same job through the returned error code, but > for analog TV there is no such option (QUERYSTD doesn't support such > detailed feedback). > > I see that you have an adv7180 in your system. Can you run > 'v4l2-compliance -uX' for the adv7180 subdev and post the output here? > # v4l2-compliance -u0 v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 Compliance test for device /d[ 2526.153591] adv7180 2-0020: = S TART STATUS = ev/v4l-subdev0: Media Driver I[ 2526.162531] adv7180 2-0020: == END STATUS === === nfo: Driver name : imx-media Model: imx-media Serial : Bus info : Media version: 4.15.0 Hardware revision: 0x (0) Driver version : 4.15.0 Interface Info: ID : 0x038d Type : V4L Sub-Device Entity Info: ID : 0x0001 (1) Name : adv7180 2-0020 Function : FAIL: Unknown V4L2 Sub-Device Pad 0x0102 : Source Link 0x027f: to remote pad 0x167 of entity 'ipu2_csi1_mux': Da ta Required ioctls: test MC information (see 'Media Driver Info' above): FAIL Allow for multiple opens: test second /dev/v4l-subdev0 open: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Sub-Device ioctls (Source Pad 0): test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK fail: v4l2-test-subdevs.cpp(301): fmt.width == 0 || fmt.width == ~0U fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format) test Try VIDIOC_SUBDEV_G/S_FMT: FAIL test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK fail: v4l2-test-subdevs.cpp(307): fmt.ycbcr_enc == 0x fail: v4l2-test-subdevs.cpp(342): checkMBusFrameFmt(node, fmt.format) test Active VIDIOC_SUBDEV_G/S_FMT: FAIL test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported) test VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 5 Private Controls: 1 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK (Not Supported) test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF:
[PATCH v10 0/8] TDA1997x HDMI video reciver
CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 4 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported) test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK (Not Supported) test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) test VIDIOC_EXPBUF: OK (Not Supported) Total: 47, Succeeded: 47, Failed: 0, Warnings: 0 $ v4l2-compliance -M0 v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 Compliance test for device /dev/media0: Media Driver Info: Driver name : imx-media Model: imx-media Serial : Bus info : Media version: 4.15.0 Hardware revision: 0x0000 (0) Driver version : 4.15.0 Required ioctls: test MEDIA_IOC_DEVICE_INFO: OK Allow for multiple opens: test second /dev/media0 open: OK test MEDIA_IOC_DEVICE_INFO: OK test for unlimited opens: OK Media Controller ioctls: fail: v4l2-test-media.cpp(96): function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN fail: v4l2-test-media.cpp(161): checkFunction(ent.function, true) test MEDIA_IOC_G_TOPOLOGY: FAIL fail: v4l2-test-media.cpp(290): num_data_links != num_links test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL test MEDIA_IOC_SETUP_LINK: OK Total: 7, Succeeded: 5, Failed: 2, Warnings: 0 above failures are due to imx/adv7180 not setting a valid entity function Hans Verkuil (1): v4l2-dv-timings: add v4l2_hdmi_colorimetry() Tim Harvey (7): media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP media: add digital video decoder video interface entity functions MAINTAINERS: add entry for NXP TDA1997x driver media: dt-bindings: Add bindings for TDA1997X media: i2c: Add TDA1997x HDMI receiver driver ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x .../devicetree/bindings/media/i2c/tda1997x.txt | 179 ++ Documentation/media/uapi/mediactl/media-types.rst | 11 + MAINTAINERS|8 + arch/arm/boot/dts/imx6q-gw54xx.dts | 105 + arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +- arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 + drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tda1997x.c | 2807 drivers/media/i2c/tda1997x_regs.h | 641 + drivers/media/v4l2-core/v4l2-dv-timings.c | 141 + drivers/media/v4l2-core/v4l2-ioctl.c |2 +- include/dt-bindings/media/tda1997x.h | 74 + include/media/i2c/tda1997x.h | 42 + include/media/v4l2-dv-timings.h| 21 + include/uapi/linux/media.h |5 + 16 files changed, 4209 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/dt-bindings/media/tda1997x.h create mode 100644 include/media/i2c/tda1997x.h -- 2.7.4
[PATCH v10 3/8] media: add digital video decoder entity functions
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v10 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTEND
[PATCH v10 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0
[PATCH v10 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-media@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-media@vger.kernel.org -- 2.7.4
[PATCH v10 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* an
[PATCH v10 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+
[PATCH v10 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
[PATCH v10 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v10: - removed unnecessary check for !timings in get/set/query dv timings (Hans) - dropped pointless s_stream handler (Hans) - remove need for detected_timings and always use set timings (Hans) v9: - remove redundant pad bounds check already in v4l2-subdev.c - assign entity function (Hans) - properly assign/check/free ctrl_handler (Hans) - fixed typo 'Rull Range' -> 'Full Range' - update csc after quant range change v8: - fix available formats for tda19971 bt656 bus width >12 - support full range of input modes based on timings_cap - fix set_format (compliance) - fixed get/set edid (compliance) - add init_cfg to setup default pad config (compliance) - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance) - fix alignment of if statement and whitespace in comment (Hans) - move regs to tda1997x_regs.h to clean up (Hans) - add define and sanity check for num of mbus_codes (Hans) v7: - fix interlaced mode - support no AVI infoframe (ie DVI) (Hans) - add support for multiple output formats (Hans) v6: - fix return on regulator enablei in tda1997x_set_power() - replace copyright with SPDX tag - fix colorspace handling v5: - uppercase string constants - use v4l2_hdmi_rx_coloriemtry to fill format - fix V4L2_CID_DV_RX_RGB_RANGE - fix interlaced mode format v4: - move include/dt-bindings/media/tda1997x.h to bindings patch - fix typos - fix default quant range for VGA - fix quant range handling and conv matrix - add additional standards and capabilities to timings_cap v3: - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros - fixed missing break - use only hdmi_infoframe_log for infoframe logging - simplify tda1997x_s_stream error handling - add delayed work proc to handle hotplug enable/disable - fix set_edid (disable HPD before writing, enable after) - remove enabling edid by default - initialize timings - take quant range into account in colorspace conversion - remove vendor/product tracking (we provide this in log_status via infoframes) - add v4l_controls - add more detail to log_status - calculate vhref generator timings - timing detection fixes (rounding errors, hswidth errors) - rename configure_input/configure_conv functions v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - change audio bindings drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile|1 + drivers/media/i2c/tda1997x.c | 2807 + drivers/media/i2c/tda1997x_regs.h | 641 + include/media/i2c/tda1997x.h | 42 + 5 files changed, 3500 insertions(+) create mode 100644 drivers/media/i2c/tda1997x.c create mode 100644 drivers/media/i2c/tda1997x_regs.h create mode 100644 include/media/i2c/tda1997x.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cb5d7ff..3522641 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -56,6 +56,15 @@ config VIDEO_TDA9840 To compile this driver as a module, choose M here: the module will be called tda9840. +config VIDEO_TDA1997X + tristate "NXP TDA1997x HDMI receiver" + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API + ---help--- + V4L2 subdevice driver for the NXP TDA1997x HDMI receivers. + + To compile this driver as a module, choose M here: the + module will be called tda1997x. + config VIDEO_TEA6415C tristate "Philips TEA6415C audio processor" depends on I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 548a9ef..adfcae9 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o +obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c new file mode 100644 index 000..0a4673b --- /dev/null +++ b/drivers/media/i2c/tda1997x.c @@ -0,0 +1,2807 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Gateworks Corporation + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include "tda1997x_regs.h" + +#define TDA1997X_MBUS_CODES5 + +/* debug level */ +static int debug; +module_param(debug
Re: [PATCH v9 6/8] media: i2c: Add TDA1997x HDMI receiver driver
On Thu, Feb 8, 2018 at 7:06 AM, Hans Verkuil wrote:
> Hi Tim,
>
> I was so hoping I could make a pull request for this, but I still found
> problems with g/s/query_dv_timings.
>
> I strongly suspect that v4l2-compliance would fail if you boot up the system
> *without* a source connected.
>
> And I discovered that I was missing additional checks in the timings tests
> for v4l2-compliance that would have found the same issue if run with a source
> connected. I've fixed and committed those tests now. I'll also try to test
> that a S_DV_TIMINGS calls updates the format.
>
> Details below:
>
> On 02/07/18 23:42, Tim Harvey wrote:
>> +struct tda1997x_state {
>
> ...
>
>> + struct v4l2_dv_timings timings;
>> + const struct v4l2_dv_timings *detected_timings;
>
> ...
>
>> +/* Configure frame detection window and VHREF timing generator */
>> +static int
>> +tda1997x_configure_vhref(struct v4l2_subdev *sd)
>> +{
>> + struct tda1997x_state *state = to_state(sd);
>> + const struct v4l2_bt_timings *bt;
>> + int width, lines;
>> + u16 href_start, href_end;
>> + u16 vref_f1_start, vref_f2_start;
>> + u8 vref_f1_width, vref_f2_width;
>> + u8 field_polarity;
>> + u16 fieldref_f1_start, fieldref_f2_start;
>> + u8 reg;
>> +
>> + if (!state->detected_timings)
>> + return -EINVAL;
>
> Why this test? Who cares if there are no detected timings? It's certainly
> not a failure. S_DV_TIMINGS should succeed regardless of whether there is
> a signal or not and regardless of the current detected timings.
>
good point. Both tda1997x_configure_vhref() and
tda1997x_configure_csc() should never return an error - I'll change
that.
>> + bt = &state->detected_timings->bt;
>
> Ouch. The timings passed in with S_DV_TIMINGS should be used.
>
> Just use state->timings here, not detected_timings.
Ok. I was thinking the VHREF generator responsible for output timings
to the SoC should always match the input source but changing it async
like that could mess with userspace buffers and the like so even
though the output will be 'wrong' after a resolution change I get that
I need to wait for userspace to come along and query then set the new
resolution.
>
>> + href_start = bt->hbackporch + bt->hsync + 1;
>> + href_end = href_start + bt->width;
>> + vref_f1_start = bt->height + bt->vbackporch + bt->vsync +
>> + bt->il_vbackporch + bt->il_vsync +
>> + bt->il_vfrontporch;
>> + vref_f1_width = bt->vbackporch + bt->vsync + bt->vfrontporch;
>> + vref_f2_start = 0;
>> + vref_f2_width = 0;
>> + fieldref_f1_start = 0;
>> + fieldref_f2_start = 0;
>> + if (bt->interlaced) {
>> + vref_f2_start = (bt->height / 2) +
>> + (bt->il_vbackporch + bt->il_vsync - 1);
>> + vref_f2_width = bt->il_vbackporch + bt->il_vsync +
>> + bt->il_vfrontporch;
>> + fieldref_f2_start = vref_f2_start + bt->il_vfrontporch +
>> + fieldref_f1_start;
>> + }
>> + field_polarity = 0;
>> +
>> + width = V4L2_DV_BT_FRAME_WIDTH(bt);
>> + lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>> +
>> + /*
>> + * Configure Frame Detection Window:
>> + * horiz area where the VHREF module consider a VSYNC a new frame
>> + */
>> + io_write16(sd, REG_FDW_S, 0x2ef); /* start position */
>> + io_write16(sd, REG_FDW_E, 0x141); /* end position */
>> +
>> + /* Set Pixel And Line Counters */
>> + if (state->chip_revision == 0)
>> + io_write16(sd, REG_PXCNT_PR, 4);
>> + else
>> + io_write16(sd, REG_PXCNT_PR, 1);
>> + io_write16(sd, REG_PXCNT_NPIX, width & MASK_VHREF);
>> + io_write16(sd, REG_LCNT_PR, 1);
>> + io_write16(sd, REG_LCNT_NLIN, lines & MASK_VHREF);
>> +
>> + /*
>> + * Configure the VHRef timing generator responsible for rebuilding all
>> + * horiz and vert synch and ref signals from its input allowing auto
>> + * detection algorithms and forcing predefined modes (480i & 576i)
>> + */
>> + reg = VHREF_STD_DET_OFF << VHREF_STD_DET_SHIFT;
>> + io_write(sd, REG_VHREF_CTRL, reg);
>> +
>> + /*
>> + * Configure the VHRef timing values. In case the VHREF generator has
>> + * been configured
[PATCH v9 0/8] TDA1997x HDMI video reciver
Driver Info:
Driver name : imx-media
Model: imx-media
Serial :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version : 4.15.0
Compliance test for device /dev/media0:
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
fail: v4l2-test-media.cpp(94): function ==
MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN
fail: v4l2-test-media.cpp(156): checkFunction(ent.function,
true)
test MEDIA_IOC_G_TOPOLOGY: FAIL
fail: v4l2-test-media.cpp(275): num_data_links != num_links
test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
test MEDIA_IOC_SETUP_LINK: OK
Total: 7, Succeeded: 5, Failed: 2, Warnings: 0
above failures are due to imx/adv7180 not setting a valid entity function
Hans Verkuil (1):
v4l2-dv-timings: add v4l2_hdmi_colorimetry()
Tim Harvey (7):
media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
media: add digital video decoder video interface entity functions
MAINTAINERS: add entry for NXP TDA1997x driver
media: dt-bindings: Add bindings for TDA1997X
media: i2c: Add TDA1997x HDMI receiver driver
ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 ++
Documentation/media/uapi/mediactl/media-types.rst | 11 +
MAINTAINERS|8 +
arch/arm/boot/dts/imx6q-gw54xx.dts | 105 +
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 +
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tda1997x.c | 2848
drivers/media/i2c/tda1997x_regs.h | 641 +
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 +
drivers/media/v4l2-core/v4l2-ioctl.c |2 +-
include/dt-bindings/media/tda1997x.h | 74 +
include/media/i2c/tda1997x.h | 42 +
include/media/v4l2-dv-timings.h| 21 +
include/uapi/linux/media.h |5 +
16 files changed, 4250 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 drivers/media/i2c/tda1997x.c
create mode 100644 drivers/media/i2c/tda1997x_regs.h
create mode 100644 include/dt-bindings/media/tda1997x.h
create mode 100644 include/media/i2c/tda1997x.h
--
2.7.4
[PATCH v9 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
[PATCH v9 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
- remove redundant pad bounds check already in v4l2-subdev.c
- assign entity function (Hans)
- properly assign/check/free ctrl_handler (Hans)
- fixed typo 'Rull Range' -> 'Full Range'
- update csc after quant range change
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+
[PATCH v9 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers.
Cc: Hans Verkuil
Signed-off-by: Tim Harvey
---
v9:
- remove redundant pad bounds check already in v4l2-subdev.c
- assign entity function (Hans)
- properly assign/check/free ctrl_handler (Hans)
- fixed typo 'Rull Range' -> 'Full Range'
- update csc after quant range change
v8:
- fix available formats for tda19971 bt656 bus width >12
- support full range of input modes based on timings_cap
- fix set_format (compliance)
- fixed get/set edid (compliance)
- add init_cfg to setup default pad config (compliance)
- added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
- fix alignment of if statement and whitespace in comment (Hans)
- move regs to tda1997x_regs.h to clean up (Hans)
- add define and sanity check for num of mbus_codes (Hans)
v7:
- fix interlaced mode
- support no AVI infoframe (ie DVI) (Hans)
- add support for multiple output formats (Hans)
v6:
- fix return on regulator enablei in tda1997x_set_power()
- replace copyright with SPDX tag
- fix colorspace handling
v5:
- uppercase string constants
- use v4l2_hdmi_rx_coloriemtry to fill format
- fix V4L2_CID_DV_RX_RGB_RANGE
- fix interlaced mode format
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- fix typos
- fix default quant range for VGA
- fix quant range handling and conv matrix
- add additional standards and capabilities to timings_cap
v3:
- use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
- fixed missing break
- use only hdmi_infoframe_log for infoframe logging
- simplify tda1997x_s_stream error handling
- add delayed work proc to handle hotplug enable/disable
- fix set_edid (disable HPD before writing, enable after)
- remove enabling edid by default
- initialize timings
- take quant range into account in colorspace conversion
- remove vendor/product tracking (we provide this in log_status via infoframes)
- add v4l_controls
- add more detail to log_status
- calculate vhref generator timings
- timing detection fixes (rounding errors, hswidth errors)
- rename configure_input/configure_conv functions
v2:
- implement dv timings enum/cap
- remove deprecated g_mbus_config op
- fix dv_query_timings
- add EDID get/set handling
- remove max-pixel-rate support
- add audio codec DAI support
- change audio bindings
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile|1 +
drivers/media/i2c/tda1997x.c | 2848 +
drivers/media/i2c/tda1997x_regs.h | 641 +
include/media/i2c/tda1997x.h | 42 +
5 files changed, 3541 insertions(+)
create mode 100644 drivers/media/i2c/tda1997x.c
create mode 100644 drivers/media/i2c/tda1997x_regs.h
create mode 100644 include/media/i2c/tda1997x.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..3522641 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
To compile this driver as a module, choose M here: the
module will be called tda9840.
+config VIDEO_TDA1997X
+ tristate "NXP TDA1997x HDMI receiver"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..adfcae9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..87af02b
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,2848 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Gateworks Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "tda1997x_regs.h"
+
+#define TDA1997X_MBUS_CODES5
+
+/* debug level */
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+/* Audio formats */
+static const char * const audtype_names[] = {
+ "PCM",
[PATCH v9 3/8] media: add digital video decoder entity function
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v9 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* an
[PATCH v9 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+
[PATCH v9 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0
[PATCH v9 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-media@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-media@vger.kernel.org -- 2.7.4
Re: [PATCH v8 0/7] TDA1997x HDMI video reciver
On Wed, Feb 7, 2018 at 1:09 AM, Hans Verkuil wrote: > On 02/07/18 09:22, Hans Verkuil wrote: >> On 02/07/2018 12:29 AM, Tim Harvey wrote: >>> Media Controller ioctls: >>> fail: v4l2-test-media.cpp(141): ent.function == >>> MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN >> >> Weird, this shouldn't happen. I'll look into this a bit more. > > Can you run 'mc_nextgen_test -e -i' and post the output? > > It's found in contrib/test. > root@ventana:~# ./v4l-utils/contrib/test/mc_nextgen_test -e -i Device: imx-media (driver imx-media) Bus: version: 0 number of entities: 24 number of interfaces: 24 number of pads: 48 number of links: 50 entity entity#1: 'unknown entity type' adv7180 2-0020, 1 pad(s), 1 source(s) entity entity#3: 'unknown entity type' tda19971 2-0048, 1 pad(s), 1 source(s) entity entity#5: 'unknown entity type' ipu1_vdic, 3 pad(s), 2 sink(s), 1 source(s) entity entity#9: 'unknown entity type' ipu2_vdic, 3 pad(s), 2 sink(s), 1 source(s) entity entity#13: 'unknown entity type' ipu1_ic_prp, 3 pad(s), 1 sink(s), 2 source(s) entity entity#17: 'unknown entity type' ipu1_ic_prpenc, 2 pad(s), 1 sink(s), 1 source(s) entity entity#20: 'V4L I/O' ipu1_ic_prpenc capture, 1 pad(s), 1 sink(s) entity entity#26: 'unknown entity type' ipu1_ic_prpvf, 2 pad(s), 1 sink(s), 1 source(s) entity entity#29: 'V4L I/O' ipu1_ic_prpvf capture, 1 pad(s), 1 sink(s) entity entity#35: 'unknown entity type' ipu2_ic_prp, 3 pad(s), 1 sink(s), 2 source(s) entity entity#39: 'unknown entity type' ipu2_ic_prpenc, 2 pad(s), 1 sink(s), 1 source(s) entity entity#42: 'V4L I/O' ipu2_ic_prpenc capture, 1 pad(s), 1 sink(s) entity entity#48: 'unknown entity type' ipu2_ic_prpvf, 2 pad(s), 1 sink(s), 1 source(s) entity entity#51: 'V4L I/O' ipu2_ic_prpvf capture, 1 pad(s), 1 sink(s) entity entity#57: 'unknown entity type' ipu1_csi0, 3 pad(s), 1 sink(s), 2 source(s) entity entity#61: 'V4L I/O' ipu1_csi0 capture, 1 pad(s), 1 sink(s) entity entity#67: 'unknown entity type' ipu1_csi1, 3 pad(s), 1 sink(s), 2 source(s) entity entity#71: 'V4L I/O' ipu1_csi1 capture, 1 pad(s), 1 sink(s) entity entity#77: 'unknown entity type' ipu2_csi0, 3 pad(s), 1 sink(s), 2 source(s) entity entity#81: 'V4L I/O' ipu2_csi0 capture, 1 pad(s), 1 sink(s) entity entity#87: 'unknown entity type' ipu2_csi1, 3 pad(s), 1 sink(s), 2 source(s) entity entity#91: 'V4L I/O' ipu2_csi1 capture, 1 pad(s), 1 sink(s) entity entity#97: 'unknown entity type' ipu1_csi0_mux, 3 pad(s), 2 sink(s), 1 source(s) entity entity#101: 'unknown entity type' ipu2_csi1_mux, 3 pad(s), 2 sink(s), 1 source(s) interface intf_devnode#21: video /dev/video0 interface intf_devnode#30: video /dev/video1 interface intf_devnode#43: video /dev/video2 interface intf_devnode#52: video /dev/video3 interface intf_devnode#62: video /dev/video4 interface intf_devnode#72: video /dev/video5 interface intf_devnode#82: video /dev/video6 interface intf_devnode#92: video /dev/video7 interface intf_devnode#141: v4l2-subdev /dev/v4l-subdev0 interface intf_devnode#143: v4l2-subdev /dev/v4l-subdev1 interface intf_devnode#145: v4l2-subdev /dev/v4l-subdev2 interface intf_devnode#147: v4l2-subdev /dev/v4l-subdev3 interface intf_devnode#149: v4l2-subdev /dev/v4l-subdev4 interface intf_devnode#151: v4l2-subdev /dev/v4l-subdev5 interface intf_devnode#153: v4l2-subdev /dev/v4l-subdev6 interface intf_devnode#155: v4l2-subdev /dev/v4l-subdev7 interface intf_devnode#157: v4l2-subdev /dev/v4l-subdev8 interface intf_devnode#159: v4l2-subdev /dev/v4l-subdev9 interface intf_devnode#161: v4l2-subdev /dev/v4l-subdev10 interface intf_devnode#163: v4l2-subdev /dev/v4l-subdev11 interface intf_devnode#165: v4l2-subdev /dev/v4l-subdev12 interface intf_devnode#167: v4l2-subdev /dev/v4l-subdev13 interface intf_devnode#169: v4l2-subdev /dev/v4l-subdev14 interface intf_devnode#171: v4l2-subdev /dev/v4l-subdev15 I updated v4l2-compliance and ran again: root@ventana:~# v4l2-compliance -m0 -M v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 Media Driver Info: Driver name : imx-media Model: imx-media Serial : Bus info : Media version: 4.15.0 Hardware revision: 0x (0) Driver version : 4.15.0 Compliance test for device /dev/media0: Required ioctls: test MEDIA_IOC_DEVICE_INFO: OK Allow for multiple opens: test second /dev/media0 open: OK test MEDIA_IOC_DEVICE_INFO: OK test for unlimited opens: OK Media Controller ioctls: fail: v4l2-test-media.cpp(94): function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN fail: v4l2-test-media.cpp(156): checkFunction(ent.function, true) test MEDIA_IOC_G_TOPOLOGY: FAIL fail: v4l2-test-media.cpp(275): num_data_links != num_links test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL test MEDIA_IOC_SETUP_LINK: OK Total: 7, Succeeded: 5, Failed: 2, Warnings: 0 Regards, Tim
Re: [PATCH v8 0/7] TDA1997x HDMI video reciver
On Tue, Feb 6, 2018 at 1:21 PM, Hans Verkuil wrote:
> On 02/06/2018 09:27 PM, Tim Harvey wrote:
>
>
>
>> v4l2-compliance test results:
>> - with the following kernel patches:
>>v4l2-subdev: clear reserved fields
>> . v4l2-subdev: without controls return -ENOTTY
>>
>> v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8
>> Media Driver Info:
>> Driver name : imx-media
>> Model: imx-media
>> Serial :
>> Bus info :
>> Media version: 4.15.0
>> Hardware revision: 0x (0)
>> Driver version : 4.15.0
>> Interface Info:
>> ID : 0x038f
>> Type : V4L Sub-Device
>> Entity Info:
>> ID : 0x0003 (3)
>> Name : tda19971 2-0048
>> Function : Unknown
>
> This is missing. It should be one of these:
>
> https://hverkuil.home.xs4all.nl/spec/uapi/mediactl/media-types.html#media-entity-type
>
> However, we don't have a proper function defined.
>
> I would suggest adding a new MEDIA_ENT_F_DTV_DECODER analogous to
> MEDIA_ENT_F_ATV_DECODER.
>
> It would be a new patch adding this + documentation.
Hows this look for adding to my next series:
Author: Tim Harvey
Date: Tue Feb 6 14:12:52 2018 -0800
[media] add digital video decoder video interface entity functions
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..6653e88 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -152,6 +152,7 @@ struct media_device_info {
* MEDIA_ENT_F_IF_VID_DECODER and/or MEDIA_ENT_F_IF_AUD_DECODER.
*/
#define MEDIA_ENT_F_TUNER (MEDIA_ENT_F_OLD_SUBDEV_BASE + 5)
+#define MEDIA_ENT_F_DTV_DECODER
(MEDIA_ENT_F_OLD_SUBDEV_BASE + 6)
#define MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWNMEDIA_ENT_F_OLD_SUBDEV_BASE
Assigning this now shows a function but does not resolve the media
compliance results:
--- a/drivers/media/i2c/tda1997x.c
+++ b/drivers/media/i2c/tda1997x.c
@@ -2586,6 +2586,7 @@ static int tda1997x_probe(struct i2c_client *client,
id->name, i2c_adapter_id(client->adapter),
client->addr);
sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
+ sd->entity.function = MEDIA_ENT_F_DTV_DECODER;
sd->entity.ops = &tda1997x_media_ops;
/* set allowed mbus modes based on chip, bus-type, and bus-width */
root@ventana:~# v4l2-compliance -u1
v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name : imx-media
Model: imx-media
Serial :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version : 4.15.0
Interface Info:
ID : 0x038f
Type : V4L Sub-Device
Entity Info:
ID : 0x0003 (3)
Name : tda19971 2-0048
Function : Unknown (00020006)
Pad 0x0104 : Source
Link 0x026f: to remote pad 0x163 of entity
'ipu1_csi0_mux': Data
...
root@ventana:~# v4l2-compliance -m0 -M
v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name : imx-media
Model: imx-media
Serial :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version : 4.15.0
Compliance test for device /dev/media0:
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
fail: v4l2-test-media.cpp(141): ent.function ==
MEDIA_ENT_F_V4L2_SUBDEV_UNK
Re: [PATCH v8 5/7] media: i2c: Add TDA1997x HDMI receiver driver
On Tue, Feb 6, 2018 at 12:38 PM, Hans Verkuil wrote:
> On 02/06/2018 09:27 PM, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil
>> Signed-off-by: Tim Harvey
>> ---
>
>
>
>> +static int tda1997x_get_dv_timings_cap(struct v4l2_subdev *sd,
>> +struct v4l2_dv_timings_cap *cap)
>> +{
>> + if (cap->pad != TDA1997X_PAD_SOURCE)
>> + return -EINVAL;
>> +
>> + *cap = tda1997x_dv_timings_cap;
>> + return 0;
>> +}
>> +
>> +static int tda1997x_enum_dv_timings(struct v4l2_subdev *sd,
>> + struct v4l2_enum_dv_timings *timings)
>> +{
>> + if (timings->pad != TDA1997X_PAD_SOURCE)
>> + return -EINVAL;
>> +
>> + return v4l2_enum_dv_timings_cap(timings, &tda1997x_dv_timings_cap,
>> + NULL, NULL);
>> +}
>
> You shouldn't need this pad test: it's done in the v4l2-subdev.c core code
> already. But please double-check :-)
>
oh right - forgot to check that. Yes, v4l2-subdev.c has pad bounds
checking on all ops I use so I can remove them.
> Can you post the output of the v4l2-compliance test? I'm curious to see it.
it's in the cover letter (should I move it to the driver patch for
subsequent submittals?)
>
> Can you also try to run v4l2-compliance -m /dev/mediaX? That also tests
> whether the right entity types are set (note: testing for that should
> also happen in the subdev compliance test, but I haven't done that yet).
>
root@ventana:~# v4l2-compliance -m0
v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8
Media Driver Info:
Driver name : imx-media
Model: imx-media
Serial :
Bus info :
Media version: 4.15.0
Hardware revision: 0x (0)
Driver version : 4.15.0
Compliance test for device /dev/media0:
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
fail: v4l2-test-media.cpp(141): ent.function ==
MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN
test MEDIA_IOC_G_TOPOLOGY: FAIL
fail: v4l2-test-media.cpp(256):
v2_entities_set.find(ent.id) == v2_entities_set.end()
test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL
test MEDIA_IOC_SETUP_LINK: OK
Total: 7, Succeeded: 5, Failed: 2, Warnings: 0
foiled again!
Is something missing after v4l2_i2c_subdev_init() or is this perhaps
something missing in the imx media drivers?
v4l2_i2c_subdev_init(sd, client, &tda1997x_subdev_ops);
snprintf(sd->name, sizeof(sd->name), "%s %d-%04x",
id->name, i2c_adapter_id(client->adapter),
client->addr);
sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
sd->entity.ops = &tda1997x_media_ops;
Regards,
Tim
