drm/tilcdc: Add bridge support and sync-lost flood recovery
Subsystems (5)
v2 cover drm/tilcdc: Add bridge support and sync-lost flood recovery
Changes since first version of the series:
- "drm/tilcdc: Recover from sync lost error flood by resetting the LCDC"
- no change
- "drm/bridge: Add ti-tfp410 DVI transmitter driver"
- HDMI -> DVI
- DT Binding document
- Prepare for tfp410 connected trough i2c by optional reg property
- Require two port nodes
- Implementation
- Implement connector node functionality with in tfp410 bridge drive, but follow generic connector binding by pulling the ddc-i2c-bus property from the connector node.
- "drm/tilcdc: Add drm bridge support for attaching drm bridge drivers"
- Remove earlier change in TD binding document. There is no need to mention DRM implementation details, like bridge support, in DT binding.
The first patch is an independent on and I've been testing it for quite a while now.
The tfp410 bridge driver and the tilcdc bridge support are tested with BeagleBone DVI-D Cape Rev A3. The tfp410 bridge driver is missing a lot of features, because the DVI-D cape does not have too many wires connected. The missing features can be added later when they are needed.
Jyri Sarha (3):
drm/tilcdc: Recover from sync lost error flood by resetting the LCDC drm/bridge: Add ti-tfp410 DVI transmitter driver drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
.../bindings/display/bridge/ti,tfp410.txt | 41 ++++ drivers/gpu/drm/bridge/Kconfig | 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++ drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 ++- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +- drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 + drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++++++++++-- drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 + 9 files changed, 428 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
Signature · 6 lines
1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 1/3 drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
Recover from sync lost error flood by resetting the LCDC instead of turning off the SYNC_LOST error IRQ. When LCDC starves on limited memory bandwidth it may sometimes result an error situation when the picture may have shifted couple of pixels to right and SYNC_LOST interrupt is generated on every frame. LCDC main reset recovers from this situation and causes a brief blanking on the screen.
--- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-)
drivers/gpu/drm/tilcdc/tilcdc_crtc.c +25 -1
@@ -55,6 +55,7 @@ struct tilcdc_crtc {int sync_lost_count;bool frame_intact; +struct work_struct recover_work; };#define to_tilcdc_crtc (x) container_of(x, struct tilcdc_crtc, base)
@@ -252,6 +253,25 @@ static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)return crtc->state && crtc->state->enable && crtc->state->active; } +static void tilcdc_crtc_recover_work (struct work_struct *work) +{ +struct tilcdc_crtc *tilcdc_crtc = + container_of(work, struct tilcdc_crtc, recover_work); +struct drm_crtc *crtc = &tilcdc_crtc->base; + +dev_info (crtc->dev->dev,"%s: Reset CRTC" , __func__); + +drm_modeset_lock_crtc (crtc,NULL ); + +if (!tilcdc_crtc_is_on (crtc)) + goto out; + +tilcdc_crtc_disable (crtc); +tilcdc_crtc_enable (crtc); +out: +drm_modeset_unlock_crtc (crtc); +} +static void tilcdc_crtc_destroy (struct drm_crtc *crtc) {struct tilcdc_crtc *tilcdc_crtc =to_tilcdc_crtc (crtc);
@@ -838,9 +858,12 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc) tilcdc_crtc->frame_intact = false;if (tilcdc_crtc->sync_lost_count++ >SYNC_LOST_COUNT_LIMIT ) { -dev_err (dev->dev,"%s(0x%08x): Sync lost flood detected, disabling the interrupt" , __func__, stat); +dev_err (dev->dev,"%s(0x%08x): Sync lost flood detected, recovering" , __func__, stat); +queue_work (system_wq, + &tilcdc_crtc->recover_work);tilcdc_write (dev,LCDC_INT_ENABLE_CLR_REG ,LCDC_SYNC_LOST ); + tilcdc_crtc->sync_lost_count =0 ; } }
@@ -880,6 +903,7 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev) "unref", unref_worker);spin_lock_init (&tilcdc_crtc->irq_lock); +INIT_WORK (&tilcdc_crtc->recover_work, tilcdc_crtc_recover_work); ret = drm_crtc_init_with_planes(dev, crtc, &tilcdc_crtc->primary,
Signature · 6 lines
1.9.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v2 2/3 drm/bridge: Add ti-tfp410 DVI transmitter driver
Add very basic ti-ftp410 DVI transmitter driver. The only feature separating this from a completely dummy bridge is the EDID read support trough DDC I2C. Even that functionality should be in a separate generic connector driver. However, because of missing DRM infrastructure support the connector is implemented within the bridge driver. Some tfp410 HW specific features may be added later if needed, because there is a set of registers behind i2c if it is connected.
This implementations is tested against my new tilcdc bridge support and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document is also added.
--- .../bindings/display/bridge/ti,tfp410.txt | 41 ++++ drivers/gpu/drm/bridge/Kconfig | 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++ 4 files changed, 272 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +41 -0
@@ -0,0 +1,41 @@ +TFP410 DVI bridge bindings + +Required properties: + - compatible: "ti,tfp410" + +Optional properties + - reg: I2C address. If and only if present the driver node + should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this). + +Required subnodes: + - port@0: Video input port node to connect the bridge to a + display controller output [1]. + - port@1: Video output port node to connect the bridge to a + connector input [1]. + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + hdmi-bridge { + compatible = "ti,tfp410"; + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + bridge_in: endpoint { + remote-endpoint = <&dc_out>; + }; + }; + + port@1 { + reg = <1>; + bridge_out: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; + }; + };
drivers/gpu/drm/bridge/Kconfig +7 -0
@@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767 ---help--- Toshiba TC358767 eDP bridge chip driver. +config DRM_TI_TFP410 + tristate "TI TFP410 DVI/HDMI bridge" + depends on OF + select DRM_KMS_HELPER + ---help--- + Texas Instruments TFP410 DVI/HDMI Transmitter driver + source "drivers/gpu/drm/bridge/analogix/Kconfig" source "drivers/gpu/drm/bridge/adv7511/Kconfig"
drivers/gpu/drm/bridge/Makefile +1 -0
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
drivers/gpu/drm/bridge/ti-tfp410.c new file +223 -0
223 lines not on this page · raw message
Signature · 6 lines
1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Herring
maintainerRe: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Quoted 28 lines · Jyri Sarha
Add very basic ti-ftp410 DVI transmitter driver. The only feature separating this from a completely dummy bridge is the EDID read support trough DDC I2C. Even that functionality should be in a separate generic connector driver. However, because of missing DRM infrastructure support the connector is implemented within the bridge driver. Some tfp410 HW specific features may be added later if needed, because there is a set of registers behind i2c if it is connected.
This implementations is tested against my new tilcdc bridge support and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document is also added.
Signed-off-by Jyri Sarha <[email protected]>--- .../bindings/display/bridge/ti,tfp410.txt | 41 ++++ drivers/gpu/drm/bridge/Kconfig | 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++ 4 files changed, 272 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.cDocumentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +0
-0
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 10
Quoted 10 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +10
-0@@ -0,0 +1,41 @@ +TFP410 DVI bridge bindings + +Required properties: + - compatible: "ti,tfp410" + +Optional properties + - reg: I2C address. If and only if present the driver node + should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this).
So this chip can work without programming I guess?
reg should only be not present if I2C is not connected in the design. It can't be a function of what the driver supports. In otherwords, you can't be moving this node around based on when you add I2C control.
Rob
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Quoted 7 lines · Rob Herring
Quoted 5 lines
+Optional properties
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 10
Quoted 4 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +4
-0+ - reg: I2C address. If and only if present the driver node + should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this).So this chip can work without programming I guess?
Yes. Just powering it up is enough for most application.
Quoted 4 lines
reg should only be not present if I2C is not connected in the design. It can't be a function of what the driver supports. In otherwords, you can't be moving this node around based on when you add I2C control.
Ok, I'll try to implement a dummy i2c driver at the same time too. I can not test anything related to it because I do not have a piece of HW with tfp410 i2c wires connected, but it should not matter as long as I am able to probe it as a i2c client.
Thanks,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Quoted 10 lines · Jyri Sarha
Quoted 7 lines · Rob Herring
Quoted 5 lines
+Optional properties
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 10
Quoted 4 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +4
-0+ - reg: I2C address. If and only if present the driver node + should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this).So this chip can work without programming I guess?
Yes. Just powering it up is enough for most application.
Right, and not only that, but in all the TI boards I have seen TFP410's i2c pins are not even connected. The data sheet says "[TFP410] can be controlled in two ways: 1) configuration and state pins or 2) the programmable I2C serial interface".
Tomi
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): 506ba969-d753-d026-5357-3329a750ceaf-l0cyMroinI0@public.gmane.org
Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Hi Jyri,
Quoted 4 lines · On Wednesday 16 Nov 2016 16:39:28 Jyri Sarha wrote:
Quoted 3 lines · Rob Herring
Quoted 3 lines
+Optional properties
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 7
Quoted 1 line
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +1
-0+ - reg: I2C address. If and only if present the driver node
I assume you meant device node, not driver node ?
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 10
Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +3
-0+ should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this).So this chip can work without programming I guess?
Yes. Just powering it up is enough for most application.
Quoted 8 lines
Quoted 3 lines
reg should only be not present if I2C is not connected in the design. It can't be a function of what the driver supports. In otherwords, you can't be moving this node around based on when you add I2C control.
Ok, I'll try to implement a dummy i2c driver at the same time too. I can not test anything related to it because I do not have a piece of HW with tfp410 i2c wires connected, but it should not matter as long as I am able to probe it as a i2c client.
I think that Rob's point was that whether the current implementation supports this or not is irrelevant from a DT bindings point of view. It should not be mentioned in the bindings document.
Signature · 8 lines
Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
Quoted 22 lines · Laurent Pinchart
Hi Jyri,
Quoted 4 lines · On Wednesday 16 Nov 2016 16:39:28 Jyri Sarha wrote:
Quoted 3 lines · Rob Herring
Quoted 3 lines
+Optional properties
Quoted 1 line
+ - reg: I2C address. If and only if present the driver node
I assume you meant device node, not driver node ?
Quoted 12 lines
Quoted 5 lines
Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt line 10
Quoted 3 lines
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file +3
-0+ should be placed into the i2c controller node where the + tfp410 i2c is connected to (the current implementation does + not yet support this).So this chip can work without programming I guess?
Yes. Just powering it up is enough for most application.
Quoted 3 lines
reg should only be not present if I2C is not connected in the design. It can't be a function of what the driver supports. In otherwords, you can't be moving this node around based on when you add I2C control.
Quoted 8 lines
Quoted 4 lines
Ok, I'll try to implement a dummy i2c driver at the same time too. I can not test anything related to it because I do not have a piece of HW with tfp410 i2c wires connected, but it should not matter as long as I am able to probe it as a i2c client.
I think that Rob's point was that whether the current implementation supports this or not is irrelevant from a DT bindings point of view. It should not be mentioned in the bindings document.
Right. Now, whether the h/w has I2C wires connected or not is relevant to the binding doc. So the doc just needs some rewording, a dummy driver isn't needed.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v2 3/3 drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
In reply to Jyri SarhaAdds drm bride support for attaching drm bridge drivers to tilcdc. The decision whether a video port leads to an external encoder or bridge is made simply based on remote device's compatible string. The code has been tested with BeagleBone-Black with and without BeagleBone DVI-D Cape Rev A3 using ti-tfp410 driver.
--- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +- drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 + drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++++++++++++++++++++++++++---- drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 + 4 files changed, 131 insertions(+), 19 deletions(-)
drivers/gpu/drm/tilcdc/tilcdc_drv.c +6 -1
@@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct device *dev) ret =tilcdc_add_external_encoders (ddev);if (ret <0 ) goto init_failed; + }else { + ret =tilcdc_attach_remote_device (ddev); +if (ret) + goto init_failed; } -if ((priv->num_encoders ==0 ) || (priv->num_connectors ==0 )) { +if (!priv->remote_encoder && + ((priv->num_encoders ==0 ) || (priv->num_connectors ==0 ))) {dev_err (dev,"no encoders/connectors found\n" ); ret = -ENXIO ; goto init_failed;
drivers/gpu/drm/tilcdc/tilcdc_drv.h +2 -0
@@ -90,6 +90,8 @@ struct tilcdc_drm_private {struct drm_connector *connectors[8 ];const struct drm_connector_helper_funcs *connector_funcs[8 ]; +struct drm_encoder *remote_encoder; +bool is_registered;bool is_componentized; };
drivers/gpu/drm/tilcdc/tilcdc_external.c +122 -18
167 lines not on this page · raw message
drivers/gpu/drm/tilcdc/tilcdc_external.h +1 -0
@@ -22,4 +22,5 @@void tilcdc_remove_external_encoders (struct drm_device *dev);int tilcdc_get_external_components (struct device *dev,struct component_match **match); +int tilcdc_attach_remote_device (struct drm_device *ddev);#endif /* __TILCDC_SLAVE_H__ */
Signature · 6 lines
1.9.1 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): 12cd62cc9ea0f79d0f399c76bfa715125a0816ce.1479142062.git.jsarha-l0cyMroinI0@public.gmane.org
Re: [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
2016-11-14 17:54 GMT+01:00 Jyri Sarha <[email protected]>:
Quoted 8 lines
Adds drm bride support for attaching drm bridge drivers to tilcdc. The decision whether a video port leads to an external encoder or bridge is made simply based on remote device's compatible string. The code has been tested with BeagleBone-Black with and without BeagleBone DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by Jyri Sarha <[email protected]>---
Hi Jyri,
thanks a lot for doing this.
One issue I see with this patch is that tilcdc doesn't seem to support deferred probe correctly (if modules are built-in). The following happens on my setup:
The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returns EPROBE_DEFER and it's propagated to tilcdc probe.
[drm] Initialized
dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus
Then the i2c bus is initialized and dump-vga-dac probe succeeds, but the second probe of tilcdc gives me:
[drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64 [drm:drm_minor_register] *ERROR* DRM: Failed to initialize/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1
I was able to work around this issue by loading modules in correct order.
I then tried testing the patch with a da850-lcdk, but I don't get anything on the display (no signal), even though the LCDC seems to work fine (modetest and dmesg messages work just like when using the tilcdc panel). Also: I see the EDID info is correctly retrieved from the display.
Could you take a look at my DT[1] and see if you find it correct?
Best regards,
Bartosz Golaszewski
[1] http://pastebin.com/dfUX7PyL
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
Quoted 27 lines · Bartosz Golaszewski
2016-11-14 17:54 GMT+01:00 Jyri Sarha <[email protected]>:
Quoted 8 lines
Adds drm bride support for attaching drm bridge drivers to tilcdc. The decision whether a video port leads to an external encoder or bridge is made simply based on remote device's compatible string. The code has been tested with BeagleBone-Black with and without BeagleBone DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by Jyri Sarha <[email protected]>---
Hi Jyri,
thanks a lot for doing this.
One issue I see with this patch is that tilcdc doesn't seem to support deferred probe correctly (if modules are built-in). The following happens on my setup:
The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returnsEPROBE_DEFERand it's propagated to tilcdc probe.[drm] Initialized
dumb-vga-dacvga_bridge: Couldn't retrieve i2c busThen the i2c bus is initialized and dump-vga-dac probe succeeds, but the second probe of tilcdc gives me:
Quoted 7 lines
[drm:drm_debugfs_init] *ERROR* Cannot create
/sys/kernel/debug/dri/64[drm:drm_minor_register] *ERROR* DRM: Failed to initialize/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1I was able to work around this issue by loading modules in correct order.
Did you have any conflicts when applying my patch? I have done quite a few changes lately and especially the initialization sequence and back off from deferred probe may get broken easily broken if the source base is not correct. I try to come up with a pull-request candidate branch soon (hopefully tomorrow) for you to test.
Quoted 8 lines
I then tried testing the patch with a da850-lcdk, but I don't get anything on the display (no signal), even though the LCDC seems to work fine (modetest and dmesg messages work just like when using the tilcdc panel). Also: I see the EDID info is correctly retrieved from the display.
Could you take a look at my DT[1] and see if you find it correct?
It is hard to follow the dts diff, but if it probes and tilcdc is able to read EDID modes, there should not be anything more to it.
Cheers,
Jyri
Quoted 5 lines
Best regards,
Bartosz Golaszewski
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): 36c37a00-0684-a758-219b-6dc71b3131ef-l0cyMroinI0@public.gmane.org
Re: [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
2016-11-15 21:46 GMT+01:00 Jyri Sarha <[email protected]>:
Quoted 33 lines · Bartosz Golaszewski
Quoted 32 lines
2016-11-14 17:54 GMT+01:00 Jyri Sarha <[email protected]>:
Quoted 8 lines
Adds drm bride support for attaching drm bridge drivers to tilcdc. The decision whether a video port leads to an external encoder or bridge is made simply based on remote device's compatible string. The code has been tested with BeagleBone-Black with and without BeagleBone DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by Jyri Sarha <[email protected]>---
Hi Jyri,
thanks a lot for doing this.
One issue I see with this patch is that tilcdc doesn't seem to support deferred probe correctly (if modules are built-in). The following happens on my setup:
The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returnsEPROBE_DEFERand it's propagated to tilcdc probe.[drm] Initialized
dumb-vga-dacvga_bridge: Couldn't retrieve i2c busThen the i2c bus is initialized and dump-vga-dac probe succeeds, but the second probe of tilcdc gives me:
[drm:drm_debugfs_init] *ERROR* Cannot create
/sys/kernel/debug/dri/64[drm:drm_minor_register] *ERROR* DRM: Failed to initialize/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1
Quoted 9 lines
Quoted 2 lines
I was able to work around this issue by loading modules in correct order.
Did you have any conflicts when applying my patch? I have done quite a few changes lately and especially the initialization sequence and back off from deferred probe may get broken easily broken if the source base is not correct. I try to come up with a pull-request candidate branch soon (hopefully tomorrow) for you to test.
I only had some trivial conflicts, but you're right, maybe I'm missing some parts. It would be great to have a branch for testing - I could then rebase my follow-up work on tilcdc against it.
Quoted 6 lines
Quoted 6 lines
I then tried testing the patch with a da850-lcdk, but I don't get anything on the display (no signal), even though the LCDC seems to work fine (modetest and dmesg messages work just like when using the tilcdc panel). Also: I see the EDID info is correctly retrieved from the display.
Quoted 6 lines
Quoted 2 lines
Could you take a look at my DT[1] and see if you find it correct?
It is hard to follow the dts diff, but if it probes and tilcdc is able to read EDID modes, there should not be anything more to it.
Yes, this is what I thought too.
Let me know when you'll have the testing branch ready.
Best regards,
Bartosz Golaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html