gma500: Intel GMA500 staging driver

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

There is no support for the parts without open source userspace (video accelerators, 3D) as per kernel policy.

I'm not a DRM expert so if there is anyone with a GMA500 who actually knows something about DRI internals then help would be most welcome.

Signed-off-by Alan Cox <[email protected]>

---

 drivers/staging/Kconfig                         |    2 
 drivers/staging/Makefile                        |    9 
 drivers/staging/gma500/Kconfig                  |   12 
 drivers/staging/gma500/Makefile                 |   30 
 drivers/staging/gma500/psb_bl.c                 |  167 ++
 drivers/staging/gma500/psb_buffer.c             |  450 ++++++
 drivers/staging/gma500/psb_drm.h                |  696 ++++++++++
 drivers/staging/gma500/psb_drv.c                | 1677 +++++++++++++++++++++++
 drivers/staging/gma500/psb_drv.h                | 1139 ++++++++++++++++
 drivers/staging/gma500/psb_fb.c                 |  840 ++++++++++++
 drivers/staging/gma500/psb_fb.h                 |   59 +
 drivers/staging/gma500/psb_fence.c              |  122 ++
 drivers/staging/gma500/psb_gfx.mod.c            |   27 
 drivers/staging/gma500/psb_gtt.c                | 1034 ++++++++++++++
 drivers/staging/gma500/psb_gtt.h                |  105 +
 drivers/staging/gma500/psb_intel_bios.c         |  301 ++++
 drivers/staging/gma500/psb_intel_bios.h         |  430 ++++++
 drivers/staging/gma500/psb_intel_display.c      | 1489 ++++++++++++++++++++
 drivers/staging/gma500/psb_intel_display.h      |   25 
 drivers/staging/gma500/psb_intel_drv.h          |  247 +++
 drivers/staging/gma500/psb_intel_i2c.c          |  169 ++
 drivers/staging/gma500/psb_intel_lvds.c         |  889 ++++++++++++
 drivers/staging/gma500/psb_intel_modes.c        |   77 +
 drivers/staging/gma500/psb_intel_opregion.c     |   78 +
 drivers/staging/gma500/psb_intel_reg.h          | 1200 ++++++++++++++++
 drivers/staging/gma500/psb_intel_sdvo.c         | 1298 ++++++++++++++++++
 drivers/staging/gma500/psb_intel_sdvo_regs.h    |  338 +++++
 drivers/staging/gma500/psb_irq.c                |  637 +++++++++
 drivers/staging/gma500/psb_irq.h                |   49 +
 drivers/staging/gma500/psb_mmu.c                |  919 +++++++++++++
 drivers/staging/gma500/psb_powermgmt.c          |  797 +++++++++++
 drivers/staging/gma500/psb_powermgmt.h          |   96 +
 drivers/staging/gma500/psb_pvr_glue.c           |   73 +
 drivers/staging/gma500/psb_pvr_glue.h           |   25 
 drivers/staging/gma500/psb_reg.h                |  588 ++++++++
 drivers/staging/gma500/psb_reset.c              |   90 +
 drivers/staging/gma500/psb_sgx.c                |  238 +++
 drivers/staging/gma500/psb_sgx.h                |   32 
 drivers/staging/gma500/psb_ttm_fence.c          |  605 ++++++++
 drivers/staging/gma500/psb_ttm_fence_api.h      |  272 ++++

 drivers/staging/gma500/psb_ttm_fence_driver.h   |  302 ++++
 drivers/staging/gma500/psb_ttm_fence_user.c     |  237 +++
 drivers/staging/gma500/psb_ttm_fence_user.h     |  140 ++
 drivers/staging/gma500/psb_ttm_glue.c           |  349 +++++
 drivers/staging/gma500/psb_ttm_placement_user.c |  628 +++++++++
 drivers/staging/gma500/psb_ttm_placement_user.h |  252 +++
 drivers/staging/gma500/psb_ttm_userobj_api.h    |   85 +
 47 files changed, 19320 insertions(+), 4 deletions(-)

drivers/staging/Makefile +1 -1

@@ -62,12 +62,13 @@ obj-$(CONFIG_SOLO6X10)		+= solo6x10/
 obj-$(CONFIG_TIDSPBRIDGE)	+= tidspbridge/
 obj-$(CONFIG_ACPI_QUICKSTART)	+= quickstart/
 obj-$(CONFIG_WESTBRIDGE_ASTORIA)	+= westbridge/astoria/
-obj-$(CONFIG_SBE_2T3E3)	+= sbe-2t3e3/
+obj-$(CONFIG_SBE_2T3E3)		+= sbe-2t3e3/
 obj-$(CONFIG_ATH6K_LEGACY)	+= ath6kl/
 obj-$(CONFIG_USB_ENESTORAGE)	+= keucr/

Quoted 2 lines

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

So that's all that is needed on the userspace side? Or is there a driver for X that also goes along with this patch that is available somewhere?

Can I also get a TODO file for this directory that lists what needs to be done to move it out of the staging tree, as well as an email to contact for patches and questions?

Quoted 15 lines

drivers/staging/Makefile +2 -3

@@ -62,12 +62,13 @@ obj-$(CONFIG_SOLO6X10)		+= solo6x10/
 obj-$(CONFIG_TIDSPBRIDGE)	+= tidspbridge/
 obj-$(CONFIG_ACPI_QUICKSTART)	+= quickstart/
 obj-$(CONFIG_WESTBRIDGE_ASTORIA)	+= westbridge/astoria/
-obj-$(CONFIG_SBE_2T3E3)	+= sbe-2t3e3/
+obj-$(CONFIG_SBE_2T3E3)		+= sbe-2t3e3/
 obj-$(CONFIG_ATH6K_LEGACY)	+= ath6kl/
 obj-$(CONFIG_USB_ENESTORAGE)	+= keucr/
-obj-$(CONFIG_BCM_WIMAX)	+= bcm/
+obj-$(CONFIG_BCM_WIMAX)		+= bcm/
 obj-$(CONFIG_FT1000)		+= ft1000/
-obj-$(CONFIG_SND_INTEL_SST)		+= intel_sst/

drivers/staging/Makefile obj-$(CONFIG_SOLO6X10) += solo6x10/ · line 74

Quoted 6 lines

drivers/staging/Makefile +3 -1

-obj-$(CONFIG_SPEAKUP)	+= speakup/
+obj-$(CONFIG_SND_INTEL_SST)	+= intel_sst/
+obj-$(CONFIG_SPEAKUP)		+= speakup/
 obj-$(CONFIG_TOUCHSCREEN_CLEARPAD_TM1217)	+= cptm1217/
 obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4)	+= ste_rmi4/
+obj-$(CONFIG_DRM_PSB)		+= gma500/

What's with the formatting changes to this file?

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

I'm not a DRM expert so if there is anyone with a GMA500 who actually knows something about DRI internals then help would be most welcome.

drivers/staging/gma500/psb_intel_reg.h new file +22 -0

+#define BIT0  0x00000001
+#define BIT1  0x00000002
+#define BIT2  0x00000004
+#define BIT3  0x00000008
+#define BIT4  0x00000010
+#define BIT5  0x00000020
+#define BIT6  0x00000040
+#define BIT7  0x00000080
+#define BIT8  0x00000100
+#define BIT9  0x00000200
+#define BIT10 0x00000400
+#define BIT11 0x00000800
+#define BIT12 0x00001000
+#define BIT13 0x00002000
+#define BIT14 0x00004000
+#define BIT15 0x00008000
+#define BIT16 0x00010000
+#define BIT17 0x00020000
+#define BIT18 0x00040000
+#define BIT19 0x00080000
+#define BIT20 0x00100000
+#define BIT21 0x00200000

+++ b/drivers/staging/gma500/psb_intel_sdvo.c

+#ifdef CONFIG_MDFD_GL3

There's a pretty significant amount of code duplication between the modesetting part of this and i915. In an idea world they'd be abstracted enough to avoid that, but I suspect that the risk of breaking i915 (which is something people actually care about) in favour of making the gma500 code (which is something people care about in a very different way) probably doesn't make it worth it right now.

Review

Quoted 2 lines

(quoted diff) +2 -0

+struct mrst_panel_descriptor_v1{
+	uint32_t Panel_Port_Control; /* 1 dword, Register 0x61180 if LVDS */

Caps *and* underscores? Checkpatch.pl needs a -Wtaste switch.

drivers/staging/gma500/psb_drm.h line 397

Quoted 3 lines

drivers/staging/gma500/psb_drm.h new file +3 -0

+	uint16_t Panel_MIPI_Display_Descriptor;
+			/*16 bits, Defined as follows: */
+			/* if MIPI, 0x0000 if LVDS */

"Defined as follows if MIPI, 0x000 if LVDS"?

Quoted 1 line

+struct gct_ioctl_arg{

This never seems to be used. I'd be kind of terrified if it ever needed to be. In fact, are any of these vbt structures used at the moment?

Quoted 1 line

+MODULE_PARM_DESC(ospm, "switch for ospm support");

What does OSPM translate as these days?

drivers/staging/gma500/psb_drv.c line 774

Quoted 7 lines

drivers/staging/gma500/psb_drv.c new file +7 -0

+	/**
+	 *  Init lid switch timer.
+	 *  NOTE: must do this after psb_intel_opregion_init
+	 *  and psb_backlight_init
+	 */
+	if (dev_priv->lid_state)
+		psb_lid_timer_init(dev_priv);

Gak. Shouldn't there be an SCI on state change on opregion systems?

You have *got* to be kidding.

I know I said that I wasn't convinced there was a benefit in trying to use the existing 915 code, but our opregion implementation is

Quoted 1 line

+++ b/drivers/staging/gma500/psb_intel_sdvo.c

Does PSB really support SDVO? I thought by that period the only thing it'd be used for was plug-in SDVO cards, which doesn't seem so likely with PSB.

drivers/staging/gma500/psb_irq.c line 525

Quoted 4 lines

drivers/staging/gma500/psb_irq.c new file +4 -0

+/*
+ * It is used to enable VBLANK interrupt
+ */
+int psb_enable_vblank(struct drm_device *dev, int pipe)

I was confused until I read the comment. Wait.

drivers/staging/gma500/psb_powermgmt.c

Quoted 1 line

drivers/staging/gma500/psb_powermgmt.c +0 -0

I have to say that the code in here scares me, but we'll see how it works...

Quoted 1 line

+#ifdef CONFIG_MDFD_GL3

Ugh. No way to determine this at runtime? Having to build this per-device sounds like a recipe for sadness.

drivers/staging/gma500/psb_powermgmt.c

Quoted 3 lines

drivers/staging/gma500/psb_powermgmt.c +3 -0

+	lid_timer->data = (unsigned long)dev_priv;
+	lid_timer->function = psb_lid_timer_func;
+	lid_timer->expires = jiffies + PSB_LID_DELAY;

So we're waking up 10 times a second just to check the lid state?

like there's two directions it can go. If the intention for now is to provide a kernel-quality unaccelerated 2D driver then there's a *lot* more code that can just be ripped out. If we want the acceleration to work then there's an argument that we should be abstracting that into a more generic SGX layer that other drivers can make use of. Does omapfb have any acceleration? If so, is there anything we can build on there?

Other than that, I think there's a few bogosities here. The only thing I'd really ask about in terms of whether it's ready to go in staging is whether all of those ioctls need to be exposed at the moment.

Quoted 7 lines · Alan Cox

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Quoted 5 lines

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

+++ b/drivers/staging/gma500/psb_intel_sdvo.c

Does PSB really support SDVO? I thought by that period the only thing it'd be used for was plug-in SDVO cards, which doesn't seem so likely with PSB.

drivers/staging/gma500/psb_ttm_fence.c

Quoted 1 line

drivers/staging/gma500/psb_ttm_fence.c +0 -0

This really looks like it's intended to be core TTM functionality, so it should probably go past dri-devel.

This is definitely the best gma500 driver we've seen yet, but it seems like there's two directions it can go. If the intention for now is to provide a kernel-quality unaccelerated 2D driver then there's a *lot* more code that can just be ripped out. If we want the acceleration to work then there's an argument that we should be abstracting that into a more generic SGX layer that other drivers can make use of. Does omapfb have any acceleration? If so, is there anything we can build on there?

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

There is no support for the parts without open source userspace (video accelerators, 3D) as per kernel policy.

I'm not a DRM expert so if there is anyone with a GMA500 who actually knows something about DRI internals then help would be most welcome.

Signed-off-by Alan Cox <[email protected]>

Before I start looking at the code, one high-level question: How much of the code in the gma500 driver would be shared with SOCs from other people (ARM based, typically) that use the PowerVR SGX core?

IOW, is this driver only for parts that Intel (or whoever) has put around the licensed 3D core, or is it actually the same code that the others would use for a non-3D SGX driver?

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

There is no support for the parts without open source userspace (video accelerators, 3D) as per kernel policy.

I'm not a DRM expert so if there is anyone with a GMA500 who actually knows something about DRI internals then help would be most welcome.

Quoted 14 lines · Alan Cox

This is an initial staging driver for the GMA500. It's been stripped out of the PVR drivers and crunched together from various bits of code and different kernels.

Currently it's unaccelerated but still pretty snappy even compositing with the frame buffer X server.

Lots of work is needed to rework the ttm and bo interfaces from being ripped out and then 2D acceleration wants putting back for framebuffer and somehow eventually via DRM.

There is no support for the parts without open source userspace (video accelerators, 3D) as per kernel policy.

Quoted 3 lines

I'm not a DRM expert so if there is anyone with a GMA500 who actually knows something about DRI internals then help would be most welcome.

Okay I'm okay with this going into staging but we should work out a plan for it going forward.

I don't have any poulsbo hw but if some were to appear I could probably expend effort on this.

So where do we want to go my opinion is

a) remove all userspace interfaces and simplify ttm memory management usage.
b) add support to hook this up to the dumb ioctl so we can do trivial generic front buffer allocation, so then a libkms + dumb kms modesetting driver can work on it.
c) figure out how to add interface for acceleration users. Whether TTM fence interfaces are required etc.

So where do we want to go my opinion is

a) remove all userspace interfaces and simplify ttm memory management usage.

b) add support to hook this up to the dumb ioctl so we can do trivial generic front buffer allocation, so then a libkms + dumb kms modesetting driver can work on it.

c) figure out how to add interface for acceleration users. Whether TTM fence interfaces are required etc.

We could probably just add a GEM style buffer allocation interface but we'd probably need to do a lot of RE first to figure out what best suits the hardware, I'm pretty sure I've haven't heard any glowing praise that the current interface suits the hw or is maintainable.

Quoted 3 lines

So where do we want to go my opinion is

a) remove all userspace interfaces and simplify ttm memory management usage.

Some of them appear to be valid/sensible ones for querying mode data and config bits. I'm slowly pruning out the rest

Quoted 3 lines

b) add support to hook this up to the dumb ioctl so we can do trivial generic front buffer allocation, so then a libkms + dumb kms modesetting driver can work on it.

What sort of dumb ioctl do you have in mind ?

Quoted 3 lines

c) figure out how to add interface for acceleration users. Whether TTM fence interfaces are required etc.

The fencing seems to be solely for the various capture/acceleration bits for video as far as I can tell.

It seems we need two things - issue a 2D command and stuff for transferring objects, although it's not clear that the latter is needed.

The old X 2D code is at:
http://git.moblin.org/cgit.cgi/deprecated/xf86-video-psb/