Hi @Konstantin ,
I definitely agree if you submit the code upstream.
My name is Marco Cavallini, my email m.cavallini AT koansoftware.com
Good luck!
Hi @Konstantin ,
Would you be able to share with me your ite driver?
I was trying to implement the 01_ite.patch you shared by adjusting it, but without success so far.
Thanks in advance
Hi @tkl the patch provided in a message above by @Konstantin applies perfectly with the latest meta-ti/meta-ti-bsp kernel here
Yes I can, I will attach my ite-it66122.c to this post completely.
This one is directly from a vanilla 6.12.57 I tested this out with and with that one I did the first test runs.
@Koan stands correct, my patches I posted earlier are pulled from my yocto layer which utilises the meta-ti kernel. But this file here is from vanilla 6.12.57 I created the yocto modification with.
This should … compile and run!
ite-it66121.c (62.9 KB)
Thanks guys for your support! Appreciate it!
I was able to compile and adjust the driver. It works now without this annoying purple line on the left side of the screen, even the graphics still not 100%. I’m in contact with Seeed Technology Co., Ltd (manufacturer of this PCB), and they promised me to push beagle board to solve this in an appropriate way.
Thanks again!
@tKL laughs, those emails to Seeed just go in a loop with the rest of us here! Can you share with everyone what LCD Pavel you are using… Please be a orderable link.
Found it, https://www.digikey.com/en/products/detail/matrix-orbital/HTT70A-TPC-BLM-B0-H5-CH-V5/7932528. I’ll add it my order test list
Regards,
Exactly, that’s the link for the LCD panel I’m using.
and ordered! fingers crossed i should get it monday..
Edit, no dice today, working from home tomorrow, fingers crossed i can grab it wednesday.
Regards,
Well, now I am confused.
I am still trying to figure out how to find a minimal set of the codechange which helps our display, to prepare something sending to upstream.
But the initial code is from @Harshkumar so he needs to agree to this being put upstream or thinking about that, or am I confused now?
As said, I have a low time budget on doing this, but still I am trying to find out and prepare an upstream commit.
Regards, Konsti
I did fix purple line for YTS700tlbf-21-100c from Anders through my original fix.
I remember that someone from TI was refactoring ITE driver in Dec 2025 and which is mentioned in this thread.
@Konstantin and I had shared the working patch and driver files in this thread so at least my understanding is, TI and BBB.org engineering team work together and find the best minimal solution with their refactored driver by taking reference of our changes.
Also verify with shared LCD parts before upstream.
@Konstantin It would be great if you can share your LCD part as well.
Thanks
A huge tilcdc refactor went into 7.0-rcX, right now display is ‘completely’ broken for IT66121 and IT66122
voodoo@BBB-ECO:~$ dmesg | grep -E "drm|it66121"
[ 0.101101] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 0.101231] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 0.101896] /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 0.972886] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 0.973013] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 0.973580] /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 1.203726] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 1.203851] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 1.205797] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 1.205904] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 1.208259] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 1.208377] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 1.254697] /connector-hdmi: Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 1.255064] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 1.255161] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with /connector-hdmi
[ 1.359171] /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 1.363879] /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 1.365248] /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0
[ 1.365504] /ocp/interconnect@48000000/segment@300000/target-module@e000/lcdc@0:
Fixed dependency cycle(s) with
/ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
[ 23.494981] systemd[1]: Starting modprobe@drm.service - Load Kernel
Module drm...
[ 26.634750] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 26.718840] systemd[1]: Finished modprobe@drm.service - Load Kernel
Module drm.
[ 47.935588] it66121 2-004d: supply vcn33 not found, using dummy regulator
[ 48.060121] it66121 2-004d: supply vcn18 not found, using dummy regulator
[ 48.067153] it66121 2-004d: supply vrf12 not found, using dummy regulator
[ 48.290284] it66121 2-004d: IT66121 revision 1 probed
[ 48.988756] [drm:drm_bridge_attach [drm]] *ERROR* failed to attach
bridge /ocp/interconnect@48000000/segment@100000/target-module@9c000/i2c@0/it66121
to encoder None-36: -22
So still stay with v6.18.x/v6.19.x (and earlier) with current hacks, till mainline (v7.0-rcX) has drm_bridge_attach working again..
Regards,
I’ve got another screen that seems like it doesn’t work with the new chip, but works fine with the old.
It’s a Hantronix HDA500PTC-2-SMIO which I think is a custom version of their HDA500PT-HDMI2 which unfortunately I don’t have a link to buy from. It looks like they use a TI TFP401APZP for the display IC.
debian@BeagleBone:~$ dmesg | grep tilcd
[ 5.422695] [drm] Initialized tilcdc 1.0.0 for 4830e000.lcdc on minor 0
[ 5.445596] tilcdc 4830e000.lcdc: [drm] Cannot find any crtc or sizes
[ 5.745080] tilcdc 4830e000.lcdc: [drm] fb0: tilcdcdrmfb frame buffer device
debian@BeagleBone:~$ cat /sys/class/drm/card0-HDMI-A-1/edid | parse-edid
Checksum Correct
Section "Monitor"
Identifier ""
ModelName ""
VendorName "ADA"
# Monitor Manufactured week 1 of 2007
# EDID version 1.3
# Digital Display
DisplaySize 150 100
Gamma 1.00
Option "DPMS" "false"
#Extension block found. Parsing...
I only know about extension blocks of type 02h. PLEASE email me!
Something strange happened. Please contact the author,
Matthew Kern at <pyrophobicman@gmail.com>
I tried setting the video kernel parameter and that got the “Cannot find any crtc or sizes” message to go away but there’s still no output.
For reference the same SD card on a REV C3 board:
debian@BeagleBone:~$ dmesg | grep tilcd
[ 5.306742] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops)
[ 5.314224] [drm] Initialized tilcdc 1.0.0 for 4830e000.lcdc on minor 0
[ 5.432686] tilcdc 4830e000.lcdc: [drm] fb0: tilcdcdrmfb frame buffer device
debian@BeagleBone:~$ cat /sys/class/drm/card0-HDMI-A-1/edid | parse-edid
Checksum Correct
Section "Monitor"
Identifier ""
ModelName ""
VendorName "ADA"
# Monitor Manufactured week 1 of 2007
# EDID version 1.3
# Digital Display
DisplaySize 150 100
Gamma 1.00
Option "DPMS" "false"
#Extension block found. Parsing...
I only know about extension blocks of type 02h. PLEASE email me!
Something strange happened. Please contact the author,
Matthew Kern at <pyrophobicman@gmail.com>
The image I used was from here : Index of /rootfs/debian-armhf-13-base-v6.12/2026-06-03
There’s no purple stripe on this screen so I’m not sure if trying out that patch above would help at all. I’m happy to ship one of our screens for testing if that could help get compatibility working faster.
Any pointers in what direction to investigate would be helpful.
Hahaha!
Finding unsupported screens has turned into a sport for you guys, hasn’t it? 
Well, for my Hantronix screen the issue seems to be that it’s expecting pure DVI but the driver only supports including extra HDMI info that confuses the screen. Bypassing the driver and telling the ITE6122 directly to only send the DVI data gets the screen to behave. I take it no one will be looking at that until the drm_bridge_attach is working on the rewrite?
@RobertCNelson, lately I have seen you refer several times to 7.x.x. Is this a new kernel you are busy with? I ask as I want to make sure that I am at least not falling far behind with my migrate-to-debian13 project.
Best!
Stay on 6.18.x LTS for production (CVE’s etc..)… Lots of things in flight for IT6612x on mainline…
Thanks, I need to hear that. It’s not like I need more to do, this stuff sure kicks some butt.
I am are running into a similar issue with a black screen. Our BBB rev d does not work with some of our displays.
On one our our displays, we are running into the same interrupt storm issue @sugamara ran into. @sugamara did you ever resolve that issue?
I have tried 6.18-bone45, 7.2-rc5-bone6 kernel, 6.12-bone99 (or whatever the latest bone version was) with @Konstantin’s patches applied.
I have isolated the issue to somewhere between the BBB talking to the hdmi framer or the hdmi framer talking to our DVI sink. I’ve attached dmesg logs for rev c and rev d with the same monitor and same sd card and same BBB except for a new hdmi framer (and EMMC, but that’s irrelevant).
dmesg_rev_d.txt (36.1 KB)
dmesg_rev_c.txt (28.3 KB)
We are using a AUO G156XW01 V.3 panel with a Caison LCD controller board. If you want @RobertCNelson we can send you a display.
I am not super familiar with kernel development or displays in general, but there’s a first time for everything. Will be posting my progress on here.
it’ll be interesting to see what bbb.io-kernel-7.2-bone with all the hdmi/dvi changes..