| Message ID | 1387205794-32246-2-git-send-email-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]: > As a temporary solution to enable DSS for selected boards when booting > with DT, a hack was added to board-generic.c in > 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable > DSS for panda & sdp boards). > > We're now adding proper DT support, so the hack can be removed. I guess this patch should be merged later on after we have the DT support working? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-12-16 20:41, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]: >> As a temporary solution to enable DSS for selected boards when booting >> with DT, a hack was added to board-generic.c in >> 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable >> DSS for panda & sdp boards). >> >> We're now adding proper DT support, so the hack can be removed. > > I guess this patch should be merged later on after we have the DT support > working? I'll move this patch also to the end of the series. "Merged later" sounds like you mean this could be merged in a separate series. I think this and the other removal can be in this series, they just need to be at the end. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 22:47]: > On 2013-12-16 20:41, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]: > >> As a temporary solution to enable DSS for selected boards when booting > >> with DT, a hack was added to board-generic.c in > >> 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable > >> DSS for panda & sdp boards). > >> > >> We're now adding proper DT support, so the hack can be removed. > > > > I guess this patch should be merged later on after we have the DT support > > working? > > I'll move this patch also to the end of the series. > > "Merged later" sounds like you mean this could be merged in a separate > series. I think this and the other removal can be in this series, they > just need to be at the end. Well yeah let's keep those separate still as at least Russell needed some more time with the legacy booting. The point we can drop the legacy booting for omap3 may still need to wait a bit, maybe even until v3.15 to keep things working. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2013-12-17 17:30, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 22:47]: >> On 2013-12-16 20:41, Tony Lindgren wrote: >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]: >>>> As a temporary solution to enable DSS for selected boards when booting >>>> with DT, a hack was added to board-generic.c in >>>> 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable >>>> DSS for panda & sdp boards). >>>> >>>> We're now adding proper DT support, so the hack can be removed. >>> >>> I guess this patch should be merged later on after we have the DT support >>> working? >> >> I'll move this patch also to the end of the series. >> >> "Merged later" sounds like you mean this could be merged in a separate >> series. I think this and the other removal can be in this series, they >> just need to be at the end. > > Well yeah let's keep those separate still as at least Russell needed > some more time with the legacy booting. The point we can drop the > legacy booting for omap3 may still need to wait a bit, maybe even > until v3.15 to keep things working. They can't be separate. Once I add DT support for a board, I have to remove the legacy support for that board. This patch removes legacy support for the boards that are converted in the series. If I don't remove the legacy support, both DT and legacy side will be ran, and both create the DSS devices... But, it's true that this patch removes the whole file, as all the boards currently there are converted. But if new boards are added to the DSS quirks, then I can't remove the file. So I'll change this patch to only remove the parts for the converted boards, not the whole file. But but... If I understand right, the plan is to remove all omap3 board files for the next merge window. I'm not totally familiar with the quirks system, but how should this be handled: omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices are created via DT code. But if the display (i.e. panels) for a particular omap3 board has not been converted to DT, we should still use the legacy DSS initialization. But the DSS is already initialized via DT. I guess I can set the status for all the DSS nodes to "disabled" in omap3.dtsi, and that should prevent DT code from creating the DSS devices. Then, each omap3-board.dts that has been converted to DSS DT, can override those to "enabled". That way the DT code should not create DSS devices by default, and the quirks system would probably work fine. Tomi
On 2013-12-18 09:12, Tomi Valkeinen wrote: >> Well yeah let's keep those separate still as at least Russell needed >> some more time with the legacy booting. The point we can drop the >> legacy booting for omap3 may still need to wait a bit, maybe even >> until v3.15 to keep things working. > > They can't be separate. Once I add DT support for a board, I have to > remove the legacy support for that board. This patch removes legacy > support for the boards that are converted in the series. > > If I don't remove the legacy support, both DT and legacy side will be > ran, and both create the DSS devices... > > But, it's true that this patch removes the whole file, as all the boards > currently there are converted. But if new boards are added to the DSS > quirks, then I can't remove the file. So I'll change this patch to only > remove the parts for the converted boards, not the whole file. > > But but... If I understand right, the plan is to remove all omap3 board > files for the next merge window. I'm not totally familiar with the > quirks system, but how should this be handled: > > omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices > are created via DT code. But if the display (i.e. panels) for a > particular omap3 board has not been converted to DT, we should still use > the legacy DSS initialization. But the DSS is already initialized via DT. > > I guess I can set the status for all the DSS nodes to "disabled" in > omap3.dtsi, and that should prevent DT code from creating the DSS > devices. Then, each omap3-board.dts that has been converted to DSS DT, > can override those to "enabled". > > That way the DT code should not create DSS devices by default, and the > quirks system would probably work fine. I changed the DSS DT nodes to be disabled by default, and I think this works nicely. It's actually better this way in any case, as we can leave blocks like DSI out for boards that don't need it. Also, I now remove the quirks only for the boards that are converted to DT, not the whole dss-common.c file. So I think we can now add new boards to dss-common.c, if and when there are ones that cannot be converted to use DSS DT yet. Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131217 23:14]: > On 2013-12-17 17:30, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 22:47]: > >> On 2013-12-16 20:41, Tony Lindgren wrote: > >>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131216 06:59]: > >>>> As a temporary solution to enable DSS for selected boards when booting > >>>> with DT, a hack was added to board-generic.c in > >>>> 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable > >>>> DSS for panda & sdp boards). > >>>> > >>>> We're now adding proper DT support, so the hack can be removed. > >>> > >>> I guess this patch should be merged later on after we have the DT support > >>> working? > >> > >> I'll move this patch also to the end of the series. > >> > >> "Merged later" sounds like you mean this could be merged in a separate > >> series. I think this and the other removal can be in this series, they > >> just need to be at the end. > > > > Well yeah let's keep those separate still as at least Russell needed > > some more time with the legacy booting. The point we can drop the > > legacy booting for omap3 may still need to wait a bit, maybe even > > until v3.15 to keep things working. > > They can't be separate. Once I add DT support for a board, I have to > remove the legacy support for that board. This patch removes legacy > support for the boards that are converted in the series. Oh OK yeah makes sense. I was worried about the legacy board-*.c files.. > If I don't remove the legacy support, both DT and legacy side will be > ran, and both create the DSS devices... > > But, it's true that this patch removes the whole file, as all the boards > currently there are converted. But if new boards are added to the DSS > quirks, then I can't remove the file. So I'll change this patch to only > remove the parts for the converted boards, not the whole file. OK > But but... If I understand right, the plan is to remove all omap3 board > files for the next merge window. I'm not totally familiar with the > quirks system, but how should this be handled: > > omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices > are created via DT code. But if the display (i.e. panels) for a > particular omap3 board has not been converted to DT, we should still use > the legacy DSS initialization. But the DSS is already initialized via DT. > > I guess I can set the status for all the DSS nodes to "disabled" in > omap3.dtsi, and that should prevent DT code from creating the DSS > devices. Then, each omap3-board.dts that has been converted to DSS DT, > can override those to "enabled". > > That way the DT code should not create DSS devices by default, and the > quirks system would probably work fine. No need for DSS related quirks for the DT boot case. I was concerned about the legacy board-*.c case. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131218 02:22]: > On 2013-12-18 09:12, Tomi Valkeinen wrote: > > >> Well yeah let's keep those separate still as at least Russell needed > >> some more time with the legacy booting. The point we can drop the > >> legacy booting for omap3 may still need to wait a bit, maybe even > >> until v3.15 to keep things working. > > > > They can't be separate. Once I add DT support for a board, I have to > > remove the legacy support for that board. This patch removes legacy > > support for the boards that are converted in the series. > > > > If I don't remove the legacy support, both DT and legacy side will be > > ran, and both create the DSS devices... > > > > But, it's true that this patch removes the whole file, as all the boards > > currently there are converted. But if new boards are added to the DSS > > quirks, then I can't remove the file. So I'll change this patch to only > > remove the parts for the converted boards, not the whole file. > > > > But but... If I understand right, the plan is to remove all omap3 board > > files for the next merge window. I'm not totally familiar with the > > quirks system, but how should this be handled: > > > > omap3.dtsi will contain the SoC's DSS nodes. This means that DSS devices > > are created via DT code. But if the display (i.e. panels) for a > > particular omap3 board has not been converted to DT, we should still use > > the legacy DSS initialization. But the DSS is already initialized via DT. > > > > I guess I can set the status for all the DSS nodes to "disabled" in > > omap3.dtsi, and that should prevent DT code from creating the DSS > > devices. Then, each omap3-board.dts that has been converted to DSS DT, > > can override those to "enabled". > > > > That way the DT code should not create DSS devices by default, and the > > quirks system would probably work fine. > > I changed the DSS DT nodes to be disabled by default, and I think this > works nicely. It's actually better this way in any case, as we can leave > blocks like DSI out for boards that don't need it. > > Also, I now remove the quirks only for the boards that are converted to > DT, not the whole dss-common.c file. So I think we can now add new > boards to dss-common.c, if and when there are ones that cannot be > converted to use DSS DT yet. OK Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index adcef406ff0a..e81dbf202a6d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -296,4 +296,4 @@ endif emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o obj-y += $(emac-m) $(emac-y) -obj-y += common-board-devices.o twl-common.o dss-common.o +obj-y += common-board-devices.o twl-common.o diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c deleted file mode 100644 index dadccc91488c..000000000000 --- a/arch/arm/mach-omap2/dss-common.c +++ /dev/null @@ -1,259 +0,0 @@ -/* - * Copyright (C) 2012 Texas Instruments, Inc.. - * Author: Tomi Valkeinen <tomi.valkeinen@ti.com> - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * - */ - -/* - * NOTE: this is a transitional file to help with DT adaptation. - * This file will be removed when DSS supports DT. - */ - -#include <linux/kernel.h> -#include <linux/gpio.h> -#include <linux/platform_device.h> - -#include <video/omapdss.h> -#include <video/omap-panel-data.h> - -#include "soc.h" -#include "dss-common.h" -#include "mux.h" - -#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */ -#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */ -#define HDMI_GPIO_HPD 63 /* Hotplug detect */ - -#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0 - -/* DVI Connector */ -static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = { - .name = "dvi", - .source = "tfp410.0", - .i2c_bus_num = 2, -}; - -static struct platform_device omap4_panda_dvi_connector_device = { - .name = "connector-dvi", - .id = 0, - .dev.platform_data = &omap4_panda_dvi_connector_pdata, -}; - -/* TFP410 DPI-to-DVI chip */ -static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = { - .name = "tfp410.0", - .source = "dpi.0", - .data_lines = 24, - .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO, -}; - -static struct platform_device omap4_panda_tfp410_device = { - .name = "tfp410", - .id = 0, - .dev.platform_data = &omap4_panda_tfp410_pdata, -}; - -/* HDMI Connector */ -static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = { - .name = "hdmi", - .source = "tpd12s015.0", -}; - -static struct platform_device omap4_panda_hdmi_connector_device = { - .name = "connector-hdmi", - .id = 0, - .dev.platform_data = &omap4_panda_hdmi_connector_pdata, -}; - -/* TPD12S015 HDMI ESD protection & level shifter chip */ -static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = { - .name = "tpd12s015.0", - .source = "hdmi.0", - - .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD, - .ls_oe_gpio = HDMI_GPIO_LS_OE, - .hpd_gpio = HDMI_GPIO_HPD, -}; - -static struct platform_device omap4_panda_tpd_device = { - .name = "tpd12s015", - .id = 0, - .dev.platform_data = &omap4_panda_tpd_pdata, -}; - -static struct omap_dss_board_info omap4_panda_dss_data = { - .default_display_name = "dvi", -}; - -void __init omap4_panda_display_init_of(void) -{ - omap_display_init(&omap4_panda_dss_data); - - platform_device_register(&omap4_panda_tfp410_device); - platform_device_register(&omap4_panda_dvi_connector_device); - - platform_device_register(&omap4_panda_tpd_device); - platform_device_register(&omap4_panda_hdmi_connector_device); -} - - -/* OMAP4 Blaze display data */ - -#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */ -#define DLP_POWER_ON_GPIO 40 - -static struct panel_dsicm_platform_data dsi1_panel = { - .name = "lcd", - .source = "dsi.0", - .reset_gpio = 102, - .use_ext_te = false, - .ext_te_gpio = 101, - .pin_config = { - .num_pins = 6, - .pins = { 0, 1, 2, 3, 4, 5 }, - }, -}; - -static struct platform_device sdp4430_lcd_device = { - .name = "panel-dsi-cm", - .id = 0, - .dev.platform_data = &dsi1_panel, -}; - -static struct panel_dsicm_platform_data dsi2_panel = { - .name = "lcd2", - .source = "dsi.1", - .reset_gpio = 104, - .use_ext_te = false, - .ext_te_gpio = 103, - .pin_config = { - .num_pins = 6, - .pins = { 0, 1, 2, 3, 4, 5 }, - }, -}; - -static struct platform_device sdp4430_lcd2_device = { - .name = "panel-dsi-cm", - .id = 1, - .dev.platform_data = &dsi2_panel, -}; - -/* HDMI Connector */ -static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = { - .name = "hdmi", - .source = "tpd12s015.0", -}; - -static struct platform_device sdp4430_hdmi_connector_device = { - .name = "connector-hdmi", - .id = 0, - .dev.platform_data = &sdp4430_hdmi_connector_pdata, -}; - -/* TPD12S015 HDMI ESD protection & level shifter chip */ -static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = { - .name = "tpd12s015.0", - .source = "hdmi.0", - - .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD, - .ls_oe_gpio = HDMI_GPIO_LS_OE, - .hpd_gpio = HDMI_GPIO_HPD, -}; - -static struct platform_device sdp4430_tpd_device = { - .name = "tpd12s015", - .id = 0, - .dev.platform_data = &sdp4430_tpd_pdata, -}; - - -static struct omap_dss_board_info sdp4430_dss_data = { - .default_display_name = "lcd", -}; - -/* - * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO. - * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails - * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is - * selected by default - */ -void __init omap_4430sdp_display_init_of(void) -{ - int r; - - r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH, - "display_sel"); - if (r) - pr_err("%s: Could not get display_sel GPIO\n", __func__); - - r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW, - "DLP POWER ON"); - if (r) - pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__); - - omap_display_init(&sdp4430_dss_data); - - platform_device_register(&sdp4430_lcd_device); - platform_device_register(&sdp4430_lcd2_device); - - platform_device_register(&sdp4430_tpd_device); - platform_device_register(&sdp4430_hdmi_connector_device); -} - - -/* OMAP3 IGEPv2 data */ - -#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170 - -/* DVI Connector */ -static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = { - .name = "dvi", - .source = "tfp410.0", - .i2c_bus_num = 2, -}; - -static struct platform_device omap3_igep2_dvi_connector_device = { - .name = "connector-dvi", - .id = 0, - .dev.platform_data = &omap3_igep2_dvi_connector_pdata, -}; - -/* TFP410 DPI-to-DVI chip */ -static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = { - .name = "tfp410.0", - .source = "dpi.0", - .data_lines = 24, - .power_down_gpio = IGEP2_DVI_TFP410_POWER_DOWN_GPIO, -}; - -static struct platform_device omap3_igep2_tfp410_device = { - .name = "tfp410", - .id = 0, - .dev.platform_data = &omap3_igep2_tfp410_pdata, -}; - -static struct omap_dss_board_info igep2_dss_data = { - .default_display_name = "dvi", -}; - -void __init omap3_igep2_display_init_of(void) -{ - omap_display_init(&igep2_dss_data); - - platform_device_register(&omap3_igep2_tfp410_device); - platform_device_register(&omap3_igep2_dvi_connector_device); -} diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h deleted file mode 100644 index a9becf0d5be8..000000000000 --- a/arch/arm/mach-omap2/dss-common.h +++ /dev/null @@ -1,13 +0,0 @@ -#ifndef __OMAP_DSS_COMMON__ -#define __OMAP_DSS_COMMON__ - -/* - * NOTE: this is a transitional file to help with DT adaptation. - * This file will be removed when DSS supports DT. - */ - -void __init omap4_panda_display_init_of(void); -void __init omap_4430sdp_display_init_of(void); -void __init omap3_igep2_display_init_of(void); - -#endif diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 39f020c982e8..acc72a002316 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -18,7 +18,6 @@ #include "common.h" #include "common-board-devices.h" -#include "dss-common.h" #include "control.h" struct pdata_init { @@ -80,7 +79,6 @@ static void __init hsmmc2_internal_input_clk(void) static void __init omap3_igep0020_legacy_init(void) { - omap3_igep2_display_init_of(); } static void __init omap3_evm_legacy_init(void) @@ -97,14 +95,12 @@ static void __init omap3_zoom_legacy_init(void) #ifdef CONFIG_ARCH_OMAP4 static void __init omap4_sdp_legacy_init(void) { - omap_4430sdp_display_init_of(); legacy_init_wl12xx(WL12XX_REFCLOCK_26, WL12XX_TCXOCLOCK_26, 53); } static void __init omap4_panda_legacy_init(void) { - omap4_panda_display_init_of(); legacy_init_ehci_clk("auxclk3_ck"); legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53); }
As a temporary solution to enable DSS for selected boards when booting with DT, a hack was added to board-generic.c in 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable DSS for panda & sdp boards). We're now adding proper DT support, so the hack can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/dss-common.c | 259 ------------------------------------- arch/arm/mach-omap2/dss-common.h | 13 -- arch/arm/mach-omap2/pdata-quirks.c | 4 - 4 files changed, 1 insertion(+), 277 deletions(-) delete mode 100644 arch/arm/mach-omap2/dss-common.c delete mode 100644 arch/arm/mach-omap2/dss-common.h