Re: Rpi 4 with DRM and 7inch panel using kms driver
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:
With the test pattern disabled, nothing interesting is output on the A_Y0P/N, etc. pins; just a constant bitstream:
(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?
When I enable the test pattern, I see meaningful data from the LVDS data pins:
With the test pattern disabled, nothing interesting is output on the A_Y0P/N, etc. pins; just a constant bitstream:
(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?
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
Code: Select all
sudo cat /sys/kernel/debug/device_component/gpu
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,
};
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 14824
- 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
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.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
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).
Re: Rpi 4 with DRM and 7inch panel using kms driver
aBUGSworstnightmare wrote: ↑Fri Jul 15, 2022 6:40 amWhat is the output of that command?Code: Select all
sudo cat /sys/kernel/debug/device_component/gpu
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
I see this in the modetest output:aBUGSworstnightmare wrote: ↑Fri Jul 15, 2022 6:40 amCheck with "modetest -M vc4 | less" to see if it has brought up DSI as a display.
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:
I'll give that a try today.aBUGSworstnightmare wrote: ↑Fri Jul 15, 2022 6:40 amI'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):
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
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:~ $
Re: Rpi 4 with DRM and 7inch panel using kms driver
I'll give that configuration a shot, thanks. (Though I'll note I haven't had any trouble getting the Pi to produce DSI.)aBUGSworstnightmare wrote: ↑Sat Jul 16, 2022 6:34 amI 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.
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?)
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
R0/G0/B0 are LSB for sure! Otherwise you could never produce white or black on 6bit only.evankrall wrote: ↑Mon Jul 18, 2022 5:32 pmI'll give that configuration a shot, thanks. (Though I'll note I haven't had any trouble getting the Pi to produce DSI.)aBUGSworstnightmare wrote: ↑Sat Jul 16, 2022 6:34 amI 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.
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?)
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.
VESA data mapping
JEIDA mapping
Also see i.e. https://hackaday.io/project/4869-ld320e ... vesa-jeida
Re: Rpi 4 with DRM and 7inch panel using kms driver
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
Re: Rpi 4 with DRM and 7inch panel using kms driver
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 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).
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.evankrall wrote: ↑Tue Jul 19, 2022 3:00 amI'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).
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
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
checked them, none has the timing details (only in LG spec) --> test another timing with a lower clock.evankrall wrote: ↑Mon Jul 18, 2022 10:12 pmI'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
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).
Re: Rpi 4 with DRM and 7inch panel using kms driver
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),
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
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),
When I measure the sync-to-sync time on the DSI lines, I see a sync period of 13.16 microseconds.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.
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.
Re: Rpi 4 with DRM and 7inch panel using kms driver
aBUGSworstnightmare wrote: ↑Tue Jul 19, 2022 4:19 amthe 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
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.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
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
Test with another timing as well. The one from EDID is not starting DSI for me here (but did not do a detailed check).evankrall wrote: ↑Tue Jul 19, 2022 7:28 amaBUGSworstnightmare wrote: ↑Tue Jul 19, 2022 4:19 amthe 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:Which, when pasted into http://www.edidreader.com gives meCode: 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
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.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
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.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.
You may have variation in line numbers in your code, but that would appear to be https://github.com/raspberrypi/linux/bl ... ple.c#L740Code: 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]
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.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);
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
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
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
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
will not work with KMS!
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.
Code: Select all
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
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.
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
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 wrote: ↑Mon Aug 01, 2022 12:13 pmI 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.
Re: Rpi 4 with DRM and 7inch panel using kms driver
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)aBUGSworstnightmare wrote: ↑Mon Aug 01, 2022 12:31 pmHas 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 wrote: ↑Mon Aug 01, 2022 12:13 pmI 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.
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.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 14824
- 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
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.
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.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.
-
- Posts: 7791
- Joined: Tue Jun 30, 2015 1:35 pm
Re: Rpi 4 with DRM and 7inch panel using kms driver
read the DSI83 registers and post the result for review.evankrall wrote: ↑Sun Sep 04, 2022 4:42 amI'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.
Share the display data sheet as well.
Re: Rpi 4 with DRM and 7inch panel using kms driver
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.aBUGSworstnightmare wrote: ↑Sun Sep 04, 2022 5:11 amread the DSI83 registers and post the result for review.
Share the display data sheet as well.
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 ....@..?........
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.