[RFC PATCH] KMS support for i.MX51/53
On Tue, Jun 07, 2011 at 08:59:28PM +0100, Alan Cox wrote: > > I'm not sure I understand you correctly. I have no address space on the > > card side since my 'card' just uses main memory. The memory I need must > > be a physically contiguous portion of sdram. I'm afraid shmem backing > > memory is not of much use for me. > > I hadn't realised you had that underlying limit. If you are limited to a > specific chunk of SDRAM and it must be physically linear rather than any > of memory then indeed it's not. > > I'd been tweaking GEM so you can borrow the abstraction and handles but > back them with your own allocator but in my case it makes sense because I > can use either main memory or a chunk of linear preallocated memory > reserved by the firmware so I wanted the commonality and single set of > handles for GEM, IOCTL_MODE_CREATE_DUMB etc. Your patch looks like it would do the trick. I'll see what I can do. 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- |
[RFC PATCH] KMS support for i.MX51/53
On Tue, Jun 07, 2011 at 12:17:01PM +0100, Alan Cox wrote: > > Currently I don't use any sophisticated memory allocater like GEM > > or similar. I helped myself with simple dma_alloc where needed. At > > GEM is actually pretty sane when you get your head around it a spot. The > main thing it took me a bit of time to get my head around is that it > allocates backing memory and handles but it doesn't allocate address > space on the card side. I'm not sure I understand you correctly. I have no address space on the card side since my 'card' just uses main memory. The memory I need must be a physically contiguous portion of sdram. I'm afraid shmem backing memory is not of much use for me. Correct me if I mix things up... 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- |
[RFC PATCH] KMS support for i.MX51/53
> I'm not sure I understand you correctly. I have no address space on the > card side since my 'card' just uses main memory. The memory I need must > be a physically contiguous portion of sdram. I'm afraid shmem backing > memory is not of much use for me. I hadn't realised you had that underlying limit. If you are limited to a specific chunk of SDRAM and it must be physically linear rather than any of memory then indeed it's not. I'd been tweaking GEM so you can borrow the abstraction and handles but back them with your own allocator but in my case it makes sense because I can use either main memory or a chunk of linear preallocated memory reserved by the firmware so I wanted the commonality and single set of handles for GEM, IOCTL_MODE_CREATE_DUMB etc. Alan
[RFC PATCH] KMS support for i.MX51/53
Hi All, The following adds a KMS driver for the Freescale i.MX51/53 SoCs. It is far from being ready but I think it is enough to send it out and get the first comments on it and to show that there's something going on. Currently I don't use any sophisticated memory allocater like GEM or similar. I helped myself with simple dma_alloc where needed. At the current state I don't need any more sophisticated allocator as I only focused on the KMS part. Many dumb framebuffers on embedded systems could use a simple allocator at least until something better usable for these kind of systems shows up. The driver currently does its allocations in the DRM_IOCTL_MODE_ADDFB ioctl, which of course is not very standard conform. I tested this driver on the i.MX51 with a DVI and VGA display connected in different clone and dual head modes. Also tested is the i.MX53 LOCO board with the optional HDMI adapter (I didn't get the TV encoder for VGA to work though). First part of the series is the IPU base driver which has been posted several times before, this time with generic interrupt support and fully multi instance safe. Also several smaller improvements have been made. For the DRM people probably only the last three patches are of interest. The series depends on several other patches not posted here. So for those who want to test this please pull the following branch: git://git.pengutronix.de/git/imx/linux-2.6.git imx-ipu-kms As said the driver is not fully standard conform and libkms currently is not suitable for this driver, so the only test utility (apart from the legacy framebuffer) is a little selfmade tool you can get here: git://git.pengutronix.de/git/sha/kmstest.git It is basically a KMS wrapper around the well known fbtest utility. Different mode settings can be supplied on the command line. A README is included. Sascha Sascha Hauer (5): DRM: add i.MX IPUv3 base driver DRM i.MX IPU: Add support for IPU submodules DRM: Add drm encoder/connector helper DRM: Add support for the sii902x HDMI/DVI encoder DRM: Add i.MX IPUv3 support arch/arm/plat-mxc/include/mach/ipu-v3.h | 22 + drivers/gpu/drm/Kconfig | 28 + drivers/gpu/drm/Makefile|2 + drivers/gpu/drm/drm_encon.c | 302 ++ drivers/gpu/drm/i2c/Makefile|3 + drivers/gpu/drm/i2c/sii902x.c | 334 +++ drivers/gpu/drm/imx/Makefile|3 + drivers/gpu/drm/imx/imx-drm.c | 936 +++ drivers/gpu/drm/imx/imx-priv.h |9 + drivers/gpu/drm/imx/ipu-v3/Makefile |3 + drivers/gpu/drm/imx/ipu-v3/ipu-common.c | 799 ++ drivers/gpu/drm/imx/ipu-v3/ipu-dc.c | 440 +++ drivers/gpu/drm/imx/ipu-v3/ipu-di.c | 665 ++ drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c | 393 + drivers/gpu/drm/imx/ipu-v3/ipu-dp.c | 342 +++ drivers/gpu/drm/imx/ipu-v3/ipu-prv.h| 218 +++ include/drm/drm_encon.h | 46 ++ include/drm/imx-ipu-v3.h| 308 ++ 18 files changed, 4853 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-mxc/include/mach/ipu-v3.h create mode 100644 drivers/gpu/drm/drm_encon.c create mode 100644 drivers/gpu/drm/i2c/sii902x.c create mode 100644 drivers/gpu/drm/imx/Makefile create mode 100644 drivers/gpu/drm/imx/imx-drm.c create mode 100644 drivers/gpu/drm/imx/imx-priv.h create mode 100644 drivers/gpu/drm/imx/ipu-v3/Makefile create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-common.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dc.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-di.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dp.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-prv.h create mode 100644 include/drm/drm_encon.h create mode 100644 include/drm/imx-ipu-v3.h
[RFC PATCH] KMS support for i.MX51/53
> Currently I don't use any sophisticated memory allocater like GEM > or similar. I helped myself with simple dma_alloc where needed. At GEM is actually pretty sane when you get your head around it a spot. The main thing it took me a bit of time to get my head around is that it allocates backing memory and handles but it doesn't allocate address space on the card side. For a minimal GEM take a look at drivers/staging/gma500/psb_gem.c. As I need to use a GTT and allocate address space I also use a standard Linux resource struct. If you just need to grab RAM and don't care about address spaces then you are well away except for getting console support I imagine. The GMS500 one has no magic interfaces for things like swapping objects, as the card is just using it for 2D frame buffer objects so hopefully is a bit easier to follow than the full works. Alan
Re: [RFC PATCH] KMS support for i.MX51/53
Currently I don't use any sophisticated memory allocater like GEM or similar. I helped myself with simple dma_alloc where needed. At GEM is actually pretty sane when you get your head around it a spot. The main thing it took me a bit of time to get my head around is that it allocates backing memory and handles but it doesn't allocate address space on the card side. For a minimal GEM take a look at drivers/staging/gma500/psb_gem.c. As I need to use a GTT and allocate address space I also use a standard Linux resource struct. If you just need to grab RAM and don't care about address spaces then you are well away except for getting console support I imagine. The GMS500 one has no magic interfaces for things like swapping objects, as the card is just using it for 2D frame buffer objects so hopefully is a bit easier to follow than the full works. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] KMS support for i.MX51/53
On Tue, Jun 07, 2011 at 12:17:01PM +0100, Alan Cox wrote: Currently I don't use any sophisticated memory allocater like GEM or similar. I helped myself with simple dma_alloc where needed. At GEM is actually pretty sane when you get your head around it a spot. The main thing it took me a bit of time to get my head around is that it allocates backing memory and handles but it doesn't allocate address space on the card side. I'm not sure I understand you correctly. I have no address space on the card side since my 'card' just uses main memory. The memory I need must be a physically contiguous portion of sdram. I'm afraid shmem backing memory is not of much use for me. Correct me if I mix things up... 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
