RE: [PATCH 2/2] ARM: OMAP2+: Remove dmm device creation
Yes ill fix it up and move the doc to the other patch and send a v2 From: Shilimkar, Santosh Sent: Wednesday, March 20, 2013 1:22 AM To: Taneja, Archit Cc: Gross, Andy; linux-omap@vger.kernel.org; Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; Menon, Nishanth Subject: Re: [PATCH 2/2] ARM: OMAP2+: Remove dmm device creation On Wednesday 20 March 2013 11:46 AM, Archit Taneja wrote: On Wednesday 20 March 2013 11:26 AM, Santosh Shilimkar wrote: On Wednesday 20 March 2013 10:13 AM, Andy Gross wrote: Remove DMM device creation via the hwmod entry. The DMM device will now be enumerated as part of the device tree information for the processor. Signed-off-by: Andy Gross andy.gr...@ti.com --- OMAP4 is still not made DT only so I suggest you to hold on for this patch till that happens. Wouldn't we need to at least prevent building the platform device using omap_device_build() when we are using DT? Yes. I assumed Andy will do that once he decides to keep the non-dt support :) Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
Tony,
Please queue this patch at your earliest convenience.
We had some discussion on the splitting out of the DMM/Tiler driver
from the omapdrm driver. There might be some interest in leveraging
the Tiler for omapfb. However, we agreed this can be deferred until
some other device (omapfb or otherwise) needs to use the Tiler.
Regards,
Andy Gross
On Mon, Jun 11, 2012 at 10:51 AM, Rob Clark rob.cl...@linaro.org wrote:
On Wed, May 23, 2012 at 3:08 PM, Andy Gross andy.gr...@ti.com wrote:
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark rob.cl...@linaro.org
---
arch/arm/mach-omap2/Makefile | 4 ++
arch/arm/mach-omap2/drm.c | 61
drivers/staging/omapdrm/omap_drv.h | 2 +-
drivers/staging/omapdrm/omap_priv.h | 55
include/linux/platform_data/omap_drm.h | 52 +++
5 files changed, 118 insertions(+), 56 deletions(-)
create mode 100644 arch/arm/mach-omap2/drm.c
delete mode 100644 drivers/staging/omapdrm/omap_priv.h
create mode 100644 include/linux/platform_data/omap_drm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,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 000..72e0f01b
--- /dev/null
+++ b/arch/arm/mach-omap2/drm.c
@@ -0,0 +1,61 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@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
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .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);
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index b7e0f07..96296e0 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -25,8 +25,8 @@
#include linux/types.h
#include drm/drmP.h
#include drm/drm_crtc_helper.h
+#include linux/platform_data/omap_drm.h
#include omap_drm.h
-#include omap_priv.h
#define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose
debug */
diff --git a/drivers/staging/omapdrm/omap_priv.h
b/drivers/staging/omapdrm/omap_priv.h
deleted file mode 100644
index ef64414..000
--- a/drivers/staging/omapdrm/omap_priv.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * include/drm/omap_priv.h
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Rob Clark r...@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
Re: [PATCH] omap2+: add drm device
Tomi, So at this point, are you OK with deferring a split of the DMM until it necessary to do so (if ever)? I'd like to get this patch in so that people have a working omapdrm device when they enable the config options. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Thu, May 24, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
+struct omap_drm_platform_data {
+ struct omap_kms_platform_data *kms_pdata;
+};
This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
didn't just move the struct. Is that on purpose?
Good point. I can clean that up.
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote: but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss v4l2 camera working w/ tiler buffers on my pandaboard, for example. Maybe fbdev is an exception to the rule because it has no way for userspace to pass it a buffer to use. But on the other hand it is a legacy API so I'm not sure if it is worth loosing too much sleep over that. I'm not that familiar with dmabuf, but are you saying it's not possible for a kernel driver to request the buffers? They _must_ come from the userspace? Anyway, even if it would be possible, if the tiler is a part of omapdrm we need omapdrm to get and use the tiler buffers. And we can't have omapdrm running when using omapfb, because they both use omapdss. And that is a good point. The DSS is kind of a sticking point to anyone having to enable DRM to get Tiler. However, omapfb doesn't currently utilize DMM/Tiler features. Can't we defer generalizing until there is a requirement for it? Andy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
