radeon.pcie_gen2=1 unusable with AMD 990X chipset

2012-03-05 Thread Boszormenyi Zoltan 
Hi,

last week I bought a new ASUS M5A99X EVO AM3+ mainboard.
It supports PCIe 2.0. I also have a Radeon 6570 videocard (PCIe 2.0)
and a 3ware 9650SE 8LPML RAID card (PCIe 1.0).

There are 3 PCIe x16 slots on the mainboard, two of them share x16
wiring so single card x16 or dual card x8/x8 is possible. The 3rd slot
is PCIe x16 slot with dedicated x4 wiring, no sharing with the first 2 slots.
The RAID card is sitting in the 3rd slot.

I am running Fedora 16 with the latest 3.2.7-1.fc16.x86_64 kernel.

I have set radeon.pcie_gen2=1 in grub2 config to test PCIe 2.0 speed with
the videocard. It reliably locks up on boot. As a result, the mainboard
gets confused so much that it needs CMOS clear, otherwise even after
hard reset it cannot boot up successfully. I tried it a couple of times,
the symptoms (without CMOS clear) are mysteriously different. From the
few attempts, I experienced these:

- the mainboard reports faulty videocard, no image on display
- the mainboard passes the videocard test but reports faulty boot drive
  (I guess it cannot initialize the RAID card as it's the primary boot drive)
  and still no image on display
- the first few screens appear on the display but e.g. the onboard SATA
  controller cannot find the DVD drive and the BIOS initialization sequence
  stops somewhere, it doesn't reach the GRUB menu

The motherboard has an AMD 990X chipset.

Without radeon.pcie_gen2=1, the system works and is stable.

I don't know what to blame. The chipset, BIOS bugs, or the mix of
PCIe 1.0 and 2.0 devices. Anyway, I thought it would be an interesting
detail for Radeon developers.

Best regards,
Zoltán Böszörményi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread Alan Cox 
From: Alan Cox 

[Resending with correct address for Linus]

Production GMA3600/3650 hardware turns out to be subtly different to the
development platforms. This combined with a minor driver bug is causing
the kernel to hang on these platforms.

This patch does the following

- turn down a couple of messages that were meant to be debug and are
  causing much confusion

- ensure the hotplug interrupt is disabled on Cedartrail systems.

- fix a bug where gtt roll mode called psbfb_sync, which tries to sync
  the 2D engine. On other devices it is harmless as the 2D engine is
  present but not in use when in gtt roll mode, on Cedartrail it causes
  a hang

Without these changes 3.3-rc hangs on boot on Cedartrail based systems.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/cdv_device.c  |2 ++
 drivers/gpu/drm/gma500/framebuffer.c |1 -
 drivers/gpu/drm/gma500/gtt.c |9 -
 3 files changed, 6 insertions(+), 6 deletions(-)


diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index 4a5b099..53404af 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -321,6 +321,8 @@ static int cdv_chip_setup(struct drm_device *dev)
cdv_get_core_freq(dev);
gma_intel_opregion_init(dev);
psb_intel_init_bios(dev);
+   REG_WRITE(PORT_HOTPLUG_EN, 0);
+   REG_WRITE(PORT_HOTPLUG_STAT, REG_READ(PORT_HOTPLUG_STAT));
return 0;
 }
 
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 830dfdd6b..be61673 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -247,7 +247,6 @@ static struct fb_ops psbfb_roll_ops = {
.fb_imageblit = cfb_imageblit,
.fb_pan_display = psbfb_pan,
.fb_mmap = psbfb_mmap,
-   .fb_sync = psbfb_sync,
.fb_ioctl = psbfb_ioctl,
 };
 
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 5d5330f..aff194f 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -446,10 +446,9 @@ int psb_gtt_init(struct drm_device *dev, int resume)
pg->gtt_start = pci_resource_start(dev->pdev, PSB_GTT_RESOURCE);
gtt_pages = pci_resource_len(dev->pdev, PSB_GTT_RESOURCE)
>> PAGE_SHIFT;
-   /* Some CDV firmware doesn't report this currently. In which case the
-  system has 64 gtt pages */
+   /* CDV doesn't report this. In which case the system has 64 gtt pages */
if (pg->gtt_start == 0 || gtt_pages == 0) {
-   dev_err(dev->dev, "GTT PCI BAR not initialized.\n");
+   dev_dbg(dev->dev, "GTT PCI BAR not initialized.\n");
gtt_pages = 64;
pg->gtt_start = dev_priv->pge_ctl;
}
@@ -461,10 +460,10 @@ int psb_gtt_init(struct drm_device *dev, int resume)
 
if (pg->gatt_pages == 0 || pg->gatt_start == 0) {
static struct resource fudge;   /* Preferably peppermint */
-   /* This can occur on CDV SDV systems. Fudge it in this case.
+   /* This can occur on CDV systems. Fudge it in this case.
   We really don't care what imaginary space is being allocated
   at this point */
-   dev_err(dev->dev, "GATT PCI BAR not initialized.\n");
+   dev_dbg(dev->dev, "GATT PCI BAR not initialized.\n");
pg->gatt_start = 0x4000;
pg->gatt_pages = (128 * 1024 * 1024) >> PAGE_SHIFT;
/* This is a little confusing but in fact the GTT is providing

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42869] New: [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=42869

   Summary: [3.3-rc1 regression] [nouveau] Spurious TV-out
detected
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3-rc5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: sch...@linux-m68k.org
Regression: Yes


Created an attachment (id=72540)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72540)
drm messages from 3.2.1

:f0:10.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX
5200 Ultra] (rev a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Device 0010
Flags: bus master, 66MHz, medium devsel, latency 16, IRQ 48
Memory at 9100 (32-bit, non-prefetchable) [size=16M]
Memory at 9800 (32-bit, prefetchable) [size=128M]
Expansion ROM at 9000 [disabled] [size=128K]

The monitor is connected to DVI-I-2, but the driver claims output is on
TV-1.

Here's the difference of the kernel output between 3.2.1 and 3.3-rc5:

< [drm] nouveau :f0:10.0: Found Display Configuration Block version 2.2
< [drm] nouveau :f0:10.0: Raw DCB entry 0: 01100102 
< [drm] nouveau :f0:10.0: Raw DCB entry 1: 01000100 88b8
< [drm] nouveau :f0:10.0: Raw DCB entry 2: 02110212 11b0
< [drm] nouveau :f0:10.0: Raw DCB entry 3: 02010210 11b088b8
< [drm] nouveau :f0:10.0: Raw DCB entry 4: 02010211 11b3
> [drm] nouveau :f0:10.0: I2C4: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C7: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C8: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C9: type 2 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C15: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: MXM: no VBIOS data, nothing to do
> [drm] nouveau :f0:10.0: DCB version 2.2
> [drm] nouveau :f0:10.0: DCB outp 00: 01100102 
> [drm] nouveau :f0:10.0: DCB outp 01: 01000100 88b8
> [drm] nouveau :f0:10.0: DCB outp 02: 02110212 11b0
> [drm] nouveau :f0:10.0: DCB outp 03: 02010210 11b088b8
> [drm] nouveau :f0:10.0: DCB outp 04: 02010211 11b3
---
< [drm] nouveau :f0:10.0: allocated 1280x1024 fb: 0x49000, bo
c00177cd8000
< [drm] nouveau :f0:10.0: Setting dpms mode 0 on tmds encoder (output 2)
< [drm] nouveau :f0:10.0: Output DVI-I-2 is running on CRTC 1 using output
B
> [drm] nouveau :f0:10.0: Load detected on output B
> [drm] nouveau :f0:10.0: allocated 720x576 fb: 0x49000, bo c00177c00400
> [drm] nouveau :f0:10.0: Setting dpms mode 0 on TV encoder (output 4)
> [drm] nouveau :f0:10.0: Output TV-1 is running on CRTC 1 using output B

Reverting commit a0b25635515ef5049f93b032a1e37f18b16e0f6f ("drm/nouveau/gpio:
reimplement as nouveau_gpio.c, fixing a number of issues") (together with
47e5d5cb83d4b41168f4afa1ca32843d4a126cc8,
52c4d767437b40b0cbc02d6a4480abb45ace64bb and
7df898b1a70b13c3a8892625f4ead929d9554293 which depend on it) fixes the issue,
and nouveau.tv_disable=1 is also a workaround.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42869] [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=42869





--- Comment #1 from Andreas Schwab   2012-03-05 14:22:09 
---
Created an attachment (id=72541)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72541)
drm messages from 3.3-rc5

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42869] [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=42869


Andreas Schwab  changed:

   What|Removed |Added

 Blocks||42644




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/10] omapdrm patches for 3.4

2012-03-05 Thread Rob Clark 
From: Rob Clark 

This is the (potentially first) batch of patches for omapdrm for 3.4.
It includes some fixes for OMAP3 (without DMM), and change in how
the DMM code gets it's platform data based on review comments from
the first version of the patch which added the omapdrm platform dev.

Also, a few cleanups, a better solution for handling fbdev calls from
atomix context, deferred unpin until scanout completes, mmap of tiled
buffers w/ stride larger than PAGE_SIZE.

There is one additional patch to come after the platform device patch
is merged (in arch/arm/plat-omap) to remove some duplicated structs.
And I am still working on support for scanout and rotated scanout of
tiled buffers, which may or may not be ready in time for 3.4 merge
window.

Andy Gross (3):
  staging: drm/omap: Disable DMM debugfs for OMAP3
  staging: drm/omap: Validate debugfs device
  staging: drm/omap: Get DMM resources from hwmod

Rob Clark (7):
  staging: drm/omap: get supported color formats from ovl
  staging: drm/omap: add a workqueue
  staging: drm/omap: call omap_gem_roll() in non-atomic ctx
  staging: drm/omap: some minor fb cleanups
  staging: drm/omap: defer unpin until scanout completes
  staging: drm/omap: debugfs for object and fb tracking
  staging: drm/omap: mmap of tiled buffers with stride >4kb

 drivers/staging/omapdrm/omap_debugfs.c   |   97 +-
 drivers/staging/omapdrm/omap_dmm_tiler.c |   91 
 drivers/staging/omapdrm/omap_dmm_tiler.h |   15 ++--
 drivers/staging/omapdrm/omap_drv.c   |   16 +++
 drivers/staging/omapdrm/omap_drv.h   |   17 +++-
 drivers/staging/omapdrm/omap_fb.c|  124 +++---
 drivers/staging/omapdrm/omap_fbdev.c |   26 -
 drivers/staging/omapdrm/omap_gem.c   |  172 ++
 drivers/staging/omapdrm/omap_plane.c |  161 +++-
 9 files changed, 570 insertions(+), 149 deletions(-)

-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/10] staging: drm/omap: get supported color formats from ovl

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Get the supported formats for a plane from ovl's supported_modes
bitmask.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |2 ++
 drivers/staging/omapdrm/omap_fb.c|   14 ++
 drivers/staging/omapdrm/omap_plane.c |   27 +++
 3 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 61fe022..d924c95 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -92,6 +92,8 @@ void omap_connector_mode_set(struct drm_connector *connector,
 void omap_connector_flush(struct drm_connector *connector,
int x, int y, int w, int h);
 
+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+   uint32_t max_formats, enum omap_color_mode supported_modes);
 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index d021a7e..116a8ff 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,6 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
 };
 
+/* convert from overlay's pixel formats bitmask to an array of fourcc's */
+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+   uint32_t max_formats, enum omap_color_mode supported_modes)
+{
+   uint32_t nformats = 0;
+   int i = 0;
+
+   for (i = 0; i < ARRAY_SIZE(formats) && nformats < max_formats; i++)
+   if (formats[i].dss_format & supported_modes)
+   pixel_formats[nformats++] = formats[i].pixel_format;
+
+   return nformats;
+}
+
 /* per-plane info for the fb: */
 struct plane {
struct drm_gem_object *bo;
diff --git a/drivers/staging/omapdrm/omap_plane.c 
b/drivers/staging/omapdrm/omap_plane.c
index 9790912..c5625e3 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -43,8 +43,10 @@ struct omap_plane {
 
/* last fb that we pinned: */
struct drm_framebuffer *pinned_fb;
-};
 
+   uint32_t nformats;
+   uint32_t formats[32];
+};
 
 /* push changes down to dss2 */
 static int commit(struct drm_plane *plane)
@@ -271,24 +273,6 @@ static const struct drm_plane_funcs omap_plane_funcs = {
.destroy = omap_plane_destroy,
 };
 
-static const uint32_t formats[] = {
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_RGBX,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_RGBA,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_ARGB1555,
-   DRM_FORMAT_RGB888,
-   DRM_FORMAT_RGBX,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_RGBA,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_NV12,
-   DRM_FORMAT_YUYV,
-   DRM_FORMAT_UYVY,
-};
-
 /* initialize plane */
 struct drm_plane *omap_plane_init(struct drm_device *dev,
struct omap_overlay *ovl, unsigned int possible_crtcs,
@@ -306,11 +290,14 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
goto fail;
}
 
+   omap_plane->nformats = omap_framebuffer_get_formats(
+   omap_plane->formats, ARRAY_SIZE(omap_plane->formats),
+   ovl->supported_modes);
omap_plane->ovl = ovl;
plane = &omap_plane->base;
 
drm_plane_init(dev, plane, possible_crtcs, &omap_plane_funcs,
-   formats, ARRAY_SIZE(formats), priv);
+   omap_plane->formats, omap_plane->nformats, priv);
 
/* get our starting configuration, set defaults for parameters
 * we don't currently use, etc:
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/10] staging: drm/omap: add a workqueue

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Add a workqueue for omapdrm driver, which is needed for at least a
couple things currently: (1) moving omap_gem_roll() to a non-atomic
context, (2) synchronizing page flips w/ DSS scanout related irq's
(in particular not unmapping previous buffer until DSS finishes
scanout).

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.c |8 
 drivers/staging/omapdrm/omap_drv.h |2 ++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 3bbea9a..7417e1f 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -570,6 +570,9 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
 
dev->dev_private = priv;
 
+   priv->wq = alloc_workqueue("omapdrm",
+   WQ_UNBOUND | WQ_NON_REENTRANT, 1);
+
omap_gem_init(dev);
 
ret = omap_modeset_init(dev);
@@ -598,6 +601,8 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
 
 static int dev_unload(struct drm_device *dev)
 {
+   struct omap_drm_private *priv = dev->dev_private;
+
DBG("unload: dev=%p", dev);
 
drm_vblank_cleanup(dev);
@@ -607,6 +612,9 @@ static int dev_unload(struct drm_device *dev)
omap_modeset_free(dev);
omap_gem_deinit(dev);
 
+   flush_workqueue(priv->wq);
+   destroy_workqueue(priv->wq);
+
kfree(dev->dev_private);
dev->dev_private = NULL;
 
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index d924c95..a84547c 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -51,6 +51,8 @@ struct omap_drm_private {
 
struct drm_fb_helper *fbdev;
 
+   struct workqueue_struct *wq;
+
bool has_dmm;
 };
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/10] staging: drm/omap: call omap_gem_roll() in non-atomic ctx

2012-03-05 Thread Rob Clark 
From: Rob Clark 

If fbcon calls us from atomic context, push the work off to the
workqueue to avoid calling into the gem/dmm code in an atomic
context.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fbdev.c |   26 ++
 drivers/staging/omapdrm/omap_gem.c   |   14 ++
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fbdev.c 
b/drivers/staging/omapdrm/omap_fbdev.c
index 96940bb..11acd4c 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -37,6 +37,9 @@ struct omap_fbdev {
struct drm_framebuffer *fb;
struct drm_gem_object *bo;
bool ywrap_enabled;
+
+   /* for deferred dmm roll when getting called in atomic ctx */
+   struct work_struct work;
 };
 
 static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
@@ -75,12 +78,22 @@ static void omap_fbdev_imageblit(struct fb_info *fbi,
image->width, image->height);
 }
 
+static void pan_worker(struct work_struct *work)
+{
+   struct omap_fbdev *fbdev = container_of(work, struct omap_fbdev, work);
+   struct fb_info *fbi = fbdev->base.fbdev;
+   int npages;
+
+   /* DMM roll shifts in 4K pages: */
+   npages = fbi->fix.line_length >> PAGE_SHIFT;
+   omap_gem_roll(fbdev->bo, fbi->var.yoffset * npages);
+}
+
 static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
 {
struct drm_fb_helper *helper = get_fb(fbi);
struct omap_fbdev *fbdev = to_omap_fbdev(helper);
-   int npages;
 
if (!helper)
goto fallback;
@@ -88,9 +101,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo 
*var,
if (!fbdev->ywrap_enabled)
goto fallback;
 
-   /* DMM roll shifts in 4K pages: */
-   npages = fbi->fix.line_length >> PAGE_SHIFT;
-   omap_gem_roll(fbdev->bo, var->yoffset * npages);
+   if (drm_can_sleep()) {
+   pan_worker(&fbdev->work);
+   } else {
+   struct omap_drm_private *priv = helper->dev->dev_private;
+   queue_work(priv->wq, &fbdev->work);
+   }
 
return 0;
 
@@ -336,6 +352,8 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
goto fail;
}
 
+   INIT_WORK(&fbdev->work, pan_worker);
+
helper = &fbdev->base;
 
helper->funcs = &omap_fb_helper_funcs;
diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index b7d6f88..bd35520 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -566,6 +566,8 @@ fail:
 
 /* Set scrolling position.  This allows us to implement fast scrolling
  * for console.
+ *
+ * Call only from non-atomic contexts.
  */
 int omap_gem_roll(struct drm_gem_object *obj, uint32_t roll)
 {
@@ -580,18 +582,6 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t 
roll)
 
omap_obj->roll = roll;
 
-   if (in_atomic() || mutex_is_locked(&obj->dev->struct_mutex)) {
-   /* this can get called from fbcon in atomic context.. so
-* just ignore it and wait for next time called from
-* interruptible context to update the PAT.. the result
-* may be that user sees wrap-around instead of scrolling
-* momentarily on the screen.  If we wanted to be fancier
-* we could perhaps schedule some workqueue work at this
-* point.
-*/
-   return 0;
-   }
-
mutex_lock(&obj->dev->struct_mutex);
 
/* if we aren't mapped yet, we don't need to do anything */
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/10] staging: drm/omap: some minor fb cleanups

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Now that 'struct drm_plane' has a pixel_format field, use that.  And
fix a minor typo.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fb.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 116a8ff..08e2e35 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -101,7 +101,7 @@ static int omap_framebuffer_create_handle(struct 
drm_framebuffer *fb,
 static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int i, n = drm_format_num_planes(omap_fb->format->pixel_format);
+   int i, n = drm_format_num_planes(fb->pixel_format);
 
DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
 
@@ -204,7 +204,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb, int x, int y,
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   if (p >= drm_format_num_planes(omap_fb->format->pixel_format))
+   if (p >= drm_format_num_planes(fb->pixel_format))
return NULL;
return omap_fb->planes[p].bo;
 }
@@ -351,8 +351,8 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
 
plane->bo = bos[i];
plane->offset = mode_cmd->offsets[i];
-   plane->pitch  = mode_cmd->pitches[i];
-   plane->paddr  = pitch;
+   plane->pitch  = pitch;
+   plane->paddr  = 0;
}
 
drm_helper_mode_fill_fb_struct(fb, mode_cmd);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/10] staging: drm/omap: defer unpin until scanout completes

2012-03-05 Thread Rob Clark 
From: Rob Clark 

When flipping, defer unpinning until scanout completes, as indicated
by the appropriate END_WIN irq.

This also re-organizes things a bit, in replacing omap_fb_{pin,unpin}
with omap_fb_replace(), to make it easier to add support for scanout
synchronized DMM refill mode (flipping by just reprogramming DMM
synchronized with DSS scanout).

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |5 +-
 drivers/staging/omapdrm/omap_fb.c|   84 -
 drivers/staging/omapdrm/omap_plane.c |  136 --
 3 files changed, 181 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index a84547c..fe4766e 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -101,8 +101,9 @@ struct drm_framebuffer *omap_framebuffer_create(struct 
drm_device *dev,
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
-int omap_framebuffer_pin(struct drm_framebuffer *fb);
-void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+   struct drm_framebuffer *b, void *arg,
+   void (*unpin)(void *arg, struct drm_gem_object *bo));
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 08e2e35..fcb248f 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -137,41 +137,6 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
 };
 
-/* pins buffer in preparation for scanout */
-int omap_framebuffer_pin(struct drm_framebuffer *fb)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int ret, i, n = drm_format_num_planes(omap_fb->format->pixel_format);
-
-   for (i = 0; i < n; i++) {
-   struct plane *plane = &omap_fb->planes[i];
-   ret = omap_gem_get_paddr(plane->bo, &plane->paddr, true);
-   if (ret)
-   goto fail;
-   }
-
-   return 0;
-
-fail:
-   while (--i > 0) {
-   struct plane *plane = &omap_fb->planes[i];
-   omap_gem_put_paddr(plane->bo);
-   }
-   return ret;
-}
-
-/* releases buffer when done with scanout */
-void omap_framebuffer_unpin(struct drm_framebuffer *fb)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int i, n = drm_format_num_planes(omap_fb->format->pixel_format);
-
-   for (i = 0; i < n; i++) {
-   struct plane *plane = &omap_fb->planes[i];
-   omap_gem_put_paddr(plane->bo);
-   }
-}
-
 /* update ovl info for scanout, handles cases of multi-planar fb's, etc.
  */
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
@@ -201,6 +166,55 @@ void omap_framebuffer_update_scanout(struct 
drm_framebuffer *fb, int x, int y,
}
 }
 
+/* Call for unpin 'a' (if not NULL), and pin 'b' (if not NULL).  Although
+ * buffers to unpin are just just pushed to the unpin fifo so that the
+ * caller can defer unpin until vblank.
+ *
+ * Note if this fails (ie. something went very wrong!), all buffers are
+ * unpinned, and the caller disables the overlay.  We could have tried
+ * to revert back to the previous set of pinned buffers but if things are
+ * hosed there is no guarantee that would succeed.
+ */
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+   struct drm_framebuffer *b, void *arg,
+   void (*unpin)(void *arg, struct drm_gem_object *bo))
+{
+   int ret = 0, i, na, nb;
+   struct omap_framebuffer *ofba = to_omap_framebuffer(a);
+   struct omap_framebuffer *ofbb = to_omap_framebuffer(b);
+
+   na = a ? drm_format_num_planes(a->pixel_format) : 0;
+   nb = b ? drm_format_num_planes(b->pixel_format) : 0;
+
+   for (i = 0; i < max(na, nb); i++) {
+   struct plane *pa, *pb;
+
+   pa = (i < na) ? &ofba->planes[i] : NULL;
+   pb = (i < nb) ? &ofbb->planes[i] : NULL;
+
+   if (pa) {
+   unpin(arg, pa->bo);
+   pa->paddr = 0;
+   }
+
+   if (pb && !ret)
+   ret = omap_gem_get_paddr(pb->bo, &pb->paddr, true);
+   }
+
+   if (ret) {
+   /* something went wrong.. unpin what has been pinned */
+   for (i = 0; i < nb; i++) {
+   struct plane *pb = &ofba->planes[i];
+   if (pb->paddr) {
+   unpin(

[PATCH 06/10] staging: drm/omap: debugfs for object and fb tracking

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Add some additional debugfs file to aid in tracking buffer usage.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_debugfs.c |   98 +++-
 drivers/staging/omapdrm/omap_drv.c |2 +
 drivers/staging/omapdrm/omap_drv.h |8 +++
 drivers/staging/omapdrm/omap_fb.c  |   18 ++
 drivers/staging/omapdrm/omap_gem.c |   64 -
 5 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
index da920df..e23f907 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -20,23 +20,119 @@
 #include "omap_drv.h"
 #include "omap_dmm_tiler.h"
 
+#include "drm_fb_helper.h"
+
+
 #ifdef CONFIG_DEBUG_FS
 
+static int gem_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   int ret;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret)
+   return ret;
+
+   seq_printf(m, "All Objects:\n");
+   omap_gem_describe_objects(&priv->obj_list, m);
+
+   mutex_unlock(&dev->struct_mutex);
+
+   return 0;
+}
+
+static int mm_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   return drm_mm_dump_table(m, dev->mm_private);
+}
+
+static int fb_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   struct drm_framebuffer *fb;
+   int ret;
+
+   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
+   if (ret)
+   return ret;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret) {
+   mutex_unlock(&dev->mode_config.mutex);
+   return ret;
+   }
+
+   seq_printf(m, "fbcon ");
+   omap_framebuffer_describe(priv->fbdev->fb, m);
+
+   list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+   if (fb == priv->fbdev->fb)
+   continue;
+
+   seq_printf(m, "user ");
+   omap_framebuffer_describe(fb, m);
+   }
+
+   mutex_unlock(&dev->struct_mutex);
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return 0;
+}
+
+/* list of debufs files that are applicable to all devices */
 static struct drm_info_list omap_debugfs_list[] = {
+   {"gem", gem_show, 0},
+   {"mm", mm_show, 0},
+   {"fb", fb_show, 0},
+};
+
+/* list of debugfs files that are specific to devices with dmm/tiler */
+static struct drm_info_list omap_dmm_debugfs_list[] = {
{"tiler_map", tiler_map_show, 0},
 };
 
 int omap_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(omap_debugfs_list,
+   struct drm_device *dev = minor->dev;
+   int ret;
+
+   ret = drm_debugfs_create_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list),
minor->debugfs_root, minor);
+
+   if (ret) {
+   dev_err(dev->dev, "could not install omap_debugfs_list\n");
+   return ret;
+   }
+
+   /* TODO: only do this if has_dmm.. but this fxn gets called before
+* dev_load() so we don't know this yet..
+*/
+   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list),
+   minor->debugfs_root, minor);
+
+   if (ret) {
+   dev_err(dev->dev, "could not install omap_dmm_debugfs_list\n");
+   return ret;
+   }
+
+   return ret;
 }
 
 void omap_debugfs_cleanup(struct drm_minor *minor)
 {
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
+   drm_debugfs_remove_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
 }
 
 #endif
diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 7417e1f..e2100bb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -573,6 +573,8 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
priv->wq = alloc_workqueue("omapdrm",
WQ_UNBOUND | WQ_NON_REENTRANT, 1);
 
+   INIT_LIST_HEAD(&priv->obj_list);
+
omap_gem_init(dev);
 
ret = omap_modeset_init(dev);
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index fe4766e..21e48cf 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -42,10 +42,13 @@
 struct omap_drm_p

[PATCH 07/10] staging: drm/omap: Disable DMM debugfs for OMAP3

2012-03-05 Thread Rob Clark 
From: Andy Gross 

OMAP3 does not contain a DMM/Tiler block.  As such, we should not
be exposing any DMM debugfs entries on OMAP3 platforms.

Added inline helper function to verify existence of DMM.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_debugfs.c   |   15 +++
 drivers/staging/omapdrm/omap_dmm_tiler.h |6 ++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
index e23f907..2f122e0 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -112,12 +112,10 @@ int omap_debugfs_init(struct drm_minor *minor)
return ret;
}
 
-   /* TODO: only do this if has_dmm.. but this fxn gets called before
-* dev_load() so we don't know this yet..
-*/
-   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
-   ARRAY_SIZE(omap_dmm_debugfs_list),
-   minor->debugfs_root, minor);
+   if (dmm_is_available())
+   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list),
+   minor->debugfs_root, minor);
 
if (ret) {
dev_err(dev->dev, "could not install omap_dmm_debugfs_list\n");
@@ -131,8 +129,9 @@ void omap_debugfs_cleanup(struct drm_minor *minor)
 {
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
-   drm_debugfs_remove_files(omap_dmm_debugfs_list,
-   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
+   if (dmm_is_available())
+   drm_debugfs_remove_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
 }
 
 #endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.h 
b/drivers/staging/omapdrm/omap_dmm_tiler.h
index f87cb65..55ab284 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.h
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.h
@@ -16,6 +16,7 @@
 #ifndef OMAP_DMM_TILER_H
 #define OMAP_DMM_TILER_H
 
+#include 
 #include "omap_drv.h"
 #include "tcm.h"
 
@@ -132,4 +133,9 @@ struct omap_dmm_platform_data {
int irq;
 };
 
+static inline int dmm_is_available(void)
+{
+   return cpu_is_omap44xx();
+}
+
 #endif
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/10] staging: drm/omap: Validate debugfs device

2012-03-05 Thread Rob Clark 
From: Andy Gross 

Added check for valid device information before dumping debugfs
information.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 852d944..e4c7bb6 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -766,10 +766,18 @@ int tiler_map_show(struct seq_file *s, void *arg)
const char *a2d = special;
const char *m2dp = m2d, *a2dp = a2d;
char nice[128];
-   int h_adj = omap_dmm->lut_height / ydiv;
-   int w_adj = omap_dmm->lut_width / xdiv;
+   int h_adj;
+   int w_adj;
unsigned long flags;
 
+   if (!omap_dmm) {
+   /* early return if dmm/tiler device is not initialized */
+   return 0;
+   }
+
+   h_adj = omap_dmm->lut_height / ydiv;
+   w_adj = omap_dmm->lut_width / xdiv;
+
map = kzalloc(h_adj * sizeof(*map), GFP_KERNEL);
global_map = kzalloc((w_adj + 1) * h_adj, GFP_KERNEL);
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/10] staging: drm/omap: Get DMM resources from hwmod

2012-03-05 Thread Rob Clark 
From: Andy Gross 

This patch splits the DMM off into a separate sub-device, in order to
utilize the platform device information that was created as part of
the OMAP hwmod entry for the DMM.

The driver probe function queries the iomem resource and IRQ using
standard platform_get functions.

The OMAP DRM driver now calls the platform_driver_register() function
for the subordinate DMM driver inside its probe function.  This
guarantees the required order for the DMM and ensures the DMM resources
are available for use by the DRM driver.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |   79 +
 drivers/staging/omapdrm/omap_dmm_tiler.h |   11 +---
 drivers/staging/omapdrm/omap_drv.c   |6 ++
 drivers/staging/omapdrm/omap_gem.c   |8 +--
 4 files changed, 68 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index e4c7bb6..1ecb6a7 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -34,6 +34,8 @@
 #include "omap_dmm_tiler.h"
 #include "omap_dmm_priv.h"
 
+#define DMM_DRIVER_NAME "dmm"
+
 /* mappings for associating views to luts */
 static struct tcm *containers[TILFMT_NFORMATS];
 static struct dmm *omap_dmm;
@@ -465,7 +467,12 @@ size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w, 
uint16_t h)
return round_up(geom[fmt].cpp * w, PAGE_SIZE) * h;
 }
 
-int omap_dmm_remove(void)
+bool dmm_is_initialized(void)
+{
+   return omap_dmm ? true : false;
+}
+
+static int omap_dmm_remove(struct platform_device *dev)
 {
struct tiler_block *block, *_block;
int i;
@@ -499,40 +506,49 @@ int omap_dmm_remove(void)
if (omap_dmm->irq != -1)
free_irq(omap_dmm->irq, omap_dmm);
 
+   iounmap(omap_dmm->base);
kfree(omap_dmm);
+   omap_dmm = NULL;
}
 
return 0;
 }
 
-int omap_dmm_init(struct drm_device *dev)
+static int omap_dmm_probe(struct platform_device *dev)
 {
int ret = -EFAULT, i;
struct tcm_area area = {0};
u32 hwinfo, pat_geom, lut_table_size;
-   struct omap_drm_platform_data *pdata = dev->dev->platform_data;
-
-   if (!pdata || !pdata->dmm_pdata) {
-   dev_err(dev->dev, "dmm platform data not present, skipping\n");
-   return ret;
-   }
+   struct resource *mem;
 
omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
if (!omap_dmm) {
-   dev_err(dev->dev, "failed to allocate driver data section\n");
+   dev_err(&dev->dev, "failed to allocate driver data section\n");
goto fail;
}
 
/* lookup hwmod data - base address and irq */
-   omap_dmm->base = pdata->dmm_pdata->base;
-   omap_dmm->irq = pdata->dmm_pdata->irq;
-   omap_dmm->dev = dev->dev;
+   mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
+   if (!mem) {
+   dev_err(&dev->dev, "failed to get base address resource\n");
+   goto fail;
+   }
+
+   omap_dmm->base = ioremap(mem->start, SZ_2K);
 
if (!omap_dmm->base) {
-   dev_err(dev->dev, "failed to get dmm base address\n");
+   dev_err(&dev->dev, "failed to get dmm base address\n");
goto fail;
}
 
+   omap_dmm->irq = platform_get_irq(dev, 0);
+   if (omap_dmm->irq < 0) {
+   dev_err(&dev->dev, "failed to get IRQ resource\n");
+   goto fail;
+   }
+
+   omap_dmm->dev = &dev->dev;
+
hwinfo = readl(omap_dmm->base + DMM_PAT_HWINFO);
omap_dmm->num_engines = (hwinfo >> 24) & 0x1F;
omap_dmm->num_lut = (hwinfo >> 16) & 0x1F;
@@ -556,7 +572,7 @@ int omap_dmm_init(struct drm_device *dev)
"omap_dmm_irq_handler", omap_dmm);
 
if (ret) {
-   dev_err(dev->dev, "couldn't register IRQ %d, error %d\n",
+   dev_err(&dev->dev, "couldn't register IRQ %d, error %d\n",
omap_dmm->irq, ret);
omap_dmm->irq = -1;
goto fail;
@@ -575,25 +591,30 @@ int omap_dmm_init(struct drm_device *dev)
 
omap_dmm->lut = vmalloc(lut_table_size * sizeof(*omap_dmm->lut));
if (!omap_dmm->lut) {
-   dev_err(dev->dev, "could not allocate lut table\n");
+   dev_err(&dev->dev, "could not allocate lut table\n");
ret = -ENOMEM;
goto fail;
}
 
omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if (!omap_dmm->dummy_page) {
-   dev_err(dev->dev, "could not allocate dummy page\n");
+   dev_err(&dev->dev, "could not allocate dummy page\n");
ret = -ENOMEM;
goto fail;
}
+
+   /* set dma mask for device */
+   /* NOTE: this is a workaround for t

[PATCH 10/10] staging: drm/omap: mmap of tiled buffers with stride >4kb

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Deal with the case of buffers with virtual stride larger than one
page in fault_2d().

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |   86 ---
 1 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index 5abd294..921f058 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -153,10 +153,23 @@ static void evict_entry(struct drm_gem_object *obj,
enum tiler_fmt fmt, struct usergart_entry *entry)
 {
if (obj->dev->dev_mapping) {
-   size_t size = PAGE_SIZE * usergart[fmt].height;
+   struct omap_gem_object *omap_obj = to_omap_bo(obj);
+   int n = usergart[fmt].height;
+   size_t size = PAGE_SIZE * n;
loff_t off = mmap_offset(obj) +
(entry->obj_pgoff << PAGE_SHIFT);
-   unmap_mapping_range(obj->dev->dev_mapping, off, size, 1);
+   const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
+   if (m > 1) {
+   int i;
+   /* if stride > than PAGE_SIZE then sparse mapping: */
+   for (i = n; i > 0; i--) {
+   unmap_mapping_range(obj->dev->dev_mapping,
+   off, PAGE_SIZE, 1);
+   off += PAGE_SIZE * m;
+   }
+   } else {
+   unmap_mapping_range(obj->dev->dev_mapping, off, size, 
1);
+   }
}
 
entry->obj = NULL;
@@ -342,26 +355,39 @@ static int fault_2d(struct drm_gem_object *obj,
void __user *vaddr;
int i, ret, slots;
 
-   if (!usergart)
-   return -EFAULT;
-
-   /* TODO: this fxn might need a bit tweaking to deal w/ tiled buffers
-* that are wider than 4kb
+   /*
+* Note the height of the slot is also equal to the number of pages
+* that need to be mapped in to fill 4kb wide CPU page.  If the slot
+* height is 64, then 64 pages fill a 4kb wide by 64 row region.
+*/
+   const int n = usergart[fmt].height;
+   const int n_shift = usergart[fmt].height_shift;
+
+   /*
+* If buffer width in bytes > PAGE_SIZE then the virtual stride is
+* rounded up to next multiple of PAGE_SIZE.. this need to be taken
+* into account in some of the math, so figure out virtual stride
+* in pages
 */
+   const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
 
/* We don't use vmf->pgoff since that has the fake offset: */
pgoff = ((unsigned long)vmf->virtual_address -
vma->vm_start) >> PAGE_SHIFT;
 
-   /* actual address we start mapping at is rounded down to previous slot
+   /*
+* Actual address we start mapping at is rounded down to previous slot
 * boundary in the y direction:
 */
-   base_pgoff = round_down(pgoff, usergart[fmt].height);
-   vaddr = vmf->virtual_address - ((pgoff - base_pgoff) << PAGE_SHIFT);
-   entry = &usergart[fmt].entry[usergart[fmt].last];
+   base_pgoff = round_down(pgoff, m << n_shift);
 
+   /* figure out buffer width in slots */
slots = omap_obj->width >> usergart[fmt].slot_shift;
 
+   vaddr = vmf->virtual_address - ((pgoff - base_pgoff) << PAGE_SHIFT);
+
+   entry = &usergart[fmt].entry[usergart[fmt].last];
+
/* evict previous buffer using this usergart entry, if any: */
if (entry->obj)
evict_entry(entry->obj, fmt, entry);
@@ -369,23 +395,30 @@ static int fault_2d(struct drm_gem_object *obj,
entry->obj = obj;
entry->obj_pgoff = base_pgoff;
 
-   /* now convert base_pgoff to phys offset from virt offset:
-*/
-   base_pgoff = (base_pgoff >> usergart[fmt].height_shift) * slots;
-
-   /* map in pages.  Note the height of the slot is also equal to the
-* number of pages that need to be mapped in to fill 4kb wide CPU page.
-* If the height is 64, then 64 pages fill a 4kb wide by 64 row region.
-* Beyond the valid pixel part of the buffer, we set pages[i] to NULL to
-* get a dummy page mapped in.. if someone reads/writes it they will get
-* random/undefined content, but at least it won't be corrupting
-* whatever other random page used to be mapped in, or other undefined
-* behavior.
+   /* now convert base_pgoff to phys offset from virt offset: */
+   base_pgoff = (base_pgoff >> n_shift) * slots;
+
+   /* for wider-than 4k.. figure out which part of the slot-row we want: */
+   if (m > 1) {
+   int off = pgoff % m;
+   entry->obj_pgoff += off;
+   base_pgoff /= m;
+   slots = min(slots - (off << n_shift), n);

Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox  wrote:
> From: Alan Cox 
>
> [Resending with correct address for Linus]

Should I take this directly, or is there a pending DRM pull that will
contain this?

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] omap2+: add drm device

2012-03-05 Thread Rob Clark 
From: Andy Gross 

Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.  DMM is split into a
separate device using hwmod.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 arch/arm/plat-omap/Makefile   |2 +-
 arch/arm/plat-omap/common.c   |3 +-
 arch/arm/plat-omap/drm.c  |   83 +
 arch/arm/plat-omap/include/plat/drm.h |   64 +
 4 files changed, 150 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-omap/drm.c
 create mode 100644 arch/arm/plat-omap/include/plat/drm.h

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o counter_32k.o drm.o
 obj-m :=
 obj-n :=
 obj-  :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-
 #define NO_LENGTH_CHECK 0x
 
 struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
 
 void __init omap_reserve(void)
 {
+   omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..28279df
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_CMA
+#  include 
+#endif
+
+#include 
+#include 
+
+#include 
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = &omapdrm_platdata,
+   },
+   .name = "omapdrm",
+   .id = 0,
+};
+
+static int __init omap_init_gpu(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_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+   /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+   dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+#  warning "CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier"
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h 
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..df9bc41
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h
@@ -0,0 +1,64 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * 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 receiv

[Bug 27922] setting graphics mode for text console with video= instead of vga= does not work

2012-03-05 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=27922


Jérôme Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gli...@freedesktop.org
 Resolution||INVALID




--- Comment #3 from Jérôme Glisse   2012-03-05 16:56:01 
---
This is not a bug, video= command line is only interpreted with kernel
modesetting enabled. We don't support anymore non kernel modesetting case for
radeon.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread David Airlie 



- Original Message -
> From: "Linus Torvalds" 
> To: "Alan Cox" 
> Cc: dri-devel@lists.freedesktop.org
> Sent: Monday, 5 March, 2012 4:50:14 PM
> Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
> 
> On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox 
> wrote:
> > From: Alan Cox 
> >
> > [Resending with correct address for Linus]
> 
> Should I take this directly, or is there a pending DRM pull that will
> contain this?

I've just queued it up in drm-fixes, will send it out now since nothing else
came in today.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm gma500 fix

2012-03-05 Thread Dave Airlie 

Hi,

Just a single gma500 fix from Alan.

Dave.

The following changes since commit a5939eefdcacd3ece57d56167a43bcc0d93733bf:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 (2012-03-04 
17:10:06 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alan Cox (1):
  drm/gma500: Fix Cedarview boot failures in 3.3-rc

 drivers/gpu/drm/gma500/cdv_device.c  |2 ++
 drivers/gpu/drm/gma500/framebuffer.c |1 -
 drivers/gpu/drm/gma500/gtt.c |9 -
 3 files changed, 6 insertions(+), 6 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] dma-buf: add support for kernel cpu access

2012-03-05 Thread Daniel Vetter 
On Fri, Mar 2, 2012 at 23:24, Rob Clark  wrote:
> Perhaps we should check somewhere for required dmabuf ops fxns (like
> kmap_atomic here), rather than just calling unconditionally what might
> be a null ptr.  At least put it in the WARN_ON(), but it might be
> nicer to catch a missing required fxns at export time, rather than
> waiting for an importer to try and call it.  Less likely that way, for
> newly added required functions go unnoticed.
>
> (same comment applies below for the non-atomic variant.. and possibly
> some other existing dmabuf ops)

Agreed, I'll rework the patch to do that when rebasing onto Sumit's latest tree.
-Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH 3/3] dma_buf: Add documentation for the new cpu access support

2012-03-05 Thread Clark, Rob 
On Fri, Mar 2, 2012 at 6:23 PM, Sakari Ailus  wrote:
> Hi Daniel,
>
> Thanks for the patch.
>
> On Thu, Mar 01, 2012 at 04:36:01PM +0100, Daniel Vetter wrote:
>> Signed-off-by: Daniel Vetter 
>> ---
>>  Documentation/dma-buf-sharing.txt |  102 
>> +++-
>>  1 files changed, 99 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/dma-buf-sharing.txt 
>> b/Documentation/dma-buf-sharing.txt
>> index 225f96d..f12542b 100644
>> --- a/Documentation/dma-buf-sharing.txt
>> +++ b/Documentation/dma-buf-sharing.txt
>> @@ -32,8 +32,12 @@ The buffer-user
>>  *IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
>>  For this first version, A buffer shared using the dma_buf sharing API:
>>  - *may* be exported to user space using "mmap" *ONLY* by exporter, outside 
>> of
>> -   this framework.
>> -- may be used *ONLY* by importers that do not need CPU access to the buffer.
>> +  this framework.
>> +- with this new iteration of the dma-buf api cpu access from the kernel has 
>> been
>> +  enable, see below for the details.
>> +
>> +dma-buf operations for device dma only
>> +--
>>
>>  The dma_buf buffer sharing API usage contains the following steps:
>>
>> @@ -219,7 +223,99 @@ NOTES:
>>     If the exporter chooses not to allow an attach() operation once a
>>     map_dma_buf() API has been called, it simply returns an error.
>>
>> -Miscellaneous notes:
>> +Kernel cpu access to a dma-buf buffer object
>> +
>> +
>> +The motivation to allow cpu access from the kernel to a dma-buf object from 
>> the
>> +importers side are:
>> +- fallback operations, e.g. if the devices is connected to a usb bus and the
>> +  kernel needs to shuffle the data around first before sending it away.
>> +- full transperancy for existing users on the importer side, i.e. userspace
>> +  should not notice the difference between a normal object from that 
>> subsystem
>> +  and an imported one backed by a dma-buf. This is really important for drm
>> +  opengl drivers that expect to still use all the existing upload/download
>> +  paths.
>> +
>> +Access to a dma_buf from the kernel context involves three steps:
>> +
>> +1. Prepare access, which invalidate any necessary caches and make the object
>> +   available for cpu access.
>> +2. Access the object page-by-page with the dma_buf map apis
>> +3. Finish access, which will flush any necessary cpu caches and free 
>> reserved
>> +   resources.
>
> Where it should be decided which operations are being done to the buffer
> when it is passed to user space and back to kernel space?
>
> How about spliting these operations to those done on the first time the
> buffer is passed to the user space (mapping to kernel address space, for
> example) and those required every time buffer is passed from kernel to user
> and back (cache flusing)?
>
> I'm asking since any unnecessary time-consuming operations, especially as
> heavy as mapping the buffer, should be avoidable in subsystems dealing
> with streaming video, cameras etc., i.e. non-GPU users.


Well, this is really something for the buffer exporter to deal with..
since there is no way for an importer to create a userspace mmap'ing
of the buffer.  A lot of these expensive operations go away if you
don't even create a userspace virtual mapping in the first place ;-)

BR,
-R

>
>> +1. Prepare acces
>> +
>> +   Before an importer can acces a dma_buf object with the cpu from the 
>> kernel
>> +   context, it needs to notice the exporter of the access that is about to
>> +   happen.
>> +
>> +   Interface:
>> +      int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> +                                size_t start, size_t len,
>> +                                enum dma_data_direction direction)
>> +
>> +   This allows the exporter to ensure that the memory is actually available 
>> for
>> +   cpu access - the exporter might need to allocate or swap-in and pin the
>> +   backing storage. The exporter also needs to ensure that cpu access is
>> +   coherent for the given range and access direction. The range and access
>> +   direction can be used by the exporter to optimize the cache flushing, 
>> i.e.
>> +   access outside of the range or with a different direction (read instead 
>> of
>> +   write) might return stale or even bogus data (e.g. when the exporter 
>> needs to
>> +   copy the data to temporaray storage).
>> +
>> +   This step might fail, e.g. in oom conditions.
>> +
>> +2. Accessing the buffer
>> +
>> +   To support dma_buf objects residing in highmem cpu access is page-based 
>> using
>> +   an api similar to kmap. Accessing a dma_buf is done in aligned chunks of
>> +   PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which 
>> returns
>> +   a pointer in kernel virtual address space. Afterwards the chunk needs to 
>> be
>> +   unmapped again. There is no limit on how often a given chunk can be 
>> map

Re: [Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access

2012-03-05 Thread Daniel Vetter 
On Fri, Mar 2, 2012 at 23:53, Rob Clark  wrote:
> nitially the expectation was that userspace would not pass a buffer
> to multiple subsystems for writing (or that if it did, it would get
> the undefined results that one could expect)..  so dealing w/
> synchronization was punted.

Imo synchronization should not be part of the dma_buf core, i.e.
userspace needs to ensure that access is synchronized.
begin/end_cpu_access are the coherency brackets (like map/unmap for
device dma). And if userspace asks for a gun and some bullets, the
kernel should just deliver. Even in drm/i915 gem land we don't (and
simply can't) make any promises about concurrent reads/writes/ioctls.

> I expect, though, that one of the next steps is some sort of
> sync-object mechanism to supplement dmabuf

Imo the only reason to add sync objects as explicit things is to make
device-to-device sync more efficient by using hw semaphores and
signalling lines. Or maybe a quick irq handler in the kernel that
kicks of the next device. I don't think we should design these to make
userspace simpler.

Cheers, Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] dma_buf: Add documentation for the new cpu access support

2012-03-05 Thread Daniel Vetter 
On Sat, Mar 3, 2012 at 01:23, Sakari Ailus  wrote:
> Where it should be decided which operations are being done to the buffer
> when it is passed to user space and back to kernel space?
>
> How about spliting these operations to those done on the first time the
> buffer is passed to the user space (mapping to kernel address space, for
> example) and those required every time buffer is passed from kernel to user
> and back (cache flusing)?
>
> I'm asking since any unnecessary time-consuming operations, especially as
> heavy as mapping the buffer, should be avoidable in subsystems dealing
> with streaming video, cameras etc., i.e. non-GPU users.

I'm a bit confused about your comments because this interface
extension doesn't support userspace mmap. So userspace isn't even part
of the picture. Adding mmap support is something entirely different
imo, and I have no idea yet how we should handle cache coherency for
that.

Yours, Daniel
-- 
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm gma500 fix

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie  wrote:
>
>  git://people.freedesktop.org/~airlied/linux drm-fixes

Hmm. Is freedesktop.org having trouble?

I got

  fatal: unable to connect to people.freedesktop.org:
  people.freedesktop.org[0: 131.252.210.176]: errno=Connection refused

and an the third try (I started stracing it to see what was up with
that "0:" part) it just hung at the connect. And a couple of times it
connected but then got reset.. So I perversely started trying to see
if it's coming alive.

And then it finally started working - but now I'm getting "Already up-to-date."

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm gma500 fix

2012-03-05 Thread Keith Packard 
<#part sign=pgpmime>
On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds 
 wrote:
> On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie  wrote:
> >
> >  git://people.freedesktop.org/~airlied/linux drm-fixes
> 
> Hmm. Is freedesktop.org having trouble?

ECC memory errors -- we're moving this stuff to a new machine as quickly
as rsync can run...

-- 
keith.pack...@intel.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm gma500 fix

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard  wrote:
> <#part sign=pgpmime>
> On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds 
>  wrote:
>> Hmm. Is freedesktop.org having trouble?
>
> ECC memory errors -- we're moving this stuff to a new machine as quickly
> as rsync can run...

Ok. I'll just take Alan's patch directly as a patch.

No worries.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

2012-03-05 Thread Rob Clark 
On Mon, Mar 5, 2012 at 6:10 PM, Tony Lindgren  wrote:
> * Rob Clark  [120305 08:24]:
>> From: Andy Gross 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation.  DMM is split into a
>> separate device using hwmod.
>> --- a/arch/arm/plat-omap/common.c
>> +++ b/arch/arm/plat-omap/common.c
>> @@ -21,10 +21,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>
>> -
>>  #define NO_LENGTH_CHECK 0x
>>
>>  struct omap_board_config_kernel *omap_board_config __initdata;
>> @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t 
>> *len)
>>
>>  void __init omap_reserve(void)
>>  {
>> +     omapdrm_reserve_vram();
>>       omapfb_reserve_sdram_memblock();
>>       omap_vram_reserve_sdram_memblock();
>>       omap_dsp_reserve_sdram_memblock();
>
> Tomi needs to look at the vram changes here.

it is just setting up a CMA region (if CMA is enabled.. basically for
once CMA is merged)

after CMA is merged, other drivers should be migrated to use CMA, and
omap_vram removed.. but that is a topic for another patch

>> --- /dev/null
>> +++ b/arch/arm/plat-omap/drm.c
>
> This file would be better in mach-omap2/drm.c. I doubt that this will
> ever be usable for omap1. But other than that, up to Tomi.

I was attempting to copy what omapfb was doing (plat-omap/fb.c)
because I wasn't really sure about plat-omap vs mach-omap2, although
on closer inspection I think the file I was looking at is actually for
the legacy omapdss1..  So I'll move this stuff under mach-omap2 and
resubmit this patch.

BR,
-R

> Tony
> --
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

2012-03-05 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #38 from Alexandre Demers  2012-03-05 
20:40:48 UTC ---
Some news: today, I updated xserver and it seems I'm now able to boot under
Gnome-Shell correctly.

However, launching RenderFeatTest.bin64 still hangs exactly where it has been
hanging for some time now and freeze my window manager. At least, it seems one
of the problem was related to xserver.

I'll hope I'll be able to find something new in the logs.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

2012-03-05 Thread Tony Lindgren 
* Rob Clark  [120305 08:24]:
> From: Andy Gross 
> 
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.  DMM is split into a
> separate device using hwmod.
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -21,10 +21,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> -
>  #define NO_LENGTH_CHECK 0x
>  
>  struct omap_board_config_kernel *omap_board_config __initdata;
> @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
>  
>  void __init omap_reserve(void)
>  {
> + omapdrm_reserve_vram();
>   omapfb_reserve_sdram_memblock();
>   omap_vram_reserve_sdram_memblock();
>   omap_dsp_reserve_sdram_memblock();

Tomi needs to look at the vram changes here.

> --- /dev/null
> +++ b/arch/arm/plat-omap/drm.c

This file would be better in mach-omap2/drm.c. I doubt that this will
ever be usable for omap1. But other than that, up to Tomi.

Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [korg]help: How to submit a kernel driver on kernel.org.

2012-03-05 Thread Aaron . Chen 陈俊杰 
Hi Paul&Jerome,

Thank you very much for your guide. It's a great help for me.

But I still have a little problem with the patch thing. I'm not familiar with 
the git.
1.Shall I need to do the clone and get the source location and target directory 
first? 
2.Where is the source location and target directory?
3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
So what shall I do to submit a driver cover all these kernel version.
4.or just email you the source code and tell you the changes?

I'm looking forward your re-guide. Thank you so much.

Regards
Aaron


-邮件原件-
发件人: Paul Menzel [mailto:paulepan...@users.sourceforge.net] 
发送时间: 2012年3月2日 5:50
收件人: Jerome Glisse
抄送: Aaron.Chen 陈俊杰; dri-devel@lists.freedesktop.org
主题: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


thank you for contacting the list. We are looking forward to your patches.

Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
> On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen 陈俊杰 wrote:

> > I’m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
> > Office. We have developed a kernel driver for all our graphics chips. We 
> > really want to know the way to submit a kernel driver to kernel.org. I have 
> > received a document file which is on 
> > http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
> > find out a place to where our drivers should be uploaded. The document say 
> > “please submit it to the maintainer listed in MAINTAINERS in the kernel 
> > file.”So where can I find the maintainer and what to do next. Would you 
> > please help me. Thank you so much.

> All you need to do is send the kernel patch to 
> dri-devel@lists.freedesktop.org
> 
> So they can get reviewed. Once they are reviewed, and if they comply 
> with the requirement, the DRM maintainer (aka Dave) will integrate 
> your patch in his tree and at some point ask Linus to pull them.
> 
> There is no ftp, or http web submission, everything is done through 
> public mailing list.

if you are familiar with Git you should send a patch formatted using `git 
format-patch -15`. Replace the 15 by the number of commits you need patches for.

You can take a look in the archive. drm/exynos and drm/omap are good examples – 
I think – on how to get new drivers submitted.


Thanks,

Paul


PS: Please also try to follow the netiquette when posting to lists [1].
Especially just send plain text messages (no HTML).


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [korg]help: How to submit a kernel driver on kernel.org.

2012-03-05 Thread Aaron . Chen 陈俊杰 
Hi Paul&Jerome,

Our driver is a frambuffer driver and there's no DRM functions.

Regards
Aaron

-邮件原件-
发件人: Aaron.Chen 陈俊杰 
发送时间: 2012年3月6日 12:14
收件人: 'Paul Menzel'; Jerome Glisse
抄送: dri-devel@lists.freedesktop.org; caesar.qiu 裘赛海
主题: Re: [korg]help: How to submit a kernel driver on kernel.org.

Hi Paul&Jerome,

Thank you very much for your guide. It's a great help for me.

But I still have a little problem with the patch thing. I'm not familiar with 
the git.
1.Shall I need to do the clone and get the source location and target directory 
first? 
2.Where is the source location and target directory?
3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
So what shall I do to submit a driver cover all these kernel version.
4.or just email you the source code and tell you the changes?

I'm looking forward your re-guide. Thank you so much.

Regards
Aaron


-邮件原件-
发件人: Paul Menzel [mailto:paulepan...@users.sourceforge.net] 
发送时间: 2012年3月2日 5:50
收件人: Jerome Glisse
抄送: Aaron.Chen 陈俊杰; dri-devel@lists.freedesktop.org
主题: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


thank you for contacting the list. We are looking forward to your patches.

Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
> On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen 陈俊杰 wrote:

> > I’m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
> > Office. We have developed a kernel driver for all our graphics chips. We 
> > really want to know the way to submit a kernel driver to kernel.org. I have 
> > received a document file which is on 
> > http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
> > find out a place to where our drivers should be uploaded. The document say 
> > “please submit it to the maintainer listed in MAINTAINERS in the kernel 
> > file.”So where can I find the maintainer and what to do next. Would you 
> > please help me. Thank you so much.

> All you need to do is send the kernel patch to 
> dri-devel@lists.freedesktop.org
> 
> So they can get reviewed. Once they are reviewed, and if they comply 
> with the requirement, the DRM maintainer (aka Dave) will integrate 
> your patch in his tree and at some point ask Linus to pull them.
> 
> There is no ftp, or http web submission, everything is done through 
> public mailing list.

if you are familiar with Git you should send a patch formatted using `git 
format-patch -15`. Replace the 15 by the number of commits you need patches for.

You can take a look in the archive. drm/exynos and drm/omap are good examples – 
I think – on how to get new drivers submitted.


Thanks,

Paul


PS: Please also try to follow the netiquette when posting to lists [1].
Especially just send plain text messages (no HTML).


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

2012-03-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #37 from Alex Deucher  2012-03-04 16:24:02 PST 
---
(In reply to comment #36)
> I know I can run a 3.2 kernel, I know I can compile a different version or
> bisect or submit patches, I know I can switch from Gnome Shell to another
> window manager without fancy effects or that I can disable options if I follow
> your advise. But this is not accessible to the average user.

You can run an older mesa release as well.  It's probably a better as a mesa
knob than a kernel knob.

> 
> Please, consider another option for the average users that will use compiled
> code available soon.

We can add a mesa option if we aren't able to get this fixed in time for the
next mesa release, but for now I'd prefer to leave it enabled otherwise most
users will just disable it and not test the current code which won't help in
getting it fixed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 13170] Macbook 5,2 only boots with acpi=off, or nosmp, or maxcpus=1

2012-03-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=13170





--- Comment #68 from Mikel Pr   2012-03-05 06:07:53 ---
MY apologies. While it does boot now without acpi=off or nosmp/maxcpus=1, only
one core is reported in /proc/cpuinfo and in Ubuntu's system-report option in
12.04.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

radeon.pcie_gen2=1 unusable with AMD 990X chipset

2012-03-05 Thread Boszormenyi Zoltan 
Hi,

last week I bought a new ASUS M5A99X EVO AM3+ mainboard.
It supports PCIe 2.0. I also have a Radeon 6570 videocard (PCIe 2.0)
and a 3ware 9650SE 8LPML RAID card (PCIe 1.0).

There are 3 PCIe x16 slots on the mainboard, two of them share x16
wiring so single card x16 or dual card x8/x8 is possible. The 3rd slot
is PCIe x16 slot with dedicated x4 wiring, no sharing with the first 2 slots.
The RAID card is sitting in the 3rd slot.

I am running Fedora 16 with the latest 3.2.7-1.fc16.x86_64 kernel.

I have set radeon.pcie_gen2=1 in grub2 config to test PCIe 2.0 speed with
the videocard. It reliably locks up on boot. As a result, the mainboard
gets confused so much that it needs CMOS clear, otherwise even after
hard reset it cannot boot up successfully. I tried it a couple of times,
the symptoms (without CMOS clear) are mysteriously different. From the
few attempts, I experienced these:

- the mainboard reports faulty videocard, no image on display
- the mainboard passes the videocard test but reports faulty boot drive
  (I guess it cannot initialize the RAID card as it's the primary boot drive)
  and still no image on display
- the first few screens appear on the display but e.g. the onboard SATA
  controller cannot find the DVD drive and the BIOS initialization sequence
  stops somewhere, it doesn't reach the GRUB menu

The motherboard has an AMD 990X chipset.

Without radeon.pcie_gen2=1, the system works and is stable.

I don't know what to blame. The chipset, BIOS bugs, or the mix of
PCIe 1.0 and 2.0 devices. Anyway, I thought it would be an interesting
detail for Radeon developers.

Best regards,
Zolt?n B?sz?rm?nyi

[PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread Alan Cox 
From: Alan Cox 

[Resending with correct address for Linus]

Production GMA3600/3650 hardware turns out to be subtly different to the
development platforms. This combined with a minor driver bug is causing
the kernel to hang on these platforms.

This patch does the following

- turn down a couple of messages that were meant to be debug and are
  causing much confusion

- ensure the hotplug interrupt is disabled on Cedartrail systems.

- fix a bug where gtt roll mode called psbfb_sync, which tries to sync
  the 2D engine. On other devices it is harmless as the 2D engine is
  present but not in use when in gtt roll mode, on Cedartrail it causes
  a hang

Without these changes 3.3-rc hangs on boot on Cedartrail based systems.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/cdv_device.c  |2 ++
 drivers/gpu/drm/gma500/framebuffer.c |1 -
 drivers/gpu/drm/gma500/gtt.c |9 -
 3 files changed, 6 insertions(+), 6 deletions(-)


diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index 4a5b099..53404af 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -321,6 +321,8 @@ static int cdv_chip_setup(struct drm_device *dev)
cdv_get_core_freq(dev);
gma_intel_opregion_init(dev);
psb_intel_init_bios(dev);
+   REG_WRITE(PORT_HOTPLUG_EN, 0);
+   REG_WRITE(PORT_HOTPLUG_STAT, REG_READ(PORT_HOTPLUG_STAT));
return 0;
 }

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 830dfdd6b..be61673 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -247,7 +247,6 @@ static struct fb_ops psbfb_roll_ops = {
.fb_imageblit = cfb_imageblit,
.fb_pan_display = psbfb_pan,
.fb_mmap = psbfb_mmap,
-   .fb_sync = psbfb_sync,
.fb_ioctl = psbfb_ioctl,
 };

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 5d5330f..aff194f 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -446,10 +446,9 @@ int psb_gtt_init(struct drm_device *dev, int resume)
pg->gtt_start = pci_resource_start(dev->pdev, PSB_GTT_RESOURCE);
gtt_pages = pci_resource_len(dev->pdev, PSB_GTT_RESOURCE)
>> PAGE_SHIFT;
-   /* Some CDV firmware doesn't report this currently. In which case the
-  system has 64 gtt pages */
+   /* CDV doesn't report this. In which case the system has 64 gtt pages */
if (pg->gtt_start == 0 || gtt_pages == 0) {
-   dev_err(dev->dev, "GTT PCI BAR not initialized.\n");
+   dev_dbg(dev->dev, "GTT PCI BAR not initialized.\n");
gtt_pages = 64;
pg->gtt_start = dev_priv->pge_ctl;
}
@@ -461,10 +460,10 @@ int psb_gtt_init(struct drm_device *dev, int resume)

if (pg->gatt_pages == 0 || pg->gatt_start == 0) {
static struct resource fudge;   /* Preferably peppermint */
-   /* This can occur on CDV SDV systems. Fudge it in this case.
+   /* This can occur on CDV systems. Fudge it in this case.
   We really don't care what imaginary space is being allocated
   at this point */
-   dev_err(dev->dev, "GATT PCI BAR not initialized.\n");
+   dev_dbg(dev->dev, "GATT PCI BAR not initialized.\n");
pg->gatt_start = 0x4000;
pg->gatt_pages = (128 * 1024 * 1024) >> PAGE_SHIFT;
/* This is a little confusing but in fact the GTT is providing

[Bug 42869] New: [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=42869

   Summary: [3.3-rc1 regression] [nouveau] Spurious TV-out
detected
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3-rc5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: schwab at linux-m68k.org
Regression: Yes


Created an attachment (id=72540)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72540)
drm messages from 3.2.1

:f0:10.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX
5200 Ultra] (rev a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Device 0010
Flags: bus master, 66MHz, medium devsel, latency 16, IRQ 48
Memory at 9100 (32-bit, non-prefetchable) [size=16M]
Memory at 9800 (32-bit, prefetchable) [size=128M]
Expansion ROM at 9000 [disabled] [size=128K]

The monitor is connected to DVI-I-2, but the driver claims output is on
TV-1.

Here's the difference of the kernel output between 3.2.1 and 3.3-rc5:

< [drm] nouveau :f0:10.0: Found Display Configuration Block version 2.2
< [drm] nouveau :f0:10.0: Raw DCB entry 0: 01100102 
< [drm] nouveau :f0:10.0: Raw DCB entry 1: 01000100 88b8
< [drm] nouveau :f0:10.0: Raw DCB entry 2: 02110212 11b0
< [drm] nouveau :f0:10.0: Raw DCB entry 3: 02010210 11b088b8
< [drm] nouveau :f0:10.0: Raw DCB entry 4: 02010211 11b3
> [drm] nouveau :f0:10.0: I2C4: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C7: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C8: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C9: type 2 index 0/0 unknown
> [drm] nouveau :f0:10.0: I2C15: type 3 index 0/0 unknown
> [drm] nouveau :f0:10.0: MXM: no VBIOS data, nothing to do
> [drm] nouveau :f0:10.0: DCB version 2.2
> [drm] nouveau :f0:10.0: DCB outp 00: 01100102 
> [drm] nouveau :f0:10.0: DCB outp 01: 01000100 88b8
> [drm] nouveau :f0:10.0: DCB outp 02: 02110212 11b0
> [drm] nouveau :f0:10.0: DCB outp 03: 02010210 11b088b8
> [drm] nouveau :f0:10.0: DCB outp 04: 02010211 11b3
---
< [drm] nouveau :f0:10.0: allocated 1280x1024 fb: 0x49000, bo
c00177cd8000
< [drm] nouveau :f0:10.0: Setting dpms mode 0 on tmds encoder (output 2)
< [drm] nouveau :f0:10.0: Output DVI-I-2 is running on CRTC 1 using output
B
> [drm] nouveau :f0:10.0: Load detected on output B
> [drm] nouveau :f0:10.0: allocated 720x576 fb: 0x49000, bo c00177c00400
> [drm] nouveau :f0:10.0: Setting dpms mode 0 on TV encoder (output 4)
> [drm] nouveau :f0:10.0: Output TV-1 is running on CRTC 1 using output B

Reverting commit a0b25635515ef5049f93b032a1e37f18b16e0f6f ("drm/nouveau/gpio:
reimplement as nouveau_gpio.c, fixing a number of issues") (together with
47e5d5cb83d4b41168f4afa1ca32843d4a126cc8,
52c4d767437b40b0cbc02d6a4480abb45ace64bb and
7df898b1a70b13c3a8892625f4ead929d9554293 which depend on it) fixes the issue,
and nouveau.tv_disable=1 is also a workaround.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 42869] [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=42869





--- Comment #1 from Andreas Schwab   2012-03-05 
14:22:09 ---
Created an attachment (id=72541)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72541)
drm messages from 3.3-rc5

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 42869] [3.3-rc1 regression] [nouveau] Spurious TV-out detected

2012-03-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=42869


Andreas Schwab  changed:

   What|Removed |Added

 Blocks||42644




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 00/10] omapdrm patches for 3.4

2012-03-05 Thread Rob Clark 
From: Rob Clark 

This is the (potentially first) batch of patches for omapdrm for 3.4.
It includes some fixes for OMAP3 (without DMM), and change in how
the DMM code gets it's platform data based on review comments from
the first version of the patch which added the omapdrm platform dev.

Also, a few cleanups, a better solution for handling fbdev calls from
atomix context, deferred unpin until scanout completes, mmap of tiled
buffers w/ stride larger than PAGE_SIZE.

There is one additional patch to come after the platform device patch
is merged (in arch/arm/plat-omap) to remove some duplicated structs.
And I am still working on support for scanout and rotated scanout of
tiled buffers, which may or may not be ready in time for 3.4 merge
window.

Andy Gross (3):
  staging: drm/omap: Disable DMM debugfs for OMAP3
  staging: drm/omap: Validate debugfs device
  staging: drm/omap: Get DMM resources from hwmod

Rob Clark (7):
  staging: drm/omap: get supported color formats from ovl
  staging: drm/omap: add a workqueue
  staging: drm/omap: call omap_gem_roll() in non-atomic ctx
  staging: drm/omap: some minor fb cleanups
  staging: drm/omap: defer unpin until scanout completes
  staging: drm/omap: debugfs for object and fb tracking
  staging: drm/omap: mmap of tiled buffers with stride >4kb

 drivers/staging/omapdrm/omap_debugfs.c   |   97 +-
 drivers/staging/omapdrm/omap_dmm_tiler.c |   91 
 drivers/staging/omapdrm/omap_dmm_tiler.h |   15 ++--
 drivers/staging/omapdrm/omap_drv.c   |   16 +++
 drivers/staging/omapdrm/omap_drv.h   |   17 +++-
 drivers/staging/omapdrm/omap_fb.c|  124 +++---
 drivers/staging/omapdrm/omap_fbdev.c |   26 -
 drivers/staging/omapdrm/omap_gem.c   |  172 ++
 drivers/staging/omapdrm/omap_plane.c |  161 +++-
 9 files changed, 570 insertions(+), 149 deletions(-)

-- 
1.7.5.4

[PATCH 01/10] staging: drm/omap: get supported color formats from ovl

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Get the supported formats for a plane from ovl's supported_modes
bitmask.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |2 ++
 drivers/staging/omapdrm/omap_fb.c|   14 ++
 drivers/staging/omapdrm/omap_plane.c |   27 +++
 3 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 61fe022..d924c95 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -92,6 +92,8 @@ void omap_connector_mode_set(struct drm_connector *connector,
 void omap_connector_flush(struct drm_connector *connector,
int x, int y, int w, int h);

+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+   uint32_t max_formats, enum omap_color_mode supported_modes);
 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index d021a7e..116a8ff 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,6 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
 };

+/* convert from overlay's pixel formats bitmask to an array of fourcc's */
+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+   uint32_t max_formats, enum omap_color_mode supported_modes)
+{
+   uint32_t nformats = 0;
+   int i = 0;
+
+   for (i = 0; i < ARRAY_SIZE(formats) && nformats < max_formats; i++)
+   if (formats[i].dss_format & supported_modes)
+   pixel_formats[nformats++] = formats[i].pixel_format;
+
+   return nformats;
+}
+
 /* per-plane info for the fb: */
 struct plane {
struct drm_gem_object *bo;
diff --git a/drivers/staging/omapdrm/omap_plane.c 
b/drivers/staging/omapdrm/omap_plane.c
index 9790912..c5625e3 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -43,8 +43,10 @@ struct omap_plane {

/* last fb that we pinned: */
struct drm_framebuffer *pinned_fb;
-};

+   uint32_t nformats;
+   uint32_t formats[32];
+};

 /* push changes down to dss2 */
 static int commit(struct drm_plane *plane)
@@ -271,24 +273,6 @@ static const struct drm_plane_funcs omap_plane_funcs = {
.destroy = omap_plane_destroy,
 };

-static const uint32_t formats[] = {
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_RGBX,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_RGBA,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_ARGB1555,
-   DRM_FORMAT_RGB888,
-   DRM_FORMAT_RGBX,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_RGBA,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_NV12,
-   DRM_FORMAT_YUYV,
-   DRM_FORMAT_UYVY,
-};
-
 /* initialize plane */
 struct drm_plane *omap_plane_init(struct drm_device *dev,
struct omap_overlay *ovl, unsigned int possible_crtcs,
@@ -306,11 +290,14 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
goto fail;
}

+   omap_plane->nformats = omap_framebuffer_get_formats(
+   omap_plane->formats, ARRAY_SIZE(omap_plane->formats),
+   ovl->supported_modes);
omap_plane->ovl = ovl;
plane = &omap_plane->base;

drm_plane_init(dev, plane, possible_crtcs, &omap_plane_funcs,
-   formats, ARRAY_SIZE(formats), priv);
+   omap_plane->formats, omap_plane->nformats, priv);

/* get our starting configuration, set defaults for parameters
 * we don't currently use, etc:
-- 
1.7.5.4

[PATCH 02/10] staging: drm/omap: add a workqueue

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Add a workqueue for omapdrm driver, which is needed for at least a
couple things currently: (1) moving omap_gem_roll() to a non-atomic
context, (2) synchronizing page flips w/ DSS scanout related irq's
(in particular not unmapping previous buffer until DSS finishes
scanout).

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.c |8 
 drivers/staging/omapdrm/omap_drv.h |2 ++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 3bbea9a..7417e1f 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -570,6 +570,9 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)

dev->dev_private = priv;

+   priv->wq = alloc_workqueue("omapdrm",
+   WQ_UNBOUND | WQ_NON_REENTRANT, 1);
+
omap_gem_init(dev);

ret = omap_modeset_init(dev);
@@ -598,6 +601,8 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)

 static int dev_unload(struct drm_device *dev)
 {
+   struct omap_drm_private *priv = dev->dev_private;
+
DBG("unload: dev=%p", dev);

drm_vblank_cleanup(dev);
@@ -607,6 +612,9 @@ static int dev_unload(struct drm_device *dev)
omap_modeset_free(dev);
omap_gem_deinit(dev);

+   flush_workqueue(priv->wq);
+   destroy_workqueue(priv->wq);
+
kfree(dev->dev_private);
dev->dev_private = NULL;

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index d924c95..a84547c 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -51,6 +51,8 @@ struct omap_drm_private {

struct drm_fb_helper *fbdev;

+   struct workqueue_struct *wq;
+
bool has_dmm;
 };

-- 
1.7.5.4

[PATCH 03/10] staging: drm/omap: call omap_gem_roll() in non-atomic ctx

2012-03-05 Thread Rob Clark 
From: Rob Clark 

If fbcon calls us from atomic context, push the work off to the
workqueue to avoid calling into the gem/dmm code in an atomic
context.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fbdev.c |   26 ++
 drivers/staging/omapdrm/omap_gem.c   |   14 ++
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fbdev.c 
b/drivers/staging/omapdrm/omap_fbdev.c
index 96940bb..11acd4c 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -37,6 +37,9 @@ struct omap_fbdev {
struct drm_framebuffer *fb;
struct drm_gem_object *bo;
bool ywrap_enabled;
+
+   /* for deferred dmm roll when getting called in atomic ctx */
+   struct work_struct work;
 };

 static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
@@ -75,12 +78,22 @@ static void omap_fbdev_imageblit(struct fb_info *fbi,
image->width, image->height);
 }

+static void pan_worker(struct work_struct *work)
+{
+   struct omap_fbdev *fbdev = container_of(work, struct omap_fbdev, work);
+   struct fb_info *fbi = fbdev->base.fbdev;
+   int npages;
+
+   /* DMM roll shifts in 4K pages: */
+   npages = fbi->fix.line_length >> PAGE_SHIFT;
+   omap_gem_roll(fbdev->bo, fbi->var.yoffset * npages);
+}
+
 static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
 {
struct drm_fb_helper *helper = get_fb(fbi);
struct omap_fbdev *fbdev = to_omap_fbdev(helper);
-   int npages;

if (!helper)
goto fallback;
@@ -88,9 +101,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo 
*var,
if (!fbdev->ywrap_enabled)
goto fallback;

-   /* DMM roll shifts in 4K pages: */
-   npages = fbi->fix.line_length >> PAGE_SHIFT;
-   omap_gem_roll(fbdev->bo, var->yoffset * npages);
+   if (drm_can_sleep()) {
+   pan_worker(&fbdev->work);
+   } else {
+   struct omap_drm_private *priv = helper->dev->dev_private;
+   queue_work(priv->wq, &fbdev->work);
+   }

return 0;

@@ -336,6 +352,8 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
goto fail;
}

+   INIT_WORK(&fbdev->work, pan_worker);
+
helper = &fbdev->base;

helper->funcs = &omap_fb_helper_funcs;
diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index b7d6f88..bd35520 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -566,6 +566,8 @@ fail:

 /* Set scrolling position.  This allows us to implement fast scrolling
  * for console.
+ *
+ * Call only from non-atomic contexts.
  */
 int omap_gem_roll(struct drm_gem_object *obj, uint32_t roll)
 {
@@ -580,18 +582,6 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t 
roll)

omap_obj->roll = roll;

-   if (in_atomic() || mutex_is_locked(&obj->dev->struct_mutex)) {
-   /* this can get called from fbcon in atomic context.. so
-* just ignore it and wait for next time called from
-* interruptible context to update the PAT.. the result
-* may be that user sees wrap-around instead of scrolling
-* momentarily on the screen.  If we wanted to be fancier
-* we could perhaps schedule some workqueue work at this
-* point.
-*/
-   return 0;
-   }
-
mutex_lock(&obj->dev->struct_mutex);

/* if we aren't mapped yet, we don't need to do anything */
-- 
1.7.5.4

[PATCH 04/10] staging: drm/omap: some minor fb cleanups

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Now that 'struct drm_plane' has a pixel_format field, use that.  And
fix a minor typo.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fb.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 116a8ff..08e2e35 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -101,7 +101,7 @@ static int omap_framebuffer_create_handle(struct 
drm_framebuffer *fb,
 static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int i, n = drm_format_num_planes(omap_fb->format->pixel_format);
+   int i, n = drm_format_num_planes(fb->pixel_format);

DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);

@@ -204,7 +204,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb, int x, int y,
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   if (p >= drm_format_num_planes(omap_fb->format->pixel_format))
+   if (p >= drm_format_num_planes(fb->pixel_format))
return NULL;
return omap_fb->planes[p].bo;
 }
@@ -351,8 +351,8 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,

plane->bo = bos[i];
plane->offset = mode_cmd->offsets[i];
-   plane->pitch  = mode_cmd->pitches[i];
-   plane->paddr  = pitch;
+   plane->pitch  = pitch;
+   plane->paddr  = 0;
}

drm_helper_mode_fill_fb_struct(fb, mode_cmd);
-- 
1.7.5.4

[PATCH 05/10] staging: drm/omap: defer unpin until scanout completes

2012-03-05 Thread Rob Clark 
From: Rob Clark 

When flipping, defer unpinning until scanout completes, as indicated
by the appropriate END_WIN irq.

This also re-organizes things a bit, in replacing omap_fb_{pin,unpin}
with omap_fb_replace(), to make it easier to add support for scanout
synchronized DMM refill mode (flipping by just reprogramming DMM
synchronized with DSS scanout).

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |5 +-
 drivers/staging/omapdrm/omap_fb.c|   84 -
 drivers/staging/omapdrm/omap_plane.c |  136 --
 3 files changed, 181 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index a84547c..fe4766e 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -101,8 +101,9 @@ struct drm_framebuffer *omap_framebuffer_create(struct 
drm_device *dev,
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
-int omap_framebuffer_pin(struct drm_framebuffer *fb);
-void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+   struct drm_framebuffer *b, void *arg,
+   void (*unpin)(void *arg, struct drm_gem_object *bo));
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 08e2e35..fcb248f 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -137,41 +137,6 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
 };

-/* pins buffer in preparation for scanout */
-int omap_framebuffer_pin(struct drm_framebuffer *fb)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int ret, i, n = drm_format_num_planes(omap_fb->format->pixel_format);
-
-   for (i = 0; i < n; i++) {
-   struct plane *plane = &omap_fb->planes[i];
-   ret = omap_gem_get_paddr(plane->bo, &plane->paddr, true);
-   if (ret)
-   goto fail;
-   }
-
-   return 0;
-
-fail:
-   while (--i > 0) {
-   struct plane *plane = &omap_fb->planes[i];
-   omap_gem_put_paddr(plane->bo);
-   }
-   return ret;
-}
-
-/* releases buffer when done with scanout */
-void omap_framebuffer_unpin(struct drm_framebuffer *fb)
-{
-   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   int i, n = drm_format_num_planes(omap_fb->format->pixel_format);
-
-   for (i = 0; i < n; i++) {
-   struct plane *plane = &omap_fb->planes[i];
-   omap_gem_put_paddr(plane->bo);
-   }
-}
-
 /* update ovl info for scanout, handles cases of multi-planar fb's, etc.
  */
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
@@ -201,6 +166,55 @@ void omap_framebuffer_update_scanout(struct 
drm_framebuffer *fb, int x, int y,
}
 }

+/* Call for unpin 'a' (if not NULL), and pin 'b' (if not NULL).  Although
+ * buffers to unpin are just just pushed to the unpin fifo so that the
+ * caller can defer unpin until vblank.
+ *
+ * Note if this fails (ie. something went very wrong!), all buffers are
+ * unpinned, and the caller disables the overlay.  We could have tried
+ * to revert back to the previous set of pinned buffers but if things are
+ * hosed there is no guarantee that would succeed.
+ */
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+   struct drm_framebuffer *b, void *arg,
+   void (*unpin)(void *arg, struct drm_gem_object *bo))
+{
+   int ret = 0, i, na, nb;
+   struct omap_framebuffer *ofba = to_omap_framebuffer(a);
+   struct omap_framebuffer *ofbb = to_omap_framebuffer(b);
+
+   na = a ? drm_format_num_planes(a->pixel_format) : 0;
+   nb = b ? drm_format_num_planes(b->pixel_format) : 0;
+
+   for (i = 0; i < max(na, nb); i++) {
+   struct plane *pa, *pb;
+
+   pa = (i < na) ? &ofba->planes[i] : NULL;
+   pb = (i < nb) ? &ofbb->planes[i] : NULL;
+
+   if (pa) {
+   unpin(arg, pa->bo);
+   pa->paddr = 0;
+   }
+
+   if (pb && !ret)
+   ret = omap_gem_get_paddr(pb->bo, &pb->paddr, true);
+   }
+
+   if (ret) {
+   /* something went wrong.. unpin what has been pinned */
+   for (i = 0; i < nb; i++) {
+   struct plane *pb = &ofba->planes[i];
+   if (pb->paddr) {
+   unpin(ar

[PATCH 06/10] staging: drm/omap: debugfs for object and fb tracking

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Add some additional debugfs file to aid in tracking buffer usage.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_debugfs.c |   98 +++-
 drivers/staging/omapdrm/omap_drv.c |2 +
 drivers/staging/omapdrm/omap_drv.h |8 +++
 drivers/staging/omapdrm/omap_fb.c  |   18 ++
 drivers/staging/omapdrm/omap_gem.c |   64 -
 5 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
index da920df..e23f907 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -20,23 +20,119 @@
 #include "omap_drv.h"
 #include "omap_dmm_tiler.h"

+#include "drm_fb_helper.h"
+
+
 #ifdef CONFIG_DEBUG_FS

+static int gem_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   int ret;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret)
+   return ret;
+
+   seq_printf(m, "All Objects:\n");
+   omap_gem_describe_objects(&priv->obj_list, m);
+
+   mutex_unlock(&dev->struct_mutex);
+
+   return 0;
+}
+
+static int mm_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   return drm_mm_dump_table(m, dev->mm_private);
+}
+
+static int fb_show(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   struct drm_framebuffer *fb;
+   int ret;
+
+   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
+   if (ret)
+   return ret;
+
+   ret = mutex_lock_interruptible(&dev->struct_mutex);
+   if (ret) {
+   mutex_unlock(&dev->mode_config.mutex);
+   return ret;
+   }
+
+   seq_printf(m, "fbcon ");
+   omap_framebuffer_describe(priv->fbdev->fb, m);
+
+   list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+   if (fb == priv->fbdev->fb)
+   continue;
+
+   seq_printf(m, "user ");
+   omap_framebuffer_describe(fb, m);
+   }
+
+   mutex_unlock(&dev->struct_mutex);
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return 0;
+}
+
+/* list of debufs files that are applicable to all devices */
 static struct drm_info_list omap_debugfs_list[] = {
+   {"gem", gem_show, 0},
+   {"mm", mm_show, 0},
+   {"fb", fb_show, 0},
+};
+
+/* list of debugfs files that are specific to devices with dmm/tiler */
+static struct drm_info_list omap_dmm_debugfs_list[] = {
{"tiler_map", tiler_map_show, 0},
 };

 int omap_debugfs_init(struct drm_minor *minor)
 {
-   return drm_debugfs_create_files(omap_debugfs_list,
+   struct drm_device *dev = minor->dev;
+   int ret;
+
+   ret = drm_debugfs_create_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list),
minor->debugfs_root, minor);
+
+   if (ret) {
+   dev_err(dev->dev, "could not install omap_debugfs_list\n");
+   return ret;
+   }
+
+   /* TODO: only do this if has_dmm.. but this fxn gets called before
+* dev_load() so we don't know this yet..
+*/
+   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list),
+   minor->debugfs_root, minor);
+
+   if (ret) {
+   dev_err(dev->dev, "could not install omap_dmm_debugfs_list\n");
+   return ret;
+   }
+
+   return ret;
 }

 void omap_debugfs_cleanup(struct drm_minor *minor)
 {
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
+   drm_debugfs_remove_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
 }

 #endif
diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 7417e1f..e2100bb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -573,6 +573,8 @@ static int dev_load(struct drm_device *dev, unsigned long 
flags)
priv->wq = alloc_workqueue("omapdrm",
WQ_UNBOUND | WQ_NON_REENTRANT, 1);

+   INIT_LIST_HEAD(&priv->obj_list);
+
omap_gem_init(dev);

ret = omap_modeset_init(dev);
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index fe4766e..21e48cf 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -42,10 +42,13 @@
 struct omap_drm_private

[PATCH 07/10] staging: drm/omap: Disable DMM debugfs for OMAP3

2012-03-05 Thread Rob Clark 
From: Andy Gross 

OMAP3 does not contain a DMM/Tiler block.  As such, we should not
be exposing any DMM debugfs entries on OMAP3 platforms.

Added inline helper function to verify existence of DMM.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_debugfs.c   |   15 +++
 drivers/staging/omapdrm/omap_dmm_tiler.h |6 ++
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
index e23f907..2f122e0 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -112,12 +112,10 @@ int omap_debugfs_init(struct drm_minor *minor)
return ret;
}

-   /* TODO: only do this if has_dmm.. but this fxn gets called before
-* dev_load() so we don't know this yet..
-*/
-   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
-   ARRAY_SIZE(omap_dmm_debugfs_list),
-   minor->debugfs_root, minor);
+   if (dmm_is_available())
+   ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list),
+   minor->debugfs_root, minor);

if (ret) {
dev_err(dev->dev, "could not install omap_dmm_debugfs_list\n");
@@ -131,8 +129,9 @@ void omap_debugfs_cleanup(struct drm_minor *minor)
 {
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
-   drm_debugfs_remove_files(omap_dmm_debugfs_list,
-   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
+   if (dmm_is_available())
+   drm_debugfs_remove_files(omap_dmm_debugfs_list,
+   ARRAY_SIZE(omap_dmm_debugfs_list), minor);
 }

 #endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.h 
b/drivers/staging/omapdrm/omap_dmm_tiler.h
index f87cb65..55ab284 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.h
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.h
@@ -16,6 +16,7 @@
 #ifndef OMAP_DMM_TILER_H
 #define OMAP_DMM_TILER_H

+#include 
 #include "omap_drv.h"
 #include "tcm.h"

@@ -132,4 +133,9 @@ struct omap_dmm_platform_data {
int irq;
 };

+static inline int dmm_is_available(void)
+{
+   return cpu_is_omap44xx();
+}
+
 #endif
-- 
1.7.5.4

[PATCH 08/10] staging: drm/omap: Validate debugfs device

2012-03-05 Thread Rob Clark 
From: Andy Gross 

Added check for valid device information before dumping debugfs
information.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 852d944..e4c7bb6 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -766,10 +766,18 @@ int tiler_map_show(struct seq_file *s, void *arg)
const char *a2d = special;
const char *m2dp = m2d, *a2dp = a2d;
char nice[128];
-   int h_adj = omap_dmm->lut_height / ydiv;
-   int w_adj = omap_dmm->lut_width / xdiv;
+   int h_adj;
+   int w_adj;
unsigned long flags;

+   if (!omap_dmm) {
+   /* early return if dmm/tiler device is not initialized */
+   return 0;
+   }
+
+   h_adj = omap_dmm->lut_height / ydiv;
+   w_adj = omap_dmm->lut_width / xdiv;
+
map = kzalloc(h_adj * sizeof(*map), GFP_KERNEL);
global_map = kzalloc((w_adj + 1) * h_adj, GFP_KERNEL);

-- 
1.7.5.4

[PATCH 09/10] staging: drm/omap: Get DMM resources from hwmod

2012-03-05 Thread Rob Clark 
From: Andy Gross 

This patch splits the DMM off into a separate sub-device, in order to
utilize the platform device information that was created as part of
the OMAP hwmod entry for the DMM.

The driver probe function queries the iomem resource and IRQ using
standard platform_get functions.

The OMAP DRM driver now calls the platform_driver_register() function
for the subordinate DMM driver inside its probe function.  This
guarantees the required order for the DMM and ensures the DMM resources
are available for use by the DRM driver.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_dmm_tiler.c |   79 +
 drivers/staging/omapdrm/omap_dmm_tiler.h |   11 +---
 drivers/staging/omapdrm/omap_drv.c   |6 ++
 drivers/staging/omapdrm/omap_gem.c   |8 +--
 4 files changed, 68 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index e4c7bb6..1ecb6a7 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -34,6 +34,8 @@
 #include "omap_dmm_tiler.h"
 #include "omap_dmm_priv.h"

+#define DMM_DRIVER_NAME "dmm"
+
 /* mappings for associating views to luts */
 static struct tcm *containers[TILFMT_NFORMATS];
 static struct dmm *omap_dmm;
@@ -465,7 +467,12 @@ size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w, 
uint16_t h)
return round_up(geom[fmt].cpp * w, PAGE_SIZE) * h;
 }

-int omap_dmm_remove(void)
+bool dmm_is_initialized(void)
+{
+   return omap_dmm ? true : false;
+}
+
+static int omap_dmm_remove(struct platform_device *dev)
 {
struct tiler_block *block, *_block;
int i;
@@ -499,40 +506,49 @@ int omap_dmm_remove(void)
if (omap_dmm->irq != -1)
free_irq(omap_dmm->irq, omap_dmm);

+   iounmap(omap_dmm->base);
kfree(omap_dmm);
+   omap_dmm = NULL;
}

return 0;
 }

-int omap_dmm_init(struct drm_device *dev)
+static int omap_dmm_probe(struct platform_device *dev)
 {
int ret = -EFAULT, i;
struct tcm_area area = {0};
u32 hwinfo, pat_geom, lut_table_size;
-   struct omap_drm_platform_data *pdata = dev->dev->platform_data;
-
-   if (!pdata || !pdata->dmm_pdata) {
-   dev_err(dev->dev, "dmm platform data not present, skipping\n");
-   return ret;
-   }
+   struct resource *mem;

omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
if (!omap_dmm) {
-   dev_err(dev->dev, "failed to allocate driver data section\n");
+   dev_err(&dev->dev, "failed to allocate driver data section\n");
goto fail;
}

/* lookup hwmod data - base address and irq */
-   omap_dmm->base = pdata->dmm_pdata->base;
-   omap_dmm->irq = pdata->dmm_pdata->irq;
-   omap_dmm->dev = dev->dev;
+   mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
+   if (!mem) {
+   dev_err(&dev->dev, "failed to get base address resource\n");
+   goto fail;
+   }
+
+   omap_dmm->base = ioremap(mem->start, SZ_2K);

if (!omap_dmm->base) {
-   dev_err(dev->dev, "failed to get dmm base address\n");
+   dev_err(&dev->dev, "failed to get dmm base address\n");
goto fail;
}

+   omap_dmm->irq = platform_get_irq(dev, 0);
+   if (omap_dmm->irq < 0) {
+   dev_err(&dev->dev, "failed to get IRQ resource\n");
+   goto fail;
+   }
+
+   omap_dmm->dev = &dev->dev;
+
hwinfo = readl(omap_dmm->base + DMM_PAT_HWINFO);
omap_dmm->num_engines = (hwinfo >> 24) & 0x1F;
omap_dmm->num_lut = (hwinfo >> 16) & 0x1F;
@@ -556,7 +572,7 @@ int omap_dmm_init(struct drm_device *dev)
"omap_dmm_irq_handler", omap_dmm);

if (ret) {
-   dev_err(dev->dev, "couldn't register IRQ %d, error %d\n",
+   dev_err(&dev->dev, "couldn't register IRQ %d, error %d\n",
omap_dmm->irq, ret);
omap_dmm->irq = -1;
goto fail;
@@ -575,25 +591,30 @@ int omap_dmm_init(struct drm_device *dev)

omap_dmm->lut = vmalloc(lut_table_size * sizeof(*omap_dmm->lut));
if (!omap_dmm->lut) {
-   dev_err(dev->dev, "could not allocate lut table\n");
+   dev_err(&dev->dev, "could not allocate lut table\n");
ret = -ENOMEM;
goto fail;
}

omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if (!omap_dmm->dummy_page) {
-   dev_err(dev->dev, "could not allocate dummy page\n");
+   dev_err(&dev->dev, "could not allocate dummy page\n");
ret = -ENOMEM;
goto fail;
}
+
+   /* set dma mask for device */
+   /* NOTE: this is a workaround for the hwmod not

[PATCH 10/10] staging: drm/omap: mmap of tiled buffers with stride >4kb

2012-03-05 Thread Rob Clark 
From: Rob Clark 

Deal with the case of buffers with virtual stride larger than one
page in fault_2d().

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |   86 ---
 1 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index 5abd294..921f058 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -153,10 +153,23 @@ static void evict_entry(struct drm_gem_object *obj,
enum tiler_fmt fmt, struct usergart_entry *entry)
 {
if (obj->dev->dev_mapping) {
-   size_t size = PAGE_SIZE * usergart[fmt].height;
+   struct omap_gem_object *omap_obj = to_omap_bo(obj);
+   int n = usergart[fmt].height;
+   size_t size = PAGE_SIZE * n;
loff_t off = mmap_offset(obj) +
(entry->obj_pgoff << PAGE_SHIFT);
-   unmap_mapping_range(obj->dev->dev_mapping, off, size, 1);
+   const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);
+   if (m > 1) {
+   int i;
+   /* if stride > than PAGE_SIZE then sparse mapping: */
+   for (i = n; i > 0; i--) {
+   unmap_mapping_range(obj->dev->dev_mapping,
+   off, PAGE_SIZE, 1);
+   off += PAGE_SIZE * m;
+   }
+   } else {
+   unmap_mapping_range(obj->dev->dev_mapping, off, size, 
1);
+   }
}

entry->obj = NULL;
@@ -342,26 +355,39 @@ static int fault_2d(struct drm_gem_object *obj,
void __user *vaddr;
int i, ret, slots;

-   if (!usergart)
-   return -EFAULT;
-
-   /* TODO: this fxn might need a bit tweaking to deal w/ tiled buffers
-* that are wider than 4kb
+   /*
+* Note the height of the slot is also equal to the number of pages
+* that need to be mapped in to fill 4kb wide CPU page.  If the slot
+* height is 64, then 64 pages fill a 4kb wide by 64 row region.
+*/
+   const int n = usergart[fmt].height;
+   const int n_shift = usergart[fmt].height_shift;
+
+   /*
+* If buffer width in bytes > PAGE_SIZE then the virtual stride is
+* rounded up to next multiple of PAGE_SIZE.. this need to be taken
+* into account in some of the math, so figure out virtual stride
+* in pages
 */
+   const int m = 1 + ((omap_obj->width << fmt) / PAGE_SIZE);

/* We don't use vmf->pgoff since that has the fake offset: */
pgoff = ((unsigned long)vmf->virtual_address -
vma->vm_start) >> PAGE_SHIFT;

-   /* actual address we start mapping at is rounded down to previous slot
+   /*
+* Actual address we start mapping at is rounded down to previous slot
 * boundary in the y direction:
 */
-   base_pgoff = round_down(pgoff, usergart[fmt].height);
-   vaddr = vmf->virtual_address - ((pgoff - base_pgoff) << PAGE_SHIFT);
-   entry = &usergart[fmt].entry[usergart[fmt].last];
+   base_pgoff = round_down(pgoff, m << n_shift);

+   /* figure out buffer width in slots */
slots = omap_obj->width >> usergart[fmt].slot_shift;

+   vaddr = vmf->virtual_address - ((pgoff - base_pgoff) << PAGE_SHIFT);
+
+   entry = &usergart[fmt].entry[usergart[fmt].last];
+
/* evict previous buffer using this usergart entry, if any: */
if (entry->obj)
evict_entry(entry->obj, fmt, entry);
@@ -369,23 +395,30 @@ static int fault_2d(struct drm_gem_object *obj,
entry->obj = obj;
entry->obj_pgoff = base_pgoff;

-   /* now convert base_pgoff to phys offset from virt offset:
-*/
-   base_pgoff = (base_pgoff >> usergart[fmt].height_shift) * slots;
-
-   /* map in pages.  Note the height of the slot is also equal to the
-* number of pages that need to be mapped in to fill 4kb wide CPU page.
-* If the height is 64, then 64 pages fill a 4kb wide by 64 row region.
-* Beyond the valid pixel part of the buffer, we set pages[i] to NULL to
-* get a dummy page mapped in.. if someone reads/writes it they will get
-* random/undefined content, but at least it won't be corrupting
-* whatever other random page used to be mapped in, or other undefined
-* behavior.
+   /* now convert base_pgoff to phys offset from virt offset: */
+   base_pgoff = (base_pgoff >> n_shift) * slots;
+
+   /* for wider-than 4k.. figure out which part of the slot-row we want: */
+   if (m > 1) {
+   int off = pgoff % m;
+   entry->obj_pgoff += off;
+   base_pgoff /= m;
+   slots = min(slots - (off << n_shift), n);
+

[PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox  wrote:
> From: Alan Cox 
>
> [Resending with correct address for Linus]

Should I take this directly, or is there a pending DRM pull that will
contain this?

 Linus

[PATCH] omap2+: add drm device

2012-03-05 Thread Rob Clark 
From: Andy Gross 

Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.  DMM is split into a
separate device using hwmod.

Signed-off-by: Andy Gross 
Signed-off-by: Rob Clark 
---
 arch/arm/plat-omap/Makefile   |2 +-
 arch/arm/plat-omap/common.c   |3 +-
 arch/arm/plat-omap/drm.c  |   83 +
 arch/arm/plat-omap/include/plat/drm.h |   64 +
 4 files changed, 150 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-omap/drm.c
 create mode 100644 arch/arm/plat-omap/include/plat/drm.h

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@

 # Common support
 obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o counter_32k.o drm.o
 obj-m :=
 obj-n :=
 obj-  :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
 #include 
 #include 
 #include 
+#include 

 #include 

-
 #define NO_LENGTH_CHECK 0x

 struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)

 void __init omap_reserve(void)
 {
+   omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..28279df
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_CMA
+#  include 
+#endif
+
+#include 
+#include 
+
+#include 
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = &omapdrm_platdata,
+   },
+   .name = "omapdrm",
+   .id = 0,
+};
+
+static int __init omap_init_gpu(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_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+   /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+   dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+#  warning "CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier"
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h 
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..df9bc41
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h
@@ -0,0 +1,64 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * 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

[Bug 27922] setting graphics mode for text console with video= instead of vga= does not work

2012-03-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=27922


J?r?me Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||glisse at freedesktop.org
 Resolution||INVALID




--- Comment #3 from J?r?me Glisse   2012-03-05 
16:56:01 ---
This is not a bug, video= command line is only interpreted with kernel
modesetting enabled. We don't support anymore non kernel modesetting case for
radeon.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

2012-03-05 Thread David Airlie 



- Original Message -
> From: "Linus Torvalds" 
> To: "Alan Cox" 
> Cc: dri-devel at lists.freedesktop.org
> Sent: Monday, 5 March, 2012 4:50:14 PM
> Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
> 
> On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox 
> wrote:
> > From: Alan Cox 
> >
> > [Resending with correct address for Linus]
> 
> Should I take this directly, or is there a pending DRM pull that will
> contain this?

I've just queued it up in drm-fixes, will send it out now since nothing else
came in today.

Dave.

[git pull] drm gma500 fix

2012-03-05 Thread Dave Airlie 

Hi,

Just a single gma500 fix from Alan.

Dave.

The following changes since commit a5939eefdcacd3ece57d56167a43bcc0d93733bf:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 (2012-03-04 
17:10:06 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alan Cox (1):
  drm/gma500: Fix Cedarview boot failures in 3.3-rc

 drivers/gpu/drm/gma500/cdv_device.c  |2 ++
 drivers/gpu/drm/gma500/framebuffer.c |1 -
 drivers/gpu/drm/gma500/gtt.c |9 -
 3 files changed, 6 insertions(+), 6 deletions(-)

[PATCH 2/3] dma-buf: add support for kernel cpu access

2012-03-05 Thread Daniel Vetter 
On Fri, Mar 2, 2012 at 23:24, Rob Clark  wrote:
> Perhaps we should check somewhere for required dmabuf ops fxns (like
> kmap_atomic here), rather than just calling unconditionally what might
> be a null ptr. ?At least put it in the WARN_ON(), but it might be
> nicer to catch a missing required fxns at export time, rather than
> waiting for an importer to try and call it. ?Less likely that way, for
> newly added required functions go unnoticed.
>
> (same comment applies below for the non-atomic variant.. and possibly
> some other existing dmabuf ops)

Agreed, I'll rework the patch to do that when rebasing onto Sumit's latest tree.
-Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Linaro-mm-sig] [PATCH 3/3] dma_buf: Add documentation for the new cpu access support

2012-03-05 Thread Clark, Rob 
On Fri, Mar 2, 2012 at 6:23 PM, Sakari Ailus  wrote:
> Hi Daniel,
>
> Thanks for the patch.
>
> On Thu, Mar 01, 2012 at 04:36:01PM +0100, Daniel Vetter wrote:
>> Signed-off-by: Daniel Vetter 
>> ---
>> ?Documentation/dma-buf-sharing.txt | ?102 
>> +++-
>> ?1 files changed, 99 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/dma-buf-sharing.txt 
>> b/Documentation/dma-buf-sharing.txt
>> index 225f96d..f12542b 100644
>> --- a/Documentation/dma-buf-sharing.txt
>> +++ b/Documentation/dma-buf-sharing.txt
>> @@ -32,8 +32,12 @@ The buffer-user
>> ?*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
>> ?For this first version, A buffer shared using the dma_buf sharing API:
>> ?- *may* be exported to user space using "mmap" *ONLY* by exporter, outside 
>> of
>> - ? this framework.
>> -- may be used *ONLY* by importers that do not need CPU access to the buffer.
>> + ?this framework.
>> +- with this new iteration of the dma-buf api cpu access from the kernel has 
>> been
>> + ?enable, see below for the details.
>> +
>> +dma-buf operations for device dma only
>> +--
>>
>> ?The dma_buf buffer sharing API usage contains the following steps:
>>
>> @@ -219,7 +223,99 @@ NOTES:
>> ? ? If the exporter chooses not to allow an attach() operation once a
>> ? ? map_dma_buf() API has been called, it simply returns an error.
>>
>> -Miscellaneous notes:
>> +Kernel cpu access to a dma-buf buffer object
>> +
>> +
>> +The motivation to allow cpu access from the kernel to a dma-buf object from 
>> the
>> +importers side are:
>> +- fallback operations, e.g. if the devices is connected to a usb bus and the
>> + ?kernel needs to shuffle the data around first before sending it away.
>> +- full transperancy for existing users on the importer side, i.e. userspace
>> + ?should not notice the difference between a normal object from that 
>> subsystem
>> + ?and an imported one backed by a dma-buf. This is really important for drm
>> + ?opengl drivers that expect to still use all the existing upload/download
>> + ?paths.
>> +
>> +Access to a dma_buf from the kernel context involves three steps:
>> +
>> +1. Prepare access, which invalidate any necessary caches and make the object
>> + ? available for cpu access.
>> +2. Access the object page-by-page with the dma_buf map apis
>> +3. Finish access, which will flush any necessary cpu caches and free 
>> reserved
>> + ? resources.
>
> Where it should be decided which operations are being done to the buffer
> when it is passed to user space and back to kernel space?
>
> How about spliting these operations to those done on the first time the
> buffer is passed to the user space (mapping to kernel address space, for
> example) and those required every time buffer is passed from kernel to user
> and back (cache flusing)?
>
> I'm asking since any unnecessary time-consuming operations, especially as
> heavy as mapping the buffer, should be avoidable in subsystems dealing
> with streaming video, cameras etc., i.e. non-GPU users.


Well, this is really something for the buffer exporter to deal with..
since there is no way for an importer to create a userspace mmap'ing
of the buffer.  A lot of these expensive operations go away if you
don't even create a userspace virtual mapping in the first place ;-)

BR,
-R

>
>> +1. Prepare acces
>> +
>> + ? Before an importer can acces a dma_buf object with the cpu from the 
>> kernel
>> + ? context, it needs to notice the exporter of the access that is about to
>> + ? happen.
>> +
>> + ? Interface:
>> + ? ? ?int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size_t start, size_t len,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?enum dma_data_direction direction)
>> +
>> + ? This allows the exporter to ensure that the memory is actually available 
>> for
>> + ? cpu access - the exporter might need to allocate or swap-in and pin the
>> + ? backing storage. The exporter also needs to ensure that cpu access is
>> + ? coherent for the given range and access direction. The range and access
>> + ? direction can be used by the exporter to optimize the cache flushing, 
>> i.e.
>> + ? access outside of the range or with a different direction (read instead 
>> of
>> + ? write) might return stale or even bogus data (e.g. when the exporter 
>> needs to
>> + ? copy the data to temporaray storage).
>> +
>> + ? This step might fail, e.g. in oom conditions.
>> +
>> +2. Accessing the buffer
>> +
>> + ? To support dma_buf objects residing in highmem cpu access is page-based 
>> using
>> + ? an api similar to kmap. Accessing a dma_buf is done in aligned chunks of
>> + ? PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which 
>> returns
>> + ? a pointer in kernel virtual address space. Afterwards the chunk needs to 
>> be
>> + ? unmapped again. There is no limit on how often a given chunk can be 
>> map

[Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access

2012-03-05 Thread Daniel Vetter 
On Fri, Mar 2, 2012 at 23:53, Rob Clark  wrote:
> nitially the expectation was that userspace would not pass a buffer
> to multiple subsystems for writing (or that if it did, it would get
> the undefined results that one could expect).. ?so dealing w/
> synchronization was punted.

Imo synchronization should not be part of the dma_buf core, i.e.
userspace needs to ensure that access is synchronized.
begin/end_cpu_access are the coherency brackets (like map/unmap for
device dma). And if userspace asks for a gun and some bullets, the
kernel should just deliver. Even in drm/i915 gem land we don't (and
simply can't) make any promises about concurrent reads/writes/ioctls.

> I expect, though, that one of the next steps is some sort of
> sync-object mechanism to supplement dmabuf

Imo the only reason to add sync objects as explicit things is to make
device-to-device sync more efficient by using hw semaphores and
signalling lines. Or maybe a quick irq handler in the kernel that
kicks of the next device. I don't think we should design these to make
userspace simpler.

Cheers, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] dma_buf: Add documentation for the new cpu access support

2012-03-05 Thread Daniel Vetter 
On Sat, Mar 3, 2012 at 01:23, Sakari Ailus  wrote:
> Where it should be decided which operations are being done to the buffer
> when it is passed to user space and back to kernel space?
>
> How about spliting these operations to those done on the first time the
> buffer is passed to the user space (mapping to kernel address space, for
> example) and those required every time buffer is passed from kernel to user
> and back (cache flusing)?
>
> I'm asking since any unnecessary time-consuming operations, especially as
> heavy as mapping the buffer, should be avoidable in subsystems dealing
> with streaming video, cameras etc., i.e. non-GPU users.

I'm a bit confused about your comments because this interface
extension doesn't support userspace mmap. So userspace isn't even part
of the picture. Adding mmap support is something entirely different
imo, and I have no idea yet how we should handle cache coherency for
that.

Yours, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[git pull] drm gma500 fix

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie  wrote:
>
> ?git://people.freedesktop.org/~airlied/linux drm-fixes

Hmm. Is freedesktop.org having trouble?

I got

  fatal: unable to connect to people.freedesktop.org:
  people.freedesktop.org[0: 131.252.210.176]: errno=Connection refused

and an the third try (I started stracing it to see what was up with
that "0:" part) it just hung at the connect. And a couple of times it
connected but then got reset.. So I perversely started trying to see
if it's coming alive.

And then it finally started working - but now I'm getting "Already up-to-date."

Linus

[git pull] drm gma500 fix

2012-03-05 Thread Keith Packard 
<#part sign=pgpmime>
On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds  wrote:
> On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie  wrote:
> >
> > ?git://people.freedesktop.org/~airlied/linux drm-fixes
> 
> Hmm. Is freedesktop.org having trouble?

ECC memory errors -- we're moving this stuff to a new machine as quickly
as rsync can run...

-- 
keith.packard at intel.com

[git pull] drm gma500 fix

2012-03-05 Thread Linus Torvalds 
On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard  wrote:
> <#part sign=pgpmime>
> On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds  linux-foundation.org> wrote:
>> Hmm. Is freedesktop.org having trouble?
>
> ECC memory errors -- we're moving this stuff to a new machine as quickly
> as rsync can run...

Ok. I'll just take Alan's patch directly as a patch.

No worries.

Linus

[PATCH] omap2+: add drm device

2012-03-05 Thread Rob Clark 
On Mon, Mar 5, 2012 at 6:10 PM, Tony Lindgren  wrote:
> * Rob Clark  [120305 08:24]:
>> From: Andy Gross 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation. ?DMM is split into a
>> separate device using hwmod.
>> --- a/arch/arm/plat-omap/common.c
>> +++ b/arch/arm/plat-omap/common.c
>> @@ -21,10 +21,10 @@
>> ?#include 
>> ?#include 
>> ?#include 
>> +#include 
>>
>> ?#include 
>>
>> -
>> ?#define NO_LENGTH_CHECK 0x
>>
>> ?struct omap_board_config_kernel *omap_board_config __initdata;
>> @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t 
>> *len)
>>
>> ?void __init omap_reserve(void)
>> ?{
>> + ? ? omapdrm_reserve_vram();
>> ? ? ? omapfb_reserve_sdram_memblock();
>> ? ? ? omap_vram_reserve_sdram_memblock();
>> ? ? ? omap_dsp_reserve_sdram_memblock();
>
> Tomi needs to look at the vram changes here.

it is just setting up a CMA region (if CMA is enabled.. basically for
once CMA is merged)

after CMA is merged, other drivers should be migrated to use CMA, and
omap_vram removed.. but that is a topic for another patch

>> --- /dev/null
>> +++ b/arch/arm/plat-omap/drm.c
>
> This file would be better in mach-omap2/drm.c. I doubt that this will
> ever be usable for omap1. But other than that, up to Tomi.

I was attempting to copy what omapfb was doing (plat-omap/fb.c)
because I wasn't really sure about plat-omap vs mach-omap2, although
on closer inspection I think the file I was looking at is actually for
the legacy omapdss1..  So I'll move this stuff under mach-omap2 and
resubmit this patch.

BR,
-R

> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

2012-03-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #38 from Alexandre Demers  
2012-03-05 20:40:48 UTC ---
Some news: today, I updated xserver and it seems I'm now able to boot under
Gnome-Shell correctly.

However, launching RenderFeatTest.bin64 still hangs exactly where it has been
hanging for some time now and freeze my window manager. At least, it seems one
of the problem was related to xserver.

I'll hope I'll be able to find something new in the logs.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] omap2+: add drm device

2012-03-05 Thread Tony Lindgren 
* Rob Clark  [120305 08:24]:
> From: Andy Gross 
> 
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.  DMM is split into a
> separate device using hwmod.
> --- a/arch/arm/plat-omap/common.c
> +++ b/arch/arm/plat-omap/common.c
> @@ -21,10 +21,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> -
>  #define NO_LENGTH_CHECK 0x
>  
>  struct omap_board_config_kernel *omap_board_config __initdata;
> @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
>  
>  void __init omap_reserve(void)
>  {
> + omapdrm_reserve_vram();
>   omapfb_reserve_sdram_memblock();
>   omap_vram_reserve_sdram_memblock();
>   omap_dsp_reserve_sdram_memblock();

Tomi needs to look at the vram changes here.

> --- /dev/null
> +++ b/arch/arm/plat-omap/drm.c

This file would be better in mach-omap2/drm.c. I doubt that this will
ever be usable for omap1. But other than that, up to Tomi.

Tony