IMX7 LCD display device tree values not matching fbset output

Technical Support
, , , ,
#1

I’m trying to set up a new display working at 1280x800 -16@60

Customization is stil in progress but i’ve already did many tests with something like this:

1280x800 {							
    clock-frequency = <83460000>;
    hactive = <1280>;
    vactive = <800>;
    hback-porch = <200>;
    hfront-porch = <64>;
    vback-porch = <24>;
    vfront-porch = <1>;
    hsync-len = <136>;
    vsync-len = <3>;
    de-active = <1>;
    hsync-active = <1>;
    vsync-active = <1>;
    pixelclk-active = <1>;
 };

No matter what kind of front/back porch or hsync-active (even pixclock) i choose, the output remains the same and when i get settings from fbset i got always the same data:

mode "1280x800-60"
    # D: 83.500 MHz, H: 49.703 kHz, V: 59.811 Hz
    geometry 1280 800 1280 800 16
    timings 11976 200 72 22 3 128 6
    vsync high
    rgba 5/11,6/5,5/0,0/0
endmode

fbset seems responding and so the screen does when i set some params from command line (not for every params)

fbset --left value

Why there’s no clear link between fbset timings and my device tree? maybe dtb has some errors? or what?

P.S: Are resolution and refresh frequency somewhat limitated by this device?

Thanks in advance.
Matteo.

#2

Greetings @Debbio!

fbset should reflect your changes to the device tree. Can you please show me the output of the vidargs environment variable on U-Boot? It could be that U-Boot is not fetching the proper timings you added.

Also, if you’re really using our Linux BSP v2.8b2, I recommend you to update to the latest stable version (2.8.7).

#3

Sorry, i desappeared from the forum for a while, anyway fbset was working, initially we didn’t get that LCD monitor under test had a processing image logic not allowing us to appreciate fbset behaviour.
Thanks.
Matteo.

#4

Hi @Debbio,

So is everything working now?
I think it was a “false alarm”, then :slight_smile:

Best regards,
André Curvello

#5

Hi André, we cannot sense it directly, i can state for sure that our monitor is doing something on his own over image positioning…my opinion now is fbset works.
Thanks for suggesting us to move to 2.8.7, i’ll take into account seriously.

#6

Hi @Debbio,

Thanks for the feedback.

Honestly, we only advise moving to BSP 2.8b7 if your environment is strictly built upon our BSP 2.8 base, and moving to a newer BSP could cause a major impact on your project and your time-to-market.

But, if you have the opportunity, I’d like to suggest you move to BSP 3.0.4 (or BSP 3.0b4), because it’s our current major LTS BSP, and it has a lot more improvements.

Best regards,
André Curvello

#7

I’ m gonna spend a few hours giving a try to bsp 3.

I just need:

  • rtc clock
  • qt 5 + x11
  • m4 rpmsg
  • some basic stuff like eth, uart, sd card
#8

Well, I can say for sure that they are OK for the BSP 3.0.4.

Please let me know if you need any further assistance.

Can I close this issue for the moment?

Best regards,
André Curvello

#9

Bsp 3.0.4 has just passed first round of testing, this is not a complete check up for our platform but it’s enough to let us using new platform for our dev purpouses!
Thank you!

#10

Excellent!

Yes, it’s a start. Good to know.

If you have any other issues, please let us know.

Best regards,
André Curvello