date:20121109

https://bugs.freedesktop.org/show_bug.cgi?id=56936

Dave Airlie  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Dave Airlie  ---
some more questions:

can you make clean?

are these native apps or under wine?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/bf6c132b/attachment.html>

[Bug 54696] unstable frame rate in Quake 3

https://bugs.freedesktop.org/show_bug.cgi?id=54696

JS  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from JS  ---
gallium has average frame rate 51 fps and worst frame rate 6 fps
classic has average frame rate 41 fps and worst frame rate 15 fps

\timedemo 1
\demo four

classic
1260 frames 30.8 seconds 40.9 fps 5.0/24.5/65.0/6.6 ms
gallium
1260 frames 24.7 seconds 51.0 fps 1.0/19.6/167.0/32.0 ms

--- Comment #2 from JS  ---
already don't use this driver

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/f3e22943/attachment.html>

[Bug 56936] cube map array support breaks rendering on BARTS

https://bugs.freedesktop.org/show_bug.cgi?id=56936

--- Comment #2 from Dave Airlie  ---
with unigine heaven I get black textures even before this, I'm not sure what I
could be going wrong running it here.

I'm testing on a caicos but I don't think barts will be too much different.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/c04a69dd/attachment-0001.html>

[PATCH] drm: fix drm_framebuffer cleanup.

t;
> >
> > And it seems like that your saying is that each specific drivers
> > should resolve this issue(access to invalid memory region) tracking the
> > pending page flip. But I think that this issue may be a missing point drm
> > framework missed so specific drivers is processing this instead. And with
> > this patch, couldn't some codes you mentioned be removed from specific
> > drivers? because it doesn't need to track the pending page flips and
> > relevant things anymore.
> >
> > There may be my missing point. I'd welcome to any comments and advices.
>
> If you don't track the page flips somehow, you can't safely free the
> previous buffer. It's that simple. You can of course make some of
> that code generic enough to be shared between drivers. That is
> actually what the drm_flip mechanism that I wrote for atomic page
> flips is; a reasonably generic helper for tracking page flips.
>
>
Thanks for comments. Right, now Exynos driver doesn't consider tracking
page flips yet. This is my TODO. Anyway couldn't we improve this patch so
that drm framework considers such thing?
I think with this patch, we could avoid invald memory access issue without
tracking page flips. In this case, pended page flips would be just ignored.

Thanks,
Inki Dae


> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/41ab379a/attachment.html>

[PATCH] drm/exynos: Add exynos drm specific fb_mmap function

sorry for being late.

2012/11/7 Rahul Sharma 

> From: Prathyush K 
>
> This patch adds a exynos drm specific implementation of fb_mmap
> which supports mapping a non-contiguous buffer to user space.
>
> This new function does not assume that the frame buffer is contiguous
> and calls dma_mmap_writecombine for mapping the buffer to user space.
> dma_mmap_writecombine will be able to map a contiguous buffer as well
> as non-contig buffer depending on whether an IOMMU mapping is created
> for drm or not.
>
> Signed-off-by: Prathyush K 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   26
> ++
>  1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 67eb6ba..3939f7f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -46,8 +46,34 @@ struct exynos_drm_fbdev {
> struct exynos_drm_gem_obj   *exynos_gem_obj;
>  };
>
> +static int exynos_drm_fb_mmap(struct fb_info *info,
> + struct vm_area_struct *vma)
> +{
> +   DRM_DEBUG_KMS("%s\n", __func__);
> +
> +   if (!vma || !info) {
> +   DRM_ERROR("invalid arguments vma 0x%x, info 0x%x.\n",
> +   (unsigned int)vma, (unsigned int)info);
> +   return -EINVAL;
> +   }
> +
> +   if (!info->screen_base || info->screen_size == 0) {
> +   DRM_ERROR("invalid screen information.\n");
> +   return -EINVAL;
> +   }
> +
> +   vma->vm_pgoff = 0;
> +   vma->vm_flags |= VM_IO;
> +   if (dma_mmap_writecombine(info->device, vma, info->screen_base,
> +   info->fix.smem_start, vma->vm_end - vma->vm_start))
>

fix.smem_start should have physical address. Please see the below comment
of framebuffer header,
struct  fb_fix_screeninfo {
...
unsigned long smem_start;/* Start of frame
buffer mem */
   /*
(physical address) */

For this, I posted fixup patch so smem_start has physical address always.

Thanks,
Inki Dae


> +   return -EAGAIN;
> +
> +   return 0;
> +}
> +
>  static struct fb_ops exynos_drm_fb_ops = {
> .owner  = THIS_MODULE,
> +   .fb_mmap= exynos_drm_fb_mmap,
> .fb_fillrect= cfb_fillrect,
> .fb_copyarea= cfb_copyarea,
> .fb_imageblit   = cfb_imageblit,
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/edd38d58/attachment.html>

[PATCH] HACK: drm: Allow encoders to be reenabled

2012-11-09 Thread Daniel Vetter

On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> >  wrote:
> > > When running the xf86-video-modesetting driver on top of a KMS driver,
> > > leaving X causes the active encoder's DPMS mode to be set to off by the
> > > drm_crtc_helper_disable() function. This doesn't set the connector's
> > > DPMS mode to off, however, which results in subsequent calls to the
> > > drm_helper_connector_dpms() function to not enable the encoder because
> > > the connector's DPMS mode hasn't changed.
> > >
> > > This patch works around this by forcing the connector's DPMS mode to off
> > > if the encoder has changed, which always happens when a new mode is set
> > > after drm_crtc_helper_disable(). The code that sets the connector DPMS
> > > mode to on will then also enable the CRTC and encoder because the mode
> > > actually changed.
> > >
> > > Signed-off-by: Thierry Reding 
> > 
> > Reviewed-by: Alex Deucher 
> 
> This is really much uglier than I would have liked, but I honestly can't
> think of any better way that would be this easy to implement. An
> alternative solution would be to add dpms fields to both drm_crtc and
> drm_encoder structures and modify drm_helper_connector_dpms() to run the
> CRTC's and encoder's .dpms() functions if the new mode is different from
> that stored in the respective dpms fields. Coding that, however, will
> probably be more involved and more likely to introduce errors somewhere
> else because of the extra accounting required.
> 
> In case this workaround isn't acceptable I can take a look at coding up
> a cleaner fix.

Imo the confusion around dpms in the crtc helper all stem from the totally
unclear semantics of dmps vs. modeset calls. Besides your case, where we
essentially disable a encoder/crtc without updating the dpms properties,
theres the symmetric issue that after a modeset call all newly active
encoders/crtcs are fully enabled, but the connector dpms property is still
the same it was before the modeset call. Which is even more funny since
userspace is allowed to change the dpms property on an unused connector.

Additional, the i915 modeset code now also updates the userspace visible
dpms property after a modeset, to avoid potential confusion in userspace -
that way the dpms property always reflects reality when the connector is
used, and is ignored when it is unused. Dunno whether forcing dpms to on
after a modeset is the semantics we want though.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 46/51] drm/i915: Add support for atomic modesetting completion events

2012-11-09 Thread Daniel Vetter

On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote:
> On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter  wrote:
> > On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
> >> On Thu, 1 Nov 2012 19:07:02 +0200
> >> Ville Syrj?l?  wrote:
> >>
> >> > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
> >> > > On Thu, 1 Nov 2012 12:12:35 +0100
> >> > > Daniel Vetter  wrote:
> >> > >
> >> > > > On Thu, Oct 25, 2012 at 8:05 PM,   
> >> > > > wrote:
> >> > > > > From: Ville Syrj?l? 
> >> > > > >
> >> > > > > Send completion events when the atomic modesetting operations has
> >> > > > > finished succesfully.
> >> > > > >
> >> > > > > Signed-off-by: Ville Syrj?l? 
> >> > > >
> >> > > > I have to admit I'm not on top of the latest ioctl/interface
> >> > > > discussion, but one new requirement for the modeset (not the pageflip
> >> > > > part) of the all this atomic stuff I've discovered is that the kernel
> >> > > > needs to be able to select the crtcs for each output completely
> >> > > > unrestricted. I think userspace should simply pass in abstract crtc
> >> > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual
> >> > > > crtcs it has selected.
> >> > > >
> >> > > > We can't do that remapping internally because the crtc abstraction 
> >> > > > is leaky:
> >> > > > - wait_for_vblank requires the pipe id, which could then change on 
> >> > > > every modeset
> >> > > > - similarly userspace doing MI_WAIT for scanlines needs to know the
> >> > > > actual hw pipe in use by a crtc.
> >> > > > And current userspace presumes that the mapping between crtc->pipe
> >> > > > doesn't change.
> 
> I don't know if it is possible, but it would be nice to try to clean
> up crtc<->pipe stuff..  userspace, at least modetest, assumes crtc ==
> crtc_list[pipe].  But I haven't noticed yet anywhere that this
> relationship is documented.  And if you are thinking about doing what
> I think you are thinking about doing, then this assumption would no
> longer hold for i915.

This relationship does already no longer hold on i915 - on gen3 at least
we sometimes switch the crtc->pipe assignement (to make fbc more useful),
which means even with todays code userspace cannot assume (when running on
i915), that the vblank pipe satisfies crtc == crtc_list[pipe].

> How frequently do you emit waits for scanline?  Places where the pipe
> # ends up in cmdstream, would it be too crazy to handle that like a
> reloc where the kernel goes and fixes up the actual value in the
> cmdstream as it does it's GEM reloc pass?  If you did this then you
> could virtualize pipe as well as crtc.

Every dri2 copyregion or Xv upload to the frontbuffer on pre-gen6 will use
it. And we need old userspace to keep on working - presumably the fb layer
will switch to using the new atomic modeset stuff (if available) to figure
out an optimal config, so this is relevant.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

acceleration is implemented on top of this driver.

> >> > +int host1x_unregister_client(struct host1x *host1x,
> >> > +struct host1x_client *client)
> >> > +{
> >> > +   struct host1x_drm_client *drm, *tmp;
> >> > +   int err;
> >> > +
> >> > +   list_for_each_entry_safe(drm, tmp, >drm_active, list) {
> >> > +   if (drm->client == client) {
> >> > +   err = host1x_drm_exit(host1x);
> >> > +   if (err < 0) {
> >> > +   dev_err(host1x->dev, "host1x_drm_exit(): 
> >> > %d\n",
> >> > +   err);
> >> > +   return err;
> >> > +   }
> >> > +
> >> > +   host1x_remove_drm_client(host1x, drm);
> >> > +   break;
> >> > +   }
> >> > +   }
> >> > +
> >> > +   mutex_lock(>clients_lock);
> >> > +   list_del_init(>list);
> >> > +   mutex_unlock(>clients_lock);
> >> > +
> >> > +   return 0;
> >> > +}
> >>
> >> btw, if I understand the register/unregister client stuff, I think
> >> there can be some potential issues.  If I understand correctly, you
> >> will create the crtc's in register.  But unregister doesn't destroy
> >> them, drm_mode_config_cleanup() when the container drm device is
> >> unloaded does.  So if there is any possibility to unregister a client
> >> without tearing down everything, you might get into some problems
> >> here.
> >>
> >> Also, you might be breaking some assumptions about when the crtc's are
> >> created.. at least if there is some possibility for userspace to sneak
> >> in and do a getresources ioctl between the first and second client.
> >> That might be easy enough to solve by adding some event for userspace
> >> to get notified that it should getresources again.  The unregister is
> >> what I worry about more.
> >>
> >> In general drm isn't set up to well for drivers that are a collection
> >> of sub-devices.  It is probably worth trying to improve this, although
> >> I am still a bit skittish about the edge cases, like what happens when
> >> you unload a sub-device mid-modeset.  The issue comes up again for
> >> common panel/display framework.
> >>
> >> But for now you might just want to do something to ensure that all the
> >> sub-devices are loaded/unloaded together as a whole.
> >
> > The way that the above is supposed to work is that the DRM relevant
> > host1x clients are kept in a separate list and only if all of them have
> > successfully been probed is the DRM portion initialized. Upon
> > unregistration, as soon as the first of these clients is unregistered,
> > all of the DRM stuff is torn down.
> 
> ahh, ok, I guess if DRM is torn down on first unregister, then you
> shouldn't be hitting issues.  I wasn't sure if the intention was to be
> able to load/unload clients independently (such as building them as
> separate modules eventually)

No, this is all supposed to stay in one driver for now. We may want to
split off the host1x code into a separate driver because eventually it
will have to be accessed by V4L2 drivers as well, so drivers/gpu/drm
isn't the optimal place for it. However the basic requirement to have
all DRM related components register or unregister at once will stay
until the DRM core can handle dynamic registration better.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/dce17030/attachment.pgp>

[Bug 56936] cube map array support breaks rendering on BARTS

https://bugs.freedesktop.org/show_bug.cgi?id=56936

maxijac at free.fr changed:

   What|Removed |Added

  Attachment #69839|0   |1
is obsolete||

--- Comment #1 from maxijac at free.fr ---
Created attachment 69840
  --> https://bugs.freedesktop.org/attachment.cgi?id=69840=edit
Hon garbage rendering bis

What is wrong with this bugzilla seeing a png as text/plain?..

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/cb62ed46/attachment.html>

[Bug 56936] New: cube map array support breaks rendering on BARTS

https://bugs.freedesktop.org/show_bug.cgi?id=56936

  Priority: medium
Bug ID: 56936
  Assignee: dri-devel at lists.freedesktop.org
   Summary: cube map array support breaks rendering on BARTS
  Severity: major
Classification: Unclassified
OS: All
  Reporter: maxijac at free.fr
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 69839
  --> https://bugs.freedesktop.org/attachment.cgi?id=69839=edit
Hon garbage rendering

Possibly affects other cards.

I bisected and the first bad commit is eb44c36df842af010269eda1be77c4aea8ebe736
r600g: add initial cube map array support (v2).

It either displays plain black or garbage textures.

I tested with Heroes of Newerth and Unigine heaven.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/70e65a65/attachment.html>

[PATCH 2/2] drm: exynos: compose and send avi and aui info frames

This patch adds code for composing AVI and AUI info frames
and send them every VSYNC.

This patch is important for hdmi certification.

Signed-off-by: Fahad Kunnathadi 
Signed-off-by: Shirish S 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   97 +-
 drivers/gpu/drm/exynos/exynos_hdmi.h |   23 
 drivers/gpu/drm/exynos/regs-hdmi.h   |   17 +-
 3 files changed, 133 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c115f8..bb8a045 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -82,6 +82,7 @@ struct hdmi_context {

/* current hdmiphy conf index */
int cur_conf;
+   int cur_video_id;

struct hdmi_resources   res;
void*parent_ctx;
@@ -944,6 +945,11 @@ static const struct hdmi_conf hdmi_confs[] = {
{ 1920, 1080, 60, false, hdmiphy_conf148_5, _conf_1080p60 },
 };

+struct hdmi_infoframe {
+   enum HDMI_PACKET_TYPE type;
+   u8 ver;
+   u8 len;
+};

 static inline u32 hdmi_reg_read(struct hdmi_context *hdata, u32 reg_id)
 {
@@ -1267,6 +1273,81 @@ static int hdmi_conf_index(struct hdmi_context *hdata,
return hdmi_v14_conf_index(mode);
 }

+static u8 hdmi_chksum(struct hdmi_context *hdata,
+   u32 start, u8 len, u32 hdr_sum)
+{
+   int i;
+   /* hdr_sum : header0 + header1 + header2
+   * start : start address of packet byte1
+   * len : packet bytes - 1 */
+   for (i = 0; i < len; ++i)
+   hdr_sum += 0xff & hdmi_reg_read(hdata, start + i * 4);
+
+   return (u8)(0x100 - (hdr_sum & 0xff));
+}
+
+void hdmi_reg_infoframe(struct hdmi_context *hdata,
+   struct hdmi_infoframe *infoframe)
+{
+   u32 hdr_sum;
+   u8 chksum;
+   u32 aspect_ratio;
+   u32 mod;
+
+   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
+   mod = hdmi_reg_read(hdata, HDMI_MODE_SEL);
+   if (hdata->dvi_mode) {
+   hdmi_reg_writeb(hdata, HDMI_VSI_CON,
+   HDMI_VSI_CON_DO_NOT_TRANSMIT);
+   hdmi_reg_writeb(hdata, HDMI_AVI_CON,
+   HDMI_AVI_CON_DO_NOT_TRANSMIT);
+   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_NO_TRAN);
+   return;
+   }
+
+   switch (infoframe->type) {
+
+   case HDMI_PACKET_TYPE_AVI:
+   hdmi_reg_writeb(hdata, HDMI_AVI_CON, HDMI_AVI_CON_EVERY_VSYNC);
+   hdmi_reg_writeb(hdata, HDMI_AVI_HEADER0, infoframe->type);
+   hdmi_reg_writeb(hdata, HDMI_AVI_HEADER1, infoframe->ver);
+   hdmi_reg_writeb(hdata, HDMI_AVI_HEADER2, infoframe->len);
+   hdr_sum = infoframe->type + infoframe->ver + infoframe->len;
+   /* Output format zero hardcoded ,RGB YBCR selection */
+   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(1), 0 << 5 |
+   AVI_ACTIVE_FORMAT_VALID |
+   AVI_UNDERSCANNED_DISPLAY_VALID);
+
+   aspect_ratio = AVI_PIC_ASPECT_RATIO_16_9;
+
+   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), aspect_ratio |
+   AVI_SAME_AS_PIC_ASPECT_RATIO);
+   hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(4), hdata->cur_video_id);
+
+   chksum = hdmi_chksum(hdata, HDMI_AVI_BYTE(1),
+   infoframe->len, hdr_sum);
+   DRM_DEBUG_KMS("AVI checksum = 0x%x\n", chksum);
+   hdmi_reg_writeb(hdata, HDMI_AVI_CHECK_SUM, chksum);
+   break;
+
+   case HDMI_PACKET_TYPE_AUI:
+   hdmi_reg_writeb(hdata, HDMI_AUI_CON, 0x02);
+   hdmi_reg_writeb(hdata, HDMI_AUI_HEADER0, infoframe->type);
+   hdmi_reg_writeb(hdata, HDMI_AUI_HEADER1, infoframe->ver);
+   hdmi_reg_writeb(hdata, HDMI_AUI_HEADER2, infoframe->len);
+   hdr_sum = infoframe->type + infoframe->ver + infoframe->len;
+   chksum = hdmi_chksum(hdata, HDMI_AUI_BYTE(1),
+   infoframe->len, hdr_sum);
+   DRM_DEBUG_KMS("AUI checksum = 0x%x\n", chksum);
+   hdmi_reg_writeb(hdata, HDMI_AUI_CHECK_SUM, chksum);
+   break;
+
+   default:
+   break;
+   }
+}
+
 static bool hdmi_is_connected(void *ctx)
 {
struct hdmi_context *hdata = ctx;
@@ -1541,6 +1622,8 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)

 static void hdmi_conf_init(struct hdmi_context *hdata)
 {
+   struct hdmi_infoframe infoframe;
+
/* disable HPD interrupts */
hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
HDMI_INTC_EN_HPD_PLUG | HDMI_INTC_EN_HPD_UNPLUG);
@@ -1575,9 +1658,17 @@ static void hdmi_conf_init(struct hdmi_context *hdata)
hdmi_reg_writeb(hdata,

[PATCH 1/2] drm: get cea video id code for a given display mode

From: Stephane Marchesin 

This patch adds support for getting CEA Video ID Code for a given
display mode after matching with edid_cea_modes list. Its index in
the list added with one, gives the desired code.

This exported function will be used by hdmi drivers for composing
AVI info frame data.

Signed-off-by: Stephane Marchesin 
Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/drm_edid.c |   20 
 include/drm/drm_crtc.h |1 +
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fadcd44..856dcd9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1516,6 +1516,26 @@ u8 *drm_find_cea_extension(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_find_cea_extension);

+/*
+ * Looks for a CEA mode matching given drm_display_mode.
+ * Returns its CEA Video ID code, or 0 if not found.
+ */
+u8 drm_match_cea_mode(struct drm_display_mode *to_match)
+{
+   struct drm_display_mode *cea_mode;
+   u8 mode;
+
+   for (mode = 0; mode < drm_num_cea_modes; mode++) {
+   cea_mode = (struct drm_display_mode *)_cea_modes[mode];
+
+   if (drm_mode_equal(to_match, cea_mode))
+   return mode + 1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(drm_match_cea_mode);
+
+
 static int
 do_cea_modes (struct drm_connector *connector, u8 *db, u8 len)
 {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 92889be..467a327 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1038,6 +1038,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device 
*dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern u8 *drm_find_cea_extension(struct edid *edid);
+extern u8 drm_match_cea_mode(struct drm_display_mode *to_match);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
 extern bool drm_detect_monitor_audio(struct edid *edid);
 extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
-- 
1.7.0.4

[PATCH 0/2] drm: exynos: hdmi: sending AVI and AUI info frames

This patch set adds provision for composing and sending AVI and AUI
infoframes by exynos drm hdmi driver.

It also adds provision to get CEA Video ID Code through the display mode
which is required for making AVI infoframe.

Based on exynos-drm-fixes branch of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

Rahul Sharma (1):
  drm: exynos: compose and send avi and aui info frames

Stephane Marchesin (1):
  drm: get cea video id code for a given display mode

 drivers/gpu/drm/drm_edid.c   |   20 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c |   97 +-
 drivers/gpu/drm/exynos/exynos_hdmi.h |   23 
 drivers/gpu/drm/exynos/regs-hdmi.h   |   17 +-
 include/drm/drm_crtc.h   |1 +
 5 files changed, 154 insertions(+), 4 deletions(-)

[PATCH] drm: fix drm_framebuffer cleanup.

2012/11/9 Ville Syrj?l? 

> On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> > This patch fixes access issue to invalid memory region.
> >
> > crtc had only one drm_framebuffer object so when framebuffer
> > cleanup was requested after page flip, it'd try to disable
> > hardware overlay to current crtc.
> > But if current crtc points to another drm_framebuffer,
> > This may induce invalid memory access.
> >
> > Assume that some application are doing page flip with two
> > drm_framebuffer objects. At this time, if second drm_framebuffer
> > is set to current crtc and the cleanup to first drm_framebuffer
> > is requested once drm release is requested, then first
> > drm_framebuffer would be cleaned up without disabling
> > hardware overlay because current crtc points to second
> > drm_framebuffer. After that, gem buffer to first drm_framebuffer
> > would be released and this makes dma access invalid memory region.
> >
> > This patch adds drm_framebuffer to drm_crtc structure as member
>
> That is exactly the reverse of what you're doing in the patch.
> We already have crtc.fb, and you're adding fb.crtc.
>
> > and makes drm_framebuffer_cleanup function check if fb->crtc is
> > same as desired fb. And also when setcrtc and pageflip are
> > requested, it makes each drm_framebuffer point to current crtc.
>
> Looks like you're just setting the crtc.fb and fb.crtc pointers to
> exactly mirror each other in the page flip ioctl. That can't fix
> anything.
>
>
At least, when drm is released, the crtc to framebuffer that was recently
used for scanout can be disabled correctly.


> First of all multiple crtcs can scan out from the same fb, so a single
> fb.crtc pointer is clearly not enough to represent the relationship
> between fbs and crtcs.
>
> Also you're not clearing the fb.crtc pointer anywhere, so now
> destroying any framebuffer that was once used for scanout, would disable
> some crtc.
>
>
It looks like that you missed my previous comment. Plaese, see the previous
comment. And that was already pointed out by Prathyush. fb.crtc will be
cleared at drm_mode_rmfb(). With this, is there my missing point?  I really
wonder that with this patch, drm framwork could be faced with any problem.


> So it looks like you're making things worse, not better.
>
> Anyway I'll just nack the whole idea. What you need to do is track the
> pending page flips, and make sure the old buffer is not freed too early.
> Just grab a reference to the old gem object when issuing the page flip,
> and unref it when you're sure the flip has occured. Or you could use the
> new drm_framebuffer refcount, but personally I don't see much point in
> that when you already have the gem object refcount at your disposal.
>
>
>

And it seems like that your saying is that each specific drivers
should resolve this issue(access to invalid memory region) tracking the
pending page flip. But I think that this issue may be a missing point drm
framework missed so specific drivers is processing this instead. And with
this patch, couldn't some codes you mentioned be removed from specific
drivers? because it doesn't need to track the pending page flips and
relevant things anymore.

There may be my missing point. I'd welcome to any comments and advices.

Thanks,
Inki Dae
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/c515ff73/attachment.html>

[PATCH 2/2] drm: tegra: Add HDMI support

On Fri, Nov 09, 2012 at 05:04:09PM +0100, Rafa? Mi?ecki wrote:
> 2012/11/9 Christian K?nig :
> > On 09.11.2012 16:45, Rafa? Mi?ecki wrote:
> >> I was told it won't work on different endian devices. See
> >> [RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> >> http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html
> >
> >
> > Yeah, that's indeed true. And honestly adding just another implementation of
> > the HDMI info frames sounds like somebody should finally sit down and
> > implement it in a common drm_hdmi.c
> 
> Agree.

Any volunteers? If nobody else steps up I'm willing to put some work
into this. I'm a bit reluctant to do this right away since time is
already very short before the 3.8 merge window. If I promise to look at
this once the Tegra DRM driver is in, would people be willing to let it
slip for now?

I know this is not much of an argument and I'm all in favour of a
generic implementation, but I don't think endianess will be an issue in
the near future on Tegra. I don't believe there are any plans to make it
support big endian.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/3447cfd1/attachment.pgp>

[PATCH] drm/ttm: remove unneeded preempt_disable/enable

2012-11-09 Thread Akinobu Mita

It is unnecessary to disable preemption explicitly while calling
copy_highpage().  Because copy_highpage() will do it again through
kmap_atomic/kunmap_atomic.

Signed-off-by: Akinobu Mita 
Cc: dri-devel at lists.freedesktop.org
Cc: David Airlie 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index bf82601..7d759a4 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -308,9 +308,7 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
if (unlikely(to_page == NULL))
goto out_err;

-   preempt_disable();
copy_highpage(to_page, from_page);
-   preempt_enable();
page_cache_release(from_page);
}

@@ -358,9 +356,7 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
ret = PTR_ERR(to_page);
goto out_err;
}
-   preempt_disable();
copy_highpage(to_page, from_page);
-   preempt_enable();
set_page_dirty(to_page);
mark_page_accessed(to_page);
page_cache_release(to_page);
-- 
1.7.11.7

[PATCH] drm: use memchr_inv()

2012-11-09 Thread Akinobu Mita

Use memchr_inv() to check the specified memory region is filled with zero.

Signed-off-by: Akinobu Mita 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fadcd44..59260bf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -307,12 +307,9 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,

 static bool drm_edid_is_zero(u8 *in_edid, int length)
 {
-   int i;
-   u32 *raw_edid = (u32 *)in_edid;
+   if (memchr_inv(in_edid, 0, length))
+   return false;

-   for (i = 0; i < length / 4; i++)
-   if (*(raw_edid + i) != 0)
-   return false;
return true;
 }

-- 
1.7.11.7

[PATCH] drm/radeon: Use hweight32

2012-11-09 Thread Akinobu Mita

Use hweight32 instead of counting for each bit

Signed-off-by: Akinobu Mita 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/radeon/r600.c| 8 +---
 drivers/gpu/drm/radeon/r600_cp.c | 7 +--
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index cda280d..169ecc9 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1424,13 +1424,7 @@ u32 r6xx_remap_render_backend(struct radeon_device *rdev,

 int r600_count_pipe_bits(uint32_t val)
 {
-   int i, ret = 0;
-
-   for (i = 0; i < 32; i++) {
-   ret += val & 1;
-   val >>= 1;
-   }
-   return ret;
+   return hweight32(val);
 }

 static void r600_gpu_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 2514123..be85f75 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -721,12 +721,7 @@ static u32 r600_get_tile_pipe_to_backend_map(u32 
num_tile_pipes,

 static int r600_count_pipe_bits(uint32_t val)
 {
-   int i, ret = 0;
-   for (i = 0; i < 32; i++) {
-   ret += val & 1;
-   val >>= 1;
-   }
-   return ret;
+   return hweight32(val);
 }

 static void r600_gfx_init(struct drm_device *dev,
-- 
1.7.11.7

[PATCH] drm: fix drm_framebuffer cleanup.

On Sat, Nov 10, 2012 at 01:50:53AM +0900, Inki Dae wrote:
> 2012/11/9 Ville Syrj?l? 
> 
> > On Fri, Nov 09, 2012 at 11:04:58PM +0900, Inki Dae wrote:
> > > 2012/11/9 Ville Syrj?l? 
> > >
> > > > On Fri, Nov 09, 2012 at 09:41:19PM +0900, Inki Dae wrote:
> > > > > 2012/11/9 Ville Syrj?l? 
> > > > >
> > > > > > On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> > > > > > > This patch fixes access issue to invalid memory region.
> > > > > > >
> > > > > > > crtc had only one drm_framebuffer object so when framebuffer
> > > > > > > cleanup was requested after page flip, it'd try to disable
> > > > > > > hardware overlay to current crtc.
> > > > > > > But if current crtc points to another drm_framebuffer,
> > > > > > > This may induce invalid memory access.
> > > > > > >
> > > > > > > Assume that some application are doing page flip with two
> > > > > > > drm_framebuffer objects. At this time, if second drm_framebuffer
> > > > > > > is set to current crtc and the cleanup to first drm_framebuffer
> > > > > > > is requested once drm release is requested, then first
> > > > > > > drm_framebuffer would be cleaned up without disabling
> > > > > > > hardware overlay because current crtc points to second
> > > > > > > drm_framebuffer. After that, gem buffer to first drm_framebuffer
> > > > > > > would be released and this makes dma access invalid memory
> > region.
> > > > > > >
> > > > > > > This patch adds drm_framebuffer to drm_crtc structure as member
> > > > > >
> > > > > > That is exactly the reverse of what you're doing in the patch.
> > > > > > We already have crtc.fb, and you're adding fb.crtc.
> > > > > >
> > > > > > > and makes drm_framebuffer_cleanup function check if fb->crtc is
> > > > > > > same as desired fb. And also when setcrtc and pageflip are
> > > > > > > requested, it makes each drm_framebuffer point to current crtc.
> > > > > >
> > > > > > Looks like you're just setting the crtc.fb and fb.crtc pointers to
> > > > > > exactly mirror each other in the page flip ioctl. That can't fix
> > > > > > anything.
> > > > > >
> > > > > >
> > > > > At least, when drm is released, the crtc to framebuffer that was
> > recently
> > > > > used for scanout can be disabled correctly.
> > > >
> > > > Let's take this scenario:
> > > >
> > > > setcrtc(crtc0, fb0)
> > > >  -> crtc0.fb = fb0, fb0.crtc = crtc0
> > > > page_flip(crtc0, fb1)
> > > >  -> crtc0.fb = fb1, fb1.crtc = crtc0
> > > > rmfb(fb0)
> > > >  -> ?
> > > >
> > > > The rmfb() will now disable crtc0 because fb0.crtc == crtc0, but
> > > > let's consider this just a bug and ignore it for now. So let's assume
> > > > that crtc0 won't be disabled when we call rmfb(fb0).
> > > >
> > > >
> > > Ok, Please assume that my patch includes the below codes. when we call
> > > rmfb(fb0), fb0->crtc is NULL. so fb0 will be freed without disabling
> > crtc.
> > >
> > > int drm_mode_rmfb(struct drm_device *dev, void *data, struct drm_file
> > > *file_priv) {
> > > 
> > > fb->crtc = NULL;
> > > fb->funcs->destroy(fb);
> > > out:
> > > ...
> > > }
> >
> > As stated above, I already assumed that.
> >
> > > > The real question is, how would your patch help? You can't free fb0
> > > > until the page flip has occured, and your patch doesn't track page
> > > > flips, so how can it do anything useful?
> > > >
> > > > > > First of all multiple crtcs can scan out from the same fb, so a
> > single
> > > > > > fb.crtc pointer is clearly not enough to represent the relationship
> > > > > > between fbs and crtcs.
> > > > > >
> > > > > > Also you're not clearing the fb.crtc pointer anywhere, so now
> > > > > > destroying any framebuffer that was once used for scanout, would
> > > > disable
> > > > > > some crtc.
> > > > > >
> > > > > >
> > > > > It looks like that you missed my previous comment. Plaese, see the
> > > > previous
> > > > > comment. And that was already pointed out by Prathyush. fb.crtc will
> > be
> > > > > cleared at drm_mode_rmfb(). With this, is there my missing point?  I
> > > > really
> > > > > wonder that with this patch, drm framwork could be faced with any
> > > > problem.
> > > >
> > > > If you clear the fb.crtc pointer before destroying the fb, then you
> > > > never disable any crtcs in response to removing a framebuffer.
> > > > That's not what we want when the fb is the current fb for the crtc.
> > > >
> > >
> > > Right, there is my missing point. How about this then? Couldn't  we check
> > > this fb is last one or not? And if last one, it makes fb->crtc keep as
> > is.
> >
> > That won't help, It would just make the behaviour of your code
> > identical to the behaviour of the current code.
> >
> > > > > > So it looks like you're making things worse, not better.
> > > > >
> > > > > Anyway I'll just nack the whole idea. What you need to do is track
> the
> > > > > pending page flips, and make sure the old buffer is not freed too
> > > early.
> > > > > Just grab a reference to the old gem object when issuing the page
> flip,
> > > > > and unref it

[PATCH v7 5/8] fbmon: add videomode helpers

2012-11-09 Thread Steffen Trumtrar

Hi!

On Fri, Nov 09, 2012 at 04:54:16PM +, Manjunathappa, Prakash wrote:
> Hi Steffen,
> 
> On Fri, Nov 09, 2012 at 02:55:45, Steffen Trumtrar wrote:
> > Hi!
> > 
> > On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
> > > Hi Steffen,
> > > 
> > > On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
> > > > +#if IS_ENABLED(CONFIG_VIDEOMODE)
> > > > +int videomode_to_fb_videomode(struct videomode *vm, struct 
> > > > fb_videomode *fbmode)
> > > > +{
> > > > +   fbmode->xres = vm->hactive;
> > > > +   fbmode->left_margin = vm->hback_porch;
> > > > +   fbmode->right_margin = vm->hfront_porch;
> > > > +   fbmode->hsync_len = vm->hsync_len;
> > > > +
> > > > +   fbmode->yres = vm->vactive;
> > > > +   fbmode->upper_margin = vm->vback_porch;
> > > > +   fbmode->lower_margin = vm->vfront_porch;
> > > > +   fbmode->vsync_len = vm->vsync_len;
> > > > +
> > > > +   fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000);
> > > > +
> > > > +   fbmode->sync = 0;
> > > > +   fbmode->vmode = 0;
> > > > +   if (vm->hah)
> > > > +   fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> > > > +   if (vm->vah)
> > > > +   fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> > > > +   if (vm->interlaced)
> > > > +   fbmode->vmode |= FB_VMODE_INTERLACED;
> > > > +   if (vm->doublescan)
> > > > +   fbmode->vmode |= FB_VMODE_DOUBLE;
> > > > +
> > > 
> > > "pixelclk-inverted" property of the panel is not percolated fb_videomode.
> > > Please let me know if I am missing something.
> > > 
> > 
> > The next version is almost finished. Only thing I'm missing is this.
> > And I actually do not know which flag would represent an inverted pixelclock
> > in fb_videomode. Does anybody have any idea what I have to do here?
> > 
> > if (vm->pixelclk_pol)
> > fbmode->sync = ???
> > 
> > That's as far as I have come and I don't see a flag that seems right.
> > Is this even a valid property of fb_videomode?
> > 
> 
> Thanks for considering it, I see IMX addresses it as proprietary FB_SYNC_ 
> flag.
> FB_SYNC_CLK_INVERT: arch/arm/plat-mxc/include/mach/mx3fb.h
> 

No problem. So, it seems this flag has to be set in some imx-specific
videomode_to_fb_videomode function. It is included in the
struct videomode, so that should be no problem. But it will not be
part of this series.

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 26345] [845G] CPU/GPU incoherency

https://bugs.freedesktop.org/show_bug.cgi?id=26345

Chris Wilson  changed:

   What|Removed |Added

 CC||tupone at gentoo.org

--- Comment #151 from Chris Wilson  ---
*** Bug 56933 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/4c937e53/attachment.html>

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

Daniel Vetter  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #94 from Daniel Vetter  ---
Loki, if you have a regression with i830M dvo support, please file a new bug
report. If it's just lack of support for a specific DVO chipset, we can't
really help you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/9d5be4b0/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #17 from Michael Dressel  ---
(In reply to comment #14)
> (In reply to comment #13)


> Maybe it would be easier to just do manual builds instead of using PKGBUILD
> for the bisect? You can point to the directory containing the manually built
> r600_dri.so with the environment variable LIBGL_DRIVERS_PATH. You may also
> want to set LIBGL_DEBUG=verbose to verify it's picking up the expected
> r600_dri.so.

At which point would I need to have the environment setup in order to pick the
driver? Can I just stop gdm set the environment and start gdm with  systemctl?

> 
> Also, especially for older commits, you may need to run make clean or even
> autogen.sh between bisection steps to prevent inconsistent builds.

There are a lot of options. Which are relevant?
COMMONOPTS="--prefix=/usr \
--sysconfdir=/etc \
--with-dri-driverdir=/usr/lib/xorg/modules/dri \
--with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \
--with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \
--enable-gallium-llvm \
--enable-egl \
--enable-gallium-egl \
--with-egl-platforms=x11,drm \
--enable-shared-glapi \
--enable-gbm \
--enable-glx-tls \
--enable-dri \
--enable-glx \
--enable-osmesa \
--enable-gles1 \
--enable-gles2 \
--enable-texture-float \
--enable-xa \
--enable-vdpau "

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/8e7b78a1/attachment.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #16 from Michael Dressel  ---
I compiled the commit 6671d0dad300e591ac7c0e5110c6778373d0149a
which I picked to start bisecting. (I picked it because the date
is related to the date of the 8.0 branch as mentioned above)

It shows the same problem.

In order to get it compiled I had to do the foloowing change:

--- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c
@@ -53,7 +53,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,

switch (ctx->ClientAPI) {
case EGL_OPENGL_ES_API:
-  switch (ctx->ClientVersion) {
+  switch (ctx->ClientMajorVersion) {
   case 1:
  api = ST_API_OPENGL;
  *profile = ST_PROFILE_OPENGL_ES1;
@@ -64,7 +64,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx,
  break;
   default:
  _eglLog(_EGL_WARNING, "unknown client version %d",
-   ctx->ClientVersion);
+   ctx->ClientMajorVersion);
  break;



And I changed my build script in order not to build vdpau and radeonsi
and some other things I beleive are not related to the driver r600 I beleive 
I need.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/4bd7c1b6/attachment-0001.html>

[Bug 56405] Distorted graphics on Radeon HD 6620G

https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #15 from Michael Dressel  ---
I tried to compile c1f4867c89adb1a6b19d66ec8ad146115909f0a7
the commit taged with mesa-8.0.4 and I get the following compilation error:

g++ -c -I. -I../../../src/gallium/include -I../../../src/gallium/auxiliary
-I../../../src/gallium/drivers  -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall
-fno-strict-aliasing -fno-builtin-memcmp -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2  -fPIC 
-D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN
-DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS
-DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -D__STDC_CONSTANT_MACROS
-DHAVE_LLVM=0x0301 -fvisibility=hidden -I/usr/include   -D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
gallivm/lp_bld_debug.cpp -o gallivm/lp_bld_debug.o
gallivm/lp_bld_debug.cpp: In function ?void lp_disassemble(const void*)?:
gallivm/lp_bld_debug.cpp:240:66: error: no matching function for call to
?llvm::Target::createMCInstPrinter(unsigned int&, const llvm::MCAsmInfo&, const
llvm::MCSubtargetInfo&) const?
gallivm/lp_bld_debug.cpp:240:66: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:37:0:
/usr/include/llvm/Support/TargetRegistry.h:395:20: note: llvm::MCInstPrinter*
llvm::Target::createMCInstPrinter(unsigned int, const llvm::MCAsmInfo&, const
llvm::MCInstrInfo&, const llvm::MCRegisterInfo&, const llvm::MCSubtargetInfo&)
const
/usr/include/llvm/Support/TargetRegistry.h:395:20: note:   candidate expects 5
arguments, 3 provided
make[3]: *** [gallivm/lp_bld_debug.o] Error 1
make[3]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium/auxiliary'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/michael/src/Mesa/mesa/src'
make: *** [default] Error 1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/8e9bafe1/attachment.html>

[PATCH] drm: fix drm_framebuffer cleanup.

rm_mode_object base;
>> +   struct drm_crtc *crtc;
>> const struct drm_framebuffer_funcs *funcs;
>> unsigned int pitches[4];
>> unsigned int offsets[4];
>> --
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/a7a753a7/attachment.html>

[PATCH] drm: exynos: fix for loosing display mode header during mode adjustment

This patch is to preserve the display mode header during the mode adjustment.
Display mode header is overwritten with the adjusted mode header which is
throwing the stack dump.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index ee110c9..c7844ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1974,6 +1974,8 @@ static void hdmi_mode_fixup(void *ctx, struct 
drm_connector *connector,
 {
struct drm_display_mode *m;
struct hdmi_context *hdata = ctx;
+   struct drm_mode_object base;
+   struct list_head head;
int index;

DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
@@ -2002,7 +2004,13 @@ static void hdmi_mode_fixup(void *ctx, struct 
drm_connector *connector,
if (index >= 0) {
DRM_INFO("desired mode doesn't exist so\n");
DRM_INFO("use the most suitable mode among modes.\n");
+
+   /* preserve display mode header while copying. */
+   head = adjusted_mode->head;
+   base = adjusted_mode->base;
memcpy(adjusted_mode, m, sizeof(*m));
+   adjusted_mode->head = head;
+   adjusted_mode->base = base;
break;
}
}
-- 
1.7.0.4

[PATCH] drm/exynos: add vm_ops to specific gem mmaper

This patch makes it takes a reference to gem object when
specific gem mmap is requested. For this, it sets
dev->driver->gem_vm_ops to vma->vm_ops.

And this patch is based on exynos-drm-next-iommu branch of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   20 +++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 50d73f1..b7ce8b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -372,10 +372,13 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp,
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buffer;
unsigned long vm_size;
+   int ret;

DRM_DEBUG_KMS("%s\n", __FILE__);

vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
+   vma->vm_private_data = obj;
+   vma->vm_ops = obj->dev->driver->gem_vm_ops;

update_vm_cache_attr(exynos_gem_obj, vma);

@@ -391,9 +394,22 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp,
if (vm_size > buffer->size)
return -EINVAL;

-   return dma_mmap_attrs(obj->dev->dev, vma, buffer->kvaddr,
+   ret = dma_mmap_attrs(obj->dev->dev, vma, buffer->kvaddr,
buffer->dma_addr, buffer->size,
>dma_attrs);
+   if (ret < 0) {
+   DRM_ERROR("failed to mmap.\n");
+   return ret;
+   }
+
+   /*
+* take a reference to this mapping of the object. And this reference
+* is unreferenced by the corresponding vm_close call.
+*/
+   drm_gem_object_reference(obj);
+   drm_vm_open_locked(obj->dev, vma);
+
+   return 0;
 }

 static const struct file_operations exynos_drm_gem_fops = {
@@ -426,6 +442,8 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void 
*data,
addr = vm_mmap(obj->filp, 0, args->size,
PROT_READ | PROT_WRITE, MAP_SHARED, 0);

+   /* restore it to drm_file object. */
+   obj->filp->private_data = file_priv;
drm_gem_object_unreference_unlocked(obj);

if (IS_ERR((void *)addr))
-- 
1.7.4.1

[PATCH] drm/exynos: Add exynos drm specific fb_mmap function

Hi All,

Please review the following patch.

regards,
Rahul Sharma

On Wed, Nov 7, 2012 at 4:38 PM, Rahul Sharma  
wrote:
> From: Prathyush K 
>
> This patch adds a exynos drm specific implementation of fb_mmap
> which supports mapping a non-contiguous buffer to user space.
>
> This new function does not assume that the frame buffer is contiguous
> and calls dma_mmap_writecombine for mapping the buffer to user space.
> dma_mmap_writecombine will be able to map a contiguous buffer as well
> as non-contig buffer depending on whether an IOMMU mapping is created
> for drm or not.
>
> Signed-off-by: Prathyush K 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   26 ++
>  1 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 67eb6ba..3939f7f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -46,8 +46,34 @@ struct exynos_drm_fbdev {
> struct exynos_drm_gem_obj   *exynos_gem_obj;
>  };
>
> +static int exynos_drm_fb_mmap(struct fb_info *info,
> + struct vm_area_struct *vma)
> +{
> +   DRM_DEBUG_KMS("%s\n", __func__);
> +
> +   if (!vma || !info) {
> +   DRM_ERROR("invalid arguments vma 0x%x, info 0x%x.\n",
> +   (unsigned int)vma, (unsigned int)info);
> +   return -EINVAL;
> +   }
> +
> +   if (!info->screen_base || info->screen_size == 0) {
> +   DRM_ERROR("invalid screen information.\n");
> +   return -EINVAL;
> +   }
> +
> +   vma->vm_pgoff = 0;
> +   vma->vm_flags |= VM_IO;
> +   if (dma_mmap_writecombine(info->device, vma, info->screen_base,
> +   info->fix.smem_start, vma->vm_end - vma->vm_start))
> +   return -EAGAIN;
> +
> +   return 0;
> +}
> +
>  static struct fb_ops exynos_drm_fb_ops = {
> .owner  = THIS_MODULE,
> +   .fb_mmap= exynos_drm_fb_mmap,
> .fb_fillrect= cfb_fillrect,
> .fb_copyarea= cfb_copyarea,
> .fb_imageblit   = cfb_imageblit,
> --
> 1.7.0.4
>

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

2012-11-09 Thread Stephen Warren

On 11/09/2012 06:59 AM, Thierry Reding wrote:
> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> support for host1x and the two display controllers found on the Tegra20
> SoC. Each display controller can drive a separate RGB/LVDS output.

I applied these two patches and the two arch/arm/mach-tegra patches you
posted, directly on top of next-20121109, and I see the following build
failure:

> drivers/gpu/drm/tegra/output.c: In function 'tegra_output_init':
> drivers/gpu/drm/tegra/output.c:166:9: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c:166:3: error: implicit declaration of function 
> 'of_get_display'
> drivers/gpu/drm/tegra/output.c:167:20: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c:168:25: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c:179:13: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c:180:3: error: implicit declaration of function 
> 'display_put'
> drivers/gpu/drm/tegra/output.c:180:21: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c:257:20: error: 'struct tegra_output' has no 
> member named 'display'
> drivers/gpu/drm/tegra/output.c: In function 'tegra_output_exit':
> drivers/gpu/drm/tegra/output.c:272:20: error: 'struct tegra_output' has no 
> member named 'display'

Does this depend on something not in linux-next?

[PATCH 2/2] drm: tegra: Add HDMI support

2012-11-09 Thread Christian König

On 09.11.2012 16:45, Rafa? Mi?ecki wrote:
> 2012/11/9 Thierry Reding :
>> +/* all fields little endian */
>> +struct hdmi_audio_infoframe {
>> +   /* PB0 */
>> +   u8 csum;
>> +
>> +   /* PB1 */
>> +   unsigned cc:3; /* channel count */
>> +   unsigned res1:1;
>> +   unsigned ct:4; /* coding type */
>> +
>> +   /* PB2 */
>> +   unsigned ss:2; /* sample size */
>> +   unsigned sf:3; /* sample frequency */
>> +   unsigned res2:3;
>> +
>> +   /* PB3 */
>> +   unsigned cxt:5; /* coding extention type */
>> +   unsigned res3:3;
>> +
>> +   /* PB4 */
>> +   u8 ca; /* channel/speaker allocation */
>> +
>> +   /* PB5 */
>> +   unsigned res5:3;
>> +   unsigned lsv:4; /* level shift value */
>> +   unsigned dm_inh:1; /* downmix inhibit */
>> +
>> +   /* PB6-10 reserved */
>> +   u8 res6;
>> +   u8 res7;
>> +   u8 res8;
>> +   u8 res9;
>> +   u8 res10;
>> +} __packed;
> I was told it won't work on different endian devices. See
> [RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
> http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html

Yeah, that's indeed true. And honestly adding just another 
implementation of the HDMI info frames sounds like somebody should 
finally sit down and implement it in a common drm_hdmi.c

Regards,
Christian.

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

d getresources again.  The unregister is
> what I worry about more.
> 
> In general drm isn't set up to well for drivers that are a collection
> of sub-devices.  It is probably worth trying to improve this, although
> I am still a bit skittish about the edge cases, like what happens when
> you unload a sub-device mid-modeset.  The issue comes up again for
> common panel/display framework.
> 
> But for now you might just want to do something to ensure that all the
> sub-devices are loaded/unloaded together as a whole.

The way that the above is supposed to work is that the DRM relevant
host1x clients are kept in a separate list and only if all of them have
successfully been probed is the DRM portion initialized. Upon
unregistration, as soon as the first of these clients is unregistered,
all of the DRM stuff is torn down.

I don't believe there's an issue here. It's precisely what I've been
testing for a while, always making sure that when built as a module it
can properly be unloaded.

That said it probably won't matter very much since on Tegra all drivers
are usually builtin, so none of this may even be used in the end.

Thanks for the quick review.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/08b664a7/attachment.pgp>

[PATCH v7 5/8] fbmon: add videomode helpers

2012-11-09 Thread Manjunathappa, Prakash

Hi Steffen,

On Fri, Nov 09, 2012 at 02:55:45, Steffen Trumtrar wrote:
> Hi!
> 
> On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
> > Hi Steffen,
> > 
> > On Wed, Oct 31, 2012 at 14:58:05, Steffen Trumtrar wrote:
> > > +#if IS_ENABLED(CONFIG_VIDEOMODE)
> > > +int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode 
> > > *fbmode)
> > > +{
> > > + fbmode->xres = vm->hactive;
> > > + fbmode->left_margin = vm->hback_porch;
> > > + fbmode->right_margin = vm->hfront_porch;
> > > + fbmode->hsync_len = vm->hsync_len;
> > > +
> > > + fbmode->yres = vm->vactive;
> > > + fbmode->upper_margin = vm->vback_porch;
> > > + fbmode->lower_margin = vm->vfront_porch;
> > > + fbmode->vsync_len = vm->vsync_len;
> > > +
> > > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock / 1000);
> > > +
> > > + fbmode->sync = 0;
> > > + fbmode->vmode = 0;
> > > + if (vm->hah)
> > > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> > > + if (vm->vah)
> > > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> > > + if (vm->interlaced)
> > > + fbmode->vmode |= FB_VMODE_INTERLACED;
> > > + if (vm->doublescan)
> > > + fbmode->vmode |= FB_VMODE_DOUBLE;
> > > +
> > 
> > "pixelclk-inverted" property of the panel is not percolated fb_videomode.
> > Please let me know if I am missing something.
> > 
> 
> The next version is almost finished. Only thing I'm missing is this.
> And I actually do not know which flag would represent an inverted pixelclock
> in fb_videomode. Does anybody have any idea what I have to do here?
> 
>   if (vm->pixelclk_pol)
>   fbmode->sync = ???
> 
> That's as far as I have come and I don't see a flag that seems right.
> Is this even a valid property of fb_videomode?
> 

Thanks for considering it, I see IMX addresses it as proprietary FB_SYNC_ flag.
FB_SYNC_CLK_INVERT: arch/arm/plat-mxc/include/mach/mx3fb.h

Thanks,
Prakash

[PATCH 2/2] drm: tegra: Add HDMI support

2012-11-09 Thread Rafał Miłecki

2012/11/9 Thierry Reding :
> +/* all fields little endian */
> +struct hdmi_audio_infoframe {
> +   /* PB0 */
> +   u8 csum;
> +
> +   /* PB1 */
> +   unsigned cc:3; /* channel count */
> +   unsigned res1:1;
> +   unsigned ct:4; /* coding type */
> +
> +   /* PB2 */
> +   unsigned ss:2; /* sample size */
> +   unsigned sf:3; /* sample frequency */
> +   unsigned res2:3;
> +
> +   /* PB3 */
> +   unsigned cxt:5; /* coding extention type */
> +   unsigned res3:3;
> +
> +   /* PB4 */
> +   u8 ca; /* channel/speaker allocation */
> +
> +   /* PB5 */
> +   unsigned res5:3;
> +   unsigned lsv:4; /* level shift value */
> +   unsigned dm_inh:1; /* downmix inhibit */
> +
> +   /* PB6-10 reserved */
> +   u8 res6;
> +   u8 res7;
> +   u8 res8;
> +   u8 res9;
> +   u8 res10;
> +} __packed;

I was told it won't work on different endian devices. See
[RFC][PATCH] drm/radeon/hdmi: define struct for AVI infoframe
http://lists.freedesktop.org/archives/dri-devel/2012-May/022544.html

-- 
Rafa?

[PATCH] drm/exynos: fix linux framebuffer address setting.

With iommu, buffer->dma_addr has device addres so this patch
fixes for physical address to be set to fix.smem_start always.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 67eb6ba..e7466c4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -87,7 +87,8 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
fbi->screen_base = buffer->kvaddr + offset;
-   fbi->fix.smem_start = (unsigned long)(buffer->dma_addr + offset);
+   fbi->fix.smem_start = (unsigned long)(page_to_phys(buffer->pages[0]) +
+   offset);
fbi->screen_size = size;
fbi->fix.smem_len = size;

-- 
1.7.4.1

[PATCH] drm: fix drm_framebuffer cleanup.

This patch fixes access issue to invalid memory region.

crtc had only one drm_framebuffer object so when framebuffer
cleanup was requested after page flip, it'd try to disable
hardware overlay to current crtc.
But if current crtc points to another drm_framebuffer,
This may induce invalid memory access.

Assume that some application are doing page flip with two
drm_framebuffer objects. At this time, if second drm_framebuffer
is set to current crtc and the cleanup to first drm_framebuffer
is requested once drm release is requested, then first
drm_framebuffer would be cleaned up without disabling
hardware overlay because current crtc points to second
drm_framebuffer. After that, gem buffer to first drm_framebuffer
would be released and this makes dma access invalid memory region.

This patch adds drm_framebuffer to drm_crtc structure as member
and makes drm_framebuffer_cleanup function check if fb->crtc is
same as desired fb. And also when setcrtc and pageflip are
requested, it makes each drm_framebuffer point to current crtc.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/drm_crtc.c |7 ---
 include/drm/drm_crtc.h |1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ef1b221..5c04bd4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -386,7 +386,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)

/* remove from any CRTC */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   if (crtc->fb == fb) {
+   if (fb->crtc == crtc) {
/* should turn off the crtc */
memset(, 0, sizeof(struct drm_mode_set));
set.crtc = crtc;
@@ -2027,6 +2027,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.mode = mode;
set.connectors = connector_set;
set.num_connectors = crtc_req->count_connectors;
+   fb->crtc = crtc;
set.fb = fb;
ret = crtc->funcs->set_config();

@@ -3635,8 +3636,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
spin_unlock_irqrestore(>event_lock, flags);
kfree(e);
}
-   }
-
+   } else
+   fb->crtc = crtc;
 out:
mutex_unlock(>mode_config.mutex);
return ret;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3fa18b7..92889be 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -256,6 +256,7 @@ struct drm_framebuffer {
struct kref refcount;
struct list_head head;
struct drm_mode_object base;
+   struct drm_crtc *crtc;
const struct drm_framebuffer_funcs *funcs;
unsigned int pitches[4];
unsigned int offsets[4];
-- 
1.7.4.1

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 09, 2012 at 11:04:58PM +0900, Inki Dae wrote:
> 2012/11/9 Ville Syrj?l? 
> 
> > On Fri, Nov 09, 2012 at 09:41:19PM +0900, Inki Dae wrote:
> > > 2012/11/9 Ville Syrj?l? 
> > >
> > > > On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> > > > > This patch fixes access issue to invalid memory region.
> > > > >
> > > > > crtc had only one drm_framebuffer object so when framebuffer
> > > > > cleanup was requested after page flip, it'd try to disable
> > > > > hardware overlay to current crtc.
> > > > > But if current crtc points to another drm_framebuffer,
> > > > > This may induce invalid memory access.
> > > > >
> > > > > Assume that some application are doing page flip with two
> > > > > drm_framebuffer objects. At this time, if second drm_framebuffer
> > > > > is set to current crtc and the cleanup to first drm_framebuffer
> > > > > is requested once drm release is requested, then first
> > > > > drm_framebuffer would be cleaned up without disabling
> > > > > hardware overlay because current crtc points to second
> > > > > drm_framebuffer. After that, gem buffer to first drm_framebuffer
> > > > > would be released and this makes dma access invalid memory region.
> > > > >
> > > > > This patch adds drm_framebuffer to drm_crtc structure as member
> > > >
> > > > That is exactly the reverse of what you're doing in the patch.
> > > > We already have crtc.fb, and you're adding fb.crtc.
> > > >
> > > > > and makes drm_framebuffer_cleanup function check if fb->crtc is
> > > > > same as desired fb. And also when setcrtc and pageflip are
> > > > > requested, it makes each drm_framebuffer point to current crtc.
> > > >
> > > > Looks like you're just setting the crtc.fb and fb.crtc pointers to
> > > > exactly mirror each other in the page flip ioctl. That can't fix
> > > > anything.
> > > >
> > > >
> > > At least, when drm is released, the crtc to framebuffer that was recently
> > > used for scanout can be disabled correctly.
> >
> > Let's take this scenario:
> >
> > setcrtc(crtc0, fb0)
> >  -> crtc0.fb = fb0, fb0.crtc = crtc0
> > page_flip(crtc0, fb1)
> >  -> crtc0.fb = fb1, fb1.crtc = crtc0
> > rmfb(fb0)
> >  -> ?
> >
> > The rmfb() will now disable crtc0 because fb0.crtc == crtc0, but
> > let's consider this just a bug and ignore it for now. So let's assume
> > that crtc0 won't be disabled when we call rmfb(fb0).
> >
> >
> Ok, Please assume that my patch includes the below codes. when we call
> rmfb(fb0), fb0->crtc is NULL. so fb0 will be freed without disabling crtc.
> 
> int drm_mode_rmfb(struct drm_device *dev, void *data, struct drm_file
> *file_priv) {
> 
> fb->crtc = NULL;
> fb->funcs->destroy(fb);
> out:
> ...
> }

As stated above, I already assumed that.

> > The real question is, how would your patch help? You can't free fb0
> > until the page flip has occured, and your patch doesn't track page
> > flips, so how can it do anything useful?
> >
> > > > First of all multiple crtcs can scan out from the same fb, so a single
> > > > fb.crtc pointer is clearly not enough to represent the relationship
> > > > between fbs and crtcs.
> > > >
> > > > Also you're not clearing the fb.crtc pointer anywhere, so now
> > > > destroying any framebuffer that was once used for scanout, would
> > disable
> > > > some crtc.
> > > >
> > > >
> > > It looks like that you missed my previous comment. Plaese, see the
> > previous
> > > comment. And that was already pointed out by Prathyush. fb.crtc will be
> > > cleared at drm_mode_rmfb(). With this, is there my missing point?  I
> > really
> > > wonder that with this patch, drm framwork could be faced with any
> > problem.
> >
> > If you clear the fb.crtc pointer before destroying the fb, then you
> > never disable any crtcs in response to removing a framebuffer.
> > That's not what we want when the fb is the current fb for the crtc.
> >
> 
> Right, there is my missing point. How about this then? Couldn't  we check
> this fb is last one or not? And if last one, it makes fb->crtc keep as is.

That won't help, It would just make the behaviour of your code
identical to the behaviour of the current code.

> > > > So it looks like you're making things worse, not better.
> > > >
> > > > Anyway I'll just nack the whole idea. What you need to do is track the
> > > > pending page flips, and make sure the old buffer is not freed too
> > early.
> > > > Just grab a reference to the old gem object when issuing the page flip,
> > > > and unref it when you're sure the flip has occured. Or you could use
> > the
> > > > new drm_framebuffer refcount, but personally I don't see much point in
> > > > that when you already have the gem object refcount at your disposal.
> > > >
> > > >
> > > >
> > >
> > > And it seems like that your saying is that each specific drivers
> > > should resolve this issue(access to invalid memory region) tracking the
> > > pending page flip. But I think that this issue may be a missing point drm
> > > framework missed so specific drivers is

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 09, 2012 at 09:41:19PM +0900, Inki Dae wrote:
> 2012/11/9 Ville Syrj?l? 
> 
> > On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> > > This patch fixes access issue to invalid memory region.
> > >
> > > crtc had only one drm_framebuffer object so when framebuffer
> > > cleanup was requested after page flip, it'd try to disable
> > > hardware overlay to current crtc.
> > > But if current crtc points to another drm_framebuffer,
> > > This may induce invalid memory access.
> > >
> > > Assume that some application are doing page flip with two
> > > drm_framebuffer objects. At this time, if second drm_framebuffer
> > > is set to current crtc and the cleanup to first drm_framebuffer
> > > is requested once drm release is requested, then first
> > > drm_framebuffer would be cleaned up without disabling
> > > hardware overlay because current crtc points to second
> > > drm_framebuffer. After that, gem buffer to first drm_framebuffer
> > > would be released and this makes dma access invalid memory region.
> > >
> > > This patch adds drm_framebuffer to drm_crtc structure as member
> >
> > That is exactly the reverse of what you're doing in the patch.
> > We already have crtc.fb, and you're adding fb.crtc.
> >
> > > and makes drm_framebuffer_cleanup function check if fb->crtc is
> > > same as desired fb. And also when setcrtc and pageflip are
> > > requested, it makes each drm_framebuffer point to current crtc.
> >
> > Looks like you're just setting the crtc.fb and fb.crtc pointers to
> > exactly mirror each other in the page flip ioctl. That can't fix
> > anything.
> >
> >
> At least, when drm is released, the crtc to framebuffer that was recently
> used for scanout can be disabled correctly.

Let's take this scenario:

setcrtc(crtc0, fb0)
 -> crtc0.fb = fb0, fb0.crtc = crtc0
page_flip(crtc0, fb1)
 -> crtc0.fb = fb1, fb1.crtc = crtc0
rmfb(fb0)
 -> ?

The rmfb() will now disable crtc0 because fb0.crtc == crtc0, but
let's consider this just a bug and ignore it for now. So let's assume
that crtc0 won't be disabled when we call rmfb(fb0).

The real question is, how would your patch help? You can't free fb0
until the page flip has occured, and your patch doesn't track page
flips, so how can it do anything useful?

> > First of all multiple crtcs can scan out from the same fb, so a single
> > fb.crtc pointer is clearly not enough to represent the relationship
> > between fbs and crtcs.
> >
> > Also you're not clearing the fb.crtc pointer anywhere, so now
> > destroying any framebuffer that was once used for scanout, would disable
> > some crtc.
> >
> >
> It looks like that you missed my previous comment. Plaese, see the previous
> comment. And that was already pointed out by Prathyush. fb.crtc will be
> cleared at drm_mode_rmfb(). With this, is there my missing point?  I really
> wonder that with this patch, drm framwork could be faced with any problem.

If you clear the fb.crtc pointer before destroying the fb, then you
never disable any crtcs in response to removing a framebuffer.
That's not what we want when the fb is the current fb for the crtc.

> > So it looks like you're making things worse, not better.
> >
> > Anyway I'll just nack the whole idea. What you need to do is track the
> > pending page flips, and make sure the old buffer is not freed too early.
> > Just grab a reference to the old gem object when issuing the page flip,
> > and unref it when you're sure the flip has occured. Or you could use the
> > new drm_framebuffer refcount, but personally I don't see much point in
> > that when you already have the gem object refcount at your disposal.
> >
> >
> >
> 
> And it seems like that your saying is that each specific drivers
> should resolve this issue(access to invalid memory region) tracking the
> pending page flip. But I think that this issue may be a missing point drm
> framework missed so specific drivers is processing this instead. And with
> this patch, couldn't some codes you mentioned be removed from specific
> drivers? because it doesn't need to track the pending page flips and
> relevant things anymore.
> 
> There may be my missing point. I'd welcome to any comments and advices.

If you don't track the page flips somehow, you can't safely free the
previous buffer. It's that simple. You can of course make some of
that code generic enough to be shared between drivers. That is
actually what the drm_flip mechanism that I wrote for atomic page
flips is; a reasonably generic helper for tracking page flips.

-- 
Ville Syrj?l?
Intel OTC

[Bug 56918] [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

--- Comment #4 from madbiologist  ---
Created attachment 69823
  --> https://bugs.freedesktop.org/attachment.cgi?id=69823=edit
radeon debug output

Thanks.  Attached file is from using Google MapsGL on Firefox 16.0.2 with Mesa
9.0.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/0d5558b8/attachment.html>

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

2012-11-09 Thread Stephen Warren

On 11/09/2012 06:59 AM, Thierry Reding wrote:
> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> support for host1x and the two display controllers found on the Tegra20
> SoC. Each display controller can drive a separate RGB/LVDS output.

> diff --git 
> a/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt 
> b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
> new file mode 100644
> index 000..b4fa934
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt

"drm" is a Linux-specific term, so shouldn't really be used as the
directory name for a binding. bindings/gpu/nvidia,tegra20-host1x.txt
would probably be just fine.

Aside from that, the bindings,
Acked-by: Stephen Warren 

I don't really know anything about DRM or our display HW, so I haven't
reviewed the code at all. I certainly ack the concept of adding the
driver though! I have asked various other people at NVIDIA to give a
quick review of the code.

[PATCH 46/51] drm/i915: Add support for atomic modesetting completion events

On Fri, Nov 9, 2012 at 3:20 PM, Daniel Vetter  wrote:
> On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote:
>> On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter  wrote:
>> > On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote:
>> >> On Thu, 1 Nov 2012 19:07:02 +0200
>> >> Ville Syrj?l?  wrote:
>> >>
>> >> > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote:
>> >> > > On Thu, 1 Nov 2012 12:12:35 +0100
>> >> > > Daniel Vetter  wrote:
>> >> > >
>> >> > > > On Thu, Oct 25, 2012 at 8:05 PM,  > >> > > > linux.intel.com> wrote:
>> >> > > > > From: Ville Syrj?l? 
>> >> > > > >
>> >> > > > > Send completion events when the atomic modesetting operations has
>> >> > > > > finished succesfully.
>> >> > > > >
>> >> > > > > Signed-off-by: Ville Syrj?l? 
>> >> > > >
>> >> > > > I have to admit I'm not on top of the latest ioctl/interface
>> >> > > > discussion, but one new requirement for the modeset (not the 
>> >> > > > pageflip
>> >> > > > part) of the all this atomic stuff I've discovered is that the 
>> >> > > > kernel
>> >> > > > needs to be able to select the crtcs for each output completely
>> >> > > > unrestricted. I think userspace should simply pass in abstract crtc
>> >> > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual
>> >> > > > crtcs it has selected.
>> >> > > >
>> >> > > > We can't do that remapping internally because the crtc abstraction 
>> >> > > > is leaky:
>> >> > > > - wait_for_vblank requires the pipe id, which could then change on 
>> >> > > > every modeset
>> >> > > > - similarly userspace doing MI_WAIT for scanlines needs to know the
>> >> > > > actual hw pipe in use by a crtc.
>> >> > > > And current userspace presumes that the mapping between crtc->pipe
>> >> > > > doesn't change.
>>
>> I don't know if it is possible, but it would be nice to try to clean
>> up crtc<->pipe stuff..  userspace, at least modetest, assumes crtc ==
>> crtc_list[pipe].  But I haven't noticed yet anywhere that this
>> relationship is documented.  And if you are thinking about doing what
>> I think you are thinking about doing, then this assumption would no
>> longer hold for i915.
>
> This relationship does already no longer hold on i915 - on gen3 at least
> we sometimes switch the crtc->pipe assignement (to make fbc more useful),
> which means even with todays code userspace cannot assume (when running on
> i915), that the vblank pipe satisfies crtc == crtc_list[pipe].

hmm, how does this not break weston compositor-drm (and modetest w/
vsync'd flipping.. although I suppose that is a less important
use-case)

>> How frequently do you emit waits for scanline?  Places where the pipe
>> # ends up in cmdstream, would it be too crazy to handle that like a
>> reloc where the kernel goes and fixes up the actual value in the
>> cmdstream as it does it's GEM reloc pass?  If you did this then you
>> could virtualize pipe as well as crtc.
>
> Every dri2 copyregion or Xv upload to the frontbuffer on pre-gen6 will use
> it. And we need old userspace to keep on working - presumably the fb layer
> will switch to using the new atomic modeset stuff (if available) to figure
> out an optimal config, so this is relevant.

yeah, not quite sure how the backwards-compat should work.. you'd have
to somehow only dynamically reassign crtcs if you could tell that
userspace is new enough to cope..

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] ARM: add get_user() support for 8 byte types

From: Rob Clark 

A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).

Signed-off-by: Rob Clark 
---
 arch/arm/include/asm/uaccess.h | 25 -
 arch/arm/lib/getuser.S | 17 -
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7e1f760..2e3fdb2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
 extern int __get_user_1(void *);
 extern int __get_user_2(void *);
 extern int __get_user_4(void *);
+extern int __get_user_8(void *);

 #define __GUP_CLOBBER_1"lr", "cc"
 #ifdef CONFIG_CPU_USE_DOMAINS
@@ -108,6 +109,7 @@ extern int __get_user_4(void *);
 #define __GUP_CLOBBER_2 "lr", "cc"
 #endif
 #define __GUP_CLOBBER_4"lr", "cc"
+#define __GUP_CLOBBER_8"lr", "cc"

 #define __get_user_x(__r2,__p,__e,__l,__s) \
   __asm__ __volatile__ (   \
@@ -122,22 +124,35 @@ extern int __get_user_4(void *);
({  \
unsigned long __limit = current_thread_info()->addr_limit - 1; \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
-   register unsigned long __r2 asm("r2");  \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \
switch (sizeof(*(__p))) {   \
-   case 1: \
+   case 1: {   \
+   register unsigned long __r2 asm("r2");  \
__get_user_x(__r2, __p, __e, __l, 1);   \
+   x = (typeof(*(p))) __r2;\
break;  \
-   case 2: \
+   }   \
+   case 2: {   \
+   register unsigned long __r2 asm("r2");  \
__get_user_x(__r2, __p, __e, __l, 2);   \
+   x = (typeof(*(p))) __r2;\
break;  \
-   case 4: \
+   }   \
+   case 4: {   \
+   register unsigned long __r2 asm("r2");  \
__get_user_x(__r2, __p, __e, __l, 4);   \
+   x = (typeof(*(p))) __r2;\
+   break;  \
+   }   \
+   case 8: {   \
+   register unsigned long long __r2 asm("r2"); \
+   __get_user_x(__r2, __p, __e, __l, 8);   \
+   x = (typeof(*(p))) __r2;\
break;  \
+   }   \
default: __e = __get_user_bad(); break; \
}   \
-   x = (typeof(*(p))) __r2;\
__e;\
})

diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..d05285c 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
  * Inputs: r0 contains the address
  * r1 contains the address limit, which must be preserved
  * Outputs:r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
  * lr corrupted
  *
  * No other registers must be altered.  (see 
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
 ENDPROC(__get_user_4)

+ENTRY(__get_user_8)
+   check_uaccess r0, 4, r1, r2, __get_user_bad
+#ifdef CONFIG_THUMB2_KERNEL
+5: TUSER(ldr)  r2, [r0]
+6: TUSER(ldr)  r3, [r0, #4]
+#else
+5: TUSER(ldr)  r2, [r0], #4
+6: TUSER(ldr)  r3, [r0]
+#endif
+   mov r0, #0
+   mov pc, lr
+ENDPROC(__get_user_8)
+
 __get_user_bad:
mov r2, #0
mov r0, #-EFAULT
@@

[Bug 54767] [r300g] 298 failures on WebGL Conformance Test

https://bugs.freedesktop.org/show_bug.cgi?id=54767

--- Comment #8 from madbiologist  ---
Created attachment 69819
  --> https://bugs.freedesktop.org/attachment.cgi?id=69819=edit
atan(vec4, vec4) image result

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/434c72ff/attachment.html>

[Bug 54767] [r300g] 298 failures on WebGL Conformance Test

https://bugs.freedesktop.org/show_bug.cgi?id=54767

--- Comment #7 from madbiologist  ---
Created attachment 69818
  --> https://bugs.freedesktop.org/attachment.cgi?id=69818=edit
error messages from test

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/d09012fc/attachment.html>

[Bug 54767] [r300g] 298 failures on WebGL Conformance Test

https://bugs.freedesktop.org/show_bug.cgi?id=54767

--- Comment #6 from madbiologist  ---
Its totally wrong.  See attachments.  I just thought perhaps it wasn't
implemented yet/correctly in the r300g driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/aafb00e4/attachment.html>

[PATCH 2/2] drm: tegra: Add HDMI support

This commit adds support for the HDMI output on the Tegra20 SoC. Only
one such output is available, but it can be driven by either of the two
display controllers.

A lot of work on this patch has been contributed by NVIDIA's Mark Zhang
 and many other people at NVIDIA were very helpful in
getting the HDMI support and surrounding infrastructure to work.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/Makefile |2 +-
 drivers/gpu/drm/tegra/drm.h|2 +
 drivers/gpu/drm/tegra/hdmi.c   | 1290 
 drivers/gpu/drm/tegra/hdmi.h   |  575 ++
 drivers/gpu/drm/tegra/host1x.c |8 +
 5 files changed, 1876 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tegra/hdmi.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.h

diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 624a807..80f73d1 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -2,6 +2,6 @@ ccflags-y := -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG

 tegra-drm-y := drm.o fb.o dc.o host1x.o
-tegra-drm-y += output.o rgb.o
+tegra-drm-y += output.o rgb.o hdmi.o

 obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 7334b68..03cb06f 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -133,6 +133,7 @@ struct tegra_output_ops {

 enum tegra_output_type {
TEGRA_OUTPUT_RGB,
+   TEGRA_OUTPUT_HDMI,
 };

 struct tegra_output {
@@ -227,6 +228,7 @@ extern int tegra_drm_fb_init(struct drm_device *drm);
 extern void tegra_drm_fb_exit(struct drm_device *drm);

 extern struct platform_driver tegra_host1x_driver;
+extern struct platform_driver tegra_hdmi_driver;
 extern struct platform_driver tegra_dc_driver;
 extern struct drm_driver tegra_drm_driver;

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
new file mode 100644
index 000..907a855
--- /dev/null
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -0,0 +1,1290 @@
+/*
+ * Copyright (C) 2012 Avionic Design GmbH
+ * Copyright (C) 2012 NVIDIA CORPORATION.  All rights reserved.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "hdmi.h"
+#include "drm.h"
+#include "dc.h"
+
+struct tegra_hdmi {
+   struct host1x_client client;
+   struct tegra_output output;
+   struct device *dev;
+
+   struct regulator *vdd;
+   struct regulator *pll;
+
+   void __iomem *regs;
+   unsigned int irq;
+
+   struct clk *clk_parent;
+   struct clk *clk;
+
+   unsigned int audio_source;
+   unsigned int audio_freq;
+   bool stereo;
+   bool dvi;
+
+   struct dentry *debugfs;
+};
+
+static inline struct tegra_hdmi *
+host1x_client_to_hdmi(struct host1x_client *client)
+{
+   return container_of(client, struct tegra_hdmi, client);
+}
+
+static inline struct tegra_hdmi *to_hdmi(struct tegra_output *output)
+{
+   return container_of(output, struct tegra_hdmi, output);
+}
+
+#define HDMI_AUDIOCLK_FREQ 21600
+#define HDMI_REKEY_DEFAULT 56
+
+enum {
+   AUTO = 0,
+   SPDIF,
+   HDA,
+};
+
+static inline unsigned long tegra_hdmi_readl(struct tegra_hdmi *hdmi,
+unsigned long reg)
+{
+   return readl(hdmi->regs + (reg << 2));
+}
+
+static inline void tegra_hdmi_writel(struct tegra_hdmi *hdmi, unsigned long 
val,
+unsigned long reg)
+{
+   writel(val, hdmi->regs + (reg << 2));
+}
+
+struct tegra_hdmi_audio_config {
+   unsigned int pclk;
+   unsigned int n;
+   unsigned int cts;
+   unsigned int aval;
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_32k[] = {
+   {  2520, 4096,  25200, 24000 },
+   {  2700, 4096,  27000, 24000 },
+   {  7425, 4096,  74250, 24000 },
+   { 14850, 4096, 148500, 24000 },
+   { 0,0,  0, 0 },
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_44_1k[] = {
+   {  2520, 5880,  26250, 25000 },
+   {  2700, 5880,  28125, 25000 },
+   {  7425, 4704,  61875, 2 },
+   { 14850, 4704, 123750, 2 },
+   { 0,0,  0, 0 },
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_48k[] = {
+   {  2520, 6144,  25200, 24000 },
+   {  2700, 6144,  27000, 24000 },
+   {  7425, 6144,  74250, 24000 },
+   { 14850, 6144, 148500, 24000 },
+   { 0,0,  0, 0 },
+};
+
+static const struct tegra_hdmi_audio_config tegra_hdmi_audio_88_2k[] = {
+   {  2520, 11760,  26250, 25000 },
+   {  2700, 11760,  28125, 25000 },
+

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS output.

Signed-off-by: Thierry Reding 
---
 .../bindings/gpu/drm/nvidia,tegra20-host1x.txt | 191 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tegra/Kconfig  |  23 +
 drivers/gpu/drm/tegra/Makefile |   7 +
 drivers/gpu/drm/tegra/dc.c | 817 +
 drivers/gpu/drm/tegra/dc.h | 384 ++
 drivers/gpu/drm/tegra/drm.c| 115 +++
 drivers/gpu/drm/tegra/drm.h| 233 ++
 drivers/gpu/drm/tegra/fb.c |  56 ++
 drivers/gpu/drm/tegra/host1x.c | 313 
 drivers/gpu/drm/tegra/output.c | 275 +++
 drivers/gpu/drm/tegra/rgb.c| 200 +
 13 files changed, 2617 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
 create mode 100644 drivers/gpu/drm/tegra/Kconfig
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 create mode 100644 drivers/gpu/drm/tegra/dc.c
 create mode 100644 drivers/gpu/drm/tegra/dc.h
 create mode 100644 drivers/gpu/drm/tegra/drm.c
 create mode 100644 drivers/gpu/drm/tegra/drm.h
 create mode 100644 drivers/gpu/drm/tegra/fb.c
 create mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/drm/tegra/output.c
 create mode 100644 drivers/gpu/drm/tegra/rgb.c

diff --git 
a/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
new file mode 100644
index 000..b4fa934
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
@@ -0,0 +1,191 @@
+NVIDIA Tegra host1x
+
+Required properties:
+- compatible: "nvidia,tegra-host1x"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- #address-cells: The number of cells used to represent physical base addresses
+  in the host1x address space. Should be 1.
+- #size-cells: The number of cells used to represent the size of an address
+  range in the host1x address space. Should be 1.
+- ranges: The mapping of the host1x address space to the CPU address space.
+
+The host1x top-level node defines a number of children, each representing one
+of the following host1x client modules:
+
+- mpe: video encoder
+
+  Required properties:
+  - compatible: "nvidia,tegra-mpe"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- vi: video input
+
+  Required properties:
+  - compatible: "nvidia,tegra-vi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- epp: encoder pre-processor
+
+  Required properties:
+  - compatible: "nvidia,tegra-epp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- isp: image signal processor
+
+  Required properties:
+  - compatible: "nvidia,tegra-isp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- gr2d: 2D graphics engine
+
+  Required properties:
+  - compatible: "nvidia,tegra-gr2d"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+- gr3d: 3D graphics engine
+
+  Required properties:
+  - compatible: "nvidia,tegra-gr3d"
+  - reg: Physical base address and length of the controller's registers.
+
+- dc: display controller
+
+  Required properties:
+  - compatible: "nvidia,tegra-dc"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+
+  Each display controller node has a child node, named "rgb", that represents
+  the RGB output associated with the controller. It can take the following
+  optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+  - nvidia,edid: supplies a binary EDID blob
+
+- hdmi: High Definition Multimedia Interface
+
+  Required properties:
+  - compatible: "nvidia,tegra-hdmi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+  - vdd-supply: regulator for supply voltage
+  - pll-supply: regulator for PLL
+
+  Optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  -

[PATCH 0/2] NVIDIA Tegra DRM driver

Hi,

This small set of patches adds support for the host1x and a subset of
the display controller hardware available on NVIDIA Tegra SoCs.

The first patch makes the RGB output available, which is directly driven
by its parent display controller and usually connected to an LVDS bridge
in embedded and notebook applications.

The second patch adds support for the HDMI output which can be driven by
any of the two display controllers.

This set of patches uses the GEM/CMA and KMS/FB helpers by Sascha Hauer
and Lars-Peter Clausen respectively.

Note that the driver is fully functional, but a few things are still
missing from this series because they depend on other patches that have
not been included in mainline yet. One such series is Steffen Trumtrar's
display helper series that allows the display modes to be defined within
the device tree, which comes in handy for embedded applications. What's
also missing from this series is the glue to wire up a backlight device
with a DRM connector so that the backlight can be switched on and off at
the proper time. I will submit incremental patches as the dependencies
make it into Linus' tree.

There is a full set of patches available in the tegra/next branch of my
repository on gitorious[0]. I know that a few people have already tested
the code on that branch, which has been very helpful in ironing out some
of the final details.

I fully realize that this is awfully late, but I still hope to get this
in for 3.8. I've talked about this with David Airlie and he said if I
can get the patches reviewed sometime before 3.7-rc6 or 3.7-rc7 by some
people of the embedded DRM crowd he may take them into the 3.8 merge
window. That would leave about 2 weeks for review, so if anybody could
find the time to look at this code that'd be great.

During the development of this series I've received a lot of feedback
and many helpful suggestions from the people at NVIDIA, so I owe them
big thanks.

Thierry

[0]: git://gitorious.org/thierryreding/linux.git

Thierry Reding (2):
  drm: Add NVIDIA Tegra20 support
  drm: tegra: Add HDMI support

 .../bindings/gpu/drm/nvidia,tegra20-host1x.txt |  191 +++
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/tegra/Kconfig  |   23 +
 drivers/gpu/drm/tegra/Makefile |7 +
 drivers/gpu/drm/tegra/dc.c |  817 +
 drivers/gpu/drm/tegra/dc.h |  384 ++
 drivers/gpu/drm/tegra/drm.c|  115 ++
 drivers/gpu/drm/tegra/drm.h|  235 
 drivers/gpu/drm/tegra/fb.c |   56 +
 drivers/gpu/drm/tegra/hdmi.c   | 1290 
 drivers/gpu/drm/tegra/hdmi.h   |  575 +
 drivers/gpu/drm/tegra/host1x.c |  321 +
 drivers/gpu/drm/tegra/output.c |  275 +
 drivers/gpu/drm/tegra/rgb.c|  200 +++
 15 files changed, 4492 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
 create mode 100644 drivers/gpu/drm/tegra/Kconfig
 create mode 100644 drivers/gpu/drm/tegra/Makefile
 create mode 100644 drivers/gpu/drm/tegra/dc.c
 create mode 100644 drivers/gpu/drm/tegra/dc.h
 create mode 100644 drivers/gpu/drm/tegra/drm.c
 create mode 100644 drivers/gpu/drm/tegra/drm.h
 create mode 100644 drivers/gpu/drm/tegra/fb.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.c
 create mode 100644 drivers/gpu/drm/tegra/hdmi.h
 create mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/drm/tegra/output.c
 create mode 100644 drivers/gpu/drm/tegra/rgb.c

-- 
1.8.0

[Bug 56918] [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

--- Comment #3 from Tom Stellard  ---
(In reply to comment #2)
> How do I set that?  In the GRUB kernel boot options?  Or with "setenv"?  And
> where do I look for the debugging output?  dmesg?  Xorg.log?  Or somewhere
> else?

Open a terminal a start firefox like this:

RADEON_DEBUG=fp,vp firefox &>mapsgl.log

Then do some stuff with MapsGL, close firefox and post the mapsgl.log file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/40fd47e5/attachment.html>

[Bug 56918] [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

--- Comment #2 from madbiologist  ---
How do I set that?  In the GRUB kernel boot options?  Or with "setenv"?  And
where do I look for the debugging output?  dmesg?  Xorg.log?  Or somewhere
else?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/b4f80ae6/attachment.html>

[PATCH] drm: fix drm_framebuffer cleanup.

2012-11-09 Thread Prathyush K

On Fri, Nov 9, 2012 at 1:09 PM, Inki Dae  wrote:

> This patch fixes access issue to invalid memory region.
>
> crtc had only one drm_framebuffer object so when framebuffer
> cleanup was requested after page flip, it'd try to disable
> hardware overlay to current crtc.
> But if current crtc points to another drm_framebuffer,
> This may induce invalid memory access.
>
> Assume that some application are doing page flip with two
> drm_framebuffer objects. At this time, if second drm_framebuffer
> is set to current crtc and the cleanup to first drm_framebuffer
> is requested once drm release is requested, then first
> drm_framebuffer would be cleaned up without disabling
> hardware overlay because current crtc points to second
> drm_framebuffer. After that, gem buffer to first drm_framebuffer
> would be released and this makes dma access invalid memory region.
>


I am confused regarding this. If crtc points to second frame buffer, then
the dma is accessing the memory region
of the second framebuffer. Why can't we free the first framebuffer and its
gem buffer?

With this patch, there is no way to free a framebuffer (which has been set
to a crtc), without disabling
the crtc.

Consider this example:
I have three framebuffers (0, 1, 2) and I set them to a crtc A one by one.
So with your patch,
fb[0]->crtc = A
fb[1]->crtc = A
fb[2]->crtc = A

After this, I am using only framebuffer 0 and 1 i.e. 0 and 1 are being page
flipped.
Now, I want to remove framebuffer 2.
fb[2]->crtc = A .. so while removing the framebuffer, we will end up
disabling the crtc
which is not correct.

I think, there should be an additional interface to unset a fb to a crtc.
That way, we can
reset the crtc inside a framebuffer so that it can be freed if not in use.
i.e. fb[2]->crtc = NULL;






> This patch adds drm_framebuffer to drm_crtc structure as member
> and makes drm_framebuffer_cleanup function check if fb->crtc is
> same as desired fb. And also when setcrtc and pageflip are
> requested, it makes each drm_framebuffer point to current crtc.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/drm_crtc.c |7 ---
>  include/drm/drm_crtc.h |1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ef1b221..5c04bd4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -386,7 +386,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>
> /* remove from any CRTC */
> list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> -   if (crtc->fb == fb) {
> +   if (fb->crtc == crtc) {
> /* should turn off the crtc */
> memset(, 0, sizeof(struct drm_mode_set));
> set.crtc = crtc;
> @@ -2027,6 +2027,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void
> *data,
> set.mode = mode;
> set.connectors = connector_set;
> set.num_connectors = crtc_req->count_connectors;
> +   fb->crtc = crtc;
> set.fb = fb;
> ret = crtc->funcs->set_config();
>
> @@ -3635,8 +3636,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> spin_unlock_irqrestore(>event_lock, flags);
> kfree(e);
> }
> -   }
> -
> +   } else
> +   fb->crtc = crtc;
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3fa18b7..92889be 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -256,6 +256,7 @@ struct drm_framebuffer {
> struct kref refcount;
> struct list_head head;
> struct drm_mode_object base;
> +   struct drm_crtc *crtc;
> const struct drm_framebuffer_funcs *funcs;
> unsigned int pitches[4];
> unsigned int offsets[4];
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/2a0513a6/attachment-0001.html>

[PATCH 8/8] drm/vmwgfx: Add and make use of a header for surface size calculation.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h |  909 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |  113 +---
 2 files changed, 928 insertions(+), 94 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h

diff --git a/drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h 
b/drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h
new file mode 100644
index 000..8369c3b
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h
@@ -0,0 +1,909 @@
+/**
+ *
+ * Copyright ? 2008-2012 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifdef __KERNEL__
+
+#include 
+#define surf_size_struct struct drm_vmw_size
+
+#else /* __KERNEL__ */
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(_A) (sizeof(_A) / sizeof((_A)[0]))
+#endif /* ARRAY_SIZE */
+
+#define DIV_ROUND_UP(x, y)  (((x) + (y) - 1) / (y))
+#define max_t(type, x, y)  ((x) > (y) ? (x) : (y))
+#define surf_size_struct SVGA3dSize
+#define u32 uint32
+
+#endif /* __KERNEL__ */
+
+#include "svga3d_reg.h"
+
+/*
+ * enum svga3d_block_desc describes the active data channels in a block.
+ *
+ * There can be at-most four active channels in a block:
+ *1. Red, bump W, luminance and depth are stored in the first channel.
+ *2. Green, bump V and stencil are stored in the second channel.
+ *3. Blue and bump U are stored in the third channel.
+ *4. Alpha and bump Q are stored in the fourth channel.
+ *
+ * Block channels can be used to store compressed and buffer data:
+ *1. For compressed formats, only the data channel is used and its size
+ *   is equal to that of a singular block in the compression scheme.
+ *2. For buffer formats, only the data channel is used and its size is
+ *   exactly one byte in length.
+ *3. In each case the bit depth represent the size of a singular block.
+ *
+ * Note: Compressed and IEEE formats do not use the bitMask structure.
+ */
+
+enum svga3d_block_desc {
+   SVGA3DBLOCKDESC_NONE= 0, /* No channels are active */
+   SVGA3DBLOCKDESC_BLUE= 1 << 0,/* Block with red channel
+   data */
+   SVGA3DBLOCKDESC_U   = 1 << 0,/* Block with bump U channel
+   data */
+   SVGA3DBLOCKDESC_UV_VIDEO= 1 << 7,/* Block with alternating video
+   U and V */
+   SVGA3DBLOCKDESC_GREEN   = 1 << 1,/* Block with green channel
+   data */
+   SVGA3DBLOCKDESC_V   = 1 << 1,/* Block with bump V channel
+   data */
+   SVGA3DBLOCKDESC_STENCIL = 1 << 1,/* Block with a stencil
+   channel */
+   SVGA3DBLOCKDESC_RED = 1 << 2,/* Block with blue channel
+   data */
+   SVGA3DBLOCKDESC_W   = 1 << 2,/* Block with bump W channel
+   data */
+   SVGA3DBLOCKDESC_LUMINANCE   = 1 << 2,/* Block with luminance channel
+   data */
+   SVGA3DBLOCKDESC_Y   = 1 << 2,/* Block with video luminance
+   data */
+   SVGA3DBLOCKDESC_DEPTH   = 1 << 2,/* Block with depth channel */
+   SVGA3DBLOCKDESC_ALPHA   = 1 << 3,/* Block with an alpha
+

[PATCH 7/8] drm/vmwgfx: Break out surface and context management to separate files

Add a resource-private header for common resource definitions

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/Makefile   |3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c   |  274 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  | 1244 +
 drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h |   84 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c   |  969 +++
 5 files changed, 1338 insertions(+), 1236 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_context.c
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 586869c..2cc6cd9 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -5,6 +5,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_marker.o vmwgfx_gmrid_manager.o \
-   vmwgfx_fence.o vmwgfx_dmabuf.o vmwgfx_scrn.o
+   vmwgfx_fence.o vmwgfx_dmabuf.o vmwgfx_scrn.o vmwgfx_context.o \
+   vmwgfx_surface.o

 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
new file mode 100644
index 000..00ae092
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -0,0 +1,274 @@
+/**
+ *
+ * Copyright ? 2009-2012 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "vmwgfx_drv.h"
+#include "vmwgfx_resource_priv.h"
+#include "ttm/ttm_placement.h"
+
+struct vmw_user_context {
+   struct ttm_base_object base;
+   struct vmw_resource res;
+};
+
+static void vmw_user_context_free(struct vmw_resource *res);
+static struct vmw_resource *
+vmw_user_context_base_to_res(struct ttm_base_object *base);
+
+static uint64_t vmw_user_context_size;
+
+static const struct vmw_user_resource_conv user_context_conv = {
+   .object_type = VMW_RES_CONTEXT,
+   .base_obj_to_res = vmw_user_context_base_to_res,
+   .res_free = vmw_user_context_free
+};
+
+const struct vmw_user_resource_conv *user_context_converter =
+   _context_conv;
+
+
+static const struct vmw_res_func vmw_legacy_context_func = {
+   .res_type = vmw_res_context,
+   .needs_backup = false,
+   .may_evict = false,
+   .type_name = "legacy contexts",
+   .backup_placement = NULL,
+   .create = NULL,
+   .destroy = NULL,
+   .bind = NULL,
+   .unbind = NULL
+};
+
+/**
+ * Context management:
+ */
+
+static void vmw_hw_context_destroy(struct vmw_resource *res)
+{
+
+   struct vmw_private *dev_priv = res->dev_priv;
+   struct {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdDestroyContext body;
+   } *cmd;
+
+
+   vmw_execbuf_release_pinned_bo(dev_priv);
+   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
+   if (unlikely(cmd == NULL)) {
+   DRM_ERROR("Failed reserving FIFO space for surface "
+ "destruction.\n");
+   return;
+   }
+
+   cmd->header.id = cpu_to_le32(SVGA_3D_CMD_CONTEXT_DESTROY);
+   cmd->header.size = cpu_to_le32(sizeof(cmd->body));
+   cmd->body.cid = cpu_to_le32(res->id);
+
+   vmw_fifo_commit(dev_priv, sizeof(*cmd));
+   vmw_3d_resource_dec(dev_priv, false);
+}
+
+static int vmw_context_init(struct vmw_private *dev_priv,
+

[PATCH 6/8] drm/vmwgfx: Refactor resource management

Refactor resource management to make it easy to hook up resources
that are backed up by buffers. In particular, resources and their
backing buffers can be evicted and rebound, if supported by the device.
To avoid query deadlocks, the query code is also modified somewhat.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c   |7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   32 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  145 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  900 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 1528 --
 6 files changed, 1802 insertions(+), 817 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index f386cea..e88b0eb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
@@ -60,7 +60,7 @@ int vmw_dmabuf_to_placement(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
return ret;

-   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
+   vmw_execbuf_release_pinned_bo(dev_priv);

ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
@@ -105,7 +105,7 @@ int vmw_dmabuf_to_vram_or_gmr(struct vmw_private *dev_priv,
return ret;

if (pin)
-   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
+   vmw_execbuf_release_pinned_bo(dev_priv);

ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
@@ -214,8 +214,7 @@ int vmw_dmabuf_to_start_of_vram(struct vmw_private 
*dev_priv,
return ret;

if (pin)
-   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
-
+   vmw_execbuf_release_pinned_bo(dev_priv);
ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
goto err_unlock;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f233473..46b121c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -432,6 +432,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
struct vmw_private *dev_priv;
int ret;
uint32_t svga_id;
+   enum vmw_res_type i;

dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (unlikely(dev_priv == NULL)) {
@@ -448,15 +449,18 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
mutex_init(_priv->cmdbuf_mutex);
mutex_init(_priv->release_mutex);
rwlock_init(_priv->resource_lock);
-   idr_init(_priv->context_idr);
-   idr_init(_priv->surface_idr);
-   idr_init(_priv->stream_idr);
+
+   for (i = vmw_res_context; i < vmw_res_max; ++i) {
+   idr_init(_priv->res_idr[i]);
+   INIT_LIST_HEAD(_priv->res_lru[i]);
+   }
+
mutex_init(_priv->init_mutex);
init_waitqueue_head(_priv->fence_queue);
init_waitqueue_head(_priv->fifo_queue);
dev_priv->fence_queue_waiters = 0;
atomic_set(_priv->fifo_queue_waiters, 0);
-   INIT_LIST_HEAD(_priv->surface_lru);
+
dev_priv->used_memory_size = 0;

dev_priv->io_start = pci_resource_start(dev->pdev, 0);
@@ -670,9 +674,9 @@ out_err2:
 out_err1:
vmw_ttm_global_release(dev_priv);
 out_err0:
-   idr_destroy(_priv->surface_idr);
-   idr_destroy(_priv->context_idr);
-   idr_destroy(_priv->stream_idr);
+   for (i = vmw_res_context; i < vmw_res_max; ++i)
+   idr_destroy(_priv->res_idr[i]);
+
kfree(dev_priv);
return ret;
 }
@@ -680,9 +684,12 @@ out_err0:
 static int vmw_driver_unload(struct drm_device *dev)
 {
struct vmw_private *dev_priv = vmw_priv(dev);
+   enum vmw_res_type i;

unregister_pm_notifier(_priv->pm_nb);

+   if (dev_priv->ctx.res_ht_initialized)
+   drm_ht_remove(_priv->ctx.res_ht);
if (dev_priv->ctx.cmd_bounce)
vfree(dev_priv->ctx.cmd_bounce);
if (dev_priv->enable_fb) {
@@ -709,9 +716,9 @@ static int vmw_driver_unload(struct drm_device *dev)
(void)ttm_bo_clean_mm(_priv->bdev, TTM_PL_VRAM);
(void)ttm_bo_device_release(_priv->bdev);
vmw_ttm_global_release(dev_priv);
-   idr_destroy(_priv->surface_idr);
-   idr_destroy(_priv->context_idr);
-   idr_destroy(_priv->stream_idr);
+
+   for (i = vmw_res_context; i < vmw_res_max; ++i)
+   idr_destroy(_priv->res_idr[i]);

kfree(dev_priv);

@@ -935,7 +942,7 @@ static void vmw_master_drop(struct drm_device *dev,

vmw_fp->locked_master = drm_master_get(file_priv->master);
ret = ttm_vt_lock(>lock, false, vmw_fp->tfile);
-   vmw_execbuf_release_pinned_bo(dev_priv, false,

[PATCH 5/8] drm/vmwgfx: Make vmw_dmabuf_unreference handle NULL objects

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 88a179e..7c6f6e3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -699,10 +699,13 @@ static inline struct vmw_surface 
*vmw_surface_reference(struct vmw_surface *srf)
 static inline void vmw_dmabuf_unreference(struct vmw_dma_buffer **buf)
 {
struct vmw_dma_buffer *tmp_buf = *buf;
-   struct ttm_buffer_object *bo = _buf->base;
+
*buf = NULL;
+   if (tmp_buf != NULL) {
+   struct ttm_buffer_object *bo = _buf->base;

-   ttm_bo_unref();
+   ttm_bo_unref();
+   }
 }

 static inline struct vmw_dma_buffer *vmw_dmabuf_reference(struct 
vmw_dma_buffer *buf)
-- 
1.7.4.4

[PATCH 4/8] drm/vmwgfx: Refactor module load to not require fifo unless fbdev is loaded

This also fixes a bug where the fence manager was left without irq
enabled when waiting for fences, causing various errors at module
load time

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   50 --
 1 files changed, 18 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 79fb7d7e..f233473 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -609,14 +609,18 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
}
}

+   if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
+   ret = drm_irq_install(dev);
+   if (ret != 0) {
+   DRM_ERROR("Failed installing irq: %d\n", ret);
+   goto out_no_irq;
+   }
+   }
+
dev_priv->fman = vmw_fence_manager_init(dev_priv);
if (unlikely(dev_priv->fman == NULL))
goto out_no_fman;

-   /* Need to start the fifo to check if we can do screen objects */
-   ret = vmw_3d_resource_inc(dev_priv, true);
-   if (unlikely(ret != 0))
-   goto out_no_fifo;
vmw_kms_save_vga(dev_priv);

/* Start kms and overlay systems, needs fifo. */
@@ -625,25 +629,11 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
goto out_no_kms;
vmw_overlay_init(dev_priv);

-   /* 3D Depends on Screen Objects being used. */
-   DRM_INFO("Detected %sdevice 3D availability.\n",
-vmw_fifo_have_3d(dev_priv) ?
-"" : "no ");
-
-   /* We might be done with the fifo now */
if (dev_priv->enable_fb) {
+   ret = vmw_3d_resource_inc(dev_priv, true);
+   if (unlikely(ret != 0))
+   goto out_no_fifo;
vmw_fb_init(dev_priv);
-   } else {
-   vmw_kms_restore_vga(dev_priv);
-   vmw_3d_resource_dec(dev_priv, true);
-   }
-
-   if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
-   ret = drm_irq_install(dev);
-   if (unlikely(ret != 0)) {
-   DRM_ERROR("Failed installing irq: %d\n", ret);
-   goto out_no_irq;
-   }
}

dev_priv->pm_nb.notifier_call = vmwgfx_pm_notifier;
@@ -651,20 +641,16 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)

return 0;

-out_no_irq:
-   if (dev_priv->enable_fb)
-   vmw_fb_close(dev_priv);
+out_no_fifo:
vmw_overlay_close(dev_priv);
vmw_kms_close(dev_priv);
 out_no_kms:
-   /* We still have a 3D resource reference held */
-   if (dev_priv->enable_fb) {
-   vmw_kms_restore_vga(dev_priv);
-   vmw_3d_resource_dec(dev_priv, false);
-   }
-out_no_fifo:
+   vmw_kms_restore_vga(dev_priv);
vmw_fence_manager_takedown(dev_priv->fman);
 out_no_fman:
+   if (dev_priv->capabilities & SVGA_CAP_IRQMASK)
+   drm_irq_uninstall(dev_priv->dev);
+out_no_irq:
if (dev_priv->stealth)
pci_release_region(dev->pdev, 2);
else
@@ -699,8 +685,6 @@ static int vmw_driver_unload(struct drm_device *dev)

if (dev_priv->ctx.cmd_bounce)
vfree(dev_priv->ctx.cmd_bounce);
-   if (dev_priv->capabilities & SVGA_CAP_IRQMASK)
-   drm_irq_uninstall(dev_priv->dev);
if (dev_priv->enable_fb) {
vmw_fb_close(dev_priv);
vmw_kms_restore_vga(dev_priv);
@@ -709,6 +693,8 @@ static int vmw_driver_unload(struct drm_device *dev)
vmw_kms_close(dev_priv);
vmw_overlay_close(dev_priv);
vmw_fence_manager_takedown(dev_priv->fman);
+   if (dev_priv->capabilities & SVGA_CAP_IRQMASK)
+   drm_irq_uninstall(dev_priv->dev);
if (dev_priv->stealth)
pci_release_region(dev->pdev, 2);
else
-- 
1.7.4.4

[PATCH 3/8] drm/vmwgfx: Make screen object code not require fifo at init time

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 6deaf2f..60f1285 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -485,7 +485,7 @@ int vmw_kms_init_screen_object_display(struct vmw_private 
*dev_priv)
return -EINVAL;
}

-   if (!(dev_priv->fifo.capabilities & SVGA_FIFO_CAP_SCREEN_OBJECT_2)) {
+   if (!(dev_priv->capabilities & SVGA_CAP_SCREEN_OBJECT_2)) {
DRM_INFO("Not using screen objects,"
 " missing cap SCREEN_OBJECT_2\n");
return -ENOSYS;
-- 
1.7.4.4

[PATCH 2/8] drm/vmwgfx: Make overlay code not require fifo at init time

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index cb55b7b..87e39f6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -35,6 +35,7 @@
 #include "svga_escape.h"

 #define VMW_MAX_NUM_STREAMS 1
+#define VMW_OVERLAY_CAP_MASK (SVGA_FIFO_CAP_VIDEO | SVGA_FIFO_CAP_ESCAPE)

 struct vmw_stream {
struct vmw_dma_buffer *buf;
@@ -449,6 +450,14 @@ int vmw_overlay_pause_all(struct vmw_private *dev_priv)
return 0;
 }

+
+static bool vmw_overlay_available(const struct vmw_private *dev_priv)
+{
+   return (dev_priv->overlay_priv != NULL && 
+   ((dev_priv->fifo.capabilities & VMW_OVERLAY_CAP_MASK) ==
+VMW_OVERLAY_CAP_MASK));
+}
+
 int vmw_overlay_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
 {
@@ -461,7 +470,7 @@ int vmw_overlay_ioctl(struct drm_device *dev, void *data,
struct vmw_resource *res;
int ret;

-   if (!overlay)
+   if (!vmw_overlay_available(dev_priv))
return -ENOSYS;

ret = vmw_user_stream_lookup(dev_priv, tfile, >stream_id, );
@@ -492,7 +501,7 @@ out_unlock:

 int vmw_overlay_num_overlays(struct vmw_private *dev_priv)
 {
-   if (!dev_priv->overlay_priv)
+   if (!vmw_overlay_available(dev_priv))
return 0;

return VMW_MAX_NUM_STREAMS;
@@ -503,7 +512,7 @@ int vmw_overlay_num_free_overlays(struct vmw_private 
*dev_priv)
struct vmw_overlay *overlay = dev_priv->overlay_priv;
int i, k;

-   if (!overlay)
+   if (!vmw_overlay_available(dev_priv))
return 0;

mutex_lock(>mutex);
@@ -569,12 +578,6 @@ int vmw_overlay_init(struct vmw_private *dev_priv)
if (dev_priv->overlay_priv)
return -EINVAL;

-   if (!(dev_priv->fifo.capabilities & SVGA_FIFO_CAP_VIDEO) &&
-(dev_priv->fifo.capabilities & SVGA_FIFO_CAP_ESCAPE)) {
-   DRM_INFO("hardware doesn't support overlays\n");
-   return -ENOSYS;
-   }
-
overlay = kzalloc(sizeof(*overlay), GFP_KERNEL);
if (!overlay)
return -ENOMEM;
-- 
1.7.4.4

[PATCH 1/8] drm/vmwgfx: Enable traces after we've hidden SVGA

Hiding SVGA seems to trigger a VGA screen clear, and with no
traces dirty it doesn't seem to repaint

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 2dd185e..79fb7d7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -924,11 +924,11 @@ static int vmw_master_set(struct drm_device *dev,

 out_no_active_lock:
if (!dev_priv->enable_fb) {
+   vmw_kms_restore_vga(dev_priv);
+   vmw_3d_resource_dec(dev_priv, true);
mutex_lock(_priv->hw_mutex);
vmw_write(dev_priv, SVGA_REG_TRACES, 1);
mutex_unlock(_priv->hw_mutex);
-   vmw_kms_restore_vga(dev_priv);
-   vmw_3d_resource_dec(dev_priv, true);
}
return ret;
 }
@@ -962,11 +962,11 @@ static void vmw_master_drop(struct drm_device *dev,
ret = ttm_bo_evict_mm(_priv->bdev, TTM_PL_VRAM);
if (unlikely(ret != 0))
DRM_ERROR("Unable to clean VRAM on master drop.\n");
+   vmw_kms_restore_vga(dev_priv);
+   vmw_3d_resource_dec(dev_priv, true);
mutex_lock(_priv->hw_mutex);
vmw_write(dev_priv, SVGA_REG_TRACES, 1);
mutex_unlock(_priv->hw_mutex);
-   vmw_kms_restore_vga(dev_priv);
-   vmw_3d_resource_dec(dev_priv, true);
}

dev_priv->active_master = _priv->fbdev_master;
-- 
1.7.4.4

[PATCH 0/8] vmwgfx stuff for -next

This patch series should be applied after the
drm/ttm: Get rid of a number of atomic read-modify-write ops vX
patch series.

It contains various improvements. Patch 7 is a rewrite of the resource
management and is intended to pave the way for an upcoming hardware
version change, and to ease implementation of multi-thread command submission.

Patch 8 adds a previously vmware-internal header so that we make sure
we compute the surface memory requirement the same way as the virtual
device does. The same file is intended to be used by mesa.

Thanks,
Thomas

[Bug 56918] [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

--- Comment #1 from Tom Stellard  ---
(In reply to comment #0)
> Created attachment 69809 [details]
> screenshot from Mesa 9.0
> 
> Using a Radeon 9800 Pro 128MB (R350) on both Mesa 8.04 and Mesa 9.0. All of
> the labels in Google MapsGL are black rectangles.  This is actually slightly
> worse on Mesa 9.0, with which the location names (at lower zoom levels)
> park, national park and state forest labels now show text on a black
> background instead of normal text as before.  On both versions of Mesa the
> street names are not shown, there are only black rectangles where the street
> names should be.
> 
> Attached screenshot is from Firefox 16.0.2 running on Mesa 9.0 on Ubuntu
> 12.10.  The 3.5.0-2-generic #2-Ubuntu kernel is a bit out of date - I can
> update to the 3.5.0-17.28 kernel (which rebases to upstream 3.5.5 plus a few
> small changes) if that is important.
> 
> Please note that this is NOT the same as bug 49088.  The fix for that was
> specifically included in 8.0.4-0ubuntu0.1 and mentioned in the changelog.

Can you set the environment variable RADEON_DEBUG=fp,vp and then post the
debugging output you get with firefox and Google MapsGL.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/ae8e8630/attachment.html>

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> This patch fixes access issue to invalid memory region.
> 
> crtc had only one drm_framebuffer object so when framebuffer
> cleanup was requested after page flip, it'd try to disable
> hardware overlay to current crtc.
> But if current crtc points to another drm_framebuffer,
> This may induce invalid memory access.
> 
> Assume that some application are doing page flip with two
> drm_framebuffer objects. At this time, if second drm_framebuffer
> is set to current crtc and the cleanup to first drm_framebuffer
> is requested once drm release is requested, then first
> drm_framebuffer would be cleaned up without disabling
> hardware overlay because current crtc points to second
> drm_framebuffer. After that, gem buffer to first drm_framebuffer
> would be released and this makes dma access invalid memory region.
> 
> This patch adds drm_framebuffer to drm_crtc structure as member

That is exactly the reverse of what you're doing in the patch.
We already have crtc.fb, and you're adding fb.crtc.

> and makes drm_framebuffer_cleanup function check if fb->crtc is
> same as desired fb. And also when setcrtc and pageflip are
> requested, it makes each drm_framebuffer point to current crtc.

Looks like you're just setting the crtc.fb and fb.crtc pointers to
exactly mirror each other in the page flip ioctl. That can't fix
anything.

First of all multiple crtcs can scan out from the same fb, so a single
fb.crtc pointer is clearly not enough to represent the relationship
between fbs and crtcs.

Also you're not clearing the fb.crtc pointer anywhere, so now
destroying any framebuffer that was once used for scanout, would disable
some crtc.

So it looks like you're making things worse, not better.

Anyway I'll just nack the whole idea. What you need to do is track the
pending page flips, and make sure the old buffer is not freed too early.
Just grab a reference to the old gem object when issuing the page flip,
and unref it when you're sure the flip has occured. Or you could use the
new drm_framebuffer refcount, but personally I don't see much point in
that when you already have the gem object refcount at your disposal.

-- 
Ville Syrj?l?
Intel OTC

[Bug 56918] [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

Alex Deucher  changed:

   What|Removed |Added

  Attachment #69809|text/plain  |image/png
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/fb1bf389/attachment.html>

[Bug 56918] New: [R350] Black labels on MapsGL

https://bugs.freedesktop.org/show_bug.cgi?id=56918

Priority: medium
Bug ID: 56918
Assignee: dri-devel at lists.freedesktop.org
Summary: [R350] Black labels on MapsGL
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: s.j.turner at uqconnect.net
Hardware: x86 (IA32)
Status: NEW
Version: 9.0
Component: Drivers/Gallium/r300
Product: Mesa

Created attachment 69809
--> https://bugs.freedesktop.org/attachment.cgi?id=69809=edit
screenshot from Mesa 9.0

Using a Radeon 9800 Pro 128MB (R350) on both Mesa 8.04 and Mesa 9.0. All of the
labels in Google MapsGL are black rectangles. This is actually slightly worse
on Mesa 9.0, with which the location names (at lower zoom levels) park,
national park and state forest labels now show text on a black background
instead of normal text as before. On both versions of Mesa the street names
are not shown, there are only black rectangles where the street names should
be.

Attached screenshot is from Firefox 16.0.2 running on Mesa 9.0 on Ubuntu 12.10.
The 3.5.0-2-generic #2-Ubuntu kernel is a bit out of date - I can update to
the 3.5.0-17.28 kernel (which rebases to upstream 3.5.5 plus a few small
changes) if that is important.

Please note that this is NOT the same as bug 49088. The fix for that was
specifically included in 8.0.4-0ubuntu0.1 and mentioned in the changelog.

--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/ecc43cd6/attachment-0001.html>

[PATCH] PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register

2012-11-09 Thread Alex Deucher

On Fri, Nov 9, 2012 at 12:15 PM, Bjorn Helgaas  wrote:
> On Thu, Nov 8, 2012 at 11:56 PM, Jingoo Han  wrote:
>> According to the PCIe 3.0 spec, PCI_EXP_LNKCAP2_SLS_2_5GB is
>> 1st bit of PCI_EXP_LNKCAP2 register, not 0th bit. So, the bit
>> definition of supported link speed vector should be fixed.
>>
>> Signed-off-by: Jingoo Han 
>> ---
>>  include/uapi/linux/pci_regs.h |6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>> index 20ae747..14a3184 100644
>> --- a/include/uapi/linux/pci_regs.h
>> +++ b/include/uapi/linux/pci_regs.h
>> @@ -544,9 +544,9 @@
>>  #define  PCI_EXP_OBFF_WAKE_EN  0x6000  /* OBFF using WAKE# signaling */
>>  #define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 44  /* v2 endpoints end here */
>>  #define PCI_EXP_LNKCAP244  /* Link Capability 2 */
>> -#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x01/* Current Link Speed 
>> 2.5GT/s */
>> -#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x02/* Current Link Speed 
>> 5.0GT/s */
>> -#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x04/* Current Link Speed 
>> 8.0GT/s */
>> +#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x02/* Current Link Speed 
>> 2.5GT/s */
>> +#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x04/* Current Link Speed 
>> 5.0GT/s */
>> +#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x08/* Current Link Speed 
>> 8.0GT/s */
>>  #define  PCI_EXP_LNKCAP2_CROSSLINK 0x100 /* Crosslink supported */
>>  #define PCI_EXP_LNKCTL248  /* Link Control 2 */
>>  #define PCI_EXP_LNKSTA250  /* Link Status 2 */
>
> I think this patch is correct, per spec sec 7.8.18.  If I apply it, I
> think the comments should also be changed to "Supported Link Speed"
> instead of "Current."

Correct.

>
> The only in-tree user of these symbols is
> drm_pcie_get_speed_cap_mask().  Dave, can you ack/nack this?  I don't
> want to apply this if it's going to break something there.

The patch is fine and shouldn't break anything.

Alex

[Bug 54767] [r300g] 298 failures on WebGL Conformance Test

https://bugs.freedesktop.org/show_bug.cgi?id=54767

--- Comment #5 from Marek Ol??k  ---
(In reply to comment #4)
> Does that include atan(vec4, vec4) in fragment shader?  I have a Radeon 9800
> Pro 128MB (R350).

I don't remember if that function works on r300. I guess you have to try and
see if the results are correct but not very precise (i.e. they're close to the
expected value) or if they're totally wrong.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/d9ed7065/attachment.html>

[PATCH] drm: fix documentation for drm_crtc_set_mode()

2012-11-09 Thread alexdeuc...@gmail.com

From: Alex Deucher 

x and y parameters are offsets, not width/height

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/drm_crtc_helper.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 1227adf..ae43f92 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -328,8 +328,8 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
  * drm_crtc_set_mode - set a mode
  * @crtc: CRTC to program
  * @mode: mode to use
- * @x: width of mode
- * @y: height of mode
+ * @x: horizontal offset into the surface
+ * @y: vertical offset into the surface
  *
  * LOCKING:
  * Caller must hold mode config lock.
-- 
1.7.7.5

[Bug 54767] [r300g] 298 failures on WebGL Conformance Test

https://bugs.freedesktop.org/show_bug.cgi?id=54767

--- Comment #4 from madbiologist  ---
(In reply to comment #3)
> r300 cannot pass some of the tests, because the hardware is too limited
> (some features cannot be implemented on r300), while other features may
> produce slightly different results due to precision issues. Some tests are
> simply unfixable.

Does that include atan(vec4, vec4) in fragment shader?  I have a Radeon 9800
Pro 128MB (R350).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/135f80db/attachment.html>

[PATCH] PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register

2012-11-09 Thread Bjorn Helgaas

On Fri, Nov 9, 2012 at 10:37 AM, Alex Deucher  wrote:
> On Fri, Nov 9, 2012 at 12:15 PM, Bjorn Helgaas  wrote:
>> On Thu, Nov 8, 2012 at 11:56 PM, Jingoo Han  wrote:
>>> According to the PCIe 3.0 spec, PCI_EXP_LNKCAP2_SLS_2_5GB is
>>> 1st bit of PCI_EXP_LNKCAP2 register, not 0th bit. So, the bit
>>> definition of supported link speed vector should be fixed.
>>>
>>> Signed-off-by: Jingoo Han 
>>> ---
>>>  include/uapi/linux/pci_regs.h |6 +++---
>>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
>>> index 20ae747..14a3184 100644
>>> --- a/include/uapi/linux/pci_regs.h
>>> +++ b/include/uapi/linux/pci_regs.h
>>> @@ -544,9 +544,9 @@
>>>  #define  PCI_EXP_OBFF_WAKE_EN  0x6000  /* OBFF using WAKE# signaling */
>>>  #define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 44  /* v2 endpoints end here */
>>>  #define PCI_EXP_LNKCAP244  /* Link Capability 2 */
>>> -#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x01/* Current Link Speed 
>>> 2.5GT/s */
>>> -#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x02/* Current Link Speed 
>>> 5.0GT/s */
>>> -#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x04/* Current Link Speed 
>>> 8.0GT/s */
>>> +#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x02/* Current Link Speed 
>>> 2.5GT/s */
>>> +#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x04/* Current Link Speed 
>>> 5.0GT/s */
>>> +#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x08/* Current Link Speed 
>>> 8.0GT/s */
>>>  #define  PCI_EXP_LNKCAP2_CROSSLINK 0x100 /* Crosslink supported */
>>>  #define PCI_EXP_LNKCTL248  /* Link Control 2 */
>>>  #define PCI_EXP_LNKSTA250  /* Link Status 2 */
>>
>> I think this patch is correct, per spec sec 7.8.18.  If I apply it, I
>> think the comments should also be changed to "Supported Link Speed"
>> instead of "Current."
>
> Correct.
>
>>
>> The only in-tree user of these symbols is
>> drm_pcie_get_speed_cap_mask().  Dave, can you ack/nack this?  I don't
>> want to apply this if it's going to break something there.
>
> The patch is fine and shouldn't break anything.

Thanks for checking this out, Alex.

I applied this to my pci/misc branch as v3.8 material.

Bjorn

[PATCH 6/6] drm/nouveau: free memory allocated with alloc_apertures()

Fix a memory leak by deallocating the memory we got from
alloc_apertures().

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 0910125..8244863 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -223,6 +223,7 @@ nouveau_drm_probe(struct pci_dev *pdev, const struct 
pci_device_id *pent)
boot = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
 #endif
remove_conflicting_framebuffers(aper, "nouveaufb", boot);
+   kfree(aper);

ret = nouveau_device_create(pdev, nouveau_name(pdev), pci_name(pdev),
nouveau_config, nouveau_debug, );
-- 
1.7.9.5

[PATCH 5/6] drm/radeon: check alloc_apertures() success in radeon_kick_out_firmware_fb()

Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/radeon/radeon_drv.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 07eb84e..8c1a83c 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -281,12 +281,15 @@ static struct drm_driver driver_old = {

 static struct drm_driver kms_driver;

-static void radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
 {
struct apertures_struct *ap;
bool primary = false;

ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
ap->ranges[0].base = pci_resource_start(pdev, 0);
ap->ranges[0].size = pci_resource_len(pdev, 0);

@@ -295,13 +298,19 @@ static void radeon_kick_out_firmware_fb(struct pci_dev 
*pdev)
 #endif
remove_conflicting_framebuffers(ap, "radeondrmfb", primary);
kfree(ap);
+
+   return 0;
 }

 static int __devinit
 radeon_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
+   int ret;
+
/* Get rid of things like offb */
-   radeon_kick_out_firmware_fb(pdev);
+   ret = radeon_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;

return drm_get_pci_dev(pdev, ent, _driver);
 }
-- 
1.7.9.5

[PATCH 4/6] drm/mgag200: remove unneeded aper->count assignment after alloc_apertures()

alloc_apertures() already does the assignment for us, so assigning the
count member after the alloc_apertures() call is not needed.

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/mgag200/mgag200_main.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 857d71b..70dd3c5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -142,7 +142,6 @@ static int mga_vram_init(struct mga_device *mdev)

aper->ranges[0].base = mdev->mc.vram_base;
aper->ranges[0].size = mdev->mc.vram_window;
-   aper->count = 1;

remove_conflicting_framebuffers(aper, "mgafb", true);
kfree(aper);
-- 
1.7.9.5

[PATCH 3/6] drm/mgag200: free memory allocated with alloc_apertures()

Fix a memory leak by deallocating the memory we got from
alloc_apertures().

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/mgag200/mgag200_main.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 07d4b24..857d71b 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -145,6 +145,7 @@ static int mga_vram_init(struct mga_device *mdev)
aper->count = 1;

remove_conflicting_framebuffers(aper, "mgafb", true);
+   kfree(aper);

if (!request_mem_region(mdev->mc.vram_base, mdev->mc.vram_window,
"mgadrmfb_vram")) {
-- 
1.7.9.5

[PATCH 2/6] drm/mgag200: check alloc_apertures() success in mga_vram_init()

Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/mgag200/mgag200_main.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index d6a1aae..07d4b24 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -133,6 +133,8 @@ static int mga_vram_init(struct mga_device *mdev)
 {
void __iomem *mem;
struct apertures_struct *aper = alloc_apertures(1);
+   if (!aper)
+   return -ENOMEM;

/* BAR 0 is VRAM */
mdev->mc.vram_base = pci_resource_start(mdev->dev->pdev, 0);
-- 
1.7.9.5

[PATCH 1/6] drm/cirrus: check alloc_apertures() success in cirrus_kick_out_firmware_fb()

Check for alloc_apertures() memory allocation failure, and propagate an
error code in case the allocation failed.

Signed-off-by: Tommi Rantala 
---
 drivers/gpu/drm/cirrus/cirrus_drv.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c 
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 101e423..dcd1a8c 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -35,12 +35,15 @@ static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
 };


-static void cirrus_kick_out_firmware_fb(struct pci_dev *pdev)
+static int cirrus_kick_out_firmware_fb(struct pci_dev *pdev)
 {
struct apertures_struct *ap;
bool primary = false;

ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
ap->ranges[0].base = pci_resource_start(pdev, 0);
ap->ranges[0].size = pci_resource_len(pdev, 0);

@@ -49,12 +52,18 @@ static void cirrus_kick_out_firmware_fb(struct pci_dev 
*pdev)
 #endif
remove_conflicting_framebuffers(ap, "cirrusdrmfb", primary);
kfree(ap);
+
+   return 0;
 }

 static int __devinit
 cirrus_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
-   cirrus_kick_out_firmware_fb(pdev);
+   int ret;
+
+   ret = cirrus_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;

return drm_get_pci_dev(pdev, ent, );
 }
-- 
1.7.9.5

[PATCH 0/6] alloc_apertures() handling fixes

Greetings,

The following patches fix a few memory leaks and other problems related to the
alloc_apertures() call.

Tommi Rantala (6):
  drm/cirrus: check alloc_apertures() success in
cirrus_kick_out_firmware_fb()
  drm/mgag200: check alloc_apertures() success in mga_vram_init()
  drm/mgag200: free memory allocated with alloc_apertures()
  drm/mgag200: remove unneeded aper->count assignment after
alloc_apertures()
  drm/radeon: check alloc_apertures() success in
radeon_kick_out_firmware_fb()
  drm/nouveau: free memory allocated with alloc_apertures()

 drivers/gpu/drm/cirrus/cirrus_drv.c|   13 +++--
 drivers/gpu/drm/mgag200/mgag200_main.c |4 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c  |1 +
 drivers/gpu/drm/radeon/radeon_drv.c|   13 +++--
 4 files changed, 26 insertions(+), 5 deletions(-)

-- 
1.7.9.5

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 9, 2012 at 1:39 AM, Inki Dae  wrote:
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3fa18b7..92889be 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -256,6 +256,7 @@ struct drm_framebuffer {
> struct kref refcount;
> struct list_head head;
> struct drm_mode_object base;
> +   struct drm_crtc *crtc;

note that one fb can be attached to multiple crtc's (and/or planes)..
so this will never work.

Anyways, I think the right answer is somehow reference-counting.  You
should *somewhere* be holding a ref to bo's until there is no more dma
access, either directly or indirectly by holding a ref to the fb
(which holds a ref to the bo(s))

BR,
-R

> const struct drm_framebuffer_funcs *funcs;
> unsigned int pitches[4];
> unsigned int offsets[4];
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

--- Comment #93 from Cool Loki  ---
Created attachment 69804
  --> https://bugs.freedesktop.org/attachment.cgi?id=69804=edit
dmesg.txt

dmseg.txt
kernel 3.7.0-rc4

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/4f477c02/attachment.html>

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 9, 2012 at 10:56 AM, Inki Dae  wrote:
>
>
> 2012/11/9 Rob Clark 
>>
>> On Fri, Nov 9, 2012 at 1:39 AM, Inki Dae  wrote:
>> > This patch fixes access issue to invalid memory region.
>> >
>> > crtc had only one drm_framebuffer object so when framebuffer
>> > cleanup was requested after page flip, it'd try to disable
>> > hardware overlay to current crtc.
>> > But if current crtc points to another drm_framebuffer,
>> > This may induce invalid memory access.
>>
>> btw, this should instead be done by holding a ref to the GEM
>> object(s)..  or these days you can increment the reference count on
>> the fb and let the fb hold ref's to the GEM object(s) (which makes it
>> a bit easier to deal with multi-planar formats)
>>
>
> Rob, let's discuss that again after you read my latest comment. Please, see
> my latest comment.

oh, I think our emails crossed paths.  But I think the crtc (or plane)
holding a ref to the fb until scanout stops should solve the issue for
you.

BR,
-R

> Thanks,
> Inki Dae
>

[git pull] drm vmwgfx

2012-11-09 Thread Dave Airlie


Hi Linus,

dropped the ball on a vmware patch, so two more fixes for vmwgfx are here,
one for hibernate issue, one for a BUG trigger.

Dave.

The following changes since commit 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0:

  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-11-09 
14:57:02 +1000)

are available in the git repository at:


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

for you to fetch changes up to afcc87aa6a233e52df73552dc1dc9ae3881b7cc8:

  drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory 
(2012-11-09 20:49:06 +1000)


Thomas Hellstrom (2):
  drm/vmwgfx: Fix hibernation device reset
  drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR 
memory

 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 9, 2012 at 10:50 AM, Inki Dae  wrote:
> I don't think so. let's see it again. below is my idea AND the reason I
> posted this patch.
> Original codes,
> gem alloc(gem0);
> -> gem0 refcount = 1
> gem0 mmap
> -> gem0 refcount = 2
> gem alloc(gem1);
> -> gem1 refcount =1
> gem1 mmap
> -> gem1 refcount =2
> addfb(fb0, gem0);
> -> gem0 refcount=3
> addfb(fb1,gem1);
> -> gem1 refcount = 3
> setcrtc(fb0, crtc0)
> -> crtc0.fb = fb0
> pageflip(crtc0, fb1);
> -> crtc0.fb = fb1.
> and pageflip is repeated
>
> close(gem0)
> -> gem0 refcount = 2
> close(gem1)
> ->gem1 refcount = 2
> munmap(gem0)
> ->gem0 refcount = 1
> munmap(gem1)
> ->gem1 refcount = 1
>
> close(drm)
> 1. fb release
> -> check if crtc->fb is same as fb0 but current crtc is pointing to fb1
> 2. so free fb0 without disabling current crtc.
> -> gem0 refcount = 0 so released. At this time, dma access invalid memory
> region unfortunately if the dma is accessing gem0.
>

I think you should either hold an extra ref to the fb until dma stops,
or block when the fb is destroyed until dma stops.

See the 'drm: refcnt drm_framebuffer' patch.  This lets me solve a
similar issue in omapdrm.  (Well, you could solve the same issue by
holding a ref to the GEM objects somewhere else until the scanout
stops, but it is easier for the crtc just to hold a ref to the fb.)

BR,
-R

>
>
> With my patch,
> ...
> setcrtc(fb0, crtc0)
> -> crtc0.fb = fb0, fb0.crtc = crtc0
> pageflip(crtc0, fb1);
> -> crtc0.fb = fb1, fb1.crtc = crtc0.
> and pageflip is repeated
>
> close(gem0)
> -> gem0 refcount = 2
> close(gem1)
> ->gem1 refcount = 2
> munmap(gem0)
> ->gem0 refcount = 1
> munmap(gem1)
> ->gem1 refcount = 1
> close(drm)
> 1. fb release
> -> fb0->crtc is same as crtc so disable crtc (dma stop)
> 2. and free fb0.
> -> gem0 refcount = 0 so released. We can avoid invalid memory access because
> the dma was stopped.
> In addition, one thing you pointed should be considered like below,
> 1. When rmfb is called, if fb is last one then it sets fb->crtc to NULL.
> - the fb is cleaned up with disabling crtc.
>

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

--- Comment #92 from Cool Loki  ---
Created attachment 69803
  --> https://bugs.freedesktop.org/attachment.cgi?id=69803=edit
lspci -v

My laptop model: Fujitsu Siemens FMV-610NU2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/96346719/attachment-0001.html>

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

--- Comment #91 from Cool Loki  ---
Created attachment 69802
  --> https://bugs.freedesktop.org/attachment.cgi?id=69802=edit
intel_drm_dumper

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/470650b8/attachment.html>

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

--- Comment #90 from Cool Loki  ---
Created attachment 69801
  --> https://bugs.freedesktop.org/attachment.cgi?id=69801=edit
rom_loki.bin

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/16bf72d4/attachment.html>

[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

https://bugs.freedesktop.org/show_bug.cgi?id=17902

Cool Loki  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #89 from Cool Loki  ---
Please help!
Here's my rom_loki.bin
have it listed two displays
NA-2501
CH-7009-A
how to solve this problem

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/1b74f4bd/attachment.html>

[PATCH] drm/omap: fix typo, s/GET_OMAP_REVISION()/GET_OMAP_TYPE/

From: Rob Clark 

The patch 'drm/omap: add support for ARCH_MULTIPLATFORM' had a small
mistake, using GET_OMAP_REVISION() instead of GET_OMAP_TYPE.

Signed-off-by: Rob Clark 
---
Same as earlier patch, but updated subject line as Paul Menzel suggested.

 arch/arm/mach-omap2/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 49a7ffb..1211790 100644
--- a/arch/arm/mach-omap2/drm.c
+++ b/arch/arm/mach-omap2/drm.c
@@ -57,7 +57,7 @@ static int __init omap_init_drm(void)
oh->name);
}

-   platform_data.omaprev = GET_OMAP_REVISION();
+   platform_data.omaprev = GET_OMAP_TYPE;

return platform_device_register(_drm_device);

-- 
1.8.0

[PATCH -fixes] drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
Cc: stable at vger.kernel.org
Cc: linux-graphics-maintainer at vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index 3ce68a2..d1498bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
@@ -306,7 +306,7 @@ void vmw_bo_pin(struct ttm_buffer_object *bo, bool pin)

BUG_ON(!atomic_read(>reserved));
BUG_ON(old_mem_type != TTM_PL_VRAM &&
-  old_mem_type != VMW_PL_FLAG_GMR);
+  old_mem_type != VMW_PL_GMR);

pl_flags = TTM_PL_FLAG_VRAM | VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED;
if (pin)
-- 
1.7.4.4

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

On Fri, Nov 9, 2012 at 10:00 AM, Thierry Reding
 wrote:
> On Fri, Nov 09, 2012 at 09:18:58AM -0600, Rob Clark wrote:
>> On Fri, Nov 9, 2012 at 7:59 AM, Thierry Reding
>>  wrote:
> [...]
>> > +static int regs_open(struct inode *inode, struct file *file)
>> > +{
>> > +   return single_open(file, regs_show, inode->i_private);
>> > +}
>> > +
>> > +static const struct file_operations regs_fops = {
>> > +   .open = regs_open,
>> > +   .read = seq_read,
>> > +   .llseek = seq_lseek,
>> > +   .release = single_release,
>> > +};
>> > +
>> > +static int tegra_dc_debugfs_init(struct tegra_dc *dc, struct dentry 
>> > *parent)
>> > +{
>> > +   char *name;
>> > +
>> > +   name = kasprintf(GFP_KERNEL, "dc.%d", dc->pipe);
>> > +   dc->debugfs = debugfs_create_dir(name, parent);
>> > +   kfree(name);
>> > +
>> > +   debugfs_create_file("regs", 0400, dc->debugfs, dc, _fops);
>> > +
>>
>> note that drm already has it's own debugfs helpers, see
>> drm_debugfs_create_files() and drm_debugfs_remove_files()
>>
>> And also see debugfs_init/debugfs_cleanup in 'struct drm_driver'.
>>
>> You probably want to be using that rather than rolling your own.  You
>> can have a look at omapdrm for a quite simple example, or i915 for a
>> more complex example.
>
> I actually tried to make use of those functions, but unfortunately it's
> not possible to hook it up properly. The reason is that I need to pass
> in some reference to the tegra_dc structure in order to read the
> registers, but the DRM debugfs support doesn't allow to do that. Or
> maybe it can. There's the void *arg argument that I could possibly use.
> Then again it won't allow the creation of separate directories for each
> of the display controllers. Or maybe I'm missing something.

yeah, no separate directories.. but you could use the void *arg.  It
is a bit awkward for dealing with multiple subdevices, we have the
same issue w/ omapdrm where dmm is a separate subdevice (and
dsi/dpi/hdmi/etc too shortly, as we merge omapdss and omapdrm).

But I guess better handling in drm for subdevices would help a lot of
the SoC platforms.  Maybe something that I'll give some more thought
later after the atomic pageflip/modeset stuff is sorted.


>> > +/* synchronization points */
>> > +#define SYNCPT_VBLANK0 26
>> > +#define SYNCPT_VBLANK1 27
>>
>> maybe these should be in dc.h?  Seems like these are related to the dc hw 
>> block?
>
> Yes, they could go into dc.h. This is one of the things that is likely
> to change at some point as more of the host1x support is added, which is
> where those syncpts are actually used.

hmm, are these values defined by the hw?  They look like register
offsets into the DC block?

>> > +int host1x_unregister_client(struct host1x *host1x,
>> > +struct host1x_client *client)
>> > +{
>> > +   struct host1x_drm_client *drm, *tmp;
>> > +   int err;
>> > +
>> > +   list_for_each_entry_safe(drm, tmp, >drm_active, list) {
>> > +   if (drm->client == client) {
>> > +   err = host1x_drm_exit(host1x);
>> > +   if (err < 0) {
>> > +   dev_err(host1x->dev, "host1x_drm_exit(): 
>> > %d\n",
>> > +   err);
>> > +   return err;
>> > +   }
>> > +
>> > +   host1x_remove_drm_client(host1x, drm);
>> > +   break;
>> > +   }
>> > +   }
>> > +
>> > +   mutex_lock(>clients_lock);
>> > +   list_del_init(>list);
>> > +   mutex_unlock(>clients_lock);
>> > +
>> > +   return 0;
>> > +}
>>
>> btw, if I understand the register/unregister client stuff, I think
>> there can be some potential issues.  If I understand correctly, you
>> will create the crtc's in register.  But unregister doesn't destroy
>> them, drm_mode_config_cleanup() when the container drm device is
>> unloaded does.  So if there is any possibility to unregister a client
>> without tearing down everything, you might get into some problems
>> here.
>>
>> Also, you might be breaking some assumptions about when the crtc's are
>> created.. at least if there is some possibility for userspace to sneak
>> in and do a getresources ioctl between the first and second client.
>> That might be easy enough to solve by adding some event for userspace
>> to get notified that it should getresources again.  The unregister is
>> what I worry about more.
>>
>> In general drm isn't set up to well for drivers that are a collection
>> of sub-devices.  It is probably worth trying to improve this, although
>> I am still a bit skittish about the edge cases, like what happens when
>> you unload a sub-device mid-modeset.  The issue comes up again for
>> common panel/display framework.
>>
>> But for now you might just want to do something to ensure that all the
>> sub-devices are loaded/unloaded together as a whole.
>
> The way that the

[PATCH] PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register

2012-11-09 Thread Bjorn Helgaas

On Thu, Nov 8, 2012 at 11:56 PM, Jingoo Han  wrote:
> According to the PCIe 3.0 spec, PCI_EXP_LNKCAP2_SLS_2_5GB is
> 1st bit of PCI_EXP_LNKCAP2 register, not 0th bit. So, the bit
> definition of supported link speed vector should be fixed.
>
> Signed-off-by: Jingoo Han 
> ---
>  include/uapi/linux/pci_regs.h |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 20ae747..14a3184 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -544,9 +544,9 @@
>  #define  PCI_EXP_OBFF_WAKE_EN  0x6000  /* OBFF using WAKE# signaling */
>  #define PCI_CAP_EXP_ENDPOINT_SIZEOF_V2 44  /* v2 endpoints end here */
>  #define PCI_EXP_LNKCAP244  /* Link Capability 2 */
> -#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x01/* Current Link Speed 2.5GT/s 
> */
> -#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x02/* Current Link Speed 5.0GT/s 
> */
> -#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x04/* Current Link Speed 8.0GT/s 
> */
> +#define  PCI_EXP_LNKCAP2_SLS_2_5GB 0x02/* Current Link Speed 2.5GT/s 
> */
> +#define  PCI_EXP_LNKCAP2_SLS_5_0GB 0x04/* Current Link Speed 5.0GT/s 
> */
> +#define  PCI_EXP_LNKCAP2_SLS_8_0GB 0x08/* Current Link Speed 8.0GT/s 
> */
>  #define  PCI_EXP_LNKCAP2_CROSSLINK 0x100 /* Crosslink supported */
>  #define PCI_EXP_LNKCTL248  /* Link Control 2 */
>  #define PCI_EXP_LNKSTA250  /* Link Status 2 */

I think this patch is correct, per spec sec 7.8.18.  If I apply it, I
think the comments should also be changed to "Supported Link Speed"
instead of "Current."

The only in-tree user of these symbols is
drm_pcie_get_speed_cap_mask().  Dave, can you ack/nack this?  I don't
want to apply this if it's going to break something there.

Bjorn

[PATCH -fixes RESEND] drm/vmwgfx: Fix hibernation device reset

The device would not reset properly when resuming from hibernation.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Dmitry Torokhov 
Cc: stable at vger.kernel.org
Cc: linux-graphics-maintainer at vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index f8b590c..f233473 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1084,6 +1084,11 @@ static void vmw_pm_complete(struct device *kdev)
struct drm_device *dev = pci_get_drvdata(pdev);
struct vmw_private *dev_priv = vmw_priv(dev);

+   mutex_lock(_priv->hw_mutex);
+   vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
+   (void) vmw_read(dev_priv, SVGA_REG_ID);
+   mutex_unlock(_priv->hw_mutex);
+
/**
 * Reclaim 3d reference held by fbdev and potentially
 * start fifo.
-- 
1.7.4.4

[PATCH v7 0/8] of: add display helper

2012-11-09 Thread Steffen Trumtrar

On Thu, Nov 08, 2012 at 03:35:47PM -0600, Rob Herring wrote:
> On 10/31/2012 04:28 AM, Steffen Trumtrar wrote:
> > Hi!
> > 
> > Finally, v7 of the series.
> > 
> > Changes since v6:
> > - get rid of some empty lines etc.
> > - move functions to their subsystems
> > - split of_ from non-of_ functions
> > - add at least some kerneldoc to some functions
> > 
> > Regards,
> > Steffen
> > 
> > 
> > Steffen Trumtrar (8):
> >   video: add display_timing struct and helpers
> >   of: add helper to parse display timings
> >   of: add generic videomode description
> >   video: add videomode helpers
> >   fbmon: add videomode helpers
> >   fbmon: add of_videomode helpers
> >   drm_modes: add videomode helpers
> >   drm_modes: add of_videomode helpers
> > 
> >  .../devicetree/bindings/video/display-timings.txt  |  139 +++
> >  drivers/gpu/drm/drm_modes.c|   78 +
> >  drivers/of/Kconfig |   12 ++
> >  drivers/of/Makefile|2 +
> >  drivers/of/of_display_timings.c|  185 
> > 
> >  drivers/of/of_videomode.c  |   47 +
> 
> Not sure why you moved this, but please move this back to drivers/video.
> We're trying to move subsystem specific pieces out of drivers/of.
> 
> Rob
> 

Hm, the of_xxx part always was in drivers/of, but I can move that. No problem.

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 1/2] drm: Add NVIDIA Tegra20 support

On Fri, Nov 9, 2012 at 7:59 AM, Thierry Reding
 wrote:
> This commit adds a KMS driver for the Tegra20 SoC. This includes basic
> support for host1x and the two display controllers found on the Tegra20
> SoC. Each display controller can drive a separate RGB/LVDS output.
>
> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/gpu/drm/nvidia,tegra20-host1x.txt | 191 +
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tegra/Kconfig  |  23 +
>  drivers/gpu/drm/tegra/Makefile |   7 +
>  drivers/gpu/drm/tegra/dc.c | 817 
> +
>  drivers/gpu/drm/tegra/dc.h | 384 ++
>  drivers/gpu/drm/tegra/drm.c| 115 +++
>  drivers/gpu/drm/tegra/drm.h| 233 ++
>  drivers/gpu/drm/tegra/fb.c |  56 ++
>  drivers/gpu/drm/tegra/host1x.c | 313 
>  drivers/gpu/drm/tegra/output.c | 275 +++
>  drivers/gpu/drm/tegra/rgb.c| 200 +
>  13 files changed, 2617 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
>  create mode 100644 drivers/gpu/drm/tegra/Kconfig
>  create mode 100644 drivers/gpu/drm/tegra/Makefile
>  create mode 100644 drivers/gpu/drm/tegra/dc.c
>  create mode 100644 drivers/gpu/drm/tegra/dc.h
>  create mode 100644 drivers/gpu/drm/tegra/drm.c
>  create mode 100644 drivers/gpu/drm/tegra/drm.h
>  create mode 100644 drivers/gpu/drm/tegra/fb.c
>  create mode 100644 drivers/gpu/drm/tegra/host1x.c
>  create mode 100644 drivers/gpu/drm/tegra/output.c
>  create mode 100644 drivers/gpu/drm/tegra/rgb.c
>
> diff --git 
> a/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt 
> b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
> new file mode 100644
> index 000..b4fa934
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/drm/nvidia,tegra20-host1x.txt
> @@ -0,0 +1,191 @@
> +NVIDIA Tegra host1x
> +
> +Required properties:
> +- compatible: "nvidia,tegra-host1x"
> +- reg: Physical base address and length of the controller's registers.
> +- interrupts: The interrupt outputs from the controller.
> +- #address-cells: The number of cells used to represent physical base 
> addresses
> +  in the host1x address space. Should be 1.
> +- #size-cells: The number of cells used to represent the size of an address
> +  range in the host1x address space. Should be 1.
> +- ranges: The mapping of the host1x address space to the CPU address space.
> +
> +The host1x top-level node defines a number of children, each representing one
> +of the following host1x client modules:
> +
> +- mpe: video encoder
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-mpe"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +- vi: video input
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-vi"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +- epp: encoder pre-processor
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-epp"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +- isp: image signal processor
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-isp"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +- gr2d: 2D graphics engine
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-gr2d"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +- gr3d: 3D graphics engine
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-gr3d"
> +  - reg: Physical base address and length of the controller's registers.
> +
> +- dc: display controller
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-dc"
> +  - reg: Physical base address and length of the controller's registers.
> +  - interrupts: The interrupt outputs from the controller.
> +
> +  Each display controller node has a child node, named "rgb", that represents
> +  the RGB output associated with the controller. It can take the following
> +  optional properties:
> +  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID 
> probing
> +  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
> +  - nvidia,edid: supplies a binary EDID blob
> +
> +- hdmi: High Definition Multimedia Interface
> +
> +  Required properties:
> +  - compatible: "nvidia,tegra-hdmi"
> +  - reg: Physical base address and length

[PATCH] drm: fix drm_framebuffer cleanup.

On Fri, Nov 9, 2012 at 1:39 AM, Inki Dae  wrote:
> This patch fixes access issue to invalid memory region.
>
> crtc had only one drm_framebuffer object so when framebuffer
> cleanup was requested after page flip, it'd try to disable
> hardware overlay to current crtc.
> But if current crtc points to another drm_framebuffer,
> This may induce invalid memory access.

btw, this should instead be done by holding a ref to the GEM
object(s)..  or these days you can increment the reference count on
the fb and let the fb hold ref's to the GEM object(s) (which makes it
a bit easier to deal with multi-planar formats)

BR,
-R

> Assume that some application are doing page flip with two
> drm_framebuffer objects. At this time, if second drm_framebuffer
> is set to current crtc and the cleanup to first drm_framebuffer
> is requested once drm release is requested, then first
> drm_framebuffer would be cleaned up without disabling
> hardware overlay because current crtc points to second
> drm_framebuffer. After that, gem buffer to first drm_framebuffer
> would be released and this makes dma access invalid memory region.
>
> This patch adds drm_framebuffer to drm_crtc structure as member
> and makes drm_framebuffer_cleanup function check if fb->crtc is
> same as desired fb. And also when setcrtc and pageflip are
> requested, it makes each drm_framebuffer point to current crtc.
>
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/drm_crtc.c |7 ---
>  include/drm/drm_crtc.h |1 +
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index ef1b221..5c04bd4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -386,7 +386,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>
> /* remove from any CRTC */
> list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> -   if (crtc->fb == fb) {
> +   if (fb->crtc == crtc) {
> /* should turn off the crtc */
> memset(, 0, sizeof(struct drm_mode_set));
> set.crtc = crtc;
> @@ -2027,6 +2027,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> set.mode = mode;
> set.connectors = connector_set;
> set.num_connectors = crtc_req->count_connectors;
> +   fb->crtc = crtc;
> set.fb = fb;
> ret = crtc->funcs->set_config();
>
> @@ -3635,8 +3636,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> spin_unlock_irqrestore(>event_lock, flags);
> kfree(e);
> }
> -   }
> -
> +   } else
> +   fb->crtc = crtc;
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3fa18b7..92889be 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -256,6 +256,7 @@ struct drm_framebuffer {
> struct kref refcount;
> struct list_head head;
> struct drm_mode_object base;
> +   struct drm_crtc *crtc;
> const struct drm_framebuffer_funcs *funcs;
> unsigned int pitches[4];
> unsigned int offsets[4];
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm radeon + nouveau fixes

2012-11-09 Thread Dave Airlie


Hi Linus,

just radeon and nouveau, mostly regressions fixers, and a couple of radeon 
register checker fixes.

Dave.

The following changes since commit 695ddeb457584a602f2ba117d08ce37cf6ec1589:

  drm/radeon: fix typo in evergreen_mc_resume() (2012-11-07 10:53:49 +1000)

are available in the git repository at:

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

for you to fetch changes up to 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0:

  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-11-09 
14:57:02 +1000)



Alex Deucher (3):
  drm/radeon/dce3: switch back to old pll allocation order for discrete
  drm/radeon/cayman: add some missing regs to the VM reg checker
  drm/radeon/si: add some missing regs to the VM reg checker

Dave Airlie (2):
  Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-nouveau-fixes' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Kelly Doran (1):
  drm/nvc0/disp: fix regression in vblank semaphore release

Maarten Lankhorst (1):
  drm/nouveau: fix acpi edid retrieval

Marcin Slusarz (3):
  drm/nv41/vm: fix typo in type name
  drm/nv40/graph: fix typo in type names
  drm/nv40/mpeg: fix context handling

 drivers/gpu/drm/nouveau/core/engine/disp/nv50.c  | 20 +
 drivers/gpu/drm/nouveau/core/engine/graph/nv40.c |  4 +-
 drivers/gpu/drm/nouveau/core/engine/mpeg/nv40.c  |  2 +-
 drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c  |  2 +-
 drivers/gpu/drm/radeon/atombios_crtc.c   | 54 ++--
 drivers/gpu/drm/radeon/evergreen_cs.c|  3 ++
 drivers/gpu/drm/radeon/evergreend.h  |  4 ++
 drivers/gpu/drm/radeon/si.c  |  1 +
 drivers/gpu/drm/radeon/sid.h |  1 +
 10 files changed, 57 insertions(+), 36 deletions(-)

[Bug 56414] [Regression nv 0de9 ]System boot fails with -fixes kernel

https://bugs.freedesktop.org/show_bug.cgi?id=56414

lu hua  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #10 from lu hua  ---
Verified.Fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/c3c482e3/attachment.html>

[Bug 56414] [Regression nv 0de9 ]System boot fails with -fixes kernel

https://bugs.freedesktop.org/show_bug.cgi?id=56414

lu hua  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from lu hua  ---
Fixed on commit 4a8dece21eea0ad6aca442272673d48693cd93b4.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121109/69dbd508/attachment.html>

Re: [PATCH v7 0/8] of: add display helper

2012-11-09 Thread Steffen Trumtrar

On Thu, Nov 08, 2012 at 03:35:47PM -0600, Rob Herring wrote:
 On 10/31/2012 04:28 AM, Steffen Trumtrar wrote:
  Hi!
  
  Finally, v7 of the series.
  
  Changes since v6:
  - get rid of some empty lines etc.
  - move functions to their subsystems
  - split of_ from non-of_ functions
  - add at least some kerneldoc to some functions
  
  Regards,
  Steffen
  
  
  Steffen Trumtrar (8):
video: add display_timing struct and helpers
of: add helper to parse display timings
of: add generic videomode description
video: add videomode helpers
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
  
   .../devicetree/bindings/video/display-timings.txt  |  139 +++
   drivers/gpu/drm/drm_modes.c|   78 +
   drivers/of/Kconfig |   12 ++
   drivers/of/Makefile|2 +
   drivers/of/of_display_timings.c|  185 
  
   drivers/of/of_videomode.c  |   47 +
 
 Not sure why you moved this, but please move this back to drivers/video.
 We're trying to move subsystem specific pieces out of drivers/of.
 
 Rob
 

Hm, the of_xxx part always was in drivers/of, but I can move that. No problem.

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: add vm_ops to specific gem mmaper

This patch makes it takes a reference to gem object when
specific gem mmap is requested. For this, it sets
dev-driver-gem_vm_ops to vma-vm_ops.

And this patch is based on exynos-drm-next-iommu branch of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |   20 +++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 50d73f1..b7ce8b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -372,10 +372,13 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp,
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buffer;
unsigned long vm_size;
+   int ret;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
vma-vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
+   vma-vm_private_data = obj;
+   vma-vm_ops = obj-dev-driver-gem_vm_ops;
 
update_vm_cache_attr(exynos_gem_obj, vma);
 
@@ -391,9 +394,22 @@ static int exynos_drm_gem_mmap_buffer(struct file *filp,
if (vm_size  buffer-size)
return -EINVAL;
 
-   return dma_mmap_attrs(obj-dev-dev, vma, buffer-kvaddr,
+   ret = dma_mmap_attrs(obj-dev-dev, vma, buffer-kvaddr,
buffer-dma_addr, buffer-size,
buffer-dma_attrs);
+   if (ret  0) {
+   DRM_ERROR(failed to mmap.\n);
+   return ret;
+   }
+
+   /*
+* take a reference to this mapping of the object. And this reference
+* is unreferenced by the corresponding vm_close call.
+*/
+   drm_gem_object_reference(obj);
+   drm_vm_open_locked(obj-dev, vma);
+
+   return 0;
 }
 
 static const struct file_operations exynos_drm_gem_fops = {
@@ -426,6 +442,8 @@ int exynos_drm_gem_mmap_ioctl(struct drm_device *dev, void 
*data,
addr = vm_mmap(obj-filp, 0, args-size,
PROT_READ | PROT_WRITE, MAP_SHARED, 0);
 
+   /* restore it to drm_file object. */
+   obj-filp-private_data = file_priv;
drm_gem_object_unreference_unlocked(obj);
 
if (IS_ERR((void *)addr))
-- 
1.7.4.1

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

Re: [PATCH] drm: fix drm_framebuffer cleanup.

2012-11-09 Thread Prathyush K

On Fri, Nov 9, 2012 at 1:09 PM, Inki Dae inki@samsung.com wrote:

 This patch fixes access issue to invalid memory region.

 crtc had only one drm_framebuffer object so when framebuffer
 cleanup was requested after page flip, it'd try to disable
 hardware overlay to current crtc.
 But if current crtc points to another drm_framebuffer,
 This may induce invalid memory access.

 Assume that some application are doing page flip with two
 drm_framebuffer objects. At this time, if second drm_framebuffer
 is set to current crtc and the cleanup to first drm_framebuffer
 is requested once drm release is requested, then first
 drm_framebuffer would be cleaned up without disabling
 hardware overlay because current crtc points to second
 drm_framebuffer. After that, gem buffer to first drm_framebuffer
 would be released and this makes dma access invalid memory region.



I am confused regarding this. If crtc points to second frame buffer, then
the dma is accessing the memory region
of the second framebuffer. Why can't we free the first framebuffer and its
gem buffer?

With this patch, there is no way to free a framebuffer (which has been set
to a crtc), without disabling
the crtc.

Consider this example:
I have three framebuffers (0, 1, 2) and I set them to a crtc A one by one.
So with your patch,
fb[0]-crtc = A
fb[1]-crtc = A
fb[2]-crtc = A

After this, I am using only framebuffer 0 and 1 i.e. 0 and 1 are being page
flipped.
Now, I want to remove framebuffer 2.
fb[2]-crtc = A .. so while removing the framebuffer, we will end up
disabling the crtc
which is not correct.

I think, there should be an additional interface to unset a fb to a crtc.
That way, we can
reset the crtc inside a framebuffer so that it can be freed if not in use.
i.e. fb[2]-crtc = NULL;






 This patch adds drm_framebuffer to drm_crtc structure as member
 and makes drm_framebuffer_cleanup function check if fb-crtc is
 same as desired fb. And also when setcrtc and pageflip are
 requested, it makes each drm_framebuffer point to current crtc.

 Signed-off-by: Inki Dae inki@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/gpu/drm/drm_crtc.c |7 ---
  include/drm/drm_crtc.h |1 +
  2 files changed, 5 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index ef1b221..5c04bd4 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -386,7 +386,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)

 /* remove from any CRTC */
 list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
 -   if (crtc-fb == fb) {
 +   if (fb-crtc == crtc) {
 /* should turn off the crtc */
 memset(set, 0, sizeof(struct drm_mode_set));
 set.crtc = crtc;
 @@ -2027,6 +2027,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void
 *data,
 set.mode = mode;
 set.connectors = connector_set;
 set.num_connectors = crtc_req-count_connectors;
 +   fb-crtc = crtc;
 set.fb = fb;
 ret = crtc-funcs-set_config(set);

 @@ -3635,8 +3636,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 spin_unlock_irqrestore(dev-event_lock, flags);
 kfree(e);
 }
 -   }
 -
 +   } else
 +   fb-crtc = crtc;
  out:
 mutex_unlock(dev-mode_config.mutex);
 return ret;
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index 3fa18b7..92889be 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -256,6 +256,7 @@ struct drm_framebuffer {
 struct kref refcount;
 struct list_head head;
 struct drm_mode_object base;
 +   struct drm_crtc *crtc;
 const struct drm_framebuffer_funcs *funcs;
 unsigned int pitches[4];
 unsigned int offsets[4];
 --
 1.7.4.1

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

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

[PATCH -fixes RESEND] drm/vmwgfx: Fix hibernation device reset