Hi Tomi, I am working to cast the timing calculations and register setup for our ssd2858 video processor and rotator into a native omapdss driver.
The setup is that the OMAP5 MIPI channel A drives the inputs of the ssd encoder and the MIPITX output of the encoder drives the panel, for which we have a separate driver that works (if we bridge the ssd2858 chip and the panel directly receives the MIPI video stream).
I am still fighting with correct architecture for this and getting the pieces to interwork.
I have tried to follow the design patterns and code of the encoer-tfp410 and encoder-opa362 and the panel is initialized and calls the ssd2858_connect() function. I.e. I assume the DT nodes are correctly setting up the basics.
But then trouble starts: the boot process hangs after creating the X11 socket and I have not found a way to debug this. Some LEDs are (software) blinking but I can't login: through the console at this stage.
startx hasn't even been called (I had removed it), so that it is a misleading symptom. I have a guess that it is the text console which tries to initialize let's say a (0 x 0) text terminal or something and then hangs it in a way that it also blocks normal getty initialization. But it is only a guess which might be wrong. The last kernel log activity is:
[ 8.423807] dsi: ssd2858_probe ok [ 8.512172] [drm] Initialized drm 1.1.0 20060810 [ 8.803653] driver_register 'btl507212-w677l' [ 8.809926] dsi: w677l_probe() [ 8.813136] dsi: w677l_probe_of() [ 8.817784] dsi: w677l_probe ok [ 9.232203] driver_register 'omapdrm' [ 9.240322] omap_connect_dssdevs [ 9.243754] omap_connect_dssdevs: hdmi [ 9.252127] dss_mgr_connect 1 hdmi.0 [ 9.256846] omap_connect_dssdevs: lcd [ 9.262098] dsi: w677l_connect() [ 9.265544] dsi: ssd2858: ssd2858_connect [ 9.269942] dsi_connect /dsi.0 -> /dsi.0 [ 9.277707] dss_mgr_connect 0 dsi.0 [ 9.283323] dsi: ssd2858: ssd2858_request_vc [ 9.288012] dsi: ssd2858: ssd2858_request_vc assigned channel 0 [ 9.294275] dsi: ssd2858: ssd2858_set_vc_id [ 9.299807] dsi: ssd2858: ssd2858_request_vc [ 9.304321] dsi: ssd2858: ssd2858_request_vc assigned channel 1 [ 9.311670] dsi: ssd2858: ssd2858_set_vc_id [ 9.317264] dsi: w677l_connect() ok [ 9.320957] omap_connect_dssdevs done !no_displays [ 9.356554] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.365465] [drm] No driver support for vblank timestamp query. [ 9.373257] dsi: w677l_disable() [ 9.378238] [CONNECTOR:26:HDMI-A-1] [ 9.381943] [CONNECTOR:30:Unknown-1] [ 9.387303] omap_connector_mode_valid() [ 9.391366] check_timings() [ 9.394332] dsi: w677l_check_timings() [ 9.399032] [CONNECTOR:30:Unknown-1] probed modes : [ 9.404196] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 9.464559] [drm] Enabling DMM ywrap scrolling
(includes some debug logging I have added through omapdss).
What I never see is that the panel (or ssd) gets an enable() call, unless I disable the ssd chip in device tree in which case the panel is enabled and works.
So something hangs between panel connect and panel enable if my encoder driver is included in the pipeline.
I understand that things work as follows: * both drivers are probed * both drivers register themselves with the omapdss system * only the panel driver receives a connect() because it has a display alias * it should trigger the encoder driver to connect() to the omap * and the panel receives a check_timings() * later on the panel should receive an enable() which also should enable the panel and be forwarded to the encoder * the encoder enables and programs the registers
What is also not exactly clear to me is the relation between the in->ops.dsi->something() and in->driver.something().
And how the timing parameters are to be initialized correctly. There are 3 (?) locations where I have to define them. One before registration in the probe() method, then in the dsi_config and the last is get_timings().
This also raises the question how we can properly initialize the timings data that the ssd2858 driver reports to the omap during omapdss_register_output().
The problem is that we have to calculate the proper timings based on the panel timings. But at this stage of driver set up we do not know the panel through dssdev->dst() and hence can't ask it for its timings. And it has not even been probed.
Not initializing dssdev->panel.timings before omapdss_register_output and assuming that get_timings() is called later on (is it ever called???) leads to strange effects.
So please can you take a look over the encoder driver code to assess if we are on the right path or are doing something fundamentally wrong.
BR and thanks, Nikolaus
encoder-solomon-ssd2858:
panel-boe-w677:
device tree (appears to do exactly what I expect):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/omap5-letux-cortex15.dts;hb=refs/heads/letux-4.6-rc5#l79 http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/boot/dts/pyra-display.dtsi;hb=refs/heads/letux-4.6-rc5
Hi,
So just a quick reply, I didn't go through all the material:
On 26/04/16 16:12, H. Nikolaus Schaller wrote:
Hi Tomi, I am working to cast the timing calculations and register setup for our ssd2858 video processor and rotator into a native omapdss driver.
The setup is that the OMAP5 MIPI channel A drives the inputs of the ssd encoder and the MIPITX output of the encoder drives the panel, for which we have a separate driver that works (if we bridge the ssd2858 chip and the panel directly receives the MIPI video stream).
I am still fighting with correct architecture for this and getting the pieces to interwork.
I have tried to follow the design patterns and code of the encoer-tfp410 and encoder-opa362 and the panel is initialized and calls the ssd2858_connect() function. I.e. I assume the DT nodes are correctly setting up the basics.
The 'port' in 'dss' node is for MIPI DPI outputs. You should not have anything there.
The ports and endpoints are used to connect the video path. You have DSS DSI, ssd2858 encoder and panel, and thus you should have the endpoints go between those.
The parent-child relationships of the nodes represent the command path. If I understand right, the ssd2858 is a DSI peripheral, so it should be under DSS's DSI node. Similarly, if the panel is a DSI panel, it should be under ssd2858 node.
However, this setup requires ssd2858 to manage its children, and that's never been done. So ssd2858 should create a DSI bus to which the panel registers (similarly to what DSS's DSI does). I'm not sure if there are problems there.
I have a somewhat similar setup on one of my boards (MIPI DPI -> encoder -> DSI panel), which has the same issue, but I haven't yet started to work on it.
But then trouble starts: the boot process hangs after creating the X11 socket and I have not found a way to debug this. Some LEDs are (software) blinking but I can't login: through the console at this stage.
startx hasn't even been called (I had removed it), so that it is a misleading symptom. I have a guess that it is the text console which tries to initialize let's say a (0 x 0) text terminal or something and then hangs it in a way that it also blocks normal getty initialization. But it is only a guess which might be wrong. The last kernel log activity is:
Are you using omapdrm? If so, you can disable fbconsole and maybe fbdev. That will help in the case that fbconsole has console lock taken when a crash happens (and nothing is printed).
[ 8.423807] dsi: ssd2858_probe ok [ 8.512172] [drm] Initialized drm 1.1.0 20060810 [ 8.803653] driver_register 'btl507212-w677l' [ 8.809926] dsi: w677l_probe() [ 8.813136] dsi: w677l_probe_of() [ 8.817784] dsi: w677l_probe ok [ 9.232203] driver_register 'omapdrm' [ 9.240322] omap_connect_dssdevs [ 9.243754] omap_connect_dssdevs: hdmi [ 9.252127] dss_mgr_connect 1 hdmi.0 [ 9.256846] omap_connect_dssdevs: lcd [ 9.262098] dsi: w677l_connect() [ 9.265544] dsi: ssd2858: ssd2858_connect [ 9.269942] dsi_connect /dsi.0 -> /dsi.0 [ 9.277707] dss_mgr_connect 0 dsi.0 [ 9.283323] dsi: ssd2858: ssd2858_request_vc [ 9.288012] dsi: ssd2858: ssd2858_request_vc assigned channel 0 [ 9.294275] dsi: ssd2858: ssd2858_set_vc_id [ 9.299807] dsi: ssd2858: ssd2858_request_vc [ 9.304321] dsi: ssd2858: ssd2858_request_vc assigned channel 1 [ 9.311670] dsi: ssd2858: ssd2858_set_vc_id [ 9.317264] dsi: w677l_connect() ok [ 9.320957] omap_connect_dssdevs done !no_displays [ 9.356554] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.365465] [drm] No driver support for vblank timestamp query. [ 9.373257] dsi: w677l_disable() [ 9.378238] [CONNECTOR:26:HDMI-A-1] [ 9.381943] [CONNECTOR:30:Unknown-1] [ 9.387303] omap_connector_mode_valid() [ 9.391366] check_timings() [ 9.394332] dsi: w677l_check_timings() [ 9.399032] [CONNECTOR:30:Unknown-1] probed modes : [ 9.404196] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 9.464559] [drm] Enabling DMM ywrap scrolling
(includes some debug logging I have added through omapdss).
What I never see is that the panel (or ssd) gets an enable() call, unless I disable the ssd chip in device tree in which case the panel is enabled and works.
So something hangs between panel connect and panel enable if my encoder driver is included in the pipeline.
I understand that things work as follows:
- both drivers are probed
- both drivers register themselves with the omapdss system
- only the panel driver receives a connect() because it has a display alias
- it should trigger the encoder driver to connect() to the omap
- and the panel receives a check_timings()
- later on the panel should receive an enable() which also should enable the panel and be forwarded to the encoder
- the encoder enables and programs the registers
Yes, all the above are true.
What is also not exactly clear to me is the relation between the in->ops.dsi->something() and in->driver.something().
Yes, it's "interesting". Legacy stuff, etc. =).
in->driver.something is what the driver at the end of the display chain offers. I.e. panel or a connector. It has operations which are not exactly related to any display bus, but more to the whole pipeline. These are called by the omapdrm or omapfb when they want to e.g. enable a display.
in->ops.dsi->something is what a driver inside the the video pipeline offers, specific to the bus in question. DSS's DSI and the ssd2858 have DSI outputs, so both of them should offer dsi ops. A DSI peripheral (in your case, ssd2858 and the panel) can use the dsi ops to do DSI operations.
And how the timing parameters are to be initialized correctly. There are 3 (?) locations where I have to define them. One before registration in the probe() method, then in the dsi_config and the last is get_timings().
This also raises the question how we can properly initialize the timings data that the ssd2858 driver reports to the omap during omapdss_register_output().
The problem is that we have to calculate the proper timings based on the panel timings. But at this stage of driver set up we do not know the panel through dssdev->dst() and hence can't ask it for its timings. And it has not even been probed.
Not initializing dssdev->panel.timings before omapdss_register_output and assuming that get_timings() is called later on (is it ever called???) leads to strange effects.
Yes, there might be issues there. I've noticed something odd there too. In your case, I guess you can just use fixed timings in the panel and ssd drivers to get forward?
Tomi
Hi,
Am 26.04.2016 um 18:31 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
So just a quick reply, I didn't go through all the material:
no problem, it was already extremely valuable.
On 26/04/16 16:12, H. Nikolaus Schaller wrote:
Hi Tomi, I am working to cast the timing calculations and register setup for our ssd2858 video processor and rotator into a native omapdss driver.
The setup is that the OMAP5 MIPI channel A drives the inputs of the ssd encoder and the MIPITX output of the encoder drives the panel, for which we have a separate driver that works (if we bridge the ssd2858 chip and the panel directly receives the MIPI video stream).
I am still fighting with correct architecture for this and getting the pieces to interwork.
I have tried to follow the design patterns and code of the encoer-tfp410 and encoder-opa362 and the panel is initialized and calls the ssd2858_connect() function. I.e. I assume the DT nodes are correctly setting up the basics.
The 'port' in 'dss' node is for MIPI DPI outputs. You should not have anything there.
Indeed, this seems to be a relict of earlier experiments. There is no reference &dsi_out anywhere.
The ports and endpoints are used to connect the video path. You have DSS DSI, ssd2858 encoder and panel, and thus you should have the endpoints go between those.
Yes.
The parent-child relationships of the nodes represent the command path. If I understand right, the ssd2858 is a DSI peripheral, so it should be under DSS's DSI node. Similarly, if the panel is a DSI panel, it should be under ssd2858 node.
Well, this was already big discussion because DT maintainers now prefer parent/child relationship which IMHO removes a lot of flexibility. Would be like all subroutines used in a function must be defined between { and }...
But I think that can easily be changed later.
However, this setup requires ssd2858 to manage its children, and that's never been done. So ssd2858 should create a DSI bus to which the panel registers (similarly to what DSS's DSI does). I'm not sure if there are problems there.
Basically I have this "bus" but not properly represented by DT subnodes. If I remember correctly the TFP410 doesn't have it either.
And it is indeed sort of "bus". The ssd2858 has two MIPI output ports and can drive multiple panels on them (using virtual channel ids).
We use only one port and one panel so that I will leave this as an excersize to future developers of the ssd driver...
Most urgent is to get the single-panel rotation mode working.
I have a somewhat similar setup on one of my boards (MIPI DPI -> encoder -> DSI panel), which has the same issue, but I haven't yet started to work on it.
Yes, that would be almost the same concept.
But then trouble starts: the boot process hangs after creating the X11 socket and I have not found a way to debug this. Some LEDs are (software) blinking but I can't login: through the console at this stage.
startx hasn't even been called (I had removed it), so that it is a misleading symptom. I have a guess that it is the text console which tries to initialize let's say a (0 x 0) text terminal or something and then hangs it in a way that it also blocks normal getty initialization. But it is only a guess which might be wrong. The last kernel log activity is:
Are you using omapdrm? If so, you can disable fbconsole and maybe fbdev.
fbdev eas already disabled but disabling fbconsole was a miracle :)
That will help in the case that fbconsole has console lock taken when a crash happens (and nothing is printed).
Now I could almost every time boot to a "login:" prompt.
Except for NULL pointer dereferencing (I had forgotten to implement one of the dsi_ops called by the panel driver).
So it appears that if such a panic occurs while the fbconsole is being set up there is no console UART available due to locking.
[ 8.423807] dsi: ssd2858_probe ok [ 8.512172] [drm] Initialized drm 1.1.0 20060810 [ 8.803653] driver_register 'btl507212-w677l' [ 8.809926] dsi: w677l_probe() [ 8.813136] dsi: w677l_probe_of() [ 8.817784] dsi: w677l_probe ok [ 9.232203] driver_register 'omapdrm' [ 9.240322] omap_connect_dssdevs [ 9.243754] omap_connect_dssdevs: hdmi [ 9.252127] dss_mgr_connect 1 hdmi.0 [ 9.256846] omap_connect_dssdevs: lcd [ 9.262098] dsi: w677l_connect() [ 9.265544] dsi: ssd2858: ssd2858_connect [ 9.269942] dsi_connect /dsi.0 -> /dsi.0 [ 9.277707] dss_mgr_connect 0 dsi.0 [ 9.283323] dsi: ssd2858: ssd2858_request_vc [ 9.288012] dsi: ssd2858: ssd2858_request_vc assigned channel 0 [ 9.294275] dsi: ssd2858: ssd2858_set_vc_id [ 9.299807] dsi: ssd2858: ssd2858_request_vc [ 9.304321] dsi: ssd2858: ssd2858_request_vc assigned channel 1 [ 9.311670] dsi: ssd2858: ssd2858_set_vc_id [ 9.317264] dsi: w677l_connect() ok [ 9.320957] omap_connect_dssdevs done !no_displays [ 9.356554] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.365465] [drm] No driver support for vblank timestamp query. [ 9.373257] dsi: w677l_disable() [ 9.378238] [CONNECTOR:26:HDMI-A-1] [ 9.381943] [CONNECTOR:30:Unknown-1] [ 9.387303] omap_connector_mode_valid() [ 9.391366] check_timings() [ 9.394332] dsi: w677l_check_timings() [ 9.399032] [CONNECTOR:30:Unknown-1] probed modes : [ 9.404196] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 9.464559] [drm] Enabling DMM ywrap scrolling
(includes some debug logging I have added through omapdss).
What I never see is that the panel (or ssd) gets an enable() call, unless I disable the ssd chip in device tree in which case the panel is enabled and works.
So something hangs between panel connect and panel enable if my encoder driver is included in the pipeline.
I understand that things work as follows:
- both drivers are probed
- both drivers register themselves with the omapdss system
- only the panel driver receives a connect() because it has a display alias
- it should trigger the encoder driver to connect() to the omap
- and the panel receives a check_timings()
- later on the panel should receive an enable() which also should enable the panel and be forwarded to the encoder
- the encoder enables and programs the registers
Yes, all the above are true.
Fine!
What is also not exactly clear to me is the relation between the in->ops.dsi->something() and in->driver.something().
Yes, it's "interesting". Legacy stuff, etc. =).
in->driver.something is what the driver at the end of the display chain offers. I.e. panel or a connector. It has operations which are not exactly related to any display bus, but more to the whole pipeline. These are called by the omapdrm or omapfb when they want to e.g. enable a display.
Ok. This means they are called only for the end of the pipeline, i.e. the panel, because it has a display alias?
Would explain why it is not called for my man-in-the-middle.
in->ops.dsi->something is what a driver inside the the video pipeline offers, specific to the bus in question. DSS's DSI and the ssd2858 have DSI outputs, so both of them should offer dsi ops. A DSI peripheral (in your case, ssd2858 and the panel) can use the dsi ops to do DSI operations.
Ok, that is fine.
And how the timing parameters are to be initialized correctly. There are 3 (?) locations where I have to define them. One before registration in the probe() method, then in the dsi_config and the last is get_timings().
This also raises the question how we can properly initialize the timings data that the ssd2858 driver reports to the omap during omapdss_register_output().
The problem is that we have to calculate the proper timings based on the panel timings. But at this stage of driver set up we do not know the panel through dssdev->dst() and hence can't ask it for its timings. And it has not even been probed.
Not initializing dssdev->panel.timings before omapdss_register_output and assuming that get_timings() is called later on (is it ever called???) leads to strange effects.
Yes, there might be issues there. I've noticed something odd there too. In your case, I guess you can just use fixed timings in the panel and ssd drivers to get forward?
For a quick hack, yes. I can just copy the panel timings statically into the ssd driver. And do the timings calculations once during probe.
A better solution that really asks the panel driver at the right moment - or postpones omapdss_register_output() until the panel asks for enable() - can be developed later.
This appears to start to work (thanks to your proposal to disable fbconsole for debugging):
[ 17.818046] [CONNECTOR:30:Unknown-1] [ 17.821929] omap_connector_mode_valid() [ 17.826044] check_timings() [ 17.829072] dsi: w677l_check_timings() [ 17.833109] [CONNECTOR:30:Unknown-1] probed modes : [ 17.838343] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 17.849178] omap_encoder_update() [ 17.852703] check_timings() [ 17.855708] dsi: w677l_check_timings() [ 17.859771] omap_encoder_enable()dsi: w677l_enable() [ 17.865079] dsi: w677l_start() [ 17.868773] dsi: ssd2858: ssd2858_bus_lock [ 17.873152] dsi: w677l_power_on() [ 17.876749] dsi: w677l_reset(0) [ 17.880284] dsi: ssd2858: ssd2858_set_config [ 17.884823] dsi_set_config [ 17.888198] dss_pll_calc clkin=19200000 min=4294955296 max=912000000 [ 17.894965] hp clkdco=1800000000 min=150000 max=52000000 [ 17.918742] omapdss DSI error: failed to find suitable DSI clock settings [ 17.925962] dsi: ssd2858: ssd2858_enable [ 18.436902] omapdss PLL error: cannot lock DSS DPLL [ 18.442173] omapdss DSI error: Failed to set dsi clocks [ 18.449386] btl507212-w677l 58004000.encoder:lcd: failed to enable DSI [ 18.456367] dsi: ssd2858: ssd2858_bus_unlock [ 18.460895] btl507212-w677l 58004000.encoder:lcd: enable failed [ 18.467220] omapdrm omapdrm.0: Failed to enable display 'lcd': -5
So I have advanced the code to a point where it tries to set up the OMAP5 video output. Now I have to find out what is wrong with the timing values passed to the dss driver so that it does not find clock settings.
As soon as I have fixed that, I hope that I just have to make DCS/MCS command messages work to program panel and ssd chip (which is a little tricky because panel commands must go through the ssd which has to be switched to a bypass mode)...
BR and thanks, Nikolaus
Short update:
Am 27.04.2016 um 19:38 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 26.04.2016 um 18:31 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
Hi,
So just a quick reply, I didn't go through all the material:
no problem, it was already extremely valuable.
On 26/04/16 16:12, H. Nikolaus Schaller wrote:
Hi Tomi, I am working to cast the timing calculations and register setup for our ssd2858 video processor and rotator into a native omapdss driver.
The setup is that the OMAP5 MIPI channel A drives the inputs of the ssd encoder and the MIPITX output of the encoder drives the panel, for which we have a separate driver that works (if we bridge the ssd2858 chip and the panel directly receives the MIPI video stream).
I am still fighting with correct architecture for this and getting the pieces to interwork.
I have tried to follow the design patterns and code of the encoer-tfp410 and encoder-opa362 and the panel is initialized and calls the ssd2858_connect() function. I.e. I assume the DT nodes are correctly setting up the basics.
The 'port' in 'dss' node is for MIPI DPI outputs. You should not have anything there.
Indeed, this seems to be a relict of earlier experiments. There is no reference &dsi_out anywhere.
The ports and endpoints are used to connect the video path. You have DSS DSI, ssd2858 encoder and panel, and thus you should have the endpoints go between those.
Yes.
The parent-child relationships of the nodes represent the command path. If I understand right, the ssd2858 is a DSI peripheral, so it should be under DSS's DSI node. Similarly, if the panel is a DSI panel, it should be under ssd2858 node.
Well, this was already big discussion because DT maintainers now prefer parent/child relationship which IMHO removes a lot of flexibility. Would be like all subroutines used in a function must be defined between { and }...
But I think that can easily be changed later.
However, this setup requires ssd2858 to manage its children, and that's never been done. So ssd2858 should create a DSI bus to which the panel registers (similarly to what DSS's DSI does). I'm not sure if there are problems there.
Basically I have this "bus" but not properly represented by DT subnodes. If I remember correctly the TFP410 doesn't have it either.
And it is indeed sort of "bus". The ssd2858 has two MIPI output ports and can drive multiple panels on them (using virtual channel ids).
We use only one port and one panel so that I will leave this as an excersize to future developers of the ssd driver...
Most urgent is to get the single-panel rotation mode working.
I have a somewhat similar setup on one of my boards (MIPI DPI -> encoder -> DSI panel), which has the same issue, but I haven't yet started to work on it.
Yes, that would be almost the same concept.
But then trouble starts: the boot process hangs after creating the X11 socket and I have not found a way to debug this. Some LEDs are (software) blinking but I can't login: through the console at this stage.
startx hasn't even been called (I had removed it), so that it is a misleading symptom. I have a guess that it is the text console which tries to initialize let's say a (0 x 0) text terminal or something and then hangs it in a way that it also blocks normal getty initialization. But it is only a guess which might be wrong. The last kernel log activity is:
Are you using omapdrm? If so, you can disable fbconsole and maybe fbdev.
fbdev eas already disabled but disabling fbconsole was a miracle :)
That will help in the case that fbconsole has console lock taken when a crash happens (and nothing is printed).
Now I could almost every time boot to a "login:" prompt.
Except for NULL pointer dereferencing (I had forgotten to implement one of the dsi_ops called by the panel driver).
So it appears that if such a panic occurs while the fbconsole is being set up there is no console UART available due to locking.
[ 8.423807] dsi: ssd2858_probe ok [ 8.512172] [drm] Initialized drm 1.1.0 20060810 [ 8.803653] driver_register 'btl507212-w677l' [ 8.809926] dsi: w677l_probe() [ 8.813136] dsi: w677l_probe_of() [ 8.817784] dsi: w677l_probe ok [ 9.232203] driver_register 'omapdrm' [ 9.240322] omap_connect_dssdevs [ 9.243754] omap_connect_dssdevs: hdmi [ 9.252127] dss_mgr_connect 1 hdmi.0 [ 9.256846] omap_connect_dssdevs: lcd [ 9.262098] dsi: w677l_connect() [ 9.265544] dsi: ssd2858: ssd2858_connect [ 9.269942] dsi_connect /dsi.0 -> /dsi.0 [ 9.277707] dss_mgr_connect 0 dsi.0 [ 9.283323] dsi: ssd2858: ssd2858_request_vc [ 9.288012] dsi: ssd2858: ssd2858_request_vc assigned channel 0 [ 9.294275] dsi: ssd2858: ssd2858_set_vc_id [ 9.299807] dsi: ssd2858: ssd2858_request_vc [ 9.304321] dsi: ssd2858: ssd2858_request_vc assigned channel 1 [ 9.311670] dsi: ssd2858: ssd2858_set_vc_id [ 9.317264] dsi: w677l_connect() ok [ 9.320957] omap_connect_dssdevs done !no_displays [ 9.356554] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 9.365465] [drm] No driver support for vblank timestamp query. [ 9.373257] dsi: w677l_disable() [ 9.378238] [CONNECTOR:26:HDMI-A-1] [ 9.381943] [CONNECTOR:30:Unknown-1] [ 9.387303] omap_connector_mode_valid() [ 9.391366] check_timings() [ 9.394332] dsi: w677l_check_timings() [ 9.399032] [CONNECTOR:30:Unknown-1] probed modes : [ 9.404196] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 9.464559] [drm] Enabling DMM ywrap scrolling
(includes some debug logging I have added through omapdss).
What I never see is that the panel (or ssd) gets an enable() call, unless I disable the ssd chip in device tree in which case the panel is enabled and works.
So something hangs between panel connect and panel enable if my encoder driver is included in the pipeline.
I understand that things work as follows:
- both drivers are probed
- both drivers register themselves with the omapdss system
- only the panel driver receives a connect() because it has a display alias
- it should trigger the encoder driver to connect() to the omap
- and the panel receives a check_timings()
- later on the panel should receive an enable() which also should enable the panel and be forwarded to the encoder
- the encoder enables and programs the registers
Yes, all the above are true.
Fine!
What is also not exactly clear to me is the relation between the in->ops.dsi->something() and in->driver.something().
Yes, it's "interesting". Legacy stuff, etc. =).
in->driver.something is what the driver at the end of the display chain offers. I.e. panel or a connector. It has operations which are not exactly related to any display bus, but more to the whole pipeline. These are called by the omapdrm or omapfb when they want to e.g. enable a display.
Ok. This means they are called only for the end of the pipeline, i.e. the panel, because it has a display alias?
Would explain why it is not called for my man-in-the-middle.
in->ops.dsi->something is what a driver inside the the video pipeline offers, specific to the bus in question. DSS's DSI and the ssd2858 have DSI outputs, so both of them should offer dsi ops. A DSI peripheral (in your case, ssd2858 and the panel) can use the dsi ops to do DSI operations.
Ok, that is fine.
And how the timing parameters are to be initialized correctly. There are 3 (?) locations where I have to define them. One before registration in the probe() method, then in the dsi_config and the last is get_timings().
This also raises the question how we can properly initialize the timings data that the ssd2858 driver reports to the omap during omapdss_register_output().
The problem is that we have to calculate the proper timings based on the panel timings. But at this stage of driver set up we do not know the panel through dssdev->dst() and hence can't ask it for its timings. And it has not even been probed.
Not initializing dssdev->panel.timings before omapdss_register_output and assuming that get_timings() is called later on (is it ever called???) leads to strange effects.
Yes, there might be issues there. I've noticed something odd there too. In your case, I guess you can just use fixed timings in the panel and ssd drivers to get forward?
For a quick hack, yes. I can just copy the panel timings statically into the ssd driver. And do the timings calculations once during probe.
A better solution that really asks the panel driver at the right moment - or postpones omapdss_register_output() until the panel asks for enable() - can be developed later.
This appears to start to work (thanks to your proposal to disable fbconsole for debugging):
[ 17.818046] [CONNECTOR:30:Unknown-1] [ 17.821929] omap_connector_mode_valid() [ 17.826044] check_timings() [ 17.829072] dsi: w677l_check_timings() [ 17.833109] [CONNECTOR:30:Unknown-1] probed modes : [ 17.838343] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 17.849178] omap_encoder_update() [ 17.852703] check_timings() [ 17.855708] dsi: w677l_check_timings() [ 17.859771] omap_encoder_enable()dsi: w677l_enable() [ 17.865079] dsi: w677l_start() [ 17.868773] dsi: ssd2858: ssd2858_bus_lock [ 17.873152] dsi: w677l_power_on() [ 17.876749] dsi: w677l_reset(0) [ 17.880284] dsi: ssd2858: ssd2858_set_config [ 17.884823] dsi_set_config [ 17.888198] dss_pll_calc clkin=19200000 min=4294955296 max=912000000 [ 17.894965] hp clkdco=1800000000 min=150000 max=52000000 [ 17.918742] omapdss DSI error: failed to find suitable DSI clock settings [ 17.925962] dsi: ssd2858: ssd2858_enable [ 18.436902] omapdss PLL error: cannot lock DSS DPLL [ 18.442173] omapdss DSI error: Failed to set dsi clocks [ 18.449386] btl507212-w677l 58004000.encoder:lcd: failed to enable DSI [ 18.456367] dsi: ssd2858: ssd2858_bus_unlock [ 18.460895] btl507212-w677l 58004000.encoder:lcd: enable failed [ 18.467220] omapdrm omapdrm.0: Failed to enable display 'lcd': -5
So I have advanced the code to a point where it tries to set up the OMAP5 video output. Now I have to find out what is wrong with the timing values passed to the dss driver so that it does not find clock settings.
I have fixed the timing calculation and passing issues (pixelclock wasn't set properly and dss min/max clock without range) and can now write DCS commands to the panel and read back (in hardware bypass mode). This means that the kernel code flow is starting to do useful things.
As soon as I have fixed that, I hope that I just have to make DCS/MCS command messages work to program panel and ssd chip (which is a little tricky because panel commands must go through the ssd which has to be switched to a bypass mode)...
It now sounds reasonable to fix initializing the ssd2858 tomorrow and then we may have a much better panel driver in our kernel.
BR, NIkolaus
Am Wed, 27 Apr 2016 19:38:18 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
thanks for the great work, sounds like we're getting there!
However:
[ 17.833109] [CONNECTOR:30:Unknown-1] probed modes : [ 17.838343] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 17.849178] omap_encoder_update()
This is what puzzles me.
Apparently, Linux finds a 720x1280 resolution - which would mean the rotation is disabled (and it's also the reason using the framebuffer or fbturbo-Driver for X doesn't work properly and shows a 720x1280 image rotated on the 1280x720 screen (meaning: The rotation is correct, but the right half of the LCD is black and the desktop goes below the LCD).
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
Am 28.04.2016 um 00:57 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Wed, 27 Apr 2016 19:38:18 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
thanks for the great work, sounds like we're getting there!
However:
[ 17.833109] [CONNECTOR:30:Unknown-1] probed modes : [ 17.838343] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 17.849178] omap_encoder_update()
This is what puzzles me.
Apparently, Linux finds a 720x1280 resolution - which would mean the rotation is disabled (and it's also the reason using the framebuffer or fbturbo-Driver for X doesn't work properly and shows a 720x1280 image rotated on the 1280x720 screen (meaning: The rotation is correct, but the right half of the LCD is black and the desktop goes below the LCD).
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
For checking if rotation setup is correct, we have to run fbset and xrandr on the command line:
root@letux:~# fbset
mode "720x1280" geometry 720 1280 720 1280 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode
root@letux:~# . x DISPLAY=:0 XAUTHORITY=/tmp/serverauth.G1HG49BZwS root@letux:~# xrandr Screen 0: minimum 320 x 200, current 720 x 1280, maximum 2048 x 2048 HDMI-1 disconnected (normal left inverted right x axis y axis) None-1 connected 720x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 720x1280 60.00*+ root@letux:~#
Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching the panel driver? Probably only if we make the ssd chip the panel and remove the real panel from the display aliases?
But I have a first screen output!!!
So the communication of the drivers with each other and the chips is basically working.
Except some timing calculations.
Time for a coffee break :)
BR, Nikolaus
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching the panel driver? Probably only if we make the ssd chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before we even received the first sample of the SSD :D)
Unless there is some setup planned where Linux knows that there is a panel and an SSD, but also knows that the SSD rotates and therefore updates the framebuffer-info.
But I have a first screen output!!!
So the communication of the drivers with each other and the chips is basically working.
Except some timing calculations.
Time for a coffee break :)
BR, Nikolaus
Hi,
Am 28.04.2016 um 14:16 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching the panel driver? Probably only if we make the ssd chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before we even received the first sample of the SSD :D)
Well, that was pure luck to make the right prognosis. Was a 50:50 chance :)
For the TV-Out (Pandora) or other chips it is not a problem.
What the real problem is that I want a panel driver and a separate ssd driver while your architecture suggests a combo driver which mixes everything. For the Pyra that would be a sufficient hack but sometime in the future we would like Tomi to mainline it... And we have and need a separate panel driver anyways for easier debugging.
So I am already working towards that goal. Although the most important goal is that you have the new driver for demonstrations on Saturday.
Unless there is some setup planned where Linux knows that there is a panel and an SSD, but also knows that the SSD rotates and therefore updates the framebuffer-info.
Linux already could know all that (it is described in the DT) but it does not use all pieces of information we provide just in a way that it simply works...
The ssd driver for example presents the correct (swapped) dimensions when it is registered, but Linux does not look there when setting up the frame buffer. Rather it looks at the other end of the pipeline which is not what I would expect, but it does.
It if would ask the video source (OMAP DSS DSI submodule) for the framebuffer dimensions and not the panel, it would have been right.
Anyways I will now bridle the horse from the other side...
Which is much easier as we now know that the bridle fits :)
I think we can then even ask the panel for the dimensions because then the ssd driver is master and the panel driver is slave. At the moment it is reversed.
BR, Nikolaus
But I have a first screen output!!!
So the communication of the drivers with each other and the chips is basically working.
Except some timing calculations.
Time for a coffee break :)
BR, Nikolaus
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Hi,
Am 28.04.2016 um 15:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
The ssd driver for example presents the correct (swapped) dimensions when it is registered, but Linux does not look there when setting up the frame buffer. Rather it looks at the other end of the pipeline which is not what I would expect, but it does.
It if would ask the video source (OMAP DSS DSI submodule) for the framebuffer dimensions and not the panel, it would have been right.
Anyways I will now bridle the horse from the other side...
Which is much easier as we now know that the bridle fits :)
I think we can then even ask the panel for the dimensions because then the ssd driver is master and the panel driver is slave. At the moment it is reversed.
It turns out to be very difficult to do it that way. Why?
The panel driver registers itself through omapdss_register_display() which is completely ok and the right solution, if we have no ssd2858.
And the ssd2858 driver registers itself as omapdss_register_output() because it provides MIPI output port(s). This means it is not treated as a panel and therefore its dimensions are sometimes ignored.
This means the current code fits into the concept of how the omapdss driver architecture is intended.
If we want to use it but make the ssd a panel, we have to provide two different drivers for the real panel. One if it is a panel connected directly to the omap and one if it is connected to our special ssd2858 "panel".
Otherwise we can't make the ssd2858 look like "the panel".
And implementing this appears to be more difficult than I had thought some hours earlier.
The only issue we have with the current setup is that the framebuffer does not fetch the correct dimensions from such a setup...
So, maybe, we should patch something there? So that the fb initialization does not ask the panel end but the omap end for frambuffer dimensions...
This would also work as before for the default case without ssd2858.
Unfortuantely I would have to dig even more deeply into the dss driver to find out how the framebuffer asks for dimensions. And how we can make the panel (if asked - when? how?) report the (swapped) coordinates of the ssd.
@Tomi: ideas? proposals? comments?
BR, Nikolaus
Am 28.04.2016 um 18:48 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 28.04.2016 um 15:05 schrieb H. Nikolaus Schaller hns@goldelico.com:
The ssd driver for example presents the correct (swapped) dimensions when it is registered, but Linux does not look there when setting up the frame buffer. Rather it looks at the other end of the pipeline which is not what I would expect, but it does.
It if would ask the video source (OMAP DSS DSI submodule) for the framebuffer dimensions and not the panel, it would have been right.
Anyways I will now bridle the horse from the other side...
Which is much easier as we now know that the bridle fits :)
I think we can then even ask the panel for the dimensions because then the ssd driver is master and the panel driver is slave. At the moment it is reversed.
It turns out to be very difficult to do it that way. Why?
The panel driver registers itself through omapdss_register_display() which is completely ok and the right solution, if we have no ssd2858.
And the ssd2858 driver registers itself as omapdss_register_output() because it provides MIPI output port(s). This means it is not treated as a panel and therefore its dimensions are sometimes ignored.
This means the current code fits into the concept of how the omapdss driver architecture is intended.
If we want to use it but make the ssd a panel, we have to provide two different drivers for the real panel. One if it is a panel connected directly to the omap and one if it is connected to our special ssd2858 "panel".
Otherwise we can't make the ssd2858 look like "the panel".
And implementing this appears to be more difficult than I had thought some hours earlier.
The only issue we have with the current setup is that the framebuffer does not fetch the correct dimensions from such a setup...
So, maybe, we should patch something there? So that the fb initialization does not ask the panel end but the omap end for frambuffer dimensions...
This would also work as before for the default case without ssd2858.
Unfortuantely I would have to dig even more deeply into the dss driver to find out how the framebuffer asks for dimensions. And how we can make the panel (if asked - when? how?) report the (swapped) coordinates of the ssd.
@Tomi: ideas? proposals? comments?
More specifically:
From
[ 8.295677] [CONNECTOR:26:HDMI-A-1] [ 8.299452] [CONNECTOR:30:Unknown-1] [ 8.303533] omap_connector_mode_valid() [ 8.307729] check_timings() [ 8.310758] dsi: w677l_check_timings() [ 8.314886] [CONNECTOR:30:Unknown-1] probed modes : [ 8.320134] Modeline 35:"720x1280" 60 76723 720 725 730 888 1280 1330 1390 1440 0x48 0xa [ 8.368237] [drm] Enabling DMM ywrap scrolling [ 8.381485] omapdrm omapdrm.0: fb0: omapdrm frame buffer device [ 8.414457] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
I think the omapdrm framebuffer seems to call panel->check_timings(). And there it is possible to return different timings (i.e. swap xres and yres).
The default implementation does nothing except returning 0.
Is this analysis right?
But how does the panel driver know that it should rotate?
BR, Nikolaus
On 28/04/16 16:05, H. Nikolaus Schaller wrote:
Hi,
Am 28.04.2016 um 14:16 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching the panel driver? Probably only if we make the ssd chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before we even received the first sample of the SSD :D)
Well, that was pure luck to make the right prognosis. Was a 50:50 chance :)
For the TV-Out (Pandora) or other chips it is not a problem.
What the real problem is that I want a panel driver and a separate ssd driver while your architecture suggests a combo driver which mixes everything.
I haven't been able to follow the discussion here (and please To: or Cc: me if you want my reply, I won't notice the emails sent only to pyra list), but one thing to consider:
The current panel/encoder model is omap specific, and should be thrown away as soon as possible. For this reason, I'm very reluctant to merge any new omap specific panels/encoders to upstream.
I'm not sure when this work to move to common DRM panels/encoders will happen (and it's a big one), but for the time being, if it makes your case easier, I think you should just go with a "combined" driver, which has both SSD and the panel drivers in one.
It's not 100% correct approach, but if it makes the display work easier, I recommend that approach instead of trying to create a perfect driver (which can't be upstreamed).
Tomi
Hi Tomi,
Am 10.05.2016 um 14:29 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 28/04/16 16:05, H. Nikolaus Schaller wrote:
Hi,
Am 28.04.2016 um 14:16 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate" that without touching the panel driver? Probably only if we make the ssd chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before we even received the first sample of the SSD :D)
Well, that was pure luck to make the right prognosis. Was a 50:50 chance :)
For the TV-Out (Pandora) or other chips it is not a problem.
What the real problem is that I want a panel driver and a separate ssd driver while your architecture suggests a combo driver which mixes everything.
I haven't been able to follow the discussion here (and please To: or Cc: me if you want my reply, I won't notice the emails sent only to pyra list),
no problem. At the moment I think it is not a general omapdss problem but something in controlling the ssd chip correctly where you could only help if you had a piece of hardware to run tests.
but one thing to consider:
The current panel/encoder model is omap specific, and should be thrown away as soon as possible.
Agreed. I was contacted recently by a team that wanted to hire me to write a driver for the ssd2858 to connect to a snapdragon. But that would mean a complete rewrite IMHO.
For this reason, I'm very reluctant to merge any new omap specific panels/encoders to upstream.
Also no problem. We need a working driver first before we think about upstreaming :) If we have such a reference driver it can be used as a starting (and benchmark) for any new type of drivers.
I'm not sure when this work to move to common DRM panels/encoders will happen (and it's a big one), but for the time being, if it makes your case easier, I think you should just go with a "combined" driver, which has both SSD and the panel drivers in one.
I can simulate such a setup if I "disable" the panel driver or make it not send DCS commands.
And if I disable the ssd side and use a display board without ssd chip installed (but MIPI signals bridged in hardware), the panel driver works even in our two-staged setup.
It's not 100% correct approach, but if it makes the display work easier, I recommend that approach instead of trying to create a perfect driver (which can't be upstreamed).
I think that the problem is not that we have two interacting drivers. They appear to interact perfectly and now seem to do what they should do (with backwards and forward calls).
The problem is that if I read out the ssd2858 registers and the ompadss debugfs I can't find a significant difference to our working hack with the mipi-debug driver + shell script. But it works only with the hack.
So the only idea not fully tested is some timing and sequence issue with chip reset and turning on/off dsi and video streams.
And another idea is that it has something to do with the "atomic timeouts" we see in the working driver.
I have checked recently and this means that some dss update should wait until a vertical retrace interrupt. Seeing "atomic timeouts" means that some actions occur too fast before the previous one was finished.
But these messages are not triggered by the driver or the dss subsystem. They are triggered as soon as X11 wants to initialize.
So this means that the mipi-panel-debug driver + shell script violates some condition - which might be exactly what the ssd chip needs to work...
BR, Nikolaus
Hi,
One thing comes to my mind: Could the difference be that with our hacky script the MIPI stream from the OMAP is already initialized (meaning: when you enable the SSD with the script it receives a proper video stream) whereas there's no video stream being sent already when you start the SSD as kernel module?
Maybe the SSD reads the video stream details as soon as it is enabled and has improper values if there's no existing video stream, causing it to run completely unsynchronized?
On May 10, 2016 5:41:35 PM GMT+02:00, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Hi Tomi,
Am 10.05.2016 um 14:29 schrieb Tomi Valkeinen
On 28/04/16 16:05, H. Nikolaus Schaller wrote:
Hi,
Am 28.04.2016 um 14:16 schrieb Michael Mrozek
Am Thu, 28 Apr 2016 10:00:03 +0200 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
Shouldn't Linux find a 1280x720 screen mode when the rotator is working properly?
This appears to report the resolution for the connector (= panel).
That's what I thought.
Ok, this looks indeed to be wrong. Hm. How can we "manipulate"
that
without touching the panel driver? Probably only if we make the
ssd
chip the panel and remove the real panel from the display aliases?
Yes, I think that's the best solution (and what I suggested before
we
even received the first sample of the SSD :D)
Well, that was pure luck to make the right prognosis. Was a 50:50
chance :)
For the TV-Out (Pandora) or other chips it is not a problem.
What the real problem is that I want a panel driver and a separate
ssd
driver while your architecture suggests a combo driver which mixes
everything.
I haven't been able to follow the discussion here (and please To: or
Cc:
me if you want my reply, I won't notice the emails sent only to pyra list),
no problem. At the moment I think it is not a general omapdss problem but something in controlling the ssd chip correctly where you could only help if you had a piece of hardware to run tests.
but one thing to consider:
The current panel/encoder model is omap specific, and should be
thrown
away as soon as possible.
Agreed. I was contacted recently by a team that wanted to hire me to write a driver for the ssd2858 to connect to a snapdragon. But that would mean a complete rewrite IMHO.
For this reason, I'm very reluctant to merge any new omap specific panels/encoders to upstream.
Also no problem. We need a working driver first before we think about upstreaming :) If we have such a reference driver it can be used as a starting (and benchmark) for any new type of drivers.
I'm not sure when this work to move to common DRM panels/encoders
will
happen (and it's a big one), but for the time being, if it makes your case easier, I think you should just go with a "combined" driver,
which
has both SSD and the panel drivers in one.
I can simulate such a setup if I "disable" the panel driver or make it not send DCS commands.
And if I disable the ssd side and use a display board without ssd chip installed (but MIPI signals bridged in hardware), the panel driver works even in our two-staged setup.
It's not 100% correct approach, but if it makes the display work
easier,
I recommend that approach instead of trying to create a perfect
driver
(which can't be upstreamed).
I think that the problem is not that we have two interacting drivers. They appear to interact perfectly and now seem to do what they should do (with backwards and forward calls).
The problem is that if I read out the ssd2858 registers and the ompadss debugfs I can't find a significant difference to our working hack with the mipi-debug driver + shell script. But it works only with the hack.
So the only idea not fully tested is some timing and sequence issue with chip reset and turning on/off dsi and video streams.
And another idea is that it has something to do with the "atomic timeouts" we see in the working driver.
I have checked recently and this means that some dss update should wait until a vertical retrace interrupt. Seeing "atomic timeouts" means that some actions occur too fast before the previous one was finished.
But these messages are not triggered by the driver or the dss subsystem. They are triggered as soon as X11 wants to initialize.
So this means that the mipi-panel-debug driver + shell script violates some condition - which might be exactly what the ssd chip needs to work...
BR, Nikolaus
Hi,
Am 10.05.2016 um 22:21 schrieb Michael Mrozek EvilDragon@openpandora.org:
Hi,
One thing comes to my mind: Could the difference be that with our hacky script the MIPI stream from the OMAP is already initialized (meaning: when you enable the SSD with the script it receives a proper video stream) whereas there's no video stream being sent already when you start the SSD as kernel module?
The script has control over turning off/on the video stream and it should be turned on at a certain step of the script.
I have tried to add thousands of printk() to the kernel [1] to verify that the sequence is the same. And it appears to be the same.
Maybe the SSD reads the video stream details as soon as it is enabled and has improper values if there's no existing video stream, causing it to run completely unsynchronized?
Yes that is amongst one of my current theories.
The most puzzling symptom is that I see slightly different looking ssd output signals with oscilloscope although ssd register settings are the same.
a) ssd has different input signals when coming out of reset
this might lead to different ssd behaviour although ssd registers get and show the same settings
b) "atomic complete timeout" in script mode makes it work
afaik, the omap dss system has shadow registers for controlling timings. Those are updated on demand and during vertical retrace to avoid flicker. And this is called "atomic complete".
The timeout indicates some violation in script mode. This could mean that we read the shadow registers correctly through debugfs (i.e. what the kernel thinks it has been programmed), but the dss and dispc still use some default or initial timing settings (because the update failed). These wrong and hidden timing settings could make it work.
BR, Nikolaus
[1]: http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=be7be2a6559f2812d3bf...