Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 26/04/14 02:53, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140424 02:53]: On 18/04/14 18:51, Tony Lindgren wrote: + gpio = of_get_gpio(node, 0); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-enable_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse enable gpio\n); + return gpio; + } We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Instead of doing it with the old gpio API, and checking the 'active' flag everywhere, I think we can use the new gpiod API which handles the polarity automatically. I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. I've compiled tested this only, as I don't have DPI panels I could use. I did try similar approach for TFP410, and it seemed to work fine. Got these working by updating my test patch to use enable-gpios instead of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH. Are we now also breaking legacy booting by reversing the polarity? I don't think so. The GPIOs should be active-high by default, if I'm not mistaken, so the polarities should be the same for legacy boot with or without those patches. Of course, I don't have the boards so I have no idea if the polarities have been correct even before. debugfs/gpio shows the actual value of the gpio, so you could check from there what it is. In any case, looks like we have some duplicate panel code.. Turns out most panel dpi users for omap3 board-*.c files are just sharp-ls037v7dw01 panels but configured in QVGA mode. At least for EVM and and LDP based on looking at the pictures and the configuration Hmm, true, board-ldp.c's panel looks very much like sharp-ls037v7dw01. Which EVM are you talking about? pins (using the names kernel): QVGA = lcd MO reset = lcd RESB ... Then the enable_gpio should be just a GPIO controlled 3.3V regulator in most cases. I suggest we move them over to ls037v7dw01 and allow configuring them both for VGA and QVGA depending on the orientation. Looking at the panel spec, it has the following pins: RESB - reset MO - VGA/QVGA UD - vertical scanning direction LR - horizontal scanning direction INI - power on control And it needs 3.3V power. Are you saying that on some boards the gpio used for enable_gpio is actually used to switch on a 3.3V regulator? I guess you do have some device with ls037v7dw01 since you've been patching it? No, I don't have any boards with that panel. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140428 03:44]: On 26/04/14 02:53, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140424 02:53]: On 18/04/14 18:51, Tony Lindgren wrote: +gpio = of_get_gpio(node, 0); +if (gpio_is_valid(gpio) || gpio == -ENOENT) { +ddata-enable_gpio = gpio; +} else { +dev_err(pdev-dev, failed to parse enable gpio\n); +return gpio; +} We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Instead of doing it with the old gpio API, and checking the 'active' flag everywhere, I think we can use the new gpiod API which handles the polarity automatically. I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. I've compiled tested this only, as I don't have DPI panels I could use. I did try similar approach for TFP410, and it seemed to work fine. Got these working by updating my test patch to use enable-gpios instead of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH. Are we now also breaking legacy booting by reversing the polarity? I don't think so. The GPIOs should be active-high by default, if I'm not mistaken, so the polarities should be the same for legacy boot with or without those patches. Of course, I don't have the boards so I have no idea if the polarities have been correct even before. OK debugfs/gpio shows the actual value of the gpio, so you could check from there what it is. Yeah that should be checked. In any case, looks like we have some duplicate panel code.. Turns out most panel dpi users for omap3 board-*.c files are just sharp-ls037v7dw01 panels but configured in QVGA mode. At least for EVM and and LDP based on looking at the pictures and the configuration Hmm, true, board-ldp.c's panel looks very much like sharp-ls037v7dw01. Yes it seems so also based on the photos of the LCD panel. And 3430sdp also seems to have something similar but it's upside down. Which EVM are you talking about? The LogicPD omap3 EVMs TMDSEVM3530 and TMDSEVM3730. The am335x EVM has a different larger panel. pins (using the names kernel): QVGA = lcd MO reset = lcd RESB ... Then the enable_gpio should be just a GPIO controlled 3.3V regulator in most cases. I suggest we move them over to ls037v7dw01 and allow configuring them both for VGA and QVGA depending on the orientation. Looking at the panel spec, it has the following pins: RESB - reset MO - VGA/QVGA UD - vertical scanning direction LR - horizontal scanning direction INI - power on control And it needs 3.3V power. Are you saying that on some boards the gpio used for enable_gpio is actually used to switch on a 3.3V regulator? The 3.3V GPIO regulator is needed in addition to the configurable pins, I guess some ls037v7dw01 panels only have a subset of the pins controllable by GPIOs, and the GPIO regulator may be used instead of the INI. But that's hard to know without schematics. I guess you do have some device with ls037v7dw01 since you've been patching it? No, I don't have any boards with that panel. OK. I'll move my boards over to ls037v7dw01 and do a DT conversion patch for it that just sets a standard gpios property for panel ls037v7dw01. The gpios entry can have 0 entries in the middle depending on wiring configuration and there should not be any need to name each GPIO. As far as I'm concerned, your panel-dpi patch is fine with me, and we should not add more configuration to it for the ls037v7dw01 panels. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140424 02:53]: On 18/04/14 18:51, Tony Lindgren wrote: + gpio = of_get_gpio(node, 0); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-enable_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse enable gpio\n); + return gpio; + } We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Instead of doing it with the old gpio API, and checking the 'active' flag everywhere, I think we can use the new gpiod API which handles the polarity automatically. I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. I've compiled tested this only, as I don't have DPI panels I could use. I did try similar approach for TFP410, and it seemed to work fine. Got these working by updating my test patch to use enable-gpios instead of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH. Are we now also breaking legacy booting by reversing the polarity? In any case, looks like we have some duplicate panel code.. Turns out most panel dpi users for omap3 board-*.c files are just sharp-ls037v7dw01 panels but configured in QVGA mode. At least for EVM and and LDP based on looking at the pictures and the configuration pins (using the names kernel): QVGA = lcd MO reset = lcd RESB ... Then the enable_gpio should be just a GPIO controlled 3.3V regulator in most cases. I suggest we move them over to ls037v7dw01 and allow configuring them both for VGA and QVGA depending on the orientation. I guess you do have some device with ls037v7dw01 since you've been patching it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 18/04/14 18:51, Tony Lindgren wrote: +gpio = of_get_gpio(node, 0); +if (gpio_is_valid(gpio) || gpio == -ENOENT) { +ddata-enable_gpio = gpio; +} else { +dev_err(pdev-dev, failed to parse enable gpio\n); +return gpio; +} We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Instead of doing it with the old gpio API, and checking the 'active' flag everywhere, I think we can use the new gpiod API which handles the polarity automatically. I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. I've compiled tested this only, as I don't have DPI panels I could use. I did try similar approach for TFP410, and it seemed to work fine. Tomi From f2280114f0eb814370664f24eba8ffee8280c840 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen tomi.valkei...@ti.com Date: Thu, 24 Apr 2014 12:36:52 +0300 Subject: [PATCH 1/3] panel-dpi: use gpiod for enable gpio --- drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 32 +- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c index 5f8f7e7c81ef..d379dec3bd4a 100644 --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c @@ -25,8 +25,10 @@ struct panel_drv_data { struct omap_video_timings videomode; + /* used for non-DT boot, to be removed */ int backlight_gpio; - int enable_gpio; + + struct gpio_desc *enable_gpio; }; #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev) @@ -77,8 +79,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev) if (r) return r; - if (gpio_is_valid(ddata-enable_gpio)) - gpio_set_value_cansleep(ddata-enable_gpio, 1); + if (ddata-enable_gpio) + gpiod_set_value_cansleep(ddata-enable_gpio, 1); if (gpio_is_valid(ddata-backlight_gpio)) gpio_set_value_cansleep(ddata-backlight_gpio, 1); @@ -96,8 +98,8 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev) if (!omapdss_device_is_enabled(dssdev)) return; - if (gpio_is_valid(ddata-enable_gpio)) - gpio_set_value_cansleep(ddata-enable_gpio, 0); + if (ddata-enable_gpio) + gpiod_set_value_cansleep(ddata-enable_gpio, 0); if (gpio_is_valid(ddata-backlight_gpio)) gpio_set_value_cansleep(ddata-backlight_gpio, 0); @@ -156,6 +158,7 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev) struct panel_drv_data *ddata = platform_get_drvdata(pdev); struct omap_dss_device *dssdev, *in; struct videomode vm; + int r; pdata = dev_get_platdata(pdev-dev); @@ -176,10 +179,20 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev) dssdev = ddata-dssdev; dssdev-name = pdata-name; - ddata-enable_gpio = pdata-enable_gpio; + r = devm_gpio_request_one(pdev-dev, pdata-enable_gpio, + GPIOF_OUT_INIT_LOW, panel enable); + if (r) + goto err_gpio; + + ddata-enable_gpio = gpio_to_desc(pdata-enable_gpio); + ddata-backlight_gpio = pdata-backlight_gpio; return 0; + +err_gpio: + omap_dss_put_device(ddata-in); + return r; } static int panel_dpi_probe(struct platform_device *pdev) @@ -202,13 +215,6 @@ static int panel_dpi_probe(struct platform_device *pdev) return -ENODEV; } - if (gpio_is_valid(ddata-enable_gpio)) { - r = devm_gpio_request_one(pdev-dev, ddata-enable_gpio, -GPIOF_OUT_INIT_LOW, panel enable); - if (r) - goto err_gpio; - } - if (gpio_is_valid(ddata-backlight_gpio)) { r = devm_gpio_request_one(pdev-dev, ddata-backlight_gpio, GPIOF_OUT_INIT_LOW, panel backlight); -- 1.9.1 From fe2a85da34499fab70212c4cc5870378678da709 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen tomi.valkei...@ti.com Date: Thu, 16 May 2013 15:14:16 +0300 Subject: [PATCH 2/3] OMAPDSS: panel-dpi: Add DT support Add DT support for panel-dpi. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reviewed-by: Archit Taneja arc...@ti.com --- drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 59 +- 1 file changed, 58 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c index d379dec3bd4a..dca6b10d1157 100644 --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c @@ -13,9 +13,12 @@ #include linux/module.h #include linux/platform_device.h #include linux/slab.h +#include linux/of.h +#include linux/of_gpio.h #include video/omapdss.h #include video/omap-panel-data.h +#include video/of_display_timing.h struct panel_drv_data { struct omap_dss_device dssdev; @@ -72,7 +75,8 @@ static int panel_dpi_enable(struct omap_dss_device
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
Hi Tomi, On Thursday 24 April 2014 12:52:42 Tomi Valkeinen wrote: On 18/04/14 18:51, Tony Lindgren wrote: + gpio = of_get_gpio(node, 0); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-enable_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse enable gpio\n); + return gpio; + } We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Instead of doing it with the old gpio API, and checking the 'active' flag everywhere, I think we can use the new gpiod API which handles the polarity automatically. I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. Just FYI, you can use the gpiod API with non-DT platforms if you register GPIO lookup entries in board code with gpiod_add_lookup_table(). I've compiled tested this only, as I don't have DPI panels I could use. I did try similar approach for TFP410, and it seemed to work fine. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 24/04/14 15:44, Laurent Pinchart wrote: I attached prototype patches (based on -rc2) for panel dpi using that approach. It's a bit messier than I'd like, because for non-DT boot we need to request the gpio using the old API, and then convert it to gpio_desc. We can remove that code when all the boards use DT. Just FYI, you can use the gpiod API with non-DT platforms if you register GPIO lookup entries in board code with gpiod_add_lookup_table(). Right, but as the board files are going away, I'd rather not touch them at all if possible. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
Hi, Just trying to summarize what has been discussed so far in various threads regarding changes needed to this patch. * Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]: --- a/drivers/video/omap2/displays-new/panel-dpi.c +++ b/drivers/video/omap2/displays-new/panel-dpi.c @@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev) return 0; } +static int panel_dpi_probe_of(struct platform_device *pdev) +{ + struct panel_drv_data *ddata = platform_get_drvdata(pdev); + struct device_node *node = pdev-dev.of_node; + struct omap_dss_device *in; + int r; + struct display_timing timing; + struct videomode vm; + int gpio; + + gpio = of_get_gpio(node, 0); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-enable_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse enable gpio\n); + return gpio; + } We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like gpio_backlight_probe_dt is doing. Then do we really want to do the dev_err for each -EPROBE_DEFER here? + gpio = of_get_gpio(node, 1); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-backlight_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse backlight gpio\n); + return gpio; + } How about let's drop the backlight_gpio as discussed since it can be handled with gpio-backlight? Instead, let's add the panel specific reset_gpio as suggested by Joachim. That seems common to some dpi using panels. Then support for the other panel specific GPIOs can then be added as a follow-up patch when we know how we want to handle them. Oh, and this patch needs the related binding documentation too in Documentation/devicetree/bindings. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140407 22:42]: On 08/04/14 03:13, Tony Lindgren wrote: Tomi, * Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]: Add DT support for panel-dpi. Looks like this patch did not get merged or am I missing something? Yes, I dropped it. None of the boards that I converted used panel-dpi. There was so much discussions about the display bindings, so I thought it's better to leave out all but the needed patches. OK As you probably are aware, we have at least these boards needing it before we can remove the omap3 legacy support: board-am3517evm.c board-cm-t35.c board-devkit8000.c board-ldp.c board-overo.c We could probably set the display timings based on the compatible flag in the driver if that's an issue? The timings shouldn't be an issue. But there's the backlight GPIO, currently handled by panel-dpi, which should be removed from the panel. We should use gpio-backlight for that one. Using gpio-backlight makes sense for sure. FYI, in the case of the LDP there are four GPIOs to configure to get things going: gpio55 LCD RESET panel-dpi? gpio56 LCD QVGApanel-dpi? twl gpio7 LCD power panel-dpi twl gpio15 LCD backlight gpio-backlight And then board-omap3pandora.c also needs support for panel_tpo_td043mtea1_platform_data. Yep, there's still much to do for DSS DT support. Hopefully it will be easier now that the core support is there. I'll continue working on the remaining boards and panels. However, I don't have any of the remaining boards, so help is of course appreciated. Yeah I can test at least the LDP here. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
Tomi, * Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]: Add DT support for panel-dpi. Looks like this patch did not get merged or am I missing something? As you probably are aware, we have at least these boards needing it before we can remove the omap3 legacy support: board-am3517evm.c board-cm-t35.c board-devkit8000.c board-ldp.c board-overo.c We could probably set the display timings based on the compatible flag in the driver if that's an issue? And then board-omap3pandora.c also needs support for panel_tpo_td043mtea1_platform_data. Regards, Tony Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/displays-new/panel-dpi.c | 64 +++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/drivers/video/omap2/displays-new/panel-dpi.c b/drivers/video/omap2/displays-new/panel-dpi.c index 5f8f7e7c81ef..b032daf0f407 100644 --- a/drivers/video/omap2/displays-new/panel-dpi.c +++ b/drivers/video/omap2/displays-new/panel-dpi.c @@ -13,9 +13,12 @@ #include linux/module.h #include linux/platform_device.h #include linux/slab.h +#include linux/of.h +#include linux/of_gpio.h #include video/omapdss.h #include video/omap-panel-data.h +#include video/of_display_timing.h struct panel_drv_data { struct omap_dss_device dssdev; @@ -70,7 +73,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev) if (omapdss_device_is_enabled(dssdev)) return 0; - in-ops.dpi-set_data_lines(in, ddata-data_lines); + if (ddata-data_lines) + in-ops.dpi-set_data_lines(in, ddata-data_lines); in-ops.dpi-set_timings(in, ddata-videomode); r = in-ops.dpi-enable(in); @@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev) return 0; } +static int panel_dpi_probe_of(struct platform_device *pdev) +{ + struct panel_drv_data *ddata = platform_get_drvdata(pdev); + struct device_node *node = pdev-dev.of_node; + struct omap_dss_device *in; + int r; + struct display_timing timing; + struct videomode vm; + int gpio; + + gpio = of_get_gpio(node, 0); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-enable_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse enable gpio\n); + return gpio; + } + + gpio = of_get_gpio(node, 1); + if (gpio_is_valid(gpio) || gpio == -ENOENT) { + ddata-backlight_gpio = gpio; + } else { + dev_err(pdev-dev, failed to parse backlight gpio\n); + return gpio; + } + + r = of_get_display_timing(node, panel-timing, timing); + if (r) { + dev_err(pdev-dev, failed to get video timing\n); + return r; + } + + videomode_from_timing(timing, vm); + videomode_to_omap_video_timings(vm, ddata-videomode); + + in = omapdss_of_find_source_for_first_ep(node); + if (IS_ERR(in)) { + dev_err(pdev-dev, failed to find video source\n); + return PTR_ERR(in); + } + + ddata-in = in; + + return 0; +} + static int panel_dpi_probe(struct platform_device *pdev) { struct panel_drv_data *ddata; @@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev) r = panel_dpi_probe_pdata(pdev); if (r) return r; + } else if (pdev-dev.of_node) { + r = panel_dpi_probe_of(pdev); + if (r) + return r; } else { return -ENODEV; } @@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev) return 0; } +static const struct of_device_id panel_dpi_of_match[] = { + { .compatible = omapdss,panel-dpi, }, + {}, +}; + +MODULE_DEVICE_TABLE(of, panel_dpi_of_match); + static struct platform_driver panel_dpi_driver = { .probe = panel_dpi_probe, .remove = __exit_p(panel_dpi_remove), .driver = { .name = panel-dpi, .owner = THIS_MODULE, + .of_match_table = panel_dpi_of_match, }, }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
On 08/04/14 03:13, Tony Lindgren wrote: Tomi, * Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]: Add DT support for panel-dpi. Looks like this patch did not get merged or am I missing something? Yes, I dropped it. None of the boards that I converted used panel-dpi. There was so much discussions about the display bindings, so I thought it's better to leave out all but the needed patches. As you probably are aware, we have at least these boards needing it before we can remove the omap3 legacy support: board-am3517evm.c board-cm-t35.c board-devkit8000.c board-ldp.c board-overo.c We could probably set the display timings based on the compatible flag in the driver if that's an issue? The timings shouldn't be an issue. But there's the backlight GPIO, currently handled by panel-dpi, which should be removed from the panel. We should use gpio-backlight for that one. And then board-omap3pandora.c also needs support for panel_tpo_td043mtea1_platform_data. Yep, there's still much to do for DSS DT support. Hopefully it will be easier now that the core support is there. I'll continue working on the remaining boards and panels. However, I don't have any of the remaining boards, so help is of course appreciated. Tomi signature.asc Description: OpenPGP digital signature