Hi Tomi,
On Tuesday 09 May 2017 12:37:36 Tomi Valkeinen wrote:
On 08/05/17 14:32, Laurent Pinchart wrote:
Don't rely on callback functions provided by the platform, but access the syscon internally to mux the DSI pins.
Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
drivers/gpu/drm/omapdrm/dss/core.c | 20 ---------- drivers/gpu/drm/omapdrm/dss/dsi.c | 82 +++++++++++++++++++++++++++++++-- drivers/gpu/drm/omapdrm/dss/dss.h | 2 - 3 files changed, 79 insertions(+), 25 deletions(-)
[snip]
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c index 400f903d8197..d86a1ca6da00 100644 --- a/drivers/gpu/drm/omapdrm/dss/dsi.c +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
[snip]
@@ -5332,6 +5393,21 @@ static int dsi_bind(struct device *dev, struct device *master, void *data) dsi->module_id = d->id;
- if (dsi->data->type == DSI_TYPE_OMAP4) {
struct device_node *np;/** The OMAP4 display DT bindings don't reference the padconf* syscon. Our only option to retrieve it is to find it by
name.
*/We could also do DT modifications at early boot phase (we do that already for a few things for tilcdc and omapdss), and then have the driver require the reference to padconf.
That's a good idea too, but I'd do that as a second step to avoid adding more dependencies on arch/arm/mach-omap2/ in this series.
But I think this is fine too.
Reviewed-by: Tomi Valkeinen tomi.valkeinen@ti.com