This patch fixes a infinite loop issue incurred when
it doesn't have a pair of crtc and connector drivers,
which was reported by Kevin Hilman like below,
http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
cdev->conn_dev could be NULL by exynos_drm_component_del call in case
that connector driver is failed while probing after compoments to crtc
and connector drivers are added to specific drm_compoment_list.
In this case, exynos_drm_match_add returns -EPROBE_DEFER error and
Exynos drm driver will try the defered probe over and over again.
This patch makes the deferred probe is tried up to 3 times in maximum.
However, this is considered only for Exynos drm so I think other SoC
drivers could also produce same issue. Therefore, the best way to resolve
this issue, infinite loop incurred by defered probe, would be that dd core
is fixed up corrrectly.
Signed-off-by: Inki Dae <inki.dae@xxxxxxxxxxx>
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..4d84f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -38,6 +38,8 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+#define MAX_TRY_PROBE_DEFER 3
+
static struct platform_device *exynos_drm_pdev;
static DEFINE_MUTEX(drm_component_lock);
@@ -481,6 +483,7 @@ static struct component_match *exynos_drm_match_add(struct device *dev)
struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
+ static unsigned int try_probe_defer;
mutex_lock(&drm_component_lock);
@@ -527,6 +530,11 @@ out_lock:
mutex_unlock(&drm_component_lock);
+ if (++try_probe_defer > MAX_TRY_PROBE_DEFER) {
+ try_probe_defer = 0;
+ return ERR_PTR(-ENODEV);
+ }
+
return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
