| Message ID | 1386160133-24026-6-git-send-email-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Tomi, On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: > omapdss driver uses a omapdss platform device to pass platform specific > function pointers and DSS hardware version from the arch code to the > driver. This device is needed also when booting with DT. > > This patch adds omapdss_init_of() function, called from board-generic at > init time, which creates the omapdss device. Is this a temporary solution that you plan to later replace with DT-only device instantiation ? > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > --- > arch/arm/mach-omap2/board-generic.c | 2 ++ > arch/arm/mach-omap2/common.h | 2 ++ > arch/arm/mach-omap2/display.c | 62 ++++++++++++++++++++++++++++++++++ > 3 files changed, 66 insertions(+) > > diff --git a/arch/arm/mach-omap2/board-generic.c > b/arch/arm/mach-omap2/board-generic.c index 19f1652e94cf..0e06771d7bee > 100644 > --- a/arch/arm/mach-omap2/board-generic.c > +++ b/arch/arm/mach-omap2/board-generic.c > @@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] > __initdata = { static void __init omap_generic_init(void) > { > pdata_quirks_init(omap_dt_match_table); > + > + omapdss_init_of(); > } > > #ifdef CONFIG_SOC_OMAP2420 > diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h > index f7644febee81..48e9cd34cae0 100644 > --- a/arch/arm/mach-omap2/common.h > +++ b/arch/arm/mach-omap2/common.h > @@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *); > /* SoC specific clock initializer */ > extern int (*omap_clk_init)(void); > > +int __init omapdss_init_of(void); > + > #endif /* __ASSEMBLER__ */ > #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */ > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c > index a4e536b11ec9..3279afc5f0b5 100644 > --- a/arch/arm/mach-omap2/display.c > +++ b/arch/arm/mach-omap2/display.c > @@ -23,6 +23,8 @@ > #include <linux/clk.h> > #include <linux/err.h> > #include <linux/delay.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > > #include <video/omapdss.h> > #include "omap_hwmod.h" > @@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh) > > return r; > } > + > +int __init omapdss_init_of(void) > +{ > + int r; > + enum omapdss_version ver; > + > + static struct omap_dss_board_info board_data = { > + .dsi_enable_pads = omap_dsi_enable_pads, > + .dsi_disable_pads = omap_dsi_disable_pads, > + .get_context_loss_count = omap_pm_get_dev_context_loss_count, > + .set_min_bus_tput = omap_dss_set_min_bus_tput, > + }; > + > + ver = omap_display_get_version(); > + > + if (ver == OMAPDSS_VER_UNKNOWN) { > + pr_err("DSS not supported on this SoC\n"); > + return -ENODEV; > + } > + > + board_data.version = ver; > + > + omap_display_device.dev.platform_data = &board_data; > + > + r = platform_device_register(&omap_display_device); > + if (r < 0) { > + pr_err("Unable to register omapdss device\n"); > + return r; > + } > + > + /* create DRM device */ > + r = omap_init_drm(); > + if (r < 0) { > + pr_err("Unable to register omapdrm device\n"); > + return r; > + } > + > + /* create vrfb device */ > + r = omap_init_vrfb(); > + if (r < 0) { > + pr_err("Unable to register omapvrfb device\n"); > + return r; > + } > + > + /* create FB device */ > + r = omap_init_fb(); > + if (r < 0) { > + pr_err("Unable to register omapfb device\n"); > + return r; > + } > + > + /* create V4L2 display device */ > + r = omap_init_vout(); > + if (r < 0) { > + pr_err("Unable to register omap_vout device\n"); > + return r; > + } > + > + return 0; > +}
On 2013-12-12 01:10, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: >> omapdss driver uses a omapdss platform device to pass platform specific >> function pointers and DSS hardware version from the arch code to the >> driver. This device is needed also when booting with DT. >> >> This patch adds omapdss_init_of() function, called from board-generic at >> init time, which creates the omapdss device. > > Is this a temporary solution that you plan to later replace with DT-only > device instantiation ? It's a long term task to remove the "virtual" omapdss device. Removing the platform data that we pass has been very difficult. For example, we need to get the OMAP revision to know which OMAP DSS hardware we have. We can't get that information from the DSS hardware (thank you, HW designers! ;). Another is DSI pin muxing. I think we need a new pinmuxing driver for that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is very simple, but the register fields are varying lengths and at varying positions, so pinmux-single doesn't work for it. Tomi
On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote: > On 2013-12-12 01:10, Laurent Pinchart wrote: >> Hi Tomi, >> >> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: >>> omapdss driver uses a omapdss platform device to pass platform specific >>> function pointers and DSS hardware version from the arch code to the >>> driver. This device is needed also when booting with DT. >>> >>> This patch adds omapdss_init_of() function, called from board-generic at >>> init time, which creates the omapdss device. >> >> Is this a temporary solution that you plan to later replace with DT-only >> device instantiation ? > > It's a long term task to remove the "virtual" omapdss device. Removing > the platform data that we pass has been very difficult. Even if we remove the platform data, what would be the right place to register the drm, fb and vout devices? We need to make sure their drivers are probed only after omapdss is initialised. > > For example, we need to get the OMAP revision to know which OMAP DSS > hardware we have. We can't get that information from the DSS hardware > (thank you, HW designers! ;). > > Another is DSI pin muxing. I think we need a new pinmuxing driver for > that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is > very simple, but the register fields are varying lengths and at varying > positions, so pinmux-single doesn't work for it. I have seen other OMAP drivers passing control module register info to their DT node. Instead of having a pinmux driver for a single register, we might want to consider just passing the control module register, and take care of the reg fields and masks in the OMAP DSI driver itself. The parsing of the DSI pins from DT, however, can be kept generic. Archit -- 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-13 10:32, Archit Taneja wrote: > On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote: >> On 2013-12-12 01:10, Laurent Pinchart wrote: >>> Hi Tomi, >>> >>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote: >>>> omapdss driver uses a omapdss platform device to pass platform specific >>>> function pointers and DSS hardware version from the arch code to the >>>> driver. This device is needed also when booting with DT. >>>> >>>> This patch adds omapdss_init_of() function, called from >>>> board-generic at >>>> init time, which creates the omapdss device. >>> >>> Is this a temporary solution that you plan to later replace with DT-only >>> device instantiation ? >> >> It's a long term task to remove the "virtual" omapdss device. Removing >> the platform data that we pass has been very difficult. > > Even if we remove the platform data, what would be the right place to > register the drm, fb and vout devices? We need to make sure their > drivers are probed only after omapdss is initialised. That's the same issue as we have already, so removing omapdss doesn't affect that. I don't think we have any good way to ensure those devices are not probed before omapdss. We just have to manage the case that omapdss has not been probed yet, by checking if omapdss is there and if not, return EPROBE_DEFER. >> For example, we need to get the OMAP revision to know which OMAP DSS >> hardware we have. We can't get that information from the DSS hardware >> (thank you, HW designers! ;). >> > >> Another is DSI pin muxing. I think we need a new pinmuxing driver for >> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is >> very simple, but the register fields are varying lengths and at varying >> positions, so pinmux-single doesn't work for it. > > I have seen other OMAP drivers passing control module register info to > their DT node. Instead of having a pinmux driver for a single register, > we might want to consider just passing the control module register, and > take care of the reg fields and masks in the OMAP DSI driver itself. Yes, that's also one option. Quite ugly, though =). Tomi
* Archit Taneja <archit@ti.com> [131213 00:33]: > > I have seen other OMAP drivers passing control module register info > to their DT node. Instead of having a pinmux driver for a single > register, we might want to consider just passing the control module > register, and take care of the reg fields and masks in the OMAP DSI > driver itself. See the PBIAS control module patches and their comments from Balaji. We can map the misc registers of SCM using drivers/mfd/syscon.c and that way drivers can access them via syscon. 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
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 19f1652e94cf..0e06771d7bee 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] __initdata = { static void __init omap_generic_init(void) { pdata_quirks_init(omap_dt_match_table); + + omapdss_init_of(); } #ifdef CONFIG_SOC_OMAP2420 diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index f7644febee81..48e9cd34cae0 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *); /* SoC specific clock initializer */ extern int (*omap_clk_init)(void); +int __init omapdss_init_of(void); + #endif /* __ASSEMBLER__ */ #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */ diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index a4e536b11ec9..3279afc5f0b5 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -23,6 +23,8 @@ #include <linux/clk.h> #include <linux/err.h> #include <linux/delay.h> +#include <linux/of.h> +#include <linux/of_platform.h> #include <video/omapdss.h> #include "omap_hwmod.h" @@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh) return r; } + +int __init omapdss_init_of(void) +{ + int r; + enum omapdss_version ver; + + static struct omap_dss_board_info board_data = { + .dsi_enable_pads = omap_dsi_enable_pads, + .dsi_disable_pads = omap_dsi_disable_pads, + .get_context_loss_count = omap_pm_get_dev_context_loss_count, + .set_min_bus_tput = omap_dss_set_min_bus_tput, + }; + + ver = omap_display_get_version(); + + if (ver == OMAPDSS_VER_UNKNOWN) { + pr_err("DSS not supported on this SoC\n"); + return -ENODEV; + } + + board_data.version = ver; + + omap_display_device.dev.platform_data = &board_data; + + r = platform_device_register(&omap_display_device); + if (r < 0) { + pr_err("Unable to register omapdss device\n"); + return r; + } + + /* create DRM device */ + r = omap_init_drm(); + if (r < 0) { + pr_err("Unable to register omapdrm device\n"); + return r; + } + + /* create vrfb device */ + r = omap_init_vrfb(); + if (r < 0) { + pr_err("Unable to register omapvrfb device\n"); + return r; + } + + /* create FB device */ + r = omap_init_fb(); + if (r < 0) { + pr_err("Unable to register omapfb device\n"); + return r; + } + + /* create V4L2 display device */ + r = omap_init_vout(); + if (r < 0) { + pr_err("Unable to register omap_vout device\n"); + return r; + } + + return 0; +}
omapdss driver uses a omapdss platform device to pass platform specific function pointers and DSS hardware version from the arch code to the driver. This device is needed also when booting with DT. This patch adds omapdss_init_of() function, called from board-generic at init time, which creates the omapdss device. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- arch/arm/mach-omap2/board-generic.c | 2 ++ arch/arm/mach-omap2/common.h | 2 ++ arch/arm/mach-omap2/display.c | 62 +++++++++++++++++++++++++++++++++++++ 3 files changed, 66 insertions(+)