Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Hi Rob, On Tue, May 22, 2012 at 03:28:20PM -0600, Rob Clark wrote: > just a few comments from a cursory review.. I need a bit more time > for a more in-depth review but that won't be tonight so I thought I'd > send what I have so far.. Thanks for this. > > +++ b/drivers/gpu/drm/imx/Kconfig > > @@ -0,0 +1,18 @@ > > +config DRM_IMX > > + tristate "DRM Support for Freescale i.MX" > > + select DRM_KMS_HELPER > > + depends on DRM && ARCH_MXC > > + > > +config DRM_IMX_FB_HELPER > > + tristate "provide legacy framebuffer /dev/fb0" > > + depends on DRM_IMX > > + > > +config DRM_IMX_LCDC > > + tristate "DRM Support for Freescale i.MX1 and i.MX2" > > + depends on DRM_IMX > > + help > > + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 > > processor. > > do you have something like cpu_is_imx2() type macros? It would be > preferable not to have a compile time config option for building for > certain hw versions. Ie. on OMAP we could do something like 'if > (cpu_is_omap3xxx()) { ... }' if there was something that needed to be > done different on omap3 family of devices. This way you could choose > to build a kernel supporting either a single omap variants, or all > omap variants. Yes, we have cpu_is_* macros. I don't see though why we should use them here. The result of DRM_IMX_LCDC will be a platform driver for which a suitable device exists only on the correct SoCs. There will be a second DRM_IMX_IPU option next to this one for the newer i.MX SoCs which will be a second platform driver. > > + > > + /* > > + * without file_priv we are called from imx_drm_fbdev_create in > > which > > + * case we only create a framebuffer without a handle. > > + */ > > + if (!file_priv) { > > + struct imx_drm_buf_entry *entry; > > + > > + entry = imx_drm_buf_create(dev, size); > > + if (IS_ERR(entry)) { > > + ret = PTR_ERR(entry); > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->entry = entry; > > + } else { > > + obj = drm_gem_object_lookup(dev, file_priv, > > mode_cmd->handles[0]); > > + if (!obj) { > > + ret = -EINVAL; > > + goto err_buffer; > > + } > > + > > + imx_drm_fb->imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + > > + drm_gem_object_unreference_unlocked(obj); > > > the fb probably should hold the reference to the GEM obj until it is > deleted.. so you don't end up freeing the buffer you are scanning out > until you are done scanning it out. Possibly this gets a bit more > straightforward if you don't have to special case the default/fbcon > framebuffer? > > IIRC, Laurent had sent a patch recently to fix the same issue in the > exynos driver. Yes, just for reference, here is a link: http://permalink.gmane.org/gmane.comp.video.dri.devel/69203 Will fix this. > > + > > +static int imx_drm_gem_mmap_buffer(struct file *filp, > > + struct vm_area_struct *vma) > > +{ > > + struct drm_gem_object *obj = filp->private_data; > > + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > > + struct imx_drm_buf_entry *entry; > > + unsigned long pfn, vm_size; > > + > > + vma->vm_flags |= VM_IO | VM_RESERVED; > > + > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > pgprot_writecombine()? copied from the exynos driver. The exynos driver recently gained support for different cache attribute flags and I could do the same. I would prefer not to even have to think about it by using some generic code here instead of duplicating other peoples bugs. Do you think it's possible to share this code as suggested by Lars? Every SoC not having a IOMMU could share the same code here, it's just not clear to me how we can put this in a form that is acceptable upstream. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
[...] >>> + >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, >>> + struct vm_area_struct *vma) >>> +{ >>> + struct drm_gem_object *obj = filp->private_data; >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); >>> + struct imx_drm_buf_entry *entry; >>> + unsigned long pfn, vm_size; >>> + >>> + vma->vm_flags |= VM_IO | VM_RESERVED; >>> + >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> >> pgprot_writecombine()? > > copied from the exynos driver. The exynos driver recently gained support > for different cache attribute flags and I could do the same. I would > prefer not to even have to think about it by using some generic code > here instead of duplicating other peoples bugs. > > Do you think it's possible to share this code as suggested by Lars? > Every SoC not having a IOMMU could share the same code here, it's just > not clear to me how we can put this in a form that is acceptable > upstream. I may have missed this in the previous discussion. But why can't we put the gem handling code in the toplevel drm folder, give it a config symbol and let drivers which want to use the code select the config symbol? I think the main concern was about introducing a new intermediate layer, but the "simple" gem support would really just a set of helper functions. Thanks, - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] DRM: add Freescale i.MX LCDC driver
On Wed, May 23, 2012 at 10:37:58AM +0200, Lars-Peter Clausen wrote: > [...] > >>> + > >>> +static int imx_drm_gem_mmap_buffer(struct file *filp, > >>> + struct vm_area_struct *vma) > >>> +{ > >>> + struct drm_gem_object *obj = filp->private_data; > >>> + struct imx_drm_gem_obj *imx_drm_gem_obj = to_imx_drm_gem_obj(obj); > >>> + struct imx_drm_buf_entry *entry; > >>> + unsigned long pfn, vm_size; > >>> + > >>> + vma->vm_flags |= VM_IO | VM_RESERVED; > >>> + > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >> > >> pgprot_writecombine()? > > > > copied from the exynos driver. The exynos driver recently gained support > > for different cache attribute flags and I could do the same. I would > > prefer not to even have to think about it by using some generic code > > here instead of duplicating other peoples bugs. > > > > Do you think it's possible to share this code as suggested by Lars? > > Every SoC not having a IOMMU could share the same code here, it's just > > not clear to me how we can put this in a form that is acceptable > > upstream. > > I may have missed this in the previous discussion. But why can't we put the > gem handling code in the toplevel drm folder, give it a config symbol and > let drivers which want to use the code select the config symbol? I think the > main concern was about introducing a new intermediate layer, but the > "simple" gem support would really just a set of helper functions. Same for the kms stuff. Me&Dave shot at sdrm because it introduces an intermediate layer, not because adding some common code for simple drm/kms drivers is pointless. That is very much welcome ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel