MIPI-DSI panel (ILI9881C) stays in reset - no dedicated RESET pin in OSM DISP interface, need GPIO_B_6 confirmation

Hi @All,

Platform / Software

--------------------

- Module: FS 8ULP OSM-SF, HW Rev 1.10

- Yocto/BitBake, linux-fus kernel 6.6.129-F+S

- Panel: Midas MDT0500B1IH-MIPI, 5", 720x1280, ILI9881C controller,

4 MIPI-DSI data lanes + clock, using upstream "bananapi,lhr050h41"

compatible/descriptor in panel-ilitek-ili9881c.c (62 MHz pixel clock,

matches our panel exactly)

What is confirmed working

--------------------------

- DSI host (nwl-dsi) attaches successfully: "lanes=4, format=0x0 flags=0x4"

- imx-dcnano DRM/KMS initializes, framebuffer device is created

(720x1280, correct resolution)

- Panel driver (ili9881c-dsi) probes successfully (no GPIO/probe errors)

- Display VDD and backlight power rails are active at the correct 3.3V

(confirmed via /sys/kernel/debug/regulator/regulator_summary)

- Backlight itself turns on correctly

The problem

-----------

Despite all of the above, the panel never displays an image - only the

backlight is visible. Kernel log shows repeated:

nwl-dsi 2db00000.dsi: [drm:nwl_dsi_host_transfer] *ERROR* [FF] DSI transfer timed out

nwl-dsi 2db00000.dsi: [drm:nwl_dsi_host_transfer] *ERROR* [10] DSI transfer timed out

Direct hardware measurement at the panel's RESET pin shows 0V after

boot, even though the SoC-side GPIO used for reset is confirmed (via

/sys/kernel/debug/gpio) to be correctly driven HIGH (deasserted) by the

kernel driver during ili9881c_prepare(). Since the ILI9881C stays in

hardware reset, it cannot acknowledge any DSI command, which explains

the transfer timeouts.

Per your FS 8ULP OSM-SF hardware manual (Table 18, DISP pin

description), the MIPI DSI interface does not define a dedicated RESET

pin - only DATA0-3, CLK, DSI_TE, DISP_VDD_EN, DISP_BL_EN and

DISP_BL_PWM. Our carrier-level schematic repurposes a generic OSM GPIO

for the panel's RESET line. Cross-referencing your ADP-OSMBB2 hardware

manual (Table 4, Connector J1), J1 pin 7 = GPIO_B_6 (OSM pin K19 / SoC

pad PTF30), which is what we are currently driving as reset-gpios in

our devicetree:

reset-gpios = <&gpiof 30 GPIO_ACTIVE_LOW>;

Questions

---------

1. Is GPIO_B_6 (K19/PTF30) a plain, unreserved general-purpose GPIO

with no special pinmux/power-domain sequencing requirement, or does

it require anything beyond the standard pinctrl_gpiof group already

present in fs-osm-sf-mx8ulp.dtsi?

2. Is there a recommended/reference power-up sequencing order between

DISP_VDD_EN, DISP_BL_EN and a customer-wired MIPI panel RESET line

(e.g. minimum delay after VDD before releasing reset)?

3. Do you have a reference devicetree/example for driving a generic

MIPI-DSI panel's RESET signal from one of the OSM GPIO_B/C pins on

this module, since the official DISP interface table doesn't

include one?

4. Is it possible that GPIO_B_6 is also used/reserved internally on

the ADP-OSMBB2 for anything else (similar to how we found GPIO_B_7

is consumed internally for the onboard Ethernet PHY reset)?

Any guidance would be greatly

appreciated.

Thank you for the detailed reply.

Update after implementing your feedback

-----------------------------------------

We set reset-gpios to GPIO_B_6 (gpiof bit 30 / PTF30) as confirmed in

your ADP-OSMBB2 hardware manual (Table 4, Connector J1, pin 7 =

GPIO_B_6). After rebuilding and booting:

- Direct voltage measurement at the panel's RESET pin now correctly

reads 3.3V (deasserted) after boot - previously it measured 0V

with our earlier (incorrect) GPIO choice.

- /sys/kernel/debug/gpio confirms the pin is correctly requested and

driven: "gpio-670 (GPIO_B_6 | reset) out hi ACTIVE LOW"

However, the panel still does not display any image (backlight only),

and the kernel log still shows the same repeated errors:

nwl-dsi 2db00000.dsi: [drm:nwl_dsi_host_transfer] *ERROR* [FF] DSI transfer timed out

nwl-dsi 2db00000.dsi: [drm:nwl_dsi_host_transfer] *ERROR* [10] DSI transfer timed out

ili9881c-dsi 2db00000.dsi.0: Skipping enable of already enabled panel

One open item from your previous reply: could you confirm whether

"BBDSI" (point 4, GPIO_B_2 at J1 Pin 7) refers to the same

ADP-OSMBB2 carrier we are using, or a different F&S reference

baseboard? Your ADP-OSMBB2 hardware manual states J1 pin 7 =

GPIO_B_6, which appears to conflict with that answer, and we want to

make sure we are not missing a second, different pin.

Current configuration

----------------------

- Panel: Midas MDT0500B1IH-MIPI, 5", 720x1280, ILI9881C, 4 MIPI-DSI

data lanes + clock (full pin list per attached datasheet: VCI,

IOVCC, RESET, TE, 4x DATA differential pairs, CLK differential

pair, LED+/-, GND, NC - no other control pin, no standby line).

- Devicetree (panel node):

compatible = "bananapi,lhr050h41", "ilitek,ili9881c";

power-supply = <&reg_disp_vdd_en>;

backlight = <&backlight_dpi>;

reset-gpios = <&gpiof 30 GPIO_ACTIVE_LOW>; /* GPIO_B_6 */

width-mm = <62>;

height-mm = <110>;

- Using the driver's built-in "bananapi,lhr050h41" descriptor as-is

(720x1280, 62 MHz pixel clock, 4 lanes) - unmodified from upstream.

- Panel/backlight power rails confirmed active at the correct 3.3V

via /sys/kernel/debug/regulator/regulator_summary.

- DSI data lane and clock continuity + correct N/P polarity confirmed

along the full physical path (module -> carrier -> our adapter

board -> display connector).

What we would like your input on

----------------------------------

1. Are there any i.MX8ULP MIPI D-PHY specific timing parameters

(e.g. T-CLK-PREPARE, HS/LP transition timing, escape-mode clock

rate) that may need board- or cable-length-specific tuning beyond

what the generic nwl-dsi/mixel-dphy drivers configure by default?

2. Are you aware of any i.MX8ULP DSI D-PHY erratum or known issue

(similar in nature to the FSGPIO parametric-shift erratum

documented for your module) that could cause the host to report a

sent transfer while the panel never acknowledges it?

3. Do you have a verified reference devicetree/kernel configuration

for any customer running a third-party MIPI-DSI panel (not one of

your own EE0350ET/BT070L reference panels) on the OSM-SF-MX8ULP +

ADP-OSMBB2 combination, that we could compare our DSI PHY/timing

configuration against?

4. Do you have any guidance on maximum permissible cable/trace length

or differential-pair length-matching tolerance for extending the

MIPI DSI signals beyond the module/carrier to an external display

connector? We want to confirm whether our current cable

construction is within acceptable electrical limits for reliable

HS signaling.

We are confident the reset, power, and devicetree/software

configuration are all correct at this point (verified against your

documentation, the upstream kernel driver, and direct hardware

measurement) - we are trying to determine whether the remaining

gap is in DSI PHY timing/configuration on our side, or purely in the

physical cable/connector construction, and would appreciate any

guidance you can offer either way.

Thank you again for your help.

Please refer mentioned Midas 5inch MIPI display Spec Connection details and SoM to Display connections straight 1:1

Hello F&S Elektronik Systeme GmbH,

Thank you for your suggestion regarding possible DCNANO PLL clock rate and PixelCLK related issues.

We investigated this area and would like to share our current findings and debugging results.

Platform

• F&S OSM-SF-MX8ULP
• Linux 6.6.129
• MDT0500B1IH-MIPI
• ILI9881C controller
• 720 x 1280 resolution
• 4-lane MIPI-DSI

DCNANO Investigation

You asked whether we see any DCNANO related errors such as: failed to find pll clock rate

We checked the kernel logs and do not see PLL-related or DCNANO clock-related errors.:

[drm] Initialized imx-dcnano
fb0: imx-dcnanodrmfb frame buffer device

Driver Verification

strings /proc/kallsyms | grep mdt0500:
output:

mdt0500b1ih_desc

mdt0500b1ih_default_mode

mdt0500b1ih_init

Device Tree

compatible = "midas,mdt0500b1ih-mipi", "ilitek,ili9881c";

reset-gpios = <&gpiof 30 GPIO_ACTIVE_LOW>;

data-lanes = <1 2 3 4>;
we also tested

data-lanes = <0 1 2 3>;

DRM State

cat /proc/fb: 0 imx-dcnanodrmf

cat /sys/class/graphics/fb0/modes: U:720x1280p-0

cat /sys/class/graphics/fb0/virtual_size: 720,1280

DRM State reports

connector DSI-1

active=1

mode=720x1280

rotation=1

Current Mode

clock = 76400

hdisplay = 720

hsync_start = 740

hsync_end = 744

htotal = 749

vdisplay = 1280

vsync_start = 1300

vsync_end = 1304

vtotal = 1324


Pannel Readback:

Midas readback:

ID=00:00:00 power-mode=00 diagnostic=00

Midas readback:

ID=00:00:00 power-mode=9c diagnostic=c0

Framebuffer Tests

We performed direct framebuffer testing.

Black framebuffer:

dd if=/dev/zero of=/dev/fb0 bs=3686400 count=1

Result:

White framebuffer:

yes | tr '\n' '\377' | dd of=/dev/fb0 bs=3686400 count=1

Result:

Random framebuffer:

cat /dev/urandom > /dev/fb0

Result:

These tests indicate that pixel data is reaching the panel and the panel is reacting to framebuffer contents.

fbcon Test

Framebuffer console was attached using:

echo 1 > /sys/class/vtconsole/vtcon1/bind

Kernel reports:

Plain Text 1 Console: switching to colour frame buffer device 90x80

Display content changes when fbcon is attached.

However, text is still not rendered correctly.

Additional Software Tests Already Performed

We have also tested:

• Different DSI mode flags
• Different PixelCLK and timing configurations
• Different MADCTL values
• Different DSI lane numbering definitions
• MDT0500 initialization sequence provided by Midas
• Alternative ILI9881C panel profiles already present in the driver

The resulting display behaviour remains broadly similar.

Current Observation

The display clearly receives and displays framebuffer data.

We can generate black, white and random display patterns successfully.

However, valid text and graphics are not rendered correctly. Instead we observe horizontal stripe artefacts and corrupted image structures.

Questions

1. Do you still suspect the current PixelCLK value (76.4 MHz), based on the above behaviour?
2. Do you have a validated PixelCLK/timing configuration for a native 720x1280 MIPI display on OSM-SF-MX8ULP?
3. Has the ILI9881C driver been validated by F&S on actual OSM-SF-MX8ULP hardware?
4. Which native MIPI displays have been successfully tested by F&S with this BSP?
5. Do you have a known-good 5-inch MIPI 720x1280 ILI9881C panel configuration that we could use for comparison?

Based on the tests above, it appears that DRM, framebuffer operation, DSI communication and panel initialization are functioning. We are trying to determine whether the issue is related to display timing, PixelCLK configuration, panel-specific source/gate mapping, or a panel revision difference.

Kind regards,

Srinadh T

Hello F&S Elektronik Systeme GmbH,
We have completed additional investigation of the MDT0500B1IH-MIPI display on our i.MX8ULP platform and would appreciate your feedback.

Hardware/Software

• F&S OSM-SF-MX8ULP
• Linux 6.6.129
• NWL MIPI-DSI host
• MDT0500B1IH-MIPI
• ILI9881C
• 4-lane RGB888

BIST Verification

We enabled the ILI9881C internal BIST mode as described in the datasheet.

Result:

• Vertical colour-bar pattern displayed correctly across the complete panel
• No distortion observed

Readback during BIST:

power-mode=10 2 diagnostic=01 3

This appears to confirm:

Normal Operation

After disabling BIST:

power-mode=9c 2 diagnostic=c0

We can successfully observe:

Therefore the DRM pipeline and DSI link appear active.

Driver Configuration

Confirmed:

dsi->format = MIPI_DSI_FMT_RGB888; 2 dsi->lanes = 4; 3

Mode Flag Testing

Tested:

VIDEO | VIDEO_BURST 2

Result:

NWL-DSI reports:

flags=0x3

Tested:

VIDEO | VIDEO_BURST | LPM 2

Result:

NWL-DSI reports:

flags=0x803

Tested:

VIDEO | VIDEO_SYNC_PULSE

Result:

NWL-DSI reports:

flags=0x5

Timing Testing

Pixel clock:

76400 -> partial recognizable image 2 70000 -> same result 3 62000 -> no display 4 `

Horizontal porch changes also did not significantly alter the symptom.

Current Observation

The panel is clearly receiving video data, however graphical content appears duplicated and corrupted.

Since:

• BIST is successful
• RGB888 is confirmed
• 4-lane operation is confirmed
• Multiple timing and mode-flag experiments have been performed

we would appreciate any guidance regarding known NWL-DSI/i.MX8ULP specific requirements or any host-side configuration that may affect packet formatting or video transmission for ILI9881C-based panels.

Kind regards,

Srinadh T