LVDS change MEDIA BLK_CTRL

Technical Support
, , , ,
1

Hello Toradex team,

I hope you are all doing great and you had a good time at Embedded World !

Hardware:

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.129-6.5.0+git.6f8fd49366db #1-TorizonCore SMP PREEMPT Fri Dec 22 11:15:52 UTC 2023
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d9775fd5577822ec4e9d6473745ca17c46edd81fc5d56864931253b6cc6414eb/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.5.0-build.8
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-14777575
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 iMX8M Plus on *** Board
Toradex version:          0058 V1.1A
Serial number:            14777XXX
Processor arch:           aarch64
------------------------------------------------------------

Images tested:

  • torizon-core-docker-verdin-imx8mp-Tezi_6.5.0+build.8.tar (STABLE Release)

Guest OS:

  • macOS (M1 Pro ARM64)
  • Linux ubuntu (VM x86_64)

Issue:

We are trying to pass the EMI test and it seems that our LVDS display is the one blocking us to pass the test. The CLK is to fast and we want to tweak it by changing the MEDIA BLK_CTRL.

Based on the i.MX 8M Plus Applications Processor Reference Manual that I downloaded on NXP, those values can be modified but I don’t understand how those can be achieve in my dts.

I have found the definition of media_blk_ctrl in the imx8mp.dtsi and this is used as clock by lcdif2 used by LVDS display. So far so good. But the clock seems off in the register used:

...
clocks = <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_PIXEL>,
		       <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_AXI>,
		       <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_APB>;
...

image001
image0011078×747 85.4 KB

So my question is, do you have an idea how I can change the value of those clocks to reduce the spike in the signal ? This is beyond my small expertise in device-tree, so if you can guide me a bit that would be very nice !

Thank you in advance.

Best regards,
M

2

Hello @unablesalt,

The best would be to send us the schematic first and set up a design review call.
We offer the free how-to-design a carrier board call, and we usually check issues like that upfront.
We also offer design reviews. very often the emission has to do with GND and shielding problems.

Best Regards,

Matthias Gohlke

3

Hello @matthias.tx,

We already did a design review together.

It seems that the shielding is not enough, that’s why we want to try updating the CLK settings.

Best,
M

4

Hello Again,

So we would like to change the value for the register: LVDS_CTRL, that can be found in the section: 13.2.3.1.41 LVDS Control Register, from MEDIA BLK_CTRL.

I checked online and it seems that other people complains about the way that NXP design it and make it hard to change the value of the CLK. So did any of you had to update this value and/or experience working with the MEDIA BLK_CTRL ?

Thanks in advance!

Best regards,
M

5

ok, I check internally how to set up the LVDS Spread spectrum clock. That should help.

Best Regards,

Matthias Gohlke

1 Like
6

Hi @unablesalt !

Just to be sure: are you using native LVDS interface from Verdin iMX8MP or LVDS from DSI interface (therefore using DSI-LVDS adapter as well)?

Anyway, we do not have a ready-to-use approach for Spread Spectrum for neither of the interfaces and we will try to check with NXP if they can help us with it. Enabling it might involve changes on ATF and U-Boot.

In the past we managed to get a set of patch to enable Spread Spectrum on DRAM clock for Verdin iMX8M Mini for a customer that needed it and it became an article in Toradex Developer: Enable Spread Spectrum Clocking on the DDR Interface | Toradex Developer Center. As you can see, it is needed to use Yocto to build the image (in your case, Torizon OS) to enable this feature.

It is important to notice: enabling Spread Spectrum is not something that will impact only the interface that you need, but it will be performed on a PLL that also serves as root/parent clock for other interfaces/devices. Therefore, when you apply such patch, you will need to perform tests on your system to be sure that it is behaving accordingly.

Best regards,

1 Like
7

Hello @henrique.tx,

I realize that I missed your message, sorry!

For the first point, we are using native LVDS interface directly from the SOMM, nothing in between.

As for the LVDS_CTRL, we just want to be able to change the value for SLEW_ADJ not the spectrum. (See 13.2.3.1.41 LVDS Control Register (LVDS_CTRL).

It might be a bit easier to do ? Or is it related to the u-boot too ?

We can resume the situation as follow: Everything should be made as simple as possible, but not simpler :wink:

Thanks in advance for your help :grin:

Best Regards,
M

8

Hi @unablesalt !

Sorry for the delay.

Usually, changing a specific register is not straight forward due to the interactions between U-Boot, Linux, ATF, etc…

But I would like to ask some more broad questions, if that is ok.

Could you please share a bit more on how it was found out that LVDS is indeed the culprit?

In the mean time, I am checking internally if we have anything related to LVDS customization.

Best regards,

9

Hello @henrique.tx,

Thank you for taking the time to help us!

So we went to the lab to take the EMC test and we realize that the data related to the LVDS are the guilty one as you can see in the image bellow:

e6a459ab-3224-449d-b10e-154ceae54f94
e6a459ab-3224-449d-b10e-154ceae54f941135×802 170 KB

At first we thought it was the cable, but it’s completely shield and connected to the ground so we don’t think that the cable is responsible.

We are still looking for alternatives, but it we really want to be able to change this value to test it.

Keep me updated on the response you will receive internally.

Best regards,
M

10

Hi @unablesalt !

Thanks for sharing more details :slight_smile:

Here I am sharing an approach that you can use before diving into driver customization (which might be needed). This is based on @stefan_e.tx’s idea :slight_smile:

Tool to be used: devmem2

You can try to modify the SLEW_ADJ on Linux during runtime by using devmem2. This devmem2 allows you to change physical addresses during runtime. Full disclosure: there might be some gotchas when using it, but I hope it will just work.

You can manually build it using a cross toolchain (quite simple to do it) and copy to your module. You will need to execute it using sudo.

I built it and I am sharing the resulting ARM64 cross-compiled executable here. But remember that executables are just like candy: you should not accept them from strangers :wink:

devmem2 (18.4 KB)

For testing, you can use this directly on the host OS (no need for container).

Making sure that the address is accessible

As you are going to manipulate a register related to native LVDS, please be sure to have it enabled. In my case, I simple enabled it by activating the overlay verdin-imx8mp_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo (reference: Setting up Displays with Torizon | Toradex Developer Center). You can use the same approach if needed.

Manipulating LVDS_CTRL’s field SLEW_ADJ

image
image1063×543 31.4 KB

According to the i.MX8MP Reference Manual, the base address for MEDIA_BLK_CRTL is 0x32EC000. The SLEW_ADJ is defined by the bits 14-16 of the LVDS_CTRL register, which has an offset of 0x0128 (table from section 13.2.3.1.1 Memory map, and diagram tables from section 13.2.3.1.41 LVDS Control Register (LVDS_CTRL)).

Therefore we must use the address 0x32EC0128 with devmem2:

$ sudo ./devmem2 0x32ec0128
Password:
/dev/mem opened.
Memory mapped at address 0xffffb1959000.
Read at address  0x32EC0128 (0xffffb1959128): 0x00000005

From the output, we can see that SLEW_ADJ (which refers to bits 14-16) has a value of zero. Unfortunately, seems like NXP has no information about what the values for LVDS_CTRL’s meaning (therefore nothing for SLEW_ADJ as well): Solved: Re: i.MX8MP undocumented LVDS_CTRL - NXP Community

As SLEW_ADJ is zero by default, you might want to try its highest possible value (which is 0x7), or maybe half (0x3 or 0x4). At the same time, you should keep the other fields of LVDS_CTRL the same. In my case here, since LVDS_CTRL has 0x5, I will write 0x1C005. The w in the command means I am dealing with data of word size (it doesn’t mean write :stuck_out_tongue: ).

$ sudo ./devmem2 0x32ec0128 w 0x0001c005
Password:
/dev/mem opened.
Memory mapped at address 0xffffa8e8f000.
Read at address  0x32EC0128 (0xffffa8e8f128): 0x00000005
Write at address 0x32EC0128 (0xffffa8e8f128): 0x0001C005, readback 0x0001C005

$ sudo ./devmem2 0x32ec0128
/dev/mem opened.
Memory mapped at address 0xffffbcef0000.
Read at address  0x32EC0128 (0xffffbcef0128): 0x0001C005

After doing this, you can perform the EMI test and hopefully the outcome will be better.

Remarks about the devmem2 approach

The modification done here is not persistent after reboot. So, if necessary, you need to execute the modification again after a reboot.

Also, please keep in mind that there is a driver taking care of the registers. This means that even if you manually modify registers, the driver might also modify them, so keep an eye on its value during your tests. You can use devmem2 to read the value.

Please let us know how it goes.

Best regards,

1 Like
11

Hello @henrique.tx,

Whaou! Thank you for this amazing answer!

I’ll run a test ASAP and keep you updated on the result, and hopefully we can find the solution to the EMI problem.

Have a good weekend!

Best,
M