DSI Device Tree Entries - module probe not being called

[Chris_G_Miller]

I am trying to get a DSI to LVDS bridge chip going. This can be directly setup using I2C - a situatiion very similar to the early drivers for the R-Pi Official 7" touch screen.
However, with current Rasbian (4.14.50) if I connect an official screen, it works fine - but i cannot see any entries in the Device Tree to make it work. There is also no module listed by lsmod - so I am more than a little puzzled. I think somehow it must all now be buried somewhere in the firmware. [An explanation of why this is and how the official screen DT/driver works would be helpful - I think it has changed from earlier releases].
I have been trying to follow Eric Anholt's helpful page at https://github.com/anholt/linux/wiki/Ra ... lay-panels.
So I have made a modified version of panel-raspberrypi-toucscreen.c which complies and loads OK.
It has the element { .compatible = "creative,lvds-bridge-i2c" }, in the of_device_id struct.
This matches the compatible= element in the flattened device tree:

Code: Select all

		i2cdsi {
		gpios = <0x10 0x2c 0x0 0x10 0x2d 0x0>;
		compatible = "i2c-gpio";
		status = "okay";
		#address-cells = <0x1>;
		#size-cells = <0x0>;
		phandle = <0x73>;

		[email protected] {
			compatible = "creative,lvds-bridge-i2c";
			phandle = <0x78>;
			reg = <0x2c>;

			port {

				endpoint {
					remote-endpoint = <0x7a>;
					phandle = <0x79>;
				};
			};
		};
	};

as per Eric's recommendations.
There is also the following element under dsi1:

Code: Select all

			port {

				endpoint {
					remote-endpoint = <0x79>;
					phandle = <0x7a>;
				};
			};

and the phandles are (I assume correctly) pointing at each other.
The problem I have is that - so far as I can tell - whilst the module is loading on boot-up (being shown in lsmod), and sitting above drm as expected -the module's 'probe' callback does not appear to be being called.
I say this because:
a) dmesg shows "[ 14.145100] bus: 'mipi-dsi': add driver panel-texas-sn65dsi83,
but then nothing else
b) printk's in the probe function are not firing
c) whilst the i2cbus is being 'poked' by the kernel module for the Goodix touch overlay driver chip, there is no activity on the 2C address configured for the DSI bridge chip (so I know I'm driving the right i2c bus) [Determined using an I2C bus analyser]
d) the DSI clock a data lane outputs are not firing up [determined with a 'scope].

If I remove the module then re-insert it using modprobe I see:

Code: Select all

[email protected]:/home/kdev# lsmod
Module                  Size  Used by
fuse                  106496  3
cmac                   16384  1
rfcomm                 77824  6
bnep                   24576  2
hci_uart               45056  1
btbcm                  16384  1 hci_uart
serdev                 20480  1 hci_uart
bluetooth             536576  29 hci_uart,bnep,btbcm,rfcomm
ecdh_generic           28672  1 bluetooth
panel_texas_sn65dsi83    16384  0
vc4                   151552  0
drm_kms_helper        184320  1 vc4
drm                   385024  3 panel_texas_sn65dsi83,vc4,drm_kms_helper
i2c_gpio               16384  0
i2c_algo_bit           16384  1 i2c_gpio
snd_soc_core          204800  1 vc4
snd_compress           24576  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
brcmfmac              307200  0
brcmutil               20480  1 brcmfmac
cfg80211              581632  1 brcmfmac
snd_bcm2835            32768  1
rfkill                 28672  6 bluetooth,cfg80211
snd_pcm                98304  4 vc4,snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
snd_timer              32768  1 snd_pcm
snd                    69632  7 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
fixed                  16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
i2c_dev                20480  0
ip_tables              24576  0
x_tables               36864  1 ip_tables
ipv6                  446464  26
[email protected]:/home/kdev# rmmod panel_texas_sn65dsi83
[email protected]:/home/kdev# modprobe -vvv panel_texas_sn65dsi83
modprobe: INFO: ../libkmod/libkmod.c:364 kmod_set_log_fn() custom logging function 0x19778 registered
modprobe: DEBUG: ../libkmod/libkmod-index.c:755 index_mm_open() file=/lib/modules/4.14.50-v7-CM+/modules.dep.bin
modprobe: DEBUG: ../libkmod/libkmod-index.c:755 index_mm_open() file=/lib/modules/4.14.50-v7-CM+/modules.alias.bin
modprobe: DEBUG: ../libkmod/libkmod-index.c:755 index_mm_open() file=/lib/modules/4.14.50-v7-CM+/modules.symbols.bin
modprobe: DEBUG: ../libkmod/libkmod-index.c:755 index_mm_open() file=/lib/modules/4.14.50-v7-CM+/modules.builtin.bin
modprobe: DEBUG: ../libkmod/libkmod-module.c:556 kmod_module_new_from_lookup() input alias=panel_texas_sn65dsi83, normalized=panel_texas_sn65dsi83
modprobe: DEBUG: ../libkmod/libkmod-module.c:562 kmod_module_new_from_lookup() lookup modules.dep panel_texas_sn65dsi83
modprobe: DEBUG: ../libkmod/libkmod.c:574 kmod_search_moddep() use mmaped index 'modules.dep' modname=panel_texas_sn65dsi83
modprobe: DEBUG: ../libkmod/libkmod.c:402 kmod_pool_get_module() get module name='panel_texas_sn65dsi83' found=(nil)
modprobe: DEBUG: ../libkmod/libkmod.c:410 kmod_pool_add_module() add 0xd9b080 key='panel_texas_sn65dsi83'
modprobe: DEBUG: ../libkmod/libkmod.c:402 kmod_pool_get_module() get module name='drm' found=(nil)
modprobe: DEBUG: ../libkmod/libkmod.c:402 kmod_pool_get_module() get module name='drm' found=(nil)
modprobe: DEBUG: ../libkmod/libkmod.c:410 kmod_pool_add_module() add 0xd9b3a0 key='drm'
modprobe: DEBUG: ../libkmod/libkmod-module.c:196 kmod_module_parse_depline() add dep: /lib/modules/4.14.50-v7-CM+/kernel/drivers/gpu/drm/drm.ko
modprobe: DEBUG: ../libkmod/libkmod-module.c:202 kmod_module_parse_depline() 1 dependencies for panel_texas_sn65dsi83
modprobe: DEBUG: ../libkmod/libkmod-module.c:583 kmod_module_new_from_lookup() lookup panel_texas_sn65dsi83=0, list=0xd9b258
modprobe: DEBUG: ../libkmod/libkmod.c:501 lookup_builtin_file() use mmaped index 'modules.builtin' modname=panel_texas_sn65dsi83
modprobe: DEBUG: ../libkmod/libkmod-module.c:1748 kmod_module_get_initstate() could not open '/sys/module/panel_texas_sn65dsi83/initstate': No such file or directory
modprobe: DEBUG: ../libkmod/libkmod-module.c:1758 kmod_module_get_initstate() could not open '/sys/module/panel_texas_sn65dsi83': No such file or directory
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_pcsp mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_usb_audio mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=cx88_alsa mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_atiixp_modem mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_intel8x0m mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_via82xx_modem mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=8250 mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=vc_mem mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=vc_mem mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=dwc_otg mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=fsck mod->name=drm mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod.c:501 lookup_builtin_file() use mmaped index 'modules.builtin' modname=drm
modprobe: DEBUG: ../libkmod/libkmod-module.c:1304 kmod_module_probe_insert_module() Ignoring module 'drm': already loaded
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_pcsp mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_usb_audio mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=cx88_alsa mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_atiixp_modem mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_intel8x0m mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=snd_via82xx_modem mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=8250 mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=bcm2708_fb mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=vc_mem mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=vc_mem mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=dwc_otg mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1391 kmod_module_get_options() modname=fsck mod->name=panel_texas_sn65dsi83 mod->alias=(null)
modprobe: DEBUG: ../libkmod/libkmod-module.c:1748 kmod_module_get_initstate() could not open '/sys/module/panel_texas_sn65dsi83/initstate': No such file or directory
modprobe: DEBUG: ../libkmod/libkmod-module.c:1758 kmod_module_get_initstate() could not open '/sys/module/panel_texas_sn65dsi83': No such file or directory
modprobe: DEBUG: ../libkmod/libkmod-module.c:744 kmod_module_get_path() name='panel_texas_sn65dsi83' path='/lib/modules/4.14.50-v7-CM+/kernel/drivers/gpu/drm/panel/panel-texas-sn65dsi83.ko'
modprobe: DEBUG: ../libkmod/libkmod-module.c:744 kmod_module_get_path() name='panel_texas_sn65dsi83' path='/lib/modules/4.14.50-v7-CM+/kernel/drivers/gpu/drm/panel/panel-texas-sn65dsi83.ko'
insmod /lib/modules/4.14.50-v7-CM+/kernel/drivers/gpu/drm/panel/panel-texas-sn65dsi83.ko
modprobe: DEBUG: ../libkmod/libkmod-module.c:744 kmod_module_get_path() name='panel_texas_sn65dsi83' path='/lib/modules/4.14.50-v7-CM+/kernel/drivers/gpu/drm/panel/panel-texas-sn65dsi83.ko'
modprobe: DEBUG: ../libkmod/libkmod-module.c:468 kmod_module_unref() kmod_module 0xd9b080 released
modprobe: DEBUG: ../libkmod/libkmod.c:418 kmod_pool_del_module() del 0xd9b080 key='panel_texas_sn65dsi83'
modprobe: DEBUG: ../libkmod/libkmod-module.c:468 kmod_module_unref() kmod_module 0xd9b3a0 released
modprobe: DEBUG: ../libkmod/libkmod.c:418 kmod_pool_del_module() del 0xd9b3a0 key='drm'
modprobe: INFO: ../libkmod/libkmod.c:331 kmod_unref() context 0xd9a178 released
[email protected]:/home/kdev#

I feel this is almost certainly an error in my devicetree but am completely foxed as to how to further debug this. (I can't attach the device-tree dump I keep getting "wrong file extension" when trying to use the Attach too)
I should add that my config.text includes "ignore_lcd=1" and "disable_touchscreen=1", as I assume these are necessary to 'release' the i2c bus on the DSI connector from being controlled by the firmware.

Also, is there a way of getting the kernel to report details of probing activity (I am using a kernel configured for "maximum smoke" on the debug front - still nothing - really struggling to get printk() to work)

Is there a helpful soul who can help me identify what I've missed?
I'd be most grateful for some guidance!

Chris

[mbt28]

Hi,

I have built a board based on the same chip and ordered it from china few days ago.

How is your progress with it? Could you able to make it work?

[Chris_G_Miller]

Yes - I have managed to make it work in that I can get a picture by kidding the R-Pi that it has an Official display attached.
You may like to look at https://e2e.ti.com/support/interface/di ... 0/t/670554 where you'll see a little about my 'mission of discovery'!
I have not yet cracked the mysteries of "device tree" entries to get my own driver to work properly - but it should be possible.
Use Texas's 'DSI Tuner' software to calculate the register values.
The Official display calls up 333.3333 MHz DSI clock. Only lane 0 is used. Happy to compare config register values with you - especially if you can help me with the Device Tree stuff!
ADDENDUM: I found that the DC level of the DSI clock seems too low for the TI chip to recognise the presence of the clock. I had to use two 2k resistors from Vcore of the TI chip to each of CP and CN. Once I'd done that, the chip seemed to clock OK

[Chris_G_Miller]

I am really struggling to get the Device Tree to make the R-Pi push out DSI signals to my DSI to LVDS bridge.
The only way I've managed to do it so far is to hook up the I2C lines in parallel to an "official" display, which means the firmware detects the display, and lights up the DSI output.
This is obviously not a practical solution (although I'm getting close to programming a PIC to emulate the I2C responses from the pi official display!)
Can somebody help me understand the various layers involved with a display?
Some posts imply the device tree should hook the display directly to the dsi hardware entity.
Others imply it should be hooked to vc4-dsi, and thence to the dsi hardware
I'm not sure whether the posts concerned reflect a subtle change in the way the R-Pi firmware works, or whether these are just two ways to achieve the end result.
So I'm struggling to understand the hierarchy of dsi, drm, vc4 etc. etc.
Can anyone help me understand the correct order to 'wire' things up in the device tree?

[mbt28]

Yes - I have managed to make it work in that I can get a picture by kidding the R-Pi that it has an Official display attached.
You may like to look at https://e2e.ti.com/support/interface/di ... 0/t/670554 where you'll see a little about my 'mission of discovery'!
I have not yet cracked the mysteries of "device tree" entries to get my own driver to work properly - but it should be possible.
Use Texas's 'DSI Tuner' software to calculate the register values.
The Official display calls up 333.3333 MHz DSI clock. Only lane 0 is used. Happy to compare config register values with you - especially if you can help me with the Device Tree stuff!
ADDENDUM: I found that the DC level of the DSI clock seems too low for the TI chip to recognise the presence of the clock. I had to use two 2k resistors from Vcore of the TI chip to each of CP and CN. Once I'd done that, the chip seemed to clock OK

Hi I have built one prototype but unfortunately it is not usable because of soldering issues. I just finished the design of new interface but I havent ordered it yet. Since TI chip is quite pricey I dont want to sacrifice another chip. Can you please share the shematic of your clock implementation? Have you done anything to the data lanes? Could you able to make the hardware work properly beside raspberyy pis firmware issues?

You can see my schematic attached.

Thanks

[Chris_G_Miller]

Yes, it all works - but take note of my need to provide some DC bias on the DSI clock lines in my post (2k pullup on each wire) - did not have to mess with the Data lanes.
I have now revised my design to use the I2C interface chip you managed to find, and it works a treat.
I will shortly be re-visiting the firmware trickery/device tree stuff to see if I can get rid of the extra 'PIC' spoofing the official display protocol on the I2C line.

[mbt28]

Yes, it all works - but take note of my need to provide some DC bias on the DSI clock lines in my post (2k pullup on each wire) - did not have to mess with the Data lanes.
I have now revised my design to use the I2C interface chip you managed to find, and it works a treat.
I will shortly be re-visiting the firmware trickery/device tree stuff to see if I can get rid of the extra 'PIC' spoofing the official display protocol on the I2C line.

Hi,

Thank you for your quick response, but in normal conditions dsi clock voltages should be same in all devices, why do we have this problem with RPI?

I am not really good with differential signalling, should I put pullups to both - and + lanes?

Thanks

[Chris_G_Miller]

Just the clock lines, not the data lanes

[mbt28]

Just the clock lines, not the data lanes

Hi,

Is it okay as attached? As I know DSI clock uses 1.2V level, is okay to use 1.8V?

Thanks

[Chris_G_Miller]

I pulled them up to the Vcore pin on the interface chip (pin 31), as I think that is the internal supply for the DSI line receivers. It worked for me. As you say, it is unclear why this should be necessary, but it appears to be.

[mbt28]

I pulled them up to the Vcore pin on the interface chip (pin 31), as I think that is the internal supply for the DSI line receivers. It worked for me. As you say, it is unclear why this should be necessary, but it appears to be.

Hi Chris,

If I change 1.8V to Vcore supply the schematic that I attached should be same as yours, am I correct? I am just worried about pulling "-" lane the same way I pulled high the "+" lane.

Sorry for repetitive messages but I think it would be helpful for other people.

Thanks

[Chris_G_Miller]

The word 'lane' is not the same as 'line' The 'lanes' are the data pairs. The two clock 'lines' operate differentially, so we are needing to pull them both up a little to meet the common mode range required by the Texas chip.
So it is correct that they are both pulled in the same direction.

[s.risler]

Hi,

Chris_G_Miller, thank you for this post ! We are trying to do the same, but it is fairly difficult to anticipate what to do to make it work. Did you managed to get rid off of all your problem? Can you provide information ?

Thank you very much for your help !