This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RSZ_FRACDIV not reset 0xffff

Other Parts Discussed in Thread: SYSCONFIG

we use the iss model to capture video,when we capture 1280*720 pixel from ov5640 and conversion from yuv422 to

nv12 .but we find the register value is 0x0000 which when reset isp ,its value is 0xffff. so we force set it with 0xffff,then we find its value is still 0x0000,why is it?

  • Hello Yang,

    Determine the upscale ratio and functional clock, and adjust the fractional clock divider as appropriate.

    The fractional clock divider gates the read requests made to the input data buffer such that the input data buffer is read at an average frequency equal to FFCLK instead of FCLK. The value of FFCLK depends upon the upscaling
    ratios as well as the input pixel clock. FFCLK = FCLK / FRACDIV MHz and RSZ_FRACDIV = 65536 / FRACDIV.

    When RSZ_ FRACDIV = 65536, therefore FFCLK = FCLK.

    The reset value for this bit-filed is 0xFFFF. When you set this register with 0xFFFF it is normal when reset state is occurred the value in the bit-field to be 0x0000. 

    See the settings in https://github.com/mirrors/linux/tree/master/drivers/staging/media/omap4iss

    Best regards,

    Yanko

  • Thank you very much for your reply. I also check RSZ_FRACDIV value . When I set ISP5_SYSCONFIG_SOFTRESE bit to reset ISP modules then we check RSZ_FRACDIV value ,its value still be 0x0000.

  • Thank you very much for your reply. I also check RSZ_FRACDIV value . When I set ISP5_SYSCONFIG_SOFTRESE bit to reset ISP modules then we check RSZ_FRACDIV value ,its value still be 0x0000. but the omap4460 Technical Reference Manual say when we reset ISP ,its value  is 0xffff. is it problem?   We  also find the register is not set value,it to say  when we set it value ,we check its value still to 0x0000. why?

  • Hello Yang,

    There is not problem to read 0x0000 in RSZ_FRACDIV when reset is occurred. I want to notice - A software reset must not reset the power manager protocols (must not reset the IDLE and STANDBY generic IPs).
    Make sure that your ISS modules are in active mode. For this purpose check the registers:

    1. ISS_CTRL - ISS control register
    2. ISS_CLKCTRL - ISS clock control register. Use to enable/disable the interface and functional clock of ISS submodules.
    3. ISS_CLKSTAT - ISS clock status register
    4. ISS_PM_STATUS - ISS power manager status register.

    Resizer module is part from ISP image signal processor. The resizer module has no standalone software reset. RSZ must be reset at the ISP level.

    I assume that your ISP module is not enable (not active), therefore your cannot set values in its registers as RSZ_FRACDIV. Check if your ISS is in active power state.

    See section 8.3.3.5.2 ISS ISP RSZ Top-Level Block Diagram in OMAP4 TRM.

    Best regards,

    Yanko

  • Thank you for you reply! Now I force set reiszer  no_standby mode ,then reset isp ,i found  RSZ_FRACDIV is  0xf8. but

    after first ISP5_IRQ_RSZ_INT_DMA ,its value change to be 0x00. why? it trouble me for a long time.

  • Hello Yang,

    Software reset is done through the ISP5_SYSCONFIG[1] SOFTRESET bit. Before issuing a software reset, the ISP must be in standby mode. The following must be done:
    1. Ensure that the interfaces are stopped from sending data and/or the ISP modules are disabled. Before
    reset, the last interrupt triggered by the ISP when the frame processing completes is RSZ_INT_DMA.
    RSZ_INT_DMA must be used to enable clean termination of the processing. Software must wait a few
    hundred cycles to trigger a soft reset after RSZ_INT_DMA is asserted; this is to ensure that the BL (blanking) is completely drained.
    This event is triggered when the last EOF (of the two MTC interfaces) is sent out to the BL and the RSZ core returns to idle. This event is active high for one GCK_MMR clock cycle.
    The reset procedure is:

    Wait until there is no DMA process and the module ready for reset.
    ISP5_SYSCONFIG[1] SOFTRESET
    and
    ISP5_IRQSTATUS_i[15] RSZ_INT_DMA

    Because the RSZ module has no software reset, software can issue one at the ISP level. Moreover, upon hardware reset, all the registers in the RSZ are reset to their reset values. Steps identify the proper software sequence before and after RSZ reset issues at the ISP level.

    Do you follow the reset sequence?

    Before reset you must disable RSZ module, so you will save the value in RSZ_FRACDIV when reset is occurred.

    Best regards,

    Yanko

  • current we using resizer to encode h264 video but we do not known  the difference between pass by and pass thought?We want to convert yuyv to nv12 by resizer ?how to set its resizer about pass?

  • Hello Yang,

    The RSZ module gets data from the IPIPEIF module or IPIPE module.

    • The data coming from the IPIPEIF module can be RAW or YUV4:2:2 data. Because the RSZ module can rescale only YUV4:2:2 data, the RSZ module must be configured in pass-through mode when RAW data is received on VP 2. It is possible to bypass the RSZ engine if YUV4:2:2 data is sent but rescaling is not needed (bypass mode).
    • The data coming from the IPIPE module can be RAW or YUV4:2:2 data. Eventually, YUV4:2:0 data can be sent through this path, but the data must be sent in two passes. Because the RSZ module can rescale only YUV4:2:2 data, the RSZ module must be configured in pass-through mode when RAW data is received on VP 1. It is possible to bypass the RSZ engine if YUV4:2:2 data is sent but rescaling is not needed (bypass mode).

    About the Resizer configuration:

    - To start up, the RSZ configuration can be set from the RSZ_SYSCONFIG register, which provides enabling the RSZ-A and RSZ-B clocks.

    - The RSZ_SRC_EN[0] EN bit starts the resizer processing. If the processing mode is set to one shot (one
    run and then turn off) from the RSZ_SRC_MODE[0] OST bit, the EN bit is cleared to 0

    - The resizer can be configured to be bypassed in certain cases (see Figure 8-206 for the module constraints) from the RSZ_SRC_FMT0[1] BYPASS bit. The data can be sent directly from here to the output interface (bypass mode) or imported to the module buffer, but not manipulated and sent to the output interface (pass-through mode).

    - The RSZ_YUV_PHS[0] POS bit sets the chrominance output. The RSZ module does not change the relative position of the chroma samples versus the luma samples between the input and output, and the chroma position at the output of the IPIPE module and at the output of the RSZ module must be identical.
    In other words, RSZ_YUV_PHS.POS = IPIPE_YUV_PHS.POS. Settings are common for both resizer engines inside the RSZ module. Each engine (RZA or RZB) can be enabled from the RZx_EN register: select the mode from RZx_MODE, and select the input and output in the YUV color scheme from the RZx_420 register (valid only if YUV 4:2:2 is the input set from RSZ_SRC_FMT1.IN420).

    • The port 1 interface is dedicated to the RSZ-A module. If the RSZ module is set up in pass-through mode, then the data is output on the port 1 interface. This interface can transfer RAW, YUV4:2:2, YUV4:2:0 and RGB data
    • The port 2 interface is dedicated to the RSZ-B module. This interface can transfer RAW, YUV4:2:2,
    YUV4:2:0 and RGB data.

    We want to convert yuyv to nv12 by resizer ?

    The resizer module supports YUV4:2:0 (nv12) output format.  The resizer can support RAW, YUV4:2:0, and YUV4:2:2 formats.
    The supported output formats are:

    Output Format      Bytes per Pixel           Output Buffers per Image             Interface Supporting the Data Format
          RAW                    2                                                   1                                                          MTC port 1
        YUV4:2:2              2 average                                   1                                                      MTC port 1 port 2
        YUV4:2:0              1.5 average                                2                                                      MTC port 1 port 2    - NV12
        RGB16                  2                                                   1                                                      MTC port 1 port 2
        ARGB32               4                                                   1                                                      MTC port 1 port 2

    To convert input yuv format in nv12 use the see the following:

    The register RZA_420[0] YEN; RZA_420[1] CEN

    0/0: in = YUV4:2:2 input, out = YUV4:2:2 output
    0/1: in = YUV4:2:2 input, out = Chrominance of YUV4:2:0 output
    1/0: in = YUV4:2:2 input, out = Luminance of YUV4:2:0 output
    1/1: in = YUV4:2:2 input, out = YUV4:2:0 output

    The register RZA_RGB_EN[0] RGB_EN must be disabled, when the output format from resizer is nv12. In pass through mode, this register must be 0. When the output format is YCbCr, this bit is 0. YUV4:2:0  data output is selected when SRC_FMT1[1] IN420 = 0 and RZA_420[0] YEN = 1  RZA_420[1] CEN = 1

    For more information you can refer to resizer driver - drivers/media/video/omap3isp/ispresizer.c

    Best regards,

    Yanko