Workaround for Chip errata(Rev.6) in i.Mx6DQ.

keitanagashima · ‎05-09-2016

Dear All,

Refer to Errata sheet (IMX6DQCE Rev. 6).

Now, we are using android jb4.2.2_1.1.0 (kernel L3.0.35_4.0.0).

Could you give me below commit information of kernel?

ERR003724

ERR004325

ERR005199

ERR007006

ERR009219

ERR009165

Best Regards,

Keita

jimmychan · ‎06-19-2016

I got the reply from the expert.

Each answer follows the errata number started with [Answer], you can check below:
HDMI:
ERR004323, HDMI: The DMA burst read transaction address region is limited to 8 KB
[Answer] Allocate audio DMA period buffer to 6K size in imx-hdmi-dam.c.
ERR005171, HDMI: HDMI Txaudio may have noise due to audio DMA FIFO overflow
ERR005174, HDMI: HDMI AHB Audio DMA stream misalignment on system initialization
[Answer] The above two workaround add by the followed patch:
ENGR00179601 Synopsys approved hdmi fifo workaround - rev 3
c584dd8c4f744d5faa5ea2811748ac786165c617
ERR005173, HDMI: Clarification on HDMI programming procedure to avoid FIFO overflow
[Answer] Mxc_hdmi.c lines 1743, write register HDMI_FC_INVIDCONF 5 times.
ERR004366, HDMI: 9000482480—ARM core read operation returns incorrect data for certain HDCP registers
[Answer] No software workaround added to driver.
CCM:
ERR009219, CCM: Asynchronous clock switching cancause unpredictable behavior [i.MX 6Dual/6Quad Only]
[Answer] imx_3.10.53_1.1.0_ga kernel: ENGR00318063-8: ARM: imx6q: hide buggy ldb_di_sel from clk API
eCSPI:
ERR009165, eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to be sent twice
[Answer] MLK-10404-3: firmware: imx: sdma: use XCH mode in escspi tx script
Use XCH mode in ecspi tx script to workaround TKT238285.
MLK-10404-2 ARM: dts: imx6dl: support ecspi DMA on i.mx6dl
Enable ecspi DMA support on i.mx6dl since there is official workaround for TKT238285.
MLK-10404-1 spi: spi-imx: use XCH mode even in DMA mode
To workaroud the TKT238285, the safe way is use XCH mode in SDMA script to simulate as
PIO mode which never report such issue. Meanwhile, set tx threashold as 0. But this
workaroud will bring performance impacted, below performance data is collected by 'dd'
with SPI-NOR flash on i.mx6dl sabresd board: mode write data read data --PIO 194KB/s 644KB/s
--DMA normal (SMC, tx_thresh=32) 222KB/s 1.4MB/s --DMA(XCH, tx_thresh=0) 210KB/s 1.0MB/s
USB:
ERR004534 and ERR004535,
[Answer] we knew these issues before designing software, so these two are covered at low power mode.
You can check arch/arm/mach-mx6/usb_dr.c for detail.
ERR007881
[Answer] For imx6DQ, the stream mode is disabled for both host and device mode. See below code at:
drivers/usb/chipidea/ci_hdrc_imx.c
static const struct ci_hdrc_imx_platform_flag imx6q_usb_data =
{ .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | CI_HDRC_IMX_EHCI_QUIRK | CI_HDRC_DISABLE_STREAMING | CI_HDRC_OVERRIDE_AHB_BURST | CI_HDRC_OVERRIDE_BURST_LENGTH, .ahbburst_config = 0, /*bit0 - bit2 at $BASE + 0x90 */ .burst_length = 0x1010, /*bit0 - bit15 at $BASE + 0x160 */ }

View solution in original post

jimmychan · ‎06-19-2016

I got the reply from the expert.

Each answer follows the errata number started with [Answer], you can check below:
HDMI:
ERR004323, HDMI: The DMA burst read transaction address region is limited to 8 KB
[Answer] Allocate audio DMA period buffer to 6K size in imx-hdmi-dam.c.
ERR005171, HDMI: HDMI Txaudio may have noise due to audio DMA FIFO overflow
ERR005174, HDMI: HDMI AHB Audio DMA stream misalignment on system initialization
[Answer] The above two workaround add by the followed patch:
ENGR00179601 Synopsys approved hdmi fifo workaround - rev 3
c584dd8c4f744d5faa5ea2811748ac786165c617
ERR005173, HDMI: Clarification on HDMI programming procedure to avoid FIFO overflow
[Answer] Mxc_hdmi.c lines 1743, write register HDMI_FC_INVIDCONF 5 times.
ERR004366, HDMI: 9000482480—ARM core read operation returns incorrect data for certain HDCP registers
[Answer] No software workaround added to driver.
CCM:
ERR009219, CCM: Asynchronous clock switching cancause unpredictable behavior [i.MX 6Dual/6Quad Only]
[Answer] imx_3.10.53_1.1.0_ga kernel: ENGR00318063-8: ARM: imx6q: hide buggy ldb_di_sel from clk API
eCSPI:
ERR009165, eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to be sent twice
[Answer] MLK-10404-3: firmware: imx: sdma: use XCH mode in escspi tx script
Use XCH mode in ecspi tx script to workaround TKT238285.
MLK-10404-2 ARM: dts: imx6dl: support ecspi DMA on i.mx6dl
Enable ecspi DMA support on i.mx6dl since there is official workaround for TKT238285.
MLK-10404-1 spi: spi-imx: use XCH mode even in DMA mode
To workaroud the TKT238285, the safe way is use XCH mode in SDMA script to simulate as
PIO mode which never report such issue. Meanwhile, set tx threashold as 0. But this
workaroud will bring performance impacted, below performance data is collected by 'dd'
with SPI-NOR flash on i.mx6dl sabresd board: mode write data read data --PIO 194KB/s 644KB/s
--DMA normal (SMC, tx_thresh=32) 222KB/s 1.4MB/s --DMA(XCH, tx_thresh=0) 210KB/s 1.0MB/s
USB:
ERR004534 and ERR004535,
[Answer] we knew these issues before designing software, so these two are covered at low power mode.
You can check arch/arm/mach-mx6/usb_dr.c for detail.
ERR007881
[Answer] For imx6DQ, the stream mode is disabled for both host and device mode. See below code at:
drivers/usb/chipidea/ci_hdrc_imx.c
static const struct ci_hdrc_imx_platform_flag imx6q_usb_data =
{ .flags = CI_HDRC_SUPPORTS_RUNTIME_PM | CI_HDRC_IMX_EHCI_QUIRK | CI_HDRC_DISABLE_STREAMING | CI_HDRC_OVERRIDE_AHB_BURST | CI_HDRC_OVERRIDE_BURST_LENGTH, .ahbburst_config = 0, /*bit0 - bit2 at $BASE + 0x90 */ .burst_length = 0x1010, /*bit0 - bit15 at $BASE + 0x160 */ }

keitanagashima · ‎06-22-2016

Dear jimmychan,

Hello. Thank you for your great information!

Sorry. I have additional questions. Please check it again.

==================

[ERR004323]

Let me clarify my understanding.

If set to HDMI_DMA_PERIOD_BYTES = 6144 of "sound/soc/imx/imx-hdmi-dma.c", is it OK?

[ERR004366]

Even if the Linux version is older than L3.0.35_4.1.0"(like a L3.0.35_4.0.0), is "software workaround added to driver" unnecessary, too?

[ERR009219]

We understood that this errata must not select the clock of LDB_DI0_IPU and LDB_DI1_IPU.

And, we think that your answer's patch doesn't cover this errata.

Is my bellow understanding right?

====

It set up the clock for LVDS at the Kernel start-up by the procedure with init_ldb_clks() function in "arch\arm\mach-imx\clk-imx6q.c" (L3.10.53).

After that, it makes a clock for LVDS not be selected.

====

And, there is bellow description in chip errata.

"This can therefore cause a loss of the LDB_DIx_IPU clock which can result in a blank LVDS display screen in the user application."

Is this errata cause the only blank display? Are there other influence?

[ERR004534][ERR004535]

My customer want to check it the their based BSP(jb4.2.2_1.0.0 L3.0.35_4.0.0).

Which part of usb_dr.c should I check?

(Could you tell me the specific line?)

[ERR007881]

The your answer's code was for recently version (newer than L3.14.28).

So, the code was not found in the older version (L3.0.35).

We confirmed the drivers\usb\otg\fsl_otg.c in version (L3.0.35).

The USB_MODE_STREAM_DISABLE looks setting SDIS = 1 in USBMODE register at line.1199 or line.1862.

May the workaround be judged to be applied only in this description?

If the workaround was lucked, could you tell me the workaround points.

==================

Best Regards,

Keita

jimmychan · ‎06-26-2016

Hi Keita,

I got the reply from the expert team:

[ERR004323]

Let me clarify my understanding.

If set to HDMI_DMA_PERIOD_BYTES = 6144 of "sound/soc/imx/imx-hdmi-dma.c", is it OK?

Ans: yes, ok.

[ERR004366]

Even if the Linux version is older than L3.0.35_4.1.0"(like a L3.0.35_4.0.0), is "software workaround added to driver" unnecessary, too?

Ans: yes, unnecessary.

[ERR009219]

We understood that this errata must not select the clock of LDB_DI0_IPU and LDB_DI1_IPU.

And, we think that your answer's patch doesn't cover this errata.

Is my bellow understanding right?

====

It set up the clock for LVDS at the Kernel start-up by the procedure with init_ldb_clks() function in "arch\arm\mach-imx\clk-imx6q.c" (L3.10.53).

After that, it makes a clock for LVDS not be selected.

====

Ans: Correct, LDB clock can only be initialized during kernel boot up once, the init_ldb_clks is called during kernel boot up, in early stage, the comment in this function says below, it follows the workaround of the errata, after it is initialized, it will make LDB_DIx_CLK_SEL not be changed, so it will avoid the issue once kernel boot up.

185 static void init_ldb_clks(void)
186 {
187 u32 reg;
188
189 /*
190 * Need to follow a strict procedure when changing the LDB
191 * clock, else we can introduce a glitch. Things to keep in
192 * mind:
193 * 1. The current and new parent clocks must be disabled.
194 * 2. The default clock for ldb_dio_clk is mmdc_ch1 which has
195 * no CG bit.
196 * 3. In the RTL implementation of the LDB_DI_CLK_SEL mux
197 * the top four options are in one mux and the PLL3 option along
198 * with another option is in the second mux. There is third mux
199 * used to decide between the first and second mux.
200 * The code below switches the parent to the bottom mux first
201 * and then manipulates the top mux. This ensures that no glitch
202 * will enter the divider.
203 *
204 * Need to disable MMDC_CH1 clock manually as there is no CG bit
205 * for this clock. The only way to disable this clock is to move
206 * it topll3_sw_clk and then to disable pll3_sw_clk
207 * Make sure periph2_clk2_sel is set to pll3_sw_clk
208 */

And, there is bellow description in chip errata.

"This can therefore cause a loss of the LDB_DIx_IPU clock which can result in a blank LVDS display screen in the user application."

Is this errata cause the only blank display? Are there other influence?

Ans : The root cause of this errata is the clock gate hardware design is NOT put before the LDB clock divider, so when doing an asynchronous clock multiplexer switch, glitch may cause LDB divider dead and there will be no clock output to LDB_DIx_IPU, so there will be blank display, any function that needs clock would be impacted.

[ERR004534][ERR004535]

My customer want to check it the their based BSP(jb4.2.2_1.0.0 L3.0.35_4.0.0).

Which part of usb_dr.c should I check?

(Could you tell me the specific line?)

Ans:

ERR004535 USB: USB suspend and resume flow clarifications

The implementation is at:

enter_phy_lowpower_suspend usb_dr.c

The caller is at:

fsl_usb_lowpower_mode drivers/usb/host/ehci-arc.c

dr_phy_low_power_mode drivers/usb/gadget/arcotg_udc.c

ERR004534 USB: Wrong HS disconnection may be generated after resume
func: _host_platform_rh_suspend and _host_platform_rh_resume at usb_dr.c

[ERR007881]

The your answer's code was for recently version (newer than L3.14.28).

So, the code was not found in the older version (L3.0.35).

We confirmed the drivers\usb\otg\fsl_otg.c in version (L3.0.35).

The USB_MODE_STREAM_DISABLE looks setting SDIS = 1 in USBMODE register at line.1199 or line.1862.

May the workaround be judged to be applied only in this description?

If the workaround was lucked, could you tell me the workaround points.

Ans : The patches for it may no be existed at your 3.0.35, the attached (sdis_3.0.x.tar.bz2) are patches for this errata at later 3.0.35 version (I am not sure if they are released)

==================

Best regards,

Jimmy

keitanagashima · ‎06-28-2016

Dear Jimmychan,

Thank you for your reply. Let me confirm below thing again.

===============

[ERR007881]

> Ans : The patches for it may no be existed at your 3.0.35, the attached (sdis_3.0.x.tar.bz2)

> are patches for this errata at later 3.0.35 version (I am not sure if they are released)

The attached patch (sdis_3.0.x.tar.bz2) looks same the patch for ERR006308.

Refer to below link about the patch for ERR006308.

"http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.1.0&id=2890c34e82..."

Q1.

Does this patch (sdis_3.0.x.tar.bz2) correspond to both of ERR007881 and ERR006308?

Q2. (If Q1's answer is "yes", please check the Q2.)

The below description was seen in ERR007881(Device mode) of i.MX6DQ Chip errata (Rev.6).

Implementing the workaround shown will prevent receive FIFO overruns, but cause a 10%-30% impact to USB performance.

But, the ERR006308(Host mode) wasn't seen the description about performance impact.

May the influence of the patch be only ERR007881 (Device mode)?

============

Best Regards,

Keita

jimmychan · ‎07-07-2016

A1. Yes , one patch for two errata.

A2.

I'm not sure if I really understood the question. But if I do, I understand the 10%-30% is a theoretical USB performance, it does not mean we actually measured all the aspects of USB transfers.

I recommend customer to test the actual USB performance in his custom board.

keitanagashima · ‎07-07-2016

Dear jimmychan ,

I have additional questions about other errata.

Please check below again.

(Sorry for my a lot of questions...)

======

[ERR004308]

1. Why does NXP not implemented the workaround in the BSP?

The Projected Impact is "Overflow of the packet FIFOs."

2. Is there possibility that a sound is broken occurs?

3. How frequency does the issue occur?

[ERR004324]

There is description of "Users should ensure their tool chain has the recommended workaround".

But, the toolchain is provided from NXP with binary.

1. From which version does it support?

2. If not supporting it, should the user be careful when creating their program?

[ERR005386]

1. Why does NXP not implemented the workaround in the BSP?

======

Best Regards,

Keita

jimmychan · ‎07-13-2016

I got the update from expert:

[ERR005386]

1. Why does NXP not implemented the workaround in the BSP?

As the description in errata document, linux community does NOT incorporate a workaround this this errata, and we always follows linux community for such ARM common feature.

[ERR004308]

In fact we have add the software workaround with ERR005173.
In mxc_hdmi.c driver, the function mxc_hdmi_clear_overflow() is called by mxc_hdmi_setup(),
and FC_INVIDCONF register is been write three-four time.

[ERR004324]

ARM has provided some more deatils on this erratum which you may have already read:
http://infocenter.arm.com/help/topic/com.arm.doc.uan0004a/UAN0004A_a9_read_read.pdf
We tried contacting the GCC tool chain folks to see if they have implemented the ARM recommended workaround to avoid the potential issue.
We did not receive any formal feedback and further research in the community does not indicate any formal patch was accepted although one was proposed:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00714.html
Linaro seems to alos have a proposal but does not seem to be accepted (in a dev branch)
https://github.com/biomimetics/ros-linaro-distro/blob/master/tbb-dev/tbb40_20120613oss-0002-ARM-supp...
So here are our some conclusions:
Customer can implement the ARM recommend workaround or patch above manually - we suspect a significant performance degradation
Customer can try the patch above, which seems was never accepted
We are unaware of any direct issues or known ways to repro this rare errata - if there was we would have seen a formal adoption by the community or ARM
So as you can see this is a complicated issue which has not gotten much adoption from the community or ARM, both of which have not really provided NXP any guidance on alternate workarounds.
Hope this helps

For the "we suspect a significant performance degradation" I want to make sure there you understand there is no study on how significant the degradation may be. We have never formally tested this approach, so please consider it as only a warning on performance issues if any.

jimmychan · ‎05-10-2016

I think you can search it in the git.freescale.com

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.1.0

For example: the errata for 754322, I used 'mmu translations' to serach.

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.1.0&qt=grep&q=mmu+tr...

the errata for 764369, I used 'mva' to search

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.1.0&qt=grep&q=mva

keitanagashima · ‎06-06-2016

Hi Jimmychan,

Do you have any update?

Best Regards,

Keita

jimmychan · ‎06-07-2016

I had asked the expert and waiting for the reply. I will let you know when I get the answer.

keitanagashima · ‎06-09-2016

Hi jimmychan,

Were you able to get the answer from expert team?

Best Regards,

Keita

jimmychan · ‎06-12-2016

Hi Keita,

Internal ticket has been created and asking R&D team now.

keitanagashima · ‎06-02-2016

Hi Jimmychan,

Thank you for your information! And I found a lot of patches.

But, I couldn't find the below patches.

Does the following workaround exist as the patch?

==============

ERR009219, CCM: Asynchronous clock switching cancause unpredictable behavior [i.MX 6Dual/6Quad Only]