topic Re: iMX6DQ IPU in i.MX Processors

iMX6DQ IPU

ogj — Fri, 16 Oct 2020 05:15:02 GMT

I am grinding my way through the IPU section of the RM plus the ipu driver code in the SDK. I have a question about the pixel format select field in word 1 of the channel mega-words (specifically chan 23). In my application I don't use any cameras or other video inputs. I will be using channels 23 and 27 to send ARGB8888 data from the frame buffers to the display. I trying to determine if I need to do anything with the pixel format select field (bits 88:85 of word 1). I assume they are for some other "camera" input that I won't be using. The SDK code sets it to 0x17 which is interesting since it is a 4-bit field and the ipu_cpmem_set_field function doesn't limit the value to the size of the field (see attached file).

Do I have to do anything with the pixel format field?

Re: iMX6DQ IPU

ogj — Fri, 16 Oct 2020 16:11:10 GMT

On further examination of the value of the SDK default uses for the PFS field (0x17), I see that it's setting the Alpha Used (ALU) bit. However the label for the value (0x17) calls it INTERLEAVED_RGB565.

ogj_0-1602864518721.png

Wouldn't that mean separate (non-interleaved) alpha? I still think I'm a little confused about what data path this field is for.

Re: iMX6DQ IPU

ogj — Sat, 17 Oct 2020 02:29:21 GMT

I've finally figured out that the PFS field in my case needs to set to something in the 0x5 to 0xF range (NA). Looking back at old presentations, I noticed there used to be a IPUFORUM@freescale.com. Does anything like that exist now?

Re: iMX6DQ IPU

igorpadykov — Mon, 19 Oct 2020 01:22:11 GMT

Hi ogj

you are right, usually this field is used for camera inputs. For displays typically RGB

format is used, in general case other formats are also supported as described in

sect.37.1.2.1.2.2 Display Interface i.MX 6Dual/6Quad Applications Processor Reference Manual

The supported formats for pixel data are
• RGB - color depth fully configurable; up to 8 bits/value (color component)
• YUV 4:2:2, 8 bits/value (for TV encoder)

Best regards
igor

Re: iMX6DQ IPU

ogj — Mon, 19 Oct 2020 22:41:00 GMT

Moving on to the IPU DI and generating the display control signals. Since the DI is not a standard LCD controller (that just uses normal values for HSYNC, VSYNC, back porch, front porch, pixel clock, etc.) is there a spreadsheet that one can put these values in and it generates all of the register settings back? Something similar to the reverse of the CPMEM tool.

Also, from going through the ipu_di.c code, it appears there is more than one DI_STP_REP_i register. It appears that there is one di_step_repeat_2 value for each of the DI_SW_GEN0/DI_SW_GEN1 register pairs (is that what the “i” means – multiple registers??). This would mean that (for DI0) there is one at 0x4_0148, 0x4_014C, 0x4_0150, and 0x4_0154, with DI_STP_REP_9 being at 0x4_0158. The RM doesn’t mention this.

I’m assuming that the register at 0x4_0148 is for DI_SW_GEN0_1/DI_SW_GEN1_1 and DI_SW_GEN0_2/DI_SW_GEN1_2, and the next register (0x4_014C) is for _GEN0_3/_GEN1_3 and _GEN0_4/_GEN1_4 and so on. Can these registers be written x16?

There are other registers that have an “i” suffix such as DI_DW_SET0_i through DI_DW_SET3_i with big address gaps in between. The original ipu_reg_def.h file shows registers in between these. Have these registers been eliminated?

Re: iMX6DQ IPU

ogj — Fri, 23 Oct 2020 23:47:11 GMT

Anyone know the answer about the undocumented DI_STP_REP_i registers?