From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod.
Signed-off-by: Andy Gross andy.gross@ti.com Signed-off-by: Rob Clark rob@ti.com --- arch/arm/plat-omap/Makefile | 2 +- arch/arm/plat-omap/common.c | 3 +- arch/arm/plat-omap/drm.c | 83 +++++++++++++++++++++++++++++++++ arch/arm/plat-omap/include/plat/drm.h | 64 +++++++++++++++++++++++++ 4 files changed, 150 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-omap/drm.c create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 9a58461..b86e6cb 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -4,7 +4,7 @@
# Common support obj-y := common.o sram.o clock.o devices.o dma.o mux.o \ - usb.o fb.o counter_32k.o + usb.o fb.o counter_32k.o drm.o obj-m := obj-n := obj- := diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 06383b5..0d87dab 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h>
#include <plat/omap-secure.h>
- #define NO_LENGTH_CHECK 0xffffffff
struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void) { + omapdrm_reserve_vram(); omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock(); diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c new file mode 100644 index 0000000..28279df --- /dev/null +++ b/arch/arm/plat-omap/drm.c @@ -0,0 +1,83 @@ +/* + * DRM/KMS device registration for TI OMAP platforms + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark rob.clark@linaro.org + * + * 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, see http://www.gnu.org/licenses/. + */ + +#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/mm.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#ifdef CONFIG_CMA +# include <linux/dma-contiguous.h> +#endif + +#include <plat/omap_device.h> +#include <plat/omap_hwmod.h> + +#include <plat/drm.h> + +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE) + +static struct omap_drm_platform_data omapdrm_platdata; + +static struct platform_device omap_drm_device = { + .dev = { + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &omapdrm_platdata, + }, + .name = "omapdrm", + .id = 0, +}; + +static int __init omap_init_gpu(void) +{ + struct omap_hwmod *oh = NULL; + struct platform_device *pdev; + + /* lookup and populate the DMM information, if present - OMAP4+ */ + oh = omap_hwmod_lookup("dmm"); + + if (oh) { + pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0, + false); + WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", + oh->name); + } + + return platform_device_register(&omap_drm_device); + +} + +arch_initcall(omap_init_gpu); + +void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA + /* + * Create private 32MiB contiguous memory area for omapdrm.0 device + * TODO revisit size.. if uc/wc buffers are allocated from CMA pages + * then the amount of memory we need goes up.. + */ + dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0); +#else +# warning "CMA is not enabled, there may be limitations about scanout buffer allocations on OMAP3 and earlier" +#endif +} + +#endif diff --git a/arch/arm/plat-omap/include/plat/drm.h b/arch/arm/plat-omap/include/plat/drm.h new file mode 100644 index 0000000..df9bc41 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/drm.h @@ -0,0 +1,64 @@ +/* + * DRM/KMS device registration for TI OMAP platforms + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark rob.clark@linaro.org + * + * 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, see http://www.gnu.org/licenses/. + */ + +#ifndef __PLAT_OMAP_DRM_H__ +#define __PLAT_OMAP_DRM_H__ + +/* + * Optional platform data to configure the default configuration of which + * pipes/overlays/CRTCs are used.. if this is not provided, then instead the + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to + * one manager, with priority given to managers that are connected to + * detected devices. Remaining overlays are used as video planes. This + * should be a good default behavior for most cases, but yet there still + * might be times when you wish to do something different. + */ +struct omap_kms_platform_data { + /* overlays to use as CRTCs: */ + int ovl_cnt; + const int *ovl_ids; + + /* overlays to use as video planes: */ + int pln_cnt; + const int *pln_ids; + + int mgr_cnt; + const int *mgr_ids; + + int dev_cnt; + const char **dev_names; +}; + +struct omap_drm_platform_data { + struct omap_kms_platform_data *kms_pdata; +}; + +#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE) + +void omapdrm_reserve_vram(void); + +#else + +static inline void omapdrm_reserve_vram(void) +{ +} + +#endif + +#endif /* __PLAT_OMAP_DRM_H__ */
* Rob Clark rob.clark@linaro.org [120305 08:24]:
From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod. --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h>
#include <plat/omap-secure.h>
#define NO_LENGTH_CHECK 0xffffffff
struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void) {
- omapdrm_reserve_vram(); omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock();
Tomi needs to look at the vram changes here.
--- /dev/null +++ b/arch/arm/plat-omap/drm.c
This file would be better in mach-omap2/drm.c. I doubt that this will ever be usable for omap1. But other than that, up to Tomi.
Tony
On Mon, Mar 5, 2012 at 6:10 PM, Tony Lindgren tony@atomide.com wrote:
- Rob Clark rob.clark@linaro.org [120305 08:24]:
From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod. --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h>
#include <plat/omap-secure.h>
#define NO_LENGTH_CHECK 0xffffffff
struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void) {
- omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock();
Tomi needs to look at the vram changes here.
it is just setting up a CMA region (if CMA is enabled.. basically for once CMA is merged)
after CMA is merged, other drivers should be migrated to use CMA, and omap_vram removed.. but that is a topic for another patch
--- /dev/null +++ b/arch/arm/plat-omap/drm.c
This file would be better in mach-omap2/drm.c. I doubt that this will ever be usable for omap1. But other than that, up to Tomi.
I was attempting to copy what omapfb was doing (plat-omap/fb.c) because I wasn't really sure about plat-omap vs mach-omap2, although on closer inspection I think the file I was looking at is actually for the legacy omapdss1.. So I'll move this stuff under mach-omap2 and resubmit this patch.
BR, -R
Tony
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod.
Signed-off-by: Andy Gross andy.gross@ti.com Signed-off-by: Rob Clark rob@ti.com
arch/arm/plat-omap/Makefile | 2 +- arch/arm/plat-omap/common.c | 3 +- arch/arm/plat-omap/drm.c | 83 +++++++++++++++++++++++++++++++++ arch/arm/plat-omap/include/plat/drm.h | 64 +++++++++++++++++++++++++ 4 files changed, 150 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-omap/drm.c create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 9a58461..b86e6cb 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -4,7 +4,7 @@
# Common support obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
usb.o fb.o counter_32k.o
usb.o fb.o counter_32k.o drm.oobj-m := obj-n := obj- := diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 06383b5..0d87dab 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h>
#include <plat/omap-secure.h>
#define NO_LENGTH_CHECK 0xffffffff
struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void) {
- omapdrm_reserve_vram(); omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
As Tony said, mach-omap2 is probably a better place. fb.c is in plat-omap because it supports both OMAP1 and OMAP2+.
new file mode 100644 index 0000000..28279df --- /dev/null +++ b/arch/arm/plat-omap/drm.c @@ -0,0 +1,83 @@ +/*
- DRM/KMS device registration for TI OMAP platforms
- Copyright (C) 2012 Texas Instruments
- Author: Rob Clark rob.clark@linaro.org
- 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, see http://www.gnu.org/licenses/.
- */
+#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/mm.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#ifdef CONFIG_CMA +# include <linux/dma-contiguous.h> +#endif
+#include <plat/omap_device.h> +#include <plat/omap_hwmod.h>
+#include <plat/drm.h>
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+static struct omap_drm_platform_data omapdrm_platdata;
+static struct platform_device omap_drm_device = {
.dev = {.coherent_dma_mask = DMA_BIT_MASK(32),.platform_data = &omapdrm_platdata,},.name = "omapdrm",.id = 0,
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
+};
+static int __init omap_init_gpu(void) +{
- struct omap_hwmod *oh = NULL;
- struct platform_device *pdev;
- /* lookup and populate the DMM information, if present - OMAP4+ */
- oh = omap_hwmod_lookup("dmm");
- if (oh) {
pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,false);WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",oh->name);- }
- return platform_device_register(&omap_drm_device);
+}
The function is called omap_init_gpu(), but it doesn't do anything related to the gpu... And aren't DMM and DRM totally separate things, why are they bunched together like that?
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
- /*
* Create private 32MiB contiguous memory area for omapdrm.0 device* TODO revisit size.. if uc/wc buffers are allocated from CMA pages* then the amount of memory we need goes up..*/- dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
+#else +# warning "CMA is not enabled, there may be limitations about scanout buffer allocations on OMAP3 and earlier" +#endif +}
+#endif diff --git a/arch/arm/plat-omap/include/plat/drm.h b/arch/arm/plat-omap/include/plat/drm.h new file mode 100644 index 0000000..df9bc41 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/drm.h @@ -0,0 +1,64 @@ +/*
- DRM/KMS device registration for TI OMAP platforms
- Copyright (C) 2012 Texas Instruments
- Author: Rob Clark rob.clark@linaro.org
- 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, see http://www.gnu.org/licenses/.
- */
+#ifndef __PLAT_OMAP_DRM_H__ +#define __PLAT_OMAP_DRM_H__
+/*
- Optional platform data to configure the default configuration of which
- pipes/overlays/CRTCs are used.. if this is not provided, then instead the
- first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
- one manager, with priority given to managers that are connected to
- detected devices. Remaining overlays are used as video planes. This
- should be a good default behavior for most cases, but yet there still
- might be times when you wish to do something different.
- */
+struct omap_kms_platform_data {
- /* overlays to use as CRTCs: */
- int ovl_cnt;
- const int *ovl_ids;
- /* overlays to use as video planes: */
- int pln_cnt;
- const int *pln_ids;
- int mgr_cnt;
- const int *mgr_ids;
- int dev_cnt;
- const char **dev_names;
+};
+struct omap_drm_platform_data {
- struct omap_kms_platform_data *kms_pdata;
+};
I don't know if there's need to add these... With device tree the plaform data will not be usable anyway.
Tomi
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod.
Signed-off-by: Andy Gross andy.gross@ti.com Signed-off-by: Rob Clark rob@ti.com
arch/arm/plat-omap/Makefile | 2 +- arch/arm/plat-omap/common.c | 3 +- arch/arm/plat-omap/drm.c | 83 +++++++++++++++++++++++++++++++++ arch/arm/plat-omap/include/plat/drm.h | 64 +++++++++++++++++++++++++ 4 files changed, 150 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-omap/drm.c create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 9a58461..b86e6cb 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -4,7 +4,7 @@
# Common support obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
- usb.o fb.o counter_32k.o
- usb.o fb.o counter_32k.o drm.o
obj-m := obj-n := obj- := diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 06383b5..0d87dab 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h>
#include <plat/omap-secure.h>
#define NO_LENGTH_CHECK 0xffffffff
struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void) {
- omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock(); diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
As Tony said, mach-omap2 is probably a better place. fb.c is in plat-omap because it supports both OMAP1 and OMAP2+.
new file mode 100644 index 0000000..28279df --- /dev/null +++ b/arch/arm/plat-omap/drm.c @@ -0,0 +1,83 @@ +/*
- DRM/KMS device registration for TI OMAP platforms
- Copyright (C) 2012 Texas Instruments
- Author: Rob Clark rob.clark@linaro.org
- 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, see http://www.gnu.org/licenses/.
- */
+#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/mm.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#ifdef CONFIG_CMA +# include <linux/dma-contiguous.h> +#endif
+#include <plat/omap_device.h> +#include <plat/omap_hwmod.h>
+#include <plat/drm.h>
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+static struct omap_drm_platform_data omapdrm_platdata;
+static struct platform_device omap_drm_device = {
- .dev = {
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &omapdrm_platdata,
- },
- .name = "omapdrm",
- .id = 0,
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
in the past, we have used multiple devices (using the platform-data to divide up the dss resources), although this was sort of a special-case. But in theory you could have multiple. (Think of a multi-seat scenario, where multiple compositors need to run and each need to be drm-master of their own device to do mode-setting on their corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking bus-id for the device: "platform:omapdrm:-1"
+};
+static int __init omap_init_gpu(void) +{
- struct omap_hwmod *oh = NULL;
- struct platform_device *pdev;
- /* lookup and populate the DMM information, if present - OMAP4+ */
- oh = omap_hwmod_lookup("dmm");
- if (oh) {
- pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
- false);
- WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
- oh->name);
- }
- return platform_device_register(&omap_drm_device);
+}
The function is called omap_init_gpu(), but it doesn't do anything related to the gpu... And aren't DMM and DRM totally separate things, why are they bunched together like that?
only legacy.. product branches also have sgx initialization here. But I can change that to omap_init_drm()
DMM is managed by the drm driver (and exposed to userspace as drm/gem buffers, shared with other devices via dma-buf, etc). It is only split out to a separate device to play along with hwmod.
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
- /*
- * Create private 32MiB contiguous memory area for omapdrm.0 device
- * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
- * then the amount of memory we need goes up..
- */
- dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
BR, -R
+#else +# warning "CMA is not enabled, there may be limitations about scanout buffer allocations on OMAP3 and earlier" +#endif +}
+#endif diff --git a/arch/arm/plat-omap/include/plat/drm.h b/arch/arm/plat-omap/include/plat/drm.h new file mode 100644 index 0000000..df9bc41 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/drm.h @@ -0,0 +1,64 @@ +/*
- DRM/KMS device registration for TI OMAP platforms
- Copyright (C) 2012 Texas Instruments
- Author: Rob Clark rob.clark@linaro.org
- 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, see http://www.gnu.org/licenses/.
- */
+#ifndef __PLAT_OMAP_DRM_H__ +#define __PLAT_OMAP_DRM_H__
+/*
- Optional platform data to configure the default configuration of which
- pipes/overlays/CRTCs are used.. if this is not provided, then instead the
- first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
- one manager, with priority given to managers that are connected to
- detected devices. Remaining overlays are used as video planes. This
- should be a good default behavior for most cases, but yet there still
- might be times when you wish to do something different.
- */
+struct omap_kms_platform_data {
- /* overlays to use as CRTCs: */
- int ovl_cnt;
- const int *ovl_ids;
- /* overlays to use as video planes: */
- int pln_cnt;
- const int *pln_ids;
- int mgr_cnt;
- const int *mgr_ids;
- int dev_cnt;
- const char **dev_names;
+};
+struct omap_drm_platform_data {
- struct omap_kms_platform_data *kms_pdata;
+};
I don't know if there's need to add these... With device tree the plaform data will not be usable anyway.
Tomi
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
in the past, we have used multiple devices (using the platform-data to divide up the dss resources), although this was sort of a special-case. But in theory you could have multiple. (Think of a multi-seat scenario, where multiple compositors need to run and each need to be drm-master of their own device to do mode-setting on their corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking bus-id for the device: "platform:omapdrm:-1"
I don't know about that, but it's the way platform devices are meant to be used if there can be only one instance. If the case where there are multiple omapdrm devices is rather theoretical, or only used for certain debugging scenarios or such, I think having the id as -1 in the mainline is cleaner.
+};
+static int __init omap_init_gpu(void) +{
struct omap_hwmod *oh = NULL;struct platform_device *pdev;/* lookup and populate the DMM information, if present - OMAP4+ */oh = omap_hwmod_lookup("dmm");if (oh) {pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,false);WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",oh->name);}return platform_device_register(&omap_drm_device);+}
The function is called omap_init_gpu(), but it doesn't do anything related to the gpu... And aren't DMM and DRM totally separate things, why are they bunched together like that?
only legacy.. product branches also have sgx initialization here. But I can change that to omap_init_drm()
DMM is managed by the drm driver (and exposed to userspace as drm/gem buffers, shared with other devices via dma-buf, etc). It is only split out to a separate device to play along with hwmod.
I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses.
Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER.
Somehow having a DMM driver inside omapdrm sounds strange.
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
/** Create private 32MiB contiguous memory area for omapdrm.0 device* TODO revisit size.. if uc/wc buffers are allocated from CMA pages* then the amount of memory we need goes up..*/dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and dma_declare_contiguous allocates the memory with memblock_alloc. So is that allocated memory available for any users? If so, why does the function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the CMA functions? Surely there must be some downside to the above? =) And if so, it should be configurable. You could have a board with no display at all, and you probably don't want to have 32MB allocated for DRM in that case.
Tomi
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
in the past, we have used multiple devices (using the platform-data to divide up the dss resources), although this was sort of a special-case. But in theory you could have multiple. (Think of a multi-seat scenario, where multiple compositors need to run and each need to be drm-master of their own device to do mode-setting on their corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking bus-id for the device: "platform:omapdrm:-1"
I don't know about that, but it's the way platform devices are meant to be used if there can be only one instance. If the case where there are multiple omapdrm devices is rather theoretical, or only used for certain debugging scenarios or such, I think having the id as -1 in the mainline is cleaner.
well, I don't care much one way or another, but need to check if there is a small patch needed in drm core code that generates the bus-id for .id = -1..
+};
+static int __init omap_init_gpu(void) +{
- struct omap_hwmod *oh = NULL;
- struct platform_device *pdev;
- /* lookup and populate the DMM information, if present - OMAP4+ */
- oh = omap_hwmod_lookup("dmm");
- if (oh) {
- pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
- false);
- WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
- oh->name);
- }
- return platform_device_register(&omap_drm_device);
+}
The function is called omap_init_gpu(), but it doesn't do anything related to the gpu... And aren't DMM and DRM totally separate things, why are they bunched together like that?
only legacy.. product branches also have sgx initialization here. But I can change that to omap_init_drm()
DMM is managed by the drm driver (and exposed to userspace as drm/gem buffers, shared with other devices via dma-buf, etc). It is only split out to a separate device to play along with hwmod.
I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses.
when most people refer to TILER they actually refer to DMM..
DMM is the piece which is basically a GART, it is what omapdrm is programming and managing.
Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER.
yes, clearly there are other users.. we pass gem buffers allocated from omapdrm to (for example, video decoder). But it is omapdrm which is managing the allocation, keeping track of which buffers are pinned and which can be evicted, dealing with the complications of userspace mmap'ing of tiled buffers, etc. That stuff you don't want littered throughout the kernel.
Somehow having a DMM driver inside omapdrm sounds strange.
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
- /*
- * Create private 32MiB contiguous memory area for omapdrm.0 device
- * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
- * then the amount of memory we need goes up..
- */
- dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and dma_declare_contiguous allocates the memory with memblock_alloc. So is that allocated memory available for any users? If so, why does the function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the CMA functions? Surely there must be some downside to the above? =) And if so, it should be configurable. You could have a board with no display at all, and you probably don't want to have 32MB allocated for DRM in that case.
Basically the short version is memory from a CMA carveout can be re-used for unpinnable memory. Not kmalloc, but it can be used for anon userspace pages, for example. Userspace needs memory too.
BR, -R
Tomi
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
in the past, we have used multiple devices (using the platform-data to divide up the dss resources), although this was sort of a special-case. But in theory you could have multiple. (Think of a multi-seat scenario, where multiple compositors need to run and each need to be drm-master of their own device to do mode-setting on their corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking bus-id for the device: "platform:omapdrm:-1"
I don't know about that, but it's the way platform devices are meant to be used if there can be only one instance. If the case where there are multiple omapdrm devices is rather theoretical, or only used for certain debugging scenarios or such, I think having the id as -1 in the mainline is cleaner.
well, I don't care much one way or another, but need to check if there is a small patch needed in drm core code that generates the bus-id for .id = -1..
Hmm, why does the drm core care about it?
And generally, I think if the bus id is -1, there is no bus id in a sense. For example, with bus id 0 you'll get a device "omapdrm.0". With bus id -1 you'll get a device "omapdrm".
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
/** Create private 32MiB contiguous memory area for omapdrm.0 device* TODO revisit size.. if uc/wc buffers are allocated from CMA pages* then the amount of memory we need goes up..*/dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and dma_declare_contiguous allocates the memory with memblock_alloc. So is that allocated memory available for any users? If so, why does the function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the CMA functions? Surely there must be some downside to the above? =) And if so, it should be configurable. You could have a board with no display at all, and you probably don't want to have 32MB allocated for DRM in that case.
Basically the short version is memory from a CMA carveout can be re-used for unpinnable memory. Not kmalloc, but it can be used for anon userspace pages, for example. Userspace needs memory too.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding a value like that without any possibility to adjust it just sounds like a rather bad thing.
Tomi
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Can there be more than one omapdrm device? I guess not. If so, the id should be -1.
in the past, we have used multiple devices (using the platform-data to divide up the dss resources), although this was sort of a special-case. But in theory you could have multiple. (Think of a multi-seat scenario, where multiple compositors need to run and each need to be drm-master of their own device to do mode-setting on their corresponding display.)
I think if we use .id = -1, then we'd end up with a funny looking bus-id for the device: "platform:omapdrm:-1"
I don't know about that, but it's the way platform devices are meant to be used if there can be only one instance. If the case where there are multiple omapdrm devices is rather theoretical, or only used for certain debugging scenarios or such, I think having the id as -1 in the mainline is cleaner.
well, I don't care much one way or another, but need to check if there is a small patch needed in drm core code that generates the bus-id for .id = -1..
Hmm, why does the drm core care about it?
Because it is the one generating the bus-id.. see drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
Anyways, it's just a detail about how libdrm/drmOpen() can differentiate between multiple instances of the same driver, similar to how PCI bus-id is used in the desktop world. It is not difficult to change in drm_platform_set_busid(), although not sure if that would be considered an ABI change to userspace. (Maybe it is less critical, I'm under the impression that other platform-drm users didn't even realize we had a bus-id.)
And generally, I think if the bus id is -1, there is no bus id in a sense. For example, with bus id 0 you'll get a device "omapdrm.0". With bus id -1 you'll get a device "omapdrm".
+arch_initcall(omap_init_gpu);
+void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA
- /*
- * Create private 32MiB contiguous memory area for omapdrm.0 device
- * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
- * then the amount of memory we need goes up..
- */
- dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
What does this actually do? Does it reserve the memory, i.e. it's not usable for others? If so, shouldn't there be a way for the user to configure it?
It can be re-used by others.. see http://lwn.net/Articles/479297/
The link didn't tell much. I looked at the patches, and dma_declare_contiguous allocates the memory with memblock_alloc. So is that allocated memory available for any users? If so, why does the function want a device pointer as an argument...
Is the memory available for normal kmalloc, or only available via the CMA functions? Surely there must be some downside to the above? =) And if so, it should be configurable. You could have a board with no display at all, and you probably don't want to have 32MB allocated for DRM in that case.
Basically the short version is memory from a CMA carveout can be re-used for unpinnable memory. Not kmalloc, but it can be used for anon userspace pages, for example. Userspace needs memory too.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding a value like that without any possibility to adjust it just sounds like a rather bad thing.
The main requirement is that, on omap3 or before (platforms without DMM) you need enough to allocate all of your scanout buffers.
I'm not against having a bootarg to adjust, although I strongly prefer sane defaults and not requiring a million bootargs just to boot in some usable fashion.
BR, -R
Tomi
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hmm, why does the drm core care about it?
Because it is the one generating the bus-id.. see drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
Anyways, it's just a detail about how libdrm/drmOpen() can differentiate between multiple instances of the same driver, similar to how PCI bus-id is used in the desktop world. It is not difficult to change in drm_platform_set_busid(), although not sure if that would be considered an ABI change to userspace. (Maybe it is less critical, I'm under the impression that other platform-drm users didn't even realize we had a bus-id.)
Ok. Well, I'm fine with id 0 also, if it makes sense in the DRM side. It was just something that caught my eye.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding a value like that without any possibility to adjust it just sounds like a rather bad thing.
The main requirement is that, on omap3 or before (platforms without DMM) you need enough to allocate all of your scanout buffers.
I'm not against having a bootarg to adjust, although I strongly prefer sane defaults and not requiring a million bootargs just to boot in some usable fashion.
Well, those are two different things. I'm fine with a default of 32MB. My point was, what if I need more, or I don't need any.
Tomi
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.comwrote:
I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses.
Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER.
Somehow having a DMM driver inside omapdrm sounds strange.
The DMM does indeed contain a number of entities. However, the TILER portion is the only part that requires a driver. All other register modifications (LISA map settings, EMIF, etc) are done statically in the loader or u-boot and never changed again. As such, DMM has become synonymous with TILER.
Regards,
Andy
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses. Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER. Somehow having a DMM driver inside omapdrm sounds strange.The DMM does indeed contain a number of entities. However, the TILER portion is the only part that requires a driver. All other register modifications (LISA map settings, EMIF, etc) are done statically in the loader or u-boot and never changed again. As such, DMM has become synonymous with TILER.
Ok. Well, as I said, I don't know much about that, just sounds rather strange to me =).
Does this "DMM has become synonymous" mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER.
Tomi
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
I have to say I don't know much about DMM, but my understanding is that DMM is a bigger entity, of which TILER is only a small part, and DMM manages all memory accesses.
Can there be other users for the DMM than DRM? I know there could be other users for the TILER, and I know you want to combine that with the DRM driver, but I'm wondering about the other parts of DMM than the TILER.
Somehow having a DMM driver inside omapdrm sounds strange.
The DMM does indeed contain a number of entities. However, the TILER portion is the only part that requires a driver. All other register modifications (LISA map settings, EMIF, etc) are done statically in the loader or u-boot and never changed again. As such, DMM has become synonymous with TILER.
Ok. Well, as I said, I don't know much about that, just sounds rather strange to me =).
Does this "DMM has become synonymous" mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER.
Well, "dmm" is the name in hwmod, so either way we are sort of "stuck" with that.. but if you look in the TRM, you'd be looking for "dynamic memory manager", so I tend to think "dmm" is the better name. But for some reason the old driver (in some product kernels but never made it upstream) was called "tiler", which might be part of the reason that people have started using the names interchangeably.
At any rate, neither "tiler" nor "dmm" appear in any userspace facing API (instead you just have some bits you can set in the flags you specify if you want tiled buffer or not when allocating a gem buffer object). So I guess it isn't as critical.
BR, -R
Tomi
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Does this "DMM has become synonymous" mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER.
Tomi
Well the breakdown of the DMM/Tiler kind of goes like this. The DMM defines a set of registers used to manipulate the PAT table that backs the address space with physical memory. The Tiler portion of the DMM really just describes the address space that is exposed. Depending on what address range you access, you'll get a different mode of access and rotation. Management of the address space is attributed to the Tiler as well and that is where we have managed the address space and provided APIs to reserve address space and pin/unpin memory to those regions.
From a hardware perspective, we need access to the resources provided
by the DMM so that we can do the PAT programming and that can only be gotten from the hwmod entry. And if you use the hwmod device entry, you have to match the name used for that entry.
Regards,
Andy
On Wed, 2012-03-07 at 09:59 -0600, Gross, Andy wrote:
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Does this "DMM has become synonymous" mean that people just started calling TILER DMM, and thus the name has stuck, or are there technical reasons to handle it as DMM in the kernel? If the former, and if TILER is the technically exact name for it, perhaps it would make sense to call it TILER, as that's what (at least I) would be looking for if I read the TRM and try to find the code for the TILER.
Tomi
Well the breakdown of the DMM/Tiler kind of goes like this. The DMM defines a set of registers used to manipulate the PAT table that backs the address space with physical memory. The Tiler portion of the DMM really just describes the address space that is exposed. Depending on what address range you access, you'll get a different mode of access and rotation. Management of the address space is attributed to the Tiler as well and that is where we have managed the address space and provided APIs to reserve address space and pin/unpin memory to those regions.
From a hardware perspective, we need access to the resources provided by the DMM so that we can do the PAT programming and that can only be gotten from the hwmod entry. And if you use the hwmod device entry, you have to match the name used for that entry.
Ok. Thanks for the detailed explanation =).
Tomi
dri-devel@lists.freedesktop.org
-
Gross, Andy -
Rob Clark -
Tomi Valkeinen -
Tony Lindgren