I have created a custom cape for a 24-bit LCD and am having trouble getting the upper bits (>16) to work. I have disabled the HDMI and on board eMMC. The panel comes up but is not showing all 24-bit color.
Where can I find full descriptions of the data entered into a Devcie Tree. I have searched for a technical reference document an cannot find one (does it need to be BBB specific?)
Here is what I am using:
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <24>;
fdd = <0x80>;
tft-alt-mode = <0>;
stn-565-mode = <0>;
mono-8bit-mode = <0>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
invert-pxl-clk;
should be 24-bit output. What does fdd mean? I’m assuming bpp is in decimal and somehow getting written to the correct register.
Ok, so I found out that fdd is the dma delay and also found the errata on 24-bit color to lcd pin mappings. That explains the colors being wrong. Still trying to find out why I can’t change to 24-bit using the device tree.
Any ideas?
Brian
What video driver are you using? The tlcdc code uses a fixed 16 bits.
I based it off the LCD4 dt. It I am reading this right, it uses the tilcdc driver. The LCD4 is supposed to be a 24-bit panel, but they are connecting it at 18-bit.
Where can I find a list of lcd drivers built in? I’ve had to resort to reading the code to firgure out some of the definitions used. I can’t find a list of drivers. Thanks for the help, Brian
/* Settings for NHD-4.3-ATXI#-T-1 / LCD4 cape: /
panel {
compatible = “tilcdc,panel”;
pinctrl-names = “default”;
pinctrl-0 = <&bone_lcd4_cape_lcd_pins>;
panel-info {
ac-bias = <255>; / AC Bias Pin Frequency /
ac-bias-intrpt = <0>; / AC Bias Pin Transitions per Interrupt /
dma-burst-sz = <16>; / DMA burst size /
bpp = <24>; / Bits per pixel, was 16 needs to be 100b in register*/
fdd = <0x80>; /* FIFO DMA Request Delay /
tft-alt-mode = <0>; / TFT Alternative Signal Mapping (Only for active) /
stn-565-mode = <0>; / 12 Bit Per Pixel (5-6-5) Mode (Only for passive) /
mono-8bit-mode = <0>; / Mono 8-bit Mode: 1=D0-D7 or 0=D0-D3 /
sync-edge = <0>; / Horizontal and Vertical Sync Edge: 0=rising 1=falling /
sync-ctrl = <1>; / Horizontal and Vertical Sync: Control: 0=ignore /
raster-order = <0>; / Raster Data Order Select: 1=Most-to-least 0=Least-to-most /
fifo-th = <0>; / DMA FIFO threshold /
invert-pxl-clk; / Invert pixel clock */
};
display-timings {
native-mode = <&timing0>;
timing0: 480x272 {
hactive = <480>;
vactive = <272>;
hback-porch = <44>;
hfront-porch = <9>;
hsync-len = <5>;
vback-porch = <13>;
vfront-porch = <4>;
vsync-len = <10>;
clock-frequency = <65000000>;
hsync-active = <0>;
vsync-active = <0>;
};
};
};
TILCD will only use 16 pins for data. If your LCD display needs 24 bits in one cycle, then you can’t do 24bit. If it can take 2 cycles and combine the 2 16 bit frames into 1 24bit frame then you may be in good shape - but I don’t know if tilcd is capable of sending 24bits of data in that manner.
I found that in am335x-evm.dts they use lcdc driver in 24bit mode. In this case you must disable TI LCDC driver in linux kernel configuration (this driver replaces lcdc driver) and modify dts for beaglebone :-).
W dniu środa, 9 października 2013 04:20:46 UTC+2 użytkownik bdwi...@gmail.com napisał:
Is this still true? Looking in the source (from http://lxr.free-electrons.com/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c) I see that it supports bpp=24 “if (priv->rev == 2)”, so I’m hoping that this has been corrected. I’m using the tilcdc in the 3.8.13-bone50 kernel from the Debian distribution. Can anyone tell me how to check the version of tilcdc in this kernel vs. the source I mentioned? And how to know if “priv->rev == 2”?
Thanks for the pointer David. I’d reviewed that before, but hadn’t noticed the extra steps at the bottom. Unfortunately, those still don’t get 24 bit video going (per fbset). So, I’m still wondering if anyone knows if the tilcdc in 3.8.13-bone50 kernel is supporting 24 bit modes, or if I need to get a different video driver.
hey,
i am currently working on BBB rev C and i want to interface 16 bit(565 RGB) parallel LCD with the board. how should i configure my BBB to get it working? i know something about device tree overlay but i haven’t found any proper documentation on how to work with LCDs.
it would be great if you can guide me or point me to some proper direction.
On Sat, 15 Jul 2017 22:56:45 -0700 (PDT),
keval4footprints@gmail.com declaimed the
following:
hey,
i am currently working on BBB rev C and i want to interface 16 bit(565 RGB)
parallel LCD with the board. how should i configure my BBB to get it
working? i know something about device tree overlay but i haven't found any
proper documentation on how to work with LCDs.
I'm pretty much guessing from on-line resources, but isn't that the
default condition used for the HDMI chip already, and brought out on P8
27-46. Seems that wiring to those pins with the stock HDMI device tree
settings might be sufficient; just don't also plug something into the HDMI
socket (precaution, if the HDMI chip reading a device configuration might
affect the P8 timings). Concede I haven't seen which pins are assigned to
R, G, or B (nor MSB/LSB)
yeah looks kind a that way , i am actually confused if HDMI is already plug and play then it means HDMI chip is also getting input and that input is my tft lcd requires what if i directly applies that to my tft lcd will it gonna work ?
On Sun, 16 Jul 2017 23:51:09 +0530, Keval Desai
<keval4footprints@gmail.com> declaimed the
following:
yeah looks kind a that way , i am actually confused if HDMI is already
plug and play then it means HDMI chip is also getting input and that input
is my tft lcd requires what if i directly applies that to my tft lcd
will it gonna work ?
Page 38 of the SRM
"""
5.13 HDMI Interface
A single HDMI interface is connected to the 16 bit LCD interface on the
processor. The 16b interface was used to preserve as many expansion pins as
possible to allow for use by the user. The NXP TDA19988BHN is used to
convert the LCD interface to HDMI and convert the audio as well. The
signals are still connected to the expansion headers to enable the use of
LCD expansion boards or access to other functions on the board as needed.
"""
The last sentence seems to apply...
okay i am going to try it today and let you know how it turns out!
okay i tried it and unfortunately it didn’t work , all pin from 27-46 were on mux 0 mode which they should be to get lcd working . i think there should be some configuration i need to do in some file. anyone have any idea about that? what should i do apart from just setting pins???
And yeah i did not touch HDMI plug at all during this process.
On Tue, 18 Jul 2017 10:41:49 +0530, Keval Desai
<keval4footprints@gmail.com> declaimed the
following:
okay i tried it and unfortunately it didn't work , all pin from 27-46 were
on mux 0 mode which they should be to get lcd working . i think there
should be some configuration i need to do in some file. anyone have any
idea about that? what should i do apart from just setting pins???
And yeah i did not touch HDMI plug at all during this process.
You're now at the stage where someone just remotely researching
documentation won't help... Sorry.
Only steps I could think of would be to: 1) verify you have a graphical
environment by using the HDMI connection to a monitor/TV without the LCD
connected [the last time I tried I think the screen was black, and only a
right-click context menu was available]; 2) {hoping the HDMI display
configuration is mostly handled by the framer chip and doesn't feed data
back to the main processor/graphics unit} repeating the HDMI test /with/
the LCD in parallel, since the chip and the LCD should be seeing the same
data stream.