evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 6:05 am

Ok, I've confirmed that the SN65 is just not converting DSI to LVDS for me. It'll happily output the test pattern, but won't do anything for me.

When I enable the test pattern, I see meaningful data from the LVDS data pins:
ima_8db2df2_small.jpeg
ima_8db2df2_small.jpeg (55.58 KiB) Viewed 6680 times
With the test pattern disabled, nothing interesting is output on the A_Y0P/N, etc. pins; just a constant bitstream:
ima_65b5ba0_small.jpeg
ima_65b5ba0_small.jpeg (50.35 KiB) Viewed 6680 times
(Note, different timescale than the previous photo. When zoomed out to the timescale of the previous photo, this would just be a horizontal band.)

This is despite the fact that I can see meaningful data on the DSI data pins: https://www.youtube.com/shorts/1QXPpRTYdVw (this is the `xeyes` command running full-screen, and I've set the holdoff on the scope so it slowly scans the image.)

With either mode (test image enabled or disabled), the LVDS clock is a steady 100MHz. Register E5 is 0x00 during all of this. Can anyone think of a reason the SN65 would refuse to convert DSI to LVDS, but not flag an error in register 0xE5?

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 6:40 am

Code: Select all

sudo cat /sys/kernel/debug/device_component/gpu
What is the output of that command?

Check with "modetest -M vc4 | less" to see if it has brought up DSI as a display.

I've never thrown a modeline on the driver (clock definition is different scale) https://github.com/raspberrypi/linux/bl ... le.c#L4575
so try again when changed to below format (example only! that's the 7in panel from the test pattern picture):

Code: Select all

static const struct display_timing chunghwa_claa070wp03xglvds_timing = {
	.pixelclock = { 66800000, 66800000, 66800000 },
	.hactive = { 800, 800, 800 },
	.hfront_porch = { 16, 16, 16 },
	.hback_porch = { 32, 32, 32 },
	.hsync_len = { 16, 16, 16 },
	.vactive = { 1280, 1280, 1280 },
	.vfront_porch = { 5, 5, 5 },
	.vback_porch = { 2, 2, 2 },
	.vsync_len = { 2, 2, 2 },
	.flags = DRM_MODE_FLAG_NHSYNC |
		 DRM_MODE_FLAG_NVSYNC |
		 DISPLAY_FLAGS_DE_HIGH,
};

static const struct panel_desc chunghwa_claa070wp03xglvds = {
	.timings = &chunghwa_claa070wp03xglvds_timing,
	.num_timings = 1,
	.bpc = 8,
	.size = {
		.width = 94,
		.height = 150,
	},
	.delay = {
		.enable = 200,
		.disable = 110,
	},
	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
	.bus_flags = DRM_BUS_FLAG_DE_HIGH,
	.connector_type = DRM_MODE_CONNECTOR_LVDS,
};

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 15329
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 8:09 am

evankrall wrote:
Fri Jul 15, 2022 6:05 am
Ok, I've confirmed that the SN65 is just not converting DSI to LVDS for me. It'll happily output the test pattern, but won't do anything for me.
How many data lanes are you running? 2 &3 seem to work, but not 4.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 11:38 am

6by9 wrote:
Fri Jul 15, 2022 8:09 am
evankrall wrote:
Fri Jul 15, 2022 6:05 am
Ok, I've confirmed that the SN65 is just not converting DSI to LVDS for me. It'll happily output the test pattern, but won't do anything for me.
How many data lanes are you running? 2 &3 seem to work, but not 4.
2-lane is fine for XGA, 3-/4-lane will give better EMI performance - which should not be an issue for such a DIY approach anyhow (as one will never measure to see if the DIY device is within any limits).

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 5:39 pm

aBUGSworstnightmare wrote:
Fri Jul 15, 2022 6:40 am

Code: Select all

sudo cat /sys/kernel/debug/device_component/gpu
What is the output of that command?

Code: Select all

meatmanek@cm4:~ $ sudo cat /sys/kernel/debug/device_component/gpu
master name                                            status
-------------------------------------------------------------
gpu                                                     bound

device name                                            status
-------------------------------------------------------------
fe400000.hvs                                            bound
fef00700.hdmi                                           bound
fef05700.hdmi                                           bound
fe700000.dsi                                            bound
fe004000.txp                                            bound
fe206000.pixelvalve                                     bound
fe207000.pixelvalve                                     bound
fe20a000.pixelvalve                                     bound
fe216000.pixelvalve                                     bound
fec12000.pixelvalve                                     bound
aBUGSworstnightmare wrote:
Fri Jul 15, 2022 6:40 am
Check with "modetest -M vc4 | less" to see if it has brought up DSI as a display.
I see this in the modetest output:

Code: Select all

46      45      connected       LVDS-1          210x164         1       45
  modes:
        index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
  #0 1024x768 59.98 1024 1284 1604 2084 768 784 794 800 100000 flags: ; type: preferred, driver
  props:
aBUGSworstnightmare wrote:
Fri Jul 15, 2022 6:40 am
I've never thrown a modeline on the driver (clock definition is different scale) https://github.com/raspberrypi/linux/bl ... le.c#L4575
so try again when changed to below format (example only! that's the 7in panel from the test pattern picture):
I'll give that a try today.

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 5:43 pm

6by9 wrote:
Fri Jul 15, 2022 8:09 am
evankrall wrote:
Fri Jul 15, 2022 6:05 am
Ok, I've confirmed that the SN65 is just not converting DSI to LVDS for me. It'll happily output the test pattern, but won't do anything for me.
How many data lanes are you running? 2 &3 seem to work, but not 4.
I'm running 4 lanes :(

With 2 or 3 lanes, I'm unable to get the DSI clock to a value that lets the sn65 set the LVDS clock at 100MHz, only 125MHz, which is out-of-spec for my panel. (Panel wants 97-103MHz.)

Maybe I need to add an external reference clock? (Is that even supported by the driver?)

Maybe I'll try a lower LVDS frequency; it seems more likely that the panel would work with a lower-than-spec clock frequency than a higher-than-spec clock frequency.

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Fri Jul 15, 2022 6:08 pm

I did a quick test with 2 and 3 lanes with lower clock frequencies, and with 2 lanes (83MHz) and 3 lanes (75MHz), I have the same symptoms where the test pattern happily displays, but once I turn the test pattern off, it just slowly fades away the way it does when there's no LVDS data. When I have more time later, I'll power up the scope and confirm.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Sat Jul 16, 2022 6:34 am

I don't have the panel in question but below starts DSI correctly at least. Don't know which data sheet you're referring to btw, but mine for this panel shows it's 8bit color.

Code: Select all

static const struct display_timing lg_lp097x02_slq1_timing = {
	.pixelclock = { 100000000, 100000000, 100000000 },
	.hactive = { 1024, 1024, 1024 },
	.hfront_porch = { 260, 260, 260 },
	.hback_porch = { 480, 480, 480 },
	.hsync_len = { 320, 320, 320 },
	.vactive = { 768, 768, 768 },
	.vfront_porch = { 16, 16, 16 },
	.vback_porch = { 6, 6, 6 },
	.vsync_len = { 10, 10, 10 },
	.flags = DISPLAY_FLAGS_DE_HIGH,
};

static const struct panel_desc lg_lp097x02_slq1 = {
	.timings = &lg_lp097x02_slq1_timing,
	.num_timings = 1,
	.bpc = 8,
	.size = {
		.width = 210,
		.height = 164,
	},
	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
	.bus_flags = DRM_BUS_FLAG_DE_HIGH,
	.connector_type = DRM_MODE_CONNECTOR_LVDS,
};

Code: Select all

pi@DSI0test:~ $ i2cdump -f -y 10 0x2c
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 35 38 49 53 44 20 20 20 01 00 89 18 00 01 00 00    58ISD   ?.??.?..
10: 2e 00 64 00 00 00 00 00 18 05 03 00 00 00 00 00    ..d.....???.....
20: 00 04 00 00 00 03 00 00 21 00 00 00 40 01 00 00    .?...?..!...@?..
30: 0a 00 00 00 e0 00 06 00 0d 00 10 00 00 00 00 00    ?...?.?.?.?.....
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 40 00 00 80 00 00 00 00 00 00 00 00    ....@..?........
pi@DSI0test:~ $ dmesg |grep dsi
[    0.069646] platform fe700000.dsi: Fixing up cyclic dependency with fe101000.cprman
[    5.886496] i2c 10-002c: Fixing up cyclic dependency with fe700000.dsi
[    8.352516] sn65dsi83 10-002c: supply vcc not found, using dummy regulator
[    8.507045] sn65dsi83 10-002c: supply vcc not found, using dummy regulator
[    8.528762] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
pi@DSI0test:~ $ sudo cat /sys/kernel/debug/device_component/gpu
master name                                            status
-------------------------------------------------------------
gpu                                                     bound

device name                                            status
-------------------------------------------------------------
fe400000.hvs                                            bound
fef00700.hdmi                                           bound
fef05700.hdmi                                           bound
fe700000.dsi                                            bound
fe004000.txp                                            bound
fe206000.pixelvalve                                     bound
fe207000.pixelvalve                                     bound
fe20a000.pixelvalve                                     bound
fe216000.pixelvalve                                     bound
fec12000.pixelvalve                                     bound
pi@DSI0test:~ $ dmesg |grep vc4
[    8.365315] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    8.366452] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    8.366538] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    8.507764] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    8.510266] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    8.510347] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input1
[    8.516430] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    8.517743] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    8.517829] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input2
[    8.528187] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    8.528762] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    8.528961] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    8.529115] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.529254] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.529396] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.529504] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.529643] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    8.537884] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[    8.579832] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
pi@DSI0test:~ $ ls /sys/bus/i2c/drivers
dummy  sn65dsi83  stmpe-i2c
pi@DSI0test:~ $ 

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Jul 18, 2022 5:32 pm

aBUGSworstnightmare wrote:
Sat Jul 16, 2022 6:34 am
I don't have the panel in question but below starts DSI correctly at least. Don't know which data sheet you're referring to btw, but mine for this panel shows it's 8bit color.
I'll give that configuration a shot, thanks. (Though I'll note I haven't had any trouble getting the Pi to produce DSI.)

There are actually two panels used in the iPad, one from Samsung, one from LG; they seem to have identical specs, but slight differences in the datasheet. The LP097X02 claims to take 4 lanes of LVDS and 8 bits, but only 3 data lanes are exposed on the connector. The LTN097XL01 only claims to take 6 bits, and its timing diagram only shows 3 lanes. Fortunately, MEDIA_BUS_FMT_RGB666_1X7X3_SPWG seems to be a subset of MEDIA_BUS_FMT_RGB888_1X7X4_SPWG (or maybe a subset of MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA? Anybody know whether R₀, B₀, G₀ are the least significant bit or the most significant bit?)

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Jul 18, 2022 8:27 pm

evankrall wrote:
Mon Jul 18, 2022 5:32 pm
aBUGSworstnightmare wrote:
Sat Jul 16, 2022 6:34 am
I don't have the panel in question but below starts DSI correctly at least. Don't know which data sheet you're referring to btw, but mine for this panel shows it's 8bit color.
I'll give that configuration a shot, thanks. (Though I'll note I haven't had any trouble getting the Pi to produce DSI.)

There are actually two panels used in the iPad, one from Samsung, one from LG; they seem to have identical specs, but slight differences in the datasheet. The LP097X02 claims to take 4 lanes of LVDS and 8 bits, but only 3 data lanes are exposed on the connector. The LTN097XL01 only claims to take 6 bits, and its timing diagram only shows 3 lanes. Fortunately, MEDIA_BUS_FMT_RGB666_1X7X3_SPWG seems to be a subset of MEDIA_BUS_FMT_RGB888_1X7X4_SPWG (or maybe a subset of MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA? Anybody know whether R₀, B₀, G₀ are the least significant bit or the most significant bit?)
R0/G0/B0 are LSB for sure! Otherwise you could never produce white or black on 6bit only.

MEDIA_BUS_Formats are little confusing as there is only a 24bit VESA mode (where LSB is in Y0). The other formats where LSB is in Y3 is JEIDA24 (RGB_1X7X4_JEIDA). That's why you can ommit Y3 in case of 18bit color only (RGB_1X7X3_SPWG).

So, RGB666_1X7X3_SPWG is 18bit JEIDA as R0 = R2 in real life (because R7 = MSB)

I'm referring to LP097X02S-SLQ1, spec is 7.Feb 2010, ver 0.1. Based on data mapping on page 9 R0 is in Y0 LVDS channel -> VESA mapping . Can you share the Samsung spec or point me to where to find it? Does Samsung panel has EDID as well? Maybe the iPad reads/uses that to define the data mapping of the LVDS transmitter (DSI85 supports both, register setting needed).
Yes, only Y0 ro Y2 exposed on the connector. My guess: error in the spec as rhe data mapping is incorrect. Typical cut&paste error in a initial revision (TCON may have selector input for mapping, but engineer pasted the wrong picture for the config).
Sry, did nit check the connector pinout! Pls change to MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA to get it working.
Image
VESA data mapping

Image
JEIDA mapping

Also see i.e. https://hackaday.io/project/4869-ld320e ... vesa-jeida

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Jul 18, 2022 10:12 pm

I've saved the datasheet to my git repo, so it's available at https://github.com/EvanKrall/pipad/blob ... 01-A01.pdf - I've also got a datasheet for a later revision which I think is formatted a little nicer in some spots: https://github.com/EvanKrall/pipad/blob ... 01-H01.pdf

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 3:00 am

I've tried your timing/panel definition, both with SPWG and JEIDA, and no dice -- still getting no image unless I enable the test pattern.

The panel does have EDID, but I don't see any traffic to i2c address 0x50 (the DDC address) when the sn65 driver initializes - just 0x2d (the sn65's address).

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 4:19 am

evankrall wrote:
Tue Jul 19, 2022 3:00 am
I've tried your timing/panel definition, both with SPWG and JEIDA, and no dice -- still getting no image unless I enable the test pattern.

The panel does have EDID, but I don't see any traffic to i2c address 0x50 (the DDC address) when the sn65 driver initializes - just 0x2d (the sn65's address).
the driver does not care about EDID! Hook it up to an I2C bus, see which address responds (0x50) and then dump the EDID. It has the timing details, so worth checking.

Well, do you have another display to test your hardware with? Might be a panel issues as well...
Get a cheap LVDS module to test with (works nice, https://www.pollin.de/p/lc-display-lg-l ... vds-121849) .

What you should try as well is using a different XGA timing to test with, i.e. https://github.com/raspberrypi/linux/bl ... le.c#L2417

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 4:36 am

evankrall wrote:
Mon Jul 18, 2022 10:12 pm
I've saved the datasheet to my git repo, so it's available at https://github.com/EvanKrall/pipad/blob ... 01-A01.pdf - I've also got a datasheet for a later revision which I think is formatted a little nicer in some spots: https://github.com/EvanKrall/pipad/blob ... 01-H01.pdf
checked them, none has the timing details (only in LG spec) --> test another timing with a lower clock.

EDIT: My WXGA panel was not able to pick-up the LG timing, but using "hannstar,hsd100pxn1" gave 'some output' -> DSI running (but panel doesn't like that for sure).
image001.jpg
Throwing hannstar hsd100pxn1 on my WXGA panel showed a working DSI interface at least. Sure, panel doesn't like the XGA timing
image001.jpg (32.2 KiB) Viewed 6042 times

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 7:23 am

I think I may have found a clue...

I downloaded the DSI-Tuner app from TI to see what it recommends. The CSRs it suggests aren't significantly different than what the sn65dsi83 driver is setting (though DSI-Tuner doesn't set the test-pattern-only registers).

However, it says the "LINE TIME (SYNC to SYNC) REQUIREMENT (us)" is 20.84 microseconds, which follows from the calculation that hactive + hfront_porch + hback_porch + hsync_len = (1024 + 260 + 480 + 320) = 2084 pixels clocks, and the clock speed is 100MHz.

From the manual for DSI-Tuner (https://www.ti.com/lit/an/slla332b/slla ... 8142549274),
The video transfer is done on a line-by-line basis in the SN65DSI8x device. The rule of
thumb for the DSI data transfer using the SN65DSI8x devices is to match the line time
(Sync-to-Sync time) between the input and the output. It is also important to maintain the
data rate so as not to underflow or overflow the internal buffer. The SN65DSI85 supports
a programmable delay value to help maintain the data rate and the availability of data in
internal buffers. The delay value, also referred as “sync delay”, is used to delay the
outgoing data, up to 0xFF number of pixels, by programming the corresponding register
field. The sync delay value can be calculated based on the DSI input parameters and the
LVDS output requirements. It is important to program the sync delay value to a properly
calculated value for correct operation of the device.
When I measure the sync-to-sync time on the DSI lines, I see a sync period of 13.16 microseconds.

I wonder if what's happening here is that the DSI HSync/HFP/HBP are defaulting to some typical values, which are much shorter than the very long hsync parameters that this panel wants.

Is there a way to tweak the DSI hsync parameters? I don't see anything obvious in vc4_dsi.c, nor anything obviously setting the DSI timing parameters in sn65dsi83.c
Last edited by evankrall on Fri Jul 22, 2022 5:42 am, edited 1 time in total.

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 7:28 am

aBUGSworstnightmare wrote:
Tue Jul 19, 2022 4:19 am
the driver does not care about EDID! Hook it up to an I2C bus, see which address responds (0x50) and then dump the EDID. It has the timing details, so worth checking.

my EDID data is:

Code: Select all

00 ff ff ff ff ff ff 00 06 10 d5 9c 00 00 00 00
01 14 01 03 80 14 0f 78 0a ef 05 9a 59 50 90 25
20 50 54 00 00 00 a1 e5 69 09 00 00 00 00 00 00
00 00 64 00 00 01 13 27 00 24 44 00 20 30 04 40
0a 00 c5 94 00 00 00 18 00 00 00 01 00 06 10 20
00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
54 4e 30 39 37 58 4c 30 31 00 0a 20 00 00 00 fc
00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 0f
Which, when pasted into http://www.edidreader.com gives me
Detailed Timing Descriptor
Pixel Clock: 100.03MHz
Horizontal Active: 1024
Horizontal Blanking: 1060
Vertical Active: 768
Vertical Blanking: 32
Horizontal Sync Offset: 4
Horizontal Sync Pulse: 64
Vertical Sync Offset: 0
Vertical Sync Pulse: 10
Horizontal Display Size: 197
Vertical Display Size: 148
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3
The "Horizontal sync pulse" of 64 is pretty different from the "Width-Active" of 320 from the LG datasheet. I'll give that a shot tomorrow I guess.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Tue Jul 19, 2022 8:04 am

evankrall wrote:
Tue Jul 19, 2022 7:28 am
aBUGSworstnightmare wrote:
Tue Jul 19, 2022 4:19 am
the driver does not care about EDID! Hook it up to an I2C bus, see which address responds (0x50) and then dump the EDID. It has the timing details, so worth checking.

my EDID data is:

Code: Select all

00 ff ff ff ff ff ff 00 06 10 d5 9c 00 00 00 00
01 14 01 03 80 14 0f 78 0a ef 05 9a 59 50 90 25
20 50 54 00 00 00 a1 e5 69 09 00 00 00 00 00 00
00 00 64 00 00 01 13 27 00 24 44 00 20 30 04 40
0a 00 c5 94 00 00 00 18 00 00 00 01 00 06 10 20
00 00 00 00 00 00 00 00 0a 20 00 00 00 fe 00 4c
54 4e 30 39 37 58 4c 30 31 00 0a 20 00 00 00 fc
00 43 6f 6c 6f 72 20 4c 43 44 0a 20 20 20 00 0f
Which, when pasted into http://www.edidreader.com gives me
Detailed Timing Descriptor
Pixel Clock: 100.03MHz
Horizontal Active: 1024
Horizontal Blanking: 1060
Vertical Active: 768
Vertical Blanking: 32
Horizontal Sync Offset: 4
Horizontal Sync Pulse: 64
Vertical Sync Offset: 0
Vertical Sync Pulse: 10
Horizontal Display Size: 197
Vertical Display Size: 148
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3
The "Horizontal sync pulse" of 64 is pretty different from the "Width-Active" of 320 from the LG datasheet. I'll give that a shot tomorrow I guess.
Test with another timing as well. The one from EDID is not starting DSI for me here (but did not do a detailed check).

Liffu
Posts: 25
Joined: Thu May 19, 2022 11:01 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Aug 01, 2022 12:13 pm

6by9 wrote:
Wed Jul 06, 2022 3:39 pm
-517 is not a fatal error - it's -EPROBE_DEFER, which denotes that a device can't complete probing at present due to some unmet dependency. All devices should clean up, and it will be attempted again later when other devices have probed.
Drivers should be using dev_err_probe for logging messages where -EPROBE_DEFER is reasonably going to be returned.

Code: Select all

[   21.104721] WARNING: CPU: 3 PID: 192 at drivers/gpu/drm/panel/panel-simple.c:740 panel_simple_probe+0x2d4/0x4c0 [panel_simple]
You may have variation in line numbers in your code, but that would appear to be https://github.com/raspberrypi/linux/bl ... ple.c#L740

Code: Select all

		WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
			 desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA) &&
			desc->bpc != 8);
So your panel isn't defined with the correct bit depth for the format. You say you're using my branch, but not what panel definition you're using. The chunghwa_claa070wp03xglvds definition that I was using certainly defines bpc correctly.
Ok after few weeks I started to work on this again, but now its not even working at all, not sure what changed but before it was working at least sometimes.
I decided to start from beginning I cloned your branch and compiled it, I am running 64bit and using your overlay with the exact panel you suggested, but still I have this error:

Code: Select all

[    8.457705] vc4_hvs fe400000.hvs: Couldn't get core clock
[    8.457936] sn65dsi83 10-002d: failed to attach dsi to host: -517
I understand what this error means but I just dont know how to fix it.

There are also some errors before but no idea if its connected to my issue in any way:

Code: Select all

[    1.539391] brcm-pcie fd500000.pcie: link down
[    1.543995] raspberrypi-clk soc:firmware:clocks: Unknown clock id: 4294967168
[    1.544028] raspberrypi-clk: probe of soc:firmware:clocks failed with error -22
This happens only when i am using vc4-kms-v3d-pi4 driver.

I also tried to use vc4-fkms-v3d-pi4 but that is also not working but the issue is different:

Code: Select all

[    8.366176] vc4-drm gpu: bound fe700000.dsi (ops vc4_dsi_ops [vc4])
[    8.366602] [drm] No displays found. Consider forcing hotplug if HDMI is attached
[    8.366630] vc4-drm gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
[    8.366747] ------------[ cut here ]------------
[    8.366757] Bogus possible_crtcs: [ENCODER:31:DSI-31] possible_crtcs=0x0 (full crtc mask=0x0)
[    8.366867] WARNING: CPU: 0 PID: 313 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x1c8/0x4d8 [drm]
[    8.367097] Modules linked in: ti_sn65dsi83(+) regmap_i2c vc4 bcm2835_codec(C) bcm2835_v4l2(C) bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common cec v3d snd_soc_core videodev gpu_sched i2c_mux_pinctrl snd_compress i2c_mux snd_pcm_dmaengine raspberrypi_hwmon panel_simple snd_pcm drm_kms_helper mc vc_sm_cma(C) i2c_bcm2835 pwm_bcm2835 snd_timer snd drm_dp_aux_bus rpivid_mem syscopyarea sysfillrect sysimgblt fb_sys_fops nvmem_rmem uio_pdrv_genirq pwm_bl uio i2c_dev aes_neon_bs drm aes_neon_blk crypto_simd cryptd drm_panel_orientation_quirks backlight fuse ip_tables x_tables ipv6
[    8.367364] CPU: 0 PID: 313 Comm: modprobe Tainted: G         C        5.15.40-v8+ #2
[    8.367380] Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
[    8.367389] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    8.367403] pc : drm_mode_config_validate+0x1c8/0x4d8 [drm]
[    8.367601] lr : drm_mode_config_validate+0x1c8/0x4d8 [drm]
[    8.367793] sp : ffffffc0089536a0
[    8.367800] x29: ffffffc0089536b0 x28: 0000000000000100 x27: 0000000000000001
[    8.367824] x26: ffffff80431ca2a8 x25: 0000000000000001 x24: ffffff80431ca2a0
[    8.367846] x23: ffffff80431ca2a8 x22: ffffffd017e2f628 x21: ffffffd017e2f5a8
[    8.367866] x20: ffffff80431ca000 x19: ffffff8043054480 x18: 0000000000000020
[    8.367887] x17: 756628203078303d x16: 73637472635f656c x15: 626973736f70205d
[    8.367907] x14: 31332d4953443a31 x13: 293078303d6b7361 x12: 6d2063747263206c
[    8.367927] x11: ffffffd07bbb6698 x10: ffffffd07bb9e658 x9 : ffffffd07a8ed108
[    8.367948] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
[    8.367968] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000027
[    8.367989] x2 : 0000000000000001 x1 : 0000000000000000 x0 : 0000000000000000
[    8.368009] Call trace:
[    8.368016]  drm_mode_config_validate+0x1c8/0x4d8 [drm]
[    8.368212]  drm_dev_register+0x184/0x218 [drm]
[    8.368407]  vc4_drm_bind+0x1fc/0x2f0 [vc4]
[    8.368477]  try_to_bring_up_master+0x170/0x1d8
[    8.368504]  __component_add+0xb0/0x180
[    8.368518]  component_add+0x1c/0x28
[    8.368533]  vc4_dsi_host_attach+0x84/0x148 [vc4]
[    8.368598]  devm_mipi_dsi_attach+0x3c/0xa0
[    8.368613]  sn65dsi83_probe+0x218/0x3a8 [ti_sn65dsi83]
[    8.368635]  i2c_device_probe+0xb0/0x2e8
[    8.368649]  really_probe+0xc0/0x300
[    8.368664]  __driver_probe_device+0x80/0xe8
[    8.368678]  driver_probe_device+0x88/0x118
[    8.368692]  __driver_attach+0x78/0x110
[    8.368705]  bus_for_each_dev+0x78/0xd0
[    8.368718]  driver_attach+0x2c/0x38
[    8.368731]  bus_add_driver+0x158/0x200
[    8.368744]  driver_register+0x6c/0x128
[    8.368758]  i2c_register_driver+0x50/0xb0
[    8.368770]  sn65dsi83_driver_init+0x28/0x1000 [ti_sn65dsi83]
[    8.368790]  do_one_initcall+0x50/0x2a0
[    8.368804]  do_init_module+0x50/0x218
[    8.368819]  load_module+0x216c/0x2828
[    8.368832]  __do_sys_init_module+0x1ac/0x228
[    8.368845]  __arm64_sys_init_module+0x24/0x30
[    8.368858]  invoke_syscall+0x4c/0x110
[    8.368873]  el0_svc_common.constprop.0+0x104/0x128
[    8.368887]  do_el0_svc+0x2c/0x90
[    8.368899]  el0_svc+0x24/0x70
[    8.368911]  el0t_64_sync_handler+0xb0/0xb8
[    8.368922]  el0t_64_sync+0x1a0/0x1a4
[    8.368933] ---[ end trace 87664c195fe4297c ]---
[    8.384076] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    8.384307] vc4-drm gpu: [drm] Cannot find any crtc or sizes
I got little further when using fkms, I get the driver loaded and dsi bound, but still no output to screen.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Aug 01, 2022 12:25 pm

will not work with KMS!

Code: Select all

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
Make sure that's in your config.txt

And the branch to clone https://github.com/6by9/linux/tree/rpi-5.15.y-sn65dsi83.
Make sure to run 'make menuconfig' as you'll need to enable the bridge driver! It's not enabled from the branch's bcm2711_defconfig

Running 32-bit and 64-bit version of that branch on several DUT (all of them are CM4 + CM4IO) atm without issues.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Aug 01, 2022 12:31 pm

Liffu wrote:
Mon Aug 01, 2022 12:13 pm
I decided to start from beginning I cloned your branch and compiled it, I am running 64bit and using your overlay with the exact panel you suggested, but still I have this error:

Code: Select all

..
[    8.457936] sn65dsi83 10-002d: failed to attach dsi to host: -517
...

I got little further when using fkms, I get the driver loaded and dsi bound, but still no output to screen.
Has been explained to you here viewtopic.php?t=305690&start=450#p2017779. Either fix it yourself (how was explained as well) or simply ignore - as it's not an error.

Liffu
Posts: 25
Joined: Thu May 19, 2022 11:01 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Aug 01, 2022 1:05 pm

aBUGSworstnightmare wrote:
Mon Aug 01, 2022 12:31 pm
Liffu wrote:
Mon Aug 01, 2022 12:13 pm
I decided to start from beginning I cloned your branch and compiled it, I am running 64bit and using your overlay with the exact panel you suggested, but still I have this error:

Code: Select all

..
[    8.457936] sn65dsi83 10-002d: failed to attach dsi to host: -517
...

I got little further when using fkms, I get the driver loaded and dsi bound, but still no output to screen.
Has been explained to you here viewtopic.php?t=305690&start=450#p2017779. Either fix it yourself (how was explained as well) or simply ignore - as it's not an error.
My problem isnt really the -517 return, I understand that its not an error, my problem is the line above it (at least that is my theory)

Code: Select all

[    8.757498] vc4_hvs fe400000.hvs: Couldn't get core clock


Everytime sn65dsi83 does want to get attach to dsi there is this error which causes -517 at least I think that is the reason. I do think that the sn65dsi83 driver is working properly, before i got it even working few times but now i cant get pass this problem.

So I cant really ignore it because the driver never gets probed successfully.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 15329
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Rpi 4 with DRM and 7inch panel using kms driver

Mon Aug 01, 2022 1:40 pm

Update your firmware, or at least confirm what version you are running ("vcgencmd get_version").

The hvs core clock link is defined at https://github.com/6by9/linux/blob/rpi- ... i.dtsi#L52, so should be found.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Sun Sep 04, 2022 4:42 am

evankrall wrote:
Tue Jul 19, 2022 7:23 am
When I measure the sync-to-sync time on the DSI lines, I see a sync period of 13.16 microseconds.
I've discovered something: it seems like something is truncating hfront_porch, hback_porch, and hsync_len to 8 bits. This explains my 13.16us sync period: 1024 + 260%256 + 480%256 + 320%256 = 1316 clock cycles, with a 100MHz clock (0.01us per clock cycle) gives 13.16us.

If I decrease hfront_porch to 255 and leave hback_porch and hsync_len at 480 and 320, my hsync period increases to 15.68 microseconds (pretty close, but not exactly the 15.67us we'd expect with this 8-bit theory - maybe something else is rounding? It seems like every measurement I've taken ends up very close to a multiple of 0.04us, or 4 clock cycles).

If I set hfront_porch to 256, I see no horizontal blanking pulses at all. (I think something is seeing a 0 and changing behavior.)

If I set hfront_porch to 266, I see an interval of 13.24us, which I also measure if I set hfront_porch to 10.

aBUGSworstnightmare
Posts: 8444
Joined: Tue Jun 30, 2015 1:35 pm

Re: Rpi 4 with DRM and 7inch panel using kms driver

Sun Sep 04, 2022 5:11 am

evankrall wrote:
Sun Sep 04, 2022 4:42 am
evankrall wrote:
Tue Jul 19, 2022 7:23 am
When I measure the sync-to-sync time on the DSI lines, I see a sync period of 13.16 microseconds.
I've discovered something: it seems like something is truncating hfront_porch, hback_porch, and hsync_len to 8 bits. This explains my 13.16us sync period: 1024 + 260%256 + 480%256 + 320%256 = 1316 clock cycles, with a 100MHz clock (0.01us per clock cycle) gives 13.16us.

If I decrease hfront_porch to 255 and leave hback_porch and hsync_len at 480 and 320, my hsync period increases to 15.68 microseconds (pretty close, but not exactly the 15.67us we'd expect with this 8-bit theory - maybe something else is rounding? It seems like every measurement I've taken ends up very close to a multiple of 0.04us, or 4 clock cycles).

If I set hfront_porch to 256, I see no horizontal blanking pulses at all. (I think something is seeing a 0 and changing behavior.)

If I set hfront_porch to 266, I see an interval of 13.24us, which I also measure if I set hfront_porch to 10.
read the DSI83 registers and post the result for review.
Share the display data sheet as well.

evankrall
Posts: 34
Joined: Tue Mar 23, 2021 3:21 am

Re: Rpi 4 with DRM and 7inch panel using kms driver

Sun Sep 04, 2022 6:17 am

aBUGSworstnightmare wrote:
Sun Sep 04, 2022 5:11 am
read the DSI83 registers and post the result for review.
Share the display data sheet as well.
To be clear, I believe the problem I'm describing in that comment is with the Pi's DSI output and/or the Linux kernel on the DSI side of things, and has nothing to do with the sn65.

But anyway, here are the registers with my panel's desired timings (HFP=260, HBP=480, hsync_len=320):

Code: Select all

meatmanek@cm4:~ $ sudo i2cdump -f -y 10 0x2d
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 35 38 49 53 44 20 20 20 01 00 87 10 00 01 00 00    58ISD   ?.??.?..
10: 26 00 3c 00 00 00 00 00 1a 05 03 00 00 00 00 00    &.<.....???.....
20: 00 04 00 00 00 03 00 00 21 00 00 00 40 01 00 00    .?...?..!...@?..
30: 0a 00 00 00 e0 00 06 00 04 00 10 00 00 00 00 00    ?...?.?.?.?.....
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 40 00 00 80 00 00 00 00 00 00 00 00    ....@..?........
(pretty-printed: https://gist.github.com/EvanKrall/4a437 ... 390ee0fc99)

Interestingly enough, CHA_HORIZONTAL_BACK_PORCH is 224 (which is 480 truncated to 8 bits). Maybe this is a limitation of the sn65 after all.

Display datasheets are at https://github.com/EvanKrall/pipad/blob ... 2-SLQ1.pdf and https://github.com/EvanKrall/pipad/blob ... 01-A01.pdf (github's PDF renderer seems to have trouble with these, you'll need to download them.) The iPad used displays from two display manufacturers, Samsung and LG, and each had their own datasheet. Both displays should be compatible (same timings, etc), but mine is the LTN097XL01.

Return to “Interfacing (DSI, CSI, I2C, etc.)”