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/mach-omap2/Makefile | 4 ++ arch/arm/mach-omap2/drm.c | 83 +++++++++++++++++++++++++++++++++ arch/arm/plat-omap/common.c | 3 +- arch/arm/plat-omap/include/plat/drm.h | 64 +++++++++++++++++++++++++ 4 files changed, 153 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/drm.c create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bd76394..9e6065b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -189,6 +189,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),) obj-y += dsp.o endif
+ifneq ($(CONFIG_DRM_OMAP),) +obj-y += drm.o +endif + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c new file mode 100644 index 0000000..779ae02 --- /dev/null +++ b/arch/arm/mach-omap2/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_drm(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_drm); + +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/common.c b/arch/arm/plat-omap/common.c index 4de7d1e..e027cc7 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/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__ */
Hi,
On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
What's the diff with this and the previous one?
I see you still have the platform data there. You didn't comment on that. Where is it used after the board files are gone when we use DT?
And how about the size of the contiguous memory area, it was left a bit unclear to me why it cannot be dynamic.
Tomi
On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Moving drm.c to mach-omap2 (header could not move because omap_reserve() is in plat-omap.. but this seems to be the same as what is done for dspbridge).
I see you still have the platform data there. You didn't comment on that. Where is it used after the board files are gone when we use DT?
I was kind-of thinking that there would be some DT<->data-structure glue somewhere.. not sure if this goes in mach-omap2 or in the driver itself, but presumably it is needed somewhere.
It is only really special cases where some board specific device-tree data is needed, so it seems like this is ok to handle later.
And how about the size of the contiguous memory area, it was left a bit unclear to me why it cannot be dynamic.
I don't think there is anything preventing adding a bootarg, but I think it is not essential so ok to add later
BR, -R
Tomi
On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
Afaik DT data should only contain information about the hardware. This is SW configuration, so I think DT people won't accept things like that.
Well, maybe not essential to you =). But you are reserving 32MB memory, which is quite a big amount. Even if the reserved memory can be used for some other purposes, it's still a big chunk of "special" memory being reserved even if the user doesn't use or have a display at all.
Well, it's not an issue for me either, but I just feel that doing things like that without allowing the user to avoid it is a bit bad thing.
Btw, do you know why the dma_declare_contiguous() takes a dev pointer as an argument, if the memory is not private to that device? (at least I understood from you that the memory can be used for other purposes).
Tomi
On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
hmm, then where *does* it go.. it is a bit too much for bootargs..
If you didn't have display, and were tight on memory, wouldn't you just disable the display device in your kernel config?
contiguous use of the memory is private to the device. There is also a global CMA pool, from which all dma_alloc_xyz() which is not associated w/ a per-device pool comes from.. but the advantage of a per-device-pool is it puts an upper limit on how much dma memory that device can allocate so that it cannot starve other devices.
BR, -R
On Wed, 2012-03-14 at 08:16 -0500, Rob Clark wrote:
I have no idea =). And I may be wrong, but my understanding is the the only thing DT data should have is information about the HW configuration.
But is that kind of configuration needed at boot time? Why cannot the userspace do the config? What configs are actually needed at boot time, before userspace takes control? The only thing coming to my mind is to define the display used for the console.
Sure, if you want to modify your kernel. But you could as well use the same kernel binary, and just say vram=0M which disables the vram allocation. For DRM you would _have_ to modify your kernel.
Actually, I just realized vram=0M doesn't work, as the code checks for ! = 0, and just skips the vram argument when it's 0 =). So my code sucks also...
Ah, I see. So the 32MB you reserve there is not visible as contiguous memory to anyone else than omapdrm, but userspace can still use the 32MB area for pages that can be moved out as needed.
But then, if it's private, it's also rather bad. If I have a kernel with omapfb and omapdrm enabled as modules, but I never use omapdrm, the 32MB is still always reserver and away from other contiguous memory use.
Also, I just realized that besides the memory reservation being fixed, it's also hidden. If I enable omapdrm in the kernel config, I get no indication that 32MB of mem is being reserved. Perhaps a Kconfig option for it, like with OMAP VRAM, and then a boot arg which will override the Kconfig value.
Well, as I said, it's not an issue for me and from my side it can be improved later.
Tomi
On Wed, Mar 14, 2012 at 8:43 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
drm builds up list of resources at startup, and attempts to light up any connected displays at boot.. the decision about what resources to use must be taken before userspace starts.
Anyways, if it is too controversial, maybe I just remove it. It is really only very special cases (possibly multi-seat setups) where you might want to do something other than the default (which is for a single omapdrm instance to use all dss video pipes). It is just code I had written previously for a certain product, and it seemed potentially useful enough to not strip out of the upstream driver.
well, I suppose there is always something somewhere to improve..
anyways, at this point omapdrm isn't enabled by default in omap2plus_defconfig.. I just want to get the platform device registration merged in some form so folks don't have to go poking around to find some out of tree patch in order to enable it.
well, there is a useful CMA debug option which will print some traces when CMA pools are created, etc.. (but probably not what you meant)
Well, as I said, it's not an issue for me and from my side it can be improved later.
yeah, when CMA is actually merged, there are a few other things I'd like to do to, incl converting omapfb over to use CMA and remove omap_vram.. but I guess those will be other patches.
BR, -R
On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
Right, I just realized CMA is not in the kernel, nor does it seem to be in the linux-next. Is there a reason why you want it already merged? Wouldn't it be easier to get it in only when it can actually be used. Especially if there's room for improvement.
Tomi
On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Some folks are already pulling CMA into product kernels for various reasons.. keeping this w/ #ifdef CONFIG_CMA guards seemed like it would make their life a bit easier.
But if people feel strongly about it, I can strip that out.
BR, -R
On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
Well, I wouldn't say "feel strongly", but... I think the mainline kernel should have code only for the mainline kernel, not for some custom kernels. And the code is not testable in any way, not even compilable. I think all code going in should be tested and compiled. Also, if the CMA code is not in, who says it won't change. Perhaps the CMA function won't even exist in the version going into mainline.
Tomi
dri-devel@lists.freedesktop.org
-
Rob Clark -
Tomi Valkeinen