From: Rob Clark rob@ti.com
These two patches cover API changes that are currently in drm-next for 3.3. The 2nd of which is the first part for enabling drm_plane support (but doesn't yet enable the new overlay functionality). I'll have another patchset, hopefully later this week, which adds the remaining bits to enable overlay (drm_plane) support.
Greg I'm not sure if you want these patches now, or just after the 3.3 merge window opens. Also, if it is easier for you, I can setup a tree that you could pull from. Please let me know what you prefer.
Rob Clark (2): drm/omap: drm API update: make fops struct const drm/omap: drm API update: addfb2
drivers/staging/omapdrm/omap_drv.c | 24 +++++---- drivers/staging/omapdrm/omap_drv.h | 53 ++++++++++++++++++- drivers/staging/omapdrm/omap_fb.c | 96 ++++++++++++++++++++++++++------- drivers/staging/omapdrm/omap_fbdev.c | 29 ++++++---- 4 files changed, 156 insertions(+), 46 deletions(-)
From: Rob Clark rob@ti.com
Update to reflect changes in: "Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark rob@ti.com --- drivers/staging/omapdrm/omap_drv.c | 24 +++++++++++++----------- 1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c b/drivers/staging/omapdrm/omap_drv.c index 7ecf578..d05e2b4 100644 --- a/drivers/staging/omapdrm/omap_drv.c +++ b/drivers/staging/omapdrm/omap_drv.c @@ -708,6 +708,18 @@ static struct vm_operations_struct omap_gem_vm_ops = { .close = drm_gem_vm_close, };
+static const struct file_operations omapdriver_fops = { + .owner = THIS_MODULE, + .open = drm_open, + .unlocked_ioctl = drm_ioctl, + .release = drm_release, + .mmap = omap_gem_mmap, + .poll = drm_poll, + .fasync = drm_fasync, + .read = drm_read, + .llseek = noop_llseek, +}; + static struct drm_driver omap_drm_driver = { .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM, @@ -734,17 +746,7 @@ static struct drm_driver omap_drm_driver = { .dumb_destroy = omap_gem_dumb_destroy, .ioctls = ioctls, .num_ioctls = DRM_OMAP_NUM_IOCTLS, - .fops = { - .owner = THIS_MODULE, - .open = drm_open, - .unlocked_ioctl = drm_ioctl, - .release = drm_release, - .mmap = omap_gem_mmap, - .poll = drm_poll, - .fasync = drm_fasync, - .read = drm_read, - .llseek = noop_llseek, - }, + .fops = &omapdriver_fops, .name = DRIVER_NAME, .desc = DRIVER_DESC, .date = DRIVER_DATE,
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api changes, right?
greg k-h
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api changes, right?
I don't think so, at least not if you want it to compile ;-)
Previously the 'struct file_operations' was inline with the 'struct drm_driver' rather than a pointer. But if it it makes it easier for you to keep track I can keep a tree that you can pull from w/ a branch on top with the patches that depend on stuff coming in thru drm-next.
BR, -R
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api changes, right?
I don't think so, at least not if you want it to compile ;-)
Doh, you are right, sorry about that.
Previously the 'struct file_operations' was inline with the 'struct drm_driver' rather than a pointer. But if it it makes it easier for you to keep track I can keep a tree that you can pull from w/ a branch on top with the patches that depend on stuff coming in thru drm-next.
No, that would mix the two branches, and I can't do that, right?
So let's just wait for the drm-next branch to be merged with Linus, and I'll hold onto these until then, ok?
thanks,
greg k-h
On Mon, Dec 12, 2011 at 7:04 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api changes, right?
I don't think so, at least not if you want it to compile ;-)
Doh, you are right, sorry about that.
Previously the 'struct file_operations' was inline with the 'struct drm_driver' rather than a pointer. But if it it makes it easier for you to keep track I can keep a tree that you can pull from w/ a branch on top with the patches that depend on stuff coming in thru drm-next.
No, that would mix the two branches, and I can't do that, right?
hmm, yeah
So let's just wait for the drm-next branch to be merged with Linus, and I'll hold onto these until then, ok?
ok, great.. if you don't mind just holding them until drm-next gets pulled into Linus's tree, that would be perfect. Thanks!
BR, -R
thanks,
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Rob Clark rob@ti.com
Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark rob@ti.com --- drivers/staging/omapdrm/omap_drv.h | 53 ++++++++++++++++++- drivers/staging/omapdrm/omap_fb.c | 96 ++++++++++++++++++++++++++------- drivers/staging/omapdrm/omap_fbdev.c | 29 ++++++---- 3 files changed, 143 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h b/drivers/staging/omapdrm/omap_drv.h index 8dd7d74..bc8daa7 100644 --- a/drivers/staging/omapdrm/omap_drv.h +++ b/drivers/staging/omapdrm/omap_drv.h @@ -76,9 +76,9 @@ void omap_connector_flush(struct drm_connector *connector, void omap_connector_dpms(struct drm_connector *connector, int mode);
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev, - struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd); + struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd); struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev, - struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo); + struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos); struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb); int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y, void **vaddr, dma_addr_t *paddr, unsigned int *screen_width); @@ -128,4 +128,53 @@ static inline int align_pitch(int pitch, int width, int bpp) return ALIGN(pitch, 8 * bytespp); }
+/* should these be made into common util helpers? + */ + +static inline int num_planes(uint32_t pixel_format) +{ + switch (pixel_format) { + default: + return 1; + case DRM_FORMAT_NV12: + case DRM_FORMAT_NV21: + case DRM_FORMAT_NV16: + case DRM_FORMAT_NV61: + return 2; + case DRM_FORMAT_YUV410: + case DRM_FORMAT_YVU410: + case DRM_FORMAT_YUV411: + case DRM_FORMAT_YVU411: + case DRM_FORMAT_YUV420: + case DRM_FORMAT_YVU420: + case DRM_FORMAT_YUV422: + case DRM_FORMAT_YVU422: + case DRM_FORMAT_YUV444: + case DRM_FORMAT_YVU444: + return 3; + } +} + +static inline int objects_lookup(struct drm_device *dev, + struct drm_file *filp, uint32_t pixel_format, + struct drm_gem_object **bos, uint32_t *handles) +{ + int i, n = num_planes(pixel_format); + + for (i = 0; i < n; i++) { + bos[i] = drm_gem_object_lookup(dev, filp, handles[i]); + if (!bos[i]) { + goto fail; + } + } + + return 0; + +fail: + while (--i > 0) { + drm_gem_object_unreference_unlocked(bos[i]); + } + return -ENOENT; +} + #endif /* __OMAP_DRV_H__ */ diff --git a/drivers/staging/omapdrm/omap_fb.c b/drivers/staging/omapdrm/omap_fb.c index 0b50c5b..b28fee3 100644 --- a/drivers/staging/omapdrm/omap_fb.c +++ b/drivers/staging/omapdrm/omap_fb.c @@ -22,11 +22,41 @@ #include "drm_crtc.h" #include "drm_crtc_helper.h"
- /* * framebuffer funcs */
+struct format { + enum omap_color_mode dss_format; + uint32_t pixel_format; + int stride_bpp; /* this times width is stride */ + bool yuv; +}; + +static struct format formats[] = { + /* 16bpp [A]RGB: */ + { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, 2, false }, /* RGB16-565 */ + { OMAP_DSS_COLOR_RGB12U, DRM_FORMAT_RGBX4444, 2, false }, /* RGB12x-4444 */ + { OMAP_DSS_COLOR_RGBX16, DRM_FORMAT_XRGB4444, 2, false }, /* xRGB12-4444 */ + { OMAP_DSS_COLOR_RGBA16, DRM_FORMAT_RGBA4444, 2, false }, /* RGBA12-4444 */ + { OMAP_DSS_COLOR_ARGB16, DRM_FORMAT_ABGR4444, 2, false }, /* ARGB16-4444 */ + { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, 2, false }, /* xRGB15-1555 */ + { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, 2, false }, /* ARGB16-1555 */ + /* 24bpp RGB: */ + { OMAP_DSS_COLOR_RGB24P, DRM_FORMAT_RGB888, 3, false }, /* RGB24-888 */ + /* 32bpp [A]RGB: */ + { OMAP_DSS_COLOR_RGBX32, DRM_FORMAT_RGBX8888, 4, false }, /* RGBx24-8888 */ + { OMAP_DSS_COLOR_RGB24U, DRM_FORMAT_XRGB8888, 4, false }, /* xRGB24-8888 */ + { OMAP_DSS_COLOR_RGBA32, DRM_FORMAT_RGBA8888, 4, false }, /* RGBA32-8888 */ + { OMAP_DSS_COLOR_ARGB32, DRM_FORMAT_ARGB8888, 4, false }, /* ARGB32-8888 */ + /* YUV: */ +/* TODO: multi-planar support.. + { OMAP_DSS_COLOR_NV12, DRM_FORMAT_NV12, 1, true }, + */ + { OMAP_DSS_COLOR_YUV2, DRM_FORMAT_YUYV, 2, true }, + { OMAP_DSS_COLOR_UYVY, DRM_FORMAT_UYVY, 2, true }, +}; + #define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)
struct omap_framebuffer { @@ -171,39 +201,61 @@ void omap_framebuffer_flush(struct drm_framebuffer *fb, }
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev, - struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd) + struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd) { - struct drm_gem_object *bo; + struct drm_gem_object *bos[4]; struct drm_framebuffer *fb; - bo = drm_gem_object_lookup(dev, file, mode_cmd->handle); - if (!bo) { - return ERR_PTR(-ENOENT); - } - fb = omap_framebuffer_init(dev, mode_cmd, bo); - if (!fb) { - return ERR_PTR(-ENOMEM); + int ret; + + ret = objects_lookup(dev, file, mode_cmd->pixel_format, + bos, mode_cmd->handles); + if (ret) + return ERR_PTR(ret); + + fb = omap_framebuffer_init(dev, mode_cmd, bos); + if (IS_ERR(fb)) { + int i, n = num_planes(mode_cmd->pixel_format); + for (i = 0; i < n; i++) + drm_gem_object_unreference_unlocked(bos[i]); + return fb; } return fb; }
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev, - struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo) + struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos) { struct omap_framebuffer *omap_fb; struct drm_framebuffer *fb = NULL; - int size, ret; + struct format *format = NULL; + int i, size, ret;
- DBG("create framebuffer: dev=%p, mode_cmd=%p (%dx%d@%d)", + DBG("create framebuffer: dev=%p, mode_cmd=%p (%dx%d@%4s)", dev, mode_cmd, mode_cmd->width, mode_cmd->height, - mode_cmd->bpp); + (char *)&mode_cmd->pixel_format); + + for (i = 0; i < ARRAY_SIZE(formats); i++) { + if (formats[i].pixel_format == mode_cmd->pixel_format) { + format = &formats[i]; + break; + } + } + + if (!format) { + dev_err(dev->dev, "unsupported pixel format: %4s\n", + (char *)&mode_cmd->pixel_format); + ret = -EINVAL; + goto fail; + }
/* in case someone tries to feed us a completely bogus stride: */ - mode_cmd->pitch = align_pitch(mode_cmd->pitch, - mode_cmd->width, mode_cmd->bpp); + mode_cmd->pitches[0] = align_pitch(mode_cmd->pitches[0], + mode_cmd->width, format->stride_bpp);
omap_fb = kzalloc(sizeof(*omap_fb), GFP_KERNEL); if (!omap_fb) { dev_err(dev->dev, "could not allocate fb\n"); + ret = -ENOMEM; goto fail; }
@@ -216,17 +268,19 @@ struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
DBG("create: FB ID: %d (%p)", fb->base.id, fb);
- size = PAGE_ALIGN(mode_cmd->pitch * mode_cmd->height); + size = PAGE_ALIGN(mode_cmd->pitches[0] * mode_cmd->height);
- if (size > bo->size) { + if (size > bos[0]->size) { dev_err(dev->dev, "provided buffer object is too small!\n"); + ret = -EINVAL; goto fail; }
- omap_fb->bo = bo; + omap_fb->bo = bos[0]; omap_fb->size = size;
- if (omap_gem_get_paddr(bo, &omap_fb->paddr, true)) { + ret = omap_gem_get_paddr(bos[0], &omap_fb->paddr, true); + if (ret) { dev_err(dev->dev, "could not map (paddr)!\n"); goto fail; } @@ -239,5 +293,5 @@ fail: if (fb) { omap_framebuffer_destroy(fb); } - return NULL; + return ERR_PTR(ret); } diff --git a/drivers/staging/omapdrm/omap_fbdev.c b/drivers/staging/omapdrm/omap_fbdev.c index 093ae2f..205eb23 100644 --- a/drivers/staging/omapdrm/omap_fbdev.c +++ b/drivers/staging/omapdrm/omap_fbdev.c @@ -129,7 +129,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, struct drm_framebuffer *fb = NULL; union omap_gem_size gsize; struct fb_info *fbi = NULL; - struct drm_mode_fb_cmd mode_cmd = {0}; + struct drm_mode_fb_cmd2 mode_cmd = {0}; dma_addr_t paddr; void __iomem *vaddr; int size, screen_width; @@ -145,37 +145,42 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, sizes->surface_height, sizes->surface_bpp, sizes->fb_width, sizes->fb_height);
+ mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, + sizes->surface_depth); + mode_cmd.width = sizes->surface_width; mode_cmd.height = sizes->surface_height;
- mode_cmd.bpp = sizes->surface_bpp; - mode_cmd.depth = sizes->surface_depth; - - mode_cmd.pitch = align_pitch( - mode_cmd.width * ((mode_cmd.bpp + 7) / 8), - mode_cmd.width, mode_cmd.bpp); + mode_cmd.pitches[0] = align_pitch( + mode_cmd.width * ((sizes->surface_bpp + 7) / 8), + mode_cmd.width, sizes->surface_bpp);
fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled; if (fbdev->ywrap_enabled) { /* need to align pitch to page size if using DMM scrolling */ - mode_cmd.pitch = ALIGN(mode_cmd.pitch, PAGE_SIZE); + mode_cmd.pitches[0] = ALIGN(mode_cmd.pitches[0], PAGE_SIZE); }
/* allocate backing bo */ gsize = (union omap_gem_size){ - .bytes = PAGE_ALIGN(mode_cmd.pitch * mode_cmd.height), + .bytes = PAGE_ALIGN(mode_cmd.pitches[0] * mode_cmd.height), }; DBG("allocating %d bytes for fb %d", gsize.bytes, dev->primary->index); fbdev->bo = omap_gem_new(dev, gsize, OMAP_BO_SCANOUT | OMAP_BO_WC); if (!fbdev->bo) { dev_err(dev->dev, "failed to allocate buffer object\n"); + ret = -ENOMEM; goto fail; }
- fb = omap_framebuffer_init(dev, &mode_cmd, fbdev->bo); - if (!fb) { + fb = omap_framebuffer_init(dev, &mode_cmd, &fbdev->bo); + if (IS_ERR(fb)) { dev_err(dev->dev, "failed to allocate fb\n"); - ret = -ENOMEM; + /* note: if fb creation failed, we can't rely on fb destroy + * to unref the bo: + */ + drm_gem_object_unreference(fbdev->bo); + ret = PTR_ERR(fb); goto fail; }
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok?
thanks,
greg k-h
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok?
Yup, thanks. That was the intention. Let me know if it gets confusing to know which patches can go now and which have dependency on other trees, and I can setup a git tree on freedesktop which branches for the parts that depend on other trees. I'm not sure if it begins to get a mess to keep track otherwise.
BR, -R
thanks,
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok?
oh, heh.. I found a couple small cleanups to this patch (adding a "const" to a table, and such).. since this can't be applied until drm-next is merged, if you don't mind I'd like to resend this one in a patchset along with the patches adding drm_plane support, which I'm pretty close to ready to send.
BR, -R
thanks,
greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Dec 13, 2011 at 08:18:03PM -0600, Rob Clark wrote:
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH greg@kroah.com wrote:
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
From: Rob Clark rob@ti.com
Update to reflect changes in: "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok?
oh, heh.. I found a couple small cleanups to this patch (adding a "const" to a table, and such).. since this can't be applied until drm-next is merged, if you don't mind I'd like to resend this one in a patchset along with the patches adding drm_plane support, which I'm pretty close to ready to send.
Ok, I've dropped it from my queue now.
greg k-h
dri-devel@lists.freedesktop.org
-
Greg KH -
Rob Clark