Fw: [Intel-gfx] [PATCH] intel: add a timed wait function

[Daniel Vetter]

On Wed, May 30, 2012 at 7:41 PM, Eric Anholt  wrote:
> I guess GL_ALREADY_SIGNALED handling will be done using a check for
> bo_busy() before calling this.

I've just read through the mesa code and gl_already_signalled seems to
be handled already by core mesa code in _mesa_ClientWaitSync (if the
driver sets syncObject->Status correctly). So I guess the current
kernel code should work as-is and only the libdrm interface needs some
colour adjustments around the timeout parameter.
-Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[PATCH/RFC] drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

[Laurent Pinchart]

Hi Michel,

On Wednesday 30 May 2012 13:29:06 Michel D?nzer wrote:
> On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote:
> > DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
> > for KMS drivers.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/gpu/drm/drm_irq.c |5 -
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > My understanding of the DRM framework tells me that calling
> > DRM_IOCTL_MODESET_CTL on a KMS driver is not only unneeded, but could also
> > mess up its internal state. Did I get it right ?
> 
> Yes, good catch.
> 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index c798eea..03f16f3 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -974,7 +974,6 @@ EXPORT_SYMBOL(drm_vblank_off);
> > 
> >   * drm_vblank_pre_modeset - account for vblanks across mode sets
> >   * @dev: DRM device
> >   * @crtc: CRTC in question
> > - * @post: post or pre mode set?
> >   *
> >   * Account for vblank events across mode setting events, which will
> >   likely
> >   * reset the hardware frame counter.
> 
> This hunk should really be in a separate patch,

I've thought about sending a separate patch, but as the change only touched a 
single line of comment related to the same function, I ended up not splitting 
it. I can resubmit two patches if needed.

> but other than that
> 
> Reviewed-by: Michel D?nzer 

Thank you.

-- 
Regards,

Laurent Pinchart

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Sascha Hauer]

On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
> 
> Only flat panel outputs using the parallel interface are supported.
> Support for SYS panels, HDMI and DSI is currently not implemented.
> 
> Signed-off-by: Laurent Pinchart 
> ---

[...]

> +int shmob_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + struct drm_file *priv = filp->private_data;
> + struct drm_device *dev = priv->minor->dev;
> + struct drm_gem_mm *mm = dev->mm_private;
> + struct shmob_drm_gem_object *sobj;
> + struct drm_local_map *map;
> + struct drm_gem_object *obj;
> + struct drm_hash_item *hash;
> + pgprot_t prot;
> + int ret;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + mutex_lock(>struct_mutex);
> +
> + if (drm_ht_find_item(>offset_hash, vma->vm_pgoff, )) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + map = drm_hash_entry(hash, struct drm_map_list, hash)->map;
> + if (!map ||
> + ((map->flags & _DRM_RESTRICTED) && !capable(CAP_SYS_ADMIN))) {
> + ret =  -EPERM;
> + goto out_unlock;
> + }
> +
> + /* Check for valid size. */
> + if (map->size < vma->vm_end - vma->vm_start) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + obj = map->handle;
> + if (!obj->dev->driver->gem_vm_ops) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + sobj = to_shmob_gem_object(obj);
> + prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> + ret = remap_pfn_range(vma, vma->vm_start, sobj->dma >> PAGE_SHIFT,
> +   vma->vm_end - vma->vm_start, prot);
> + if (ret < 0)
> + goto out_unlock;
> +
> + vma->vm_flags |= VM_RESERVED | VM_IO | VM_PFNMAP | VM_DONTEXPAND;
> + vma->vm_ops = obj->dev->driver->gem_vm_ops;
> + vma->vm_private_data = obj;
> + vma->vm_page_prot = prot;
> +
> + /* Take a ref for this mapping of the object, so that the fault
> +  * handler can dereference the mmap offset's pointer to the object.
> +  * This reference is cleaned up by the corresponding vm_close
> +  * (which should happen whether the vma was created by this call, or
> +  * by a vm_open due to mremap or partial unmap or whatever).
> +  */
> + drm_gem_object_reference(obj);
> +
> + drm_vm_open_locked(dev, vma);
> +
> +out_unlock:
> + mutex_unlock(>struct_mutex);
> +
> + return ret;
> +}

I just noticed this function is nearly a copy of drm_gem_mmap except for
the the additional remap_pfn_range here. Would it make sense to turn
drm_gem_mmap into a wrapper around a drm_gem_mmap_locked, call this one
from here and add the remap_pfn_range?

If yes, I would do so in my cma gem helper patch.

Sascha

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

[PATCH] drm/radeon: fix regression in UMS CS ioctl

[Jerome Glisse]

On Wed, May 30, 2012 at 10:09 AM,   wrote:
> From: Alex Deucher 
>
> radeon_cs_parser_init is called by both the legacy UMS
> CS ioctl and the KMS CS ioctl. ?Protect KMS specific
> pieces of the code by checking that rdev is not NULL.
>
> Reported-by: Michael Burian 
>
> Signed-off-by: Alex Deucher 
Reviewed-by: Jerome Glisse 
> Cc: stable at vger.kernel.org
> ---
> ?drivers/gpu/drm/radeon/radeon_cs.c | ? 31 +--
> ?1 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 0137689..142f894 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -147,6 +147,7 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser 
> *p)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sync_to_ring, p->ring);
> ?}
>
> +/* XXX: note that this is called from the legacy UMS CS ioctl as well */
> ?int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
> ?{
> ? ? ? ?struct drm_radeon_cs *cs = data;
> @@ -245,22 +246,24 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
> void *data)
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> - ? ? ? if ((p->cs_flags & RADEON_CS_USE_VM) &&
> - ? ? ? ? ? !p->rdev->vm_manager.enabled) {
> - ? ? ? ? ? ? ? DRM_ERROR("VM not active on asic!\n");
> - ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? }
> -
> - ? ? ? /* we only support VM on SI+ */
> - ? ? ? if ((p->rdev->family >= CHIP_TAHITI) &&
> - ? ? ? ? ? ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
> - ? ? ? ? ? ? ? DRM_ERROR("VM required on SI+!\n");
> - ? ? ? ? ? ? ? return -EINVAL;
> - ? ? ? }
> + ? ? ? /* these are KMS only */
> + ? ? ? if (p->rdev) {
> + ? ? ? ? ? ? ? if ((p->cs_flags & RADEON_CS_USE_VM) &&
> + ? ? ? ? ? ? ? ? ? !p->rdev->vm_manager.enabled) {
> + ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("VM not active on asic!\n");
> + ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? ? ? ? ? }
>
> - ? ? ? if (radeon_cs_get_ring(p, ring, priority))
> - ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? ? ? ? ? /* we only support VM on SI+ */
> + ? ? ? ? ? ? ? if ((p->rdev->family >= CHIP_TAHITI) &&
> + ? ? ? ? ? ? ? ? ? ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
> + ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("VM required on SI+!\n");
> + ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? ? ? ? ? }
>
> + ? ? ? ? ? ? ? if (radeon_cs_get_ring(p, ring, priority))
> + ? ? ? ? ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? }
>
> ? ? ? ?/* deal with non-vm */
> ? ? ? ?if ((p->chunk_ib_idx != -1) &&
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] DRM: add drm gem CMA helper

[Sascha Hauer]

On Wed, May 30, 2012 at 05:40:13PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
> 
> Thank you for the patch. I've successfully tested the helper with the new SH 
> Mobile DRM driver. Just a couple of comments below in addition to Lars' 
> comments (this is not a full review, just details that caught my attention 
> when comparing the code with my implementation, and trying to use it).
> 
> > +/*
> > + * drm_gem_cma_mmap - (struct file_operation)->mmap callback function
> > + */
> > +int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
> > +{
> > +   int ret;
> > +
> > +   ret = drm_gem_mmap(filp, vma);
> > +   if (ret)
> > +   return ret;
> > +
> > +   vma->vm_flags &= ~VM_PFNMAP;
> > +   vma->vm_flags |= VM_MIXEDMAP;
> 
> Why is this a mixed map ?

Honestly, I don't know. This is copied from the exynos driver. I don't
know much about these flags, so if you think something else is better
here than you're probably right ;)

> 
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
> 
> My implementation maps the whole buffer in one go at mmap time, not page by 
> page at page fault time. Isn't that more efficient when mapping frame buffer 
> memory ?

I remember Alan has mentioned this in an earlier review. I'll update
the patch accordingly.

I will fix this and the other things you mentioned and repost.

Thanks
 Sascha

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

Lots of i915/drm spew on 3.4

[Dave Jones]

On Wed, May 30, 2012 at 05:58:48PM -0400, Dave Jones wrote:
 > On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
 >  > On Wed, May 30, 2012 at 11:31 PM, Dave Jones  wrote:
 >  > > On this hardware:
 >  > >
 >  > > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ 
 > Integrated Graphics Controller (rev 02)
 >  > >
 >  > > I get this every boot with Linus current tree (up to 
 > af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
 >  > 
 >  > Just a quick question, is this a regression? 
 > 
 > seems so, I don't see it on 3.3
 > 
 >  > If so, can you please
 >  > attach the output of xrandr --verbose from a noisy and a quite kernel
 >  > (otherwise just please attach it from this noisy kernel).
 > 
 > this machine runs headless, so has no X installed right now, I'll get it in 
 > a while.

Attached.

Dave 
-- next part --
A non-text attachment was scrubbed...
Name: xrandr-3.3
Type: application/x-troff-man
Size: 7704 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/3a1fc4a2/attachment-0002.man>
-- next part --
A non-text attachment was scrubbed...
Name: xrandr-3.4
Type: application/x-troff-man
Size: 21691 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/3a1fc4a2/attachment-0003.man>

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #56 from Alexandre Demers  
2012-05-30 11:18:28 PDT ---
(In reply to comment #55)
> (In reply to comment #54)
> > On latest git (3cd7bee48f7caf7850ea64d40f43875d4c975507), in
> > src/gallium/drivers/r600/r66_hw_context.c, on line 194, shouldn't it be:
> > - int offset
> > + unsigned offset
> 
> That might be slightly better, but it doesn't really matter. It's the offset
> from the start of the MMIO aperture, so it would only matter if the register
> aperture grew beyond 2GB, which we're almost 5 orders of magnitude short of.
> Very unlikely.
> 
> 
> > Also, at line 1259, I'm not quite sure why it is shifted by 2. Most of the
> > time, offset is usually shifted by 8.
> 
> It's just converting offset from units of 32 bits to bytes.
> 
> 
> > Just looking through the code to see if something could have been missed...
> 
> Right now it would be most useful to track down why radeon_bomgr_find_va /
> radeon_bomgr_force_va ends up returning the offset the kernel complains about.

What do you suggest? I'll be playing with kernel 3.5-rc1 when available, but I
don't think that will fix it. Is there or could there be a way to track what's
going on with a debug switch or something similar?

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

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Wed, May 30, 2012 at 08:39:13AM -0700, Linus Torvalds wrote:
> On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
> >
> > Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> > drm.debug=0xe, reproduce the noise and then attach the full dmesg?
> 
> Hmm. Now *I* can't reproduce it either.
> 
> I have updated my system in the meantime, so maybe this is related to
> that. However, I suspect it's more likely that it's some race
> condition, because when I got it, I got a *lot* of it, but they were
> all very tightly bunched together:
> 
>  [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
>  [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
> intel_dp_check_edp+0x5d/0xb0()
> 
> ie that's 12 of those warnings (each of them with that huge backtrace
> etc), but they are all within 0.03 seconds of each other. So I suspect
> it needs to hit some particular timing window, and I was just
> (un)lucky.
> 
> Because when I try it now with DRM debugging, I can't hit it. And just
> to make sure, I re-did the test without debugging too (in case the
> debugging would have changed timing), but can't reproduce it that way
> either.

Hm, that's pretty strange that you can't reproduce this any more. We check
this has_edp stuff once at boot and then never touch it again. Getting all
these backtraces in close bunches is expected, because we have a lot of
these checks - because we've had a lot of bugs :(. Did you by chance
upgrade the firmware or switch from efi booting to bios booting - we use
the vbios to detect part of the edp configuration?

The only other thing I could think of is whether disabling the internal
panel changes anything. Iirc that's an edp panel on macbook airs, so this
could paper over most of the warnings if it's enabled.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Lots of i915/drm spew on 3.4

[Dave Jones]

On Wed, May 30, 2012 at 11:51:54PM +0200, Daniel Vetter wrote:
 > On Wed, May 30, 2012 at 11:31 PM, Dave Jones  wrote:
 > > On this hardware:
 > >
 > > 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
 > > Graphics Controller (rev 02)
 > >
 > > I get this every boot with Linus current tree (up to 
 > > af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)
 > 
 > Just a quick question, is this a regression? 

seems so, I don't see it on 3.3

 > If so, can you please
 > attach the output of xrandr --verbose from a noisy and a quite kernel
 > (otherwise just please attach it from this noisy kernel).

this machine runs headless, so has no X installed right now, I'll get it in a 
while.

Dave

[PATCH] DRM: add drm gem CMA helper

[Laurent Pinchart]

Hi Sascha,

Thank you for the patch. I've successfully tested the helper with the new SH 
Mobile DRM driver. Just a couple of comments below in addition to Lars' 
comments (this is not a full review, just details that caught my attention 
when comparing the code with my implementation, and trying to use it).

On Tuesday 29 May 2012 16:10:27 Sascha Hauer wrote:
> Many embedded drm devices do not have a IOMMU and no dedicated
> memory for graphics. These devices use CMA (Contiguous Memory
> Allocator) backed graphics memory. This patch provides helper
> functions to be able to share the code.
> 
> Signed-off-by: Sascha Hauer 
> ---
> 
> Lars-Peter, please let me know if this fits your needs or if you are missing
> something.
> 
>  drivers/gpu/drm/Kconfig  |6 +
>  drivers/gpu/drm/Makefile |1 +
>  drivers/gpu/drm/drm_gem_cma_helper.c |  321 +++
>  include/drm/drm_gem_cma_helper.h |   47 +
>  4 files changed, 375 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c
>  create mode 100644 include/drm/drm_gem_cma_helper.h

[snip]

> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c new file mode 100644
> index 000..75534ff
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -0,0 +1,321 @@

[snip]

> +/*
> + * drm_gem_cma_create - allocate an object with the given size
> + *
> + * returns a struct drm_gem_cma_obj* on success or ERR_PTR values
> + * on failure.
> + */
> +struct drm_gem_cma_obj *drm_gem_cma_create(struct drm_device *drm,
> + unsigned int size)
> +{
> + struct drm_gem_cma_obj *cma_obj;
> + struct drm_gem_object *gem_obj;
> + int ret;
> +
> + size = roundup(size, PAGE_SIZE);

As PAGE_SIZE is guaranteed to be a power of two, you can use round_up, which 
should be faster.

> +
> + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
> + if (!cma_obj)
> + return ERR_PTR(-ENOMEM);
> +
> + cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
> + (dma_addr_t *)_obj->paddr,
> + GFP_KERNEL | __GFP_NOWARN);
> + if (!cma_obj->vaddr) {
> + dev_err(drm->dev, "failed to allocate buffer with size %d\n", 
> size);
> + ret = -ENOMEM;
> + goto err_dma_alloc;
> + }
> +
> + gem_obj = _obj->base;
> +
> + ret = drm_gem_object_init(drm, gem_obj, size);
> + if (ret)
> + goto err_obj_init;
> +
> + ret = drm_gem_create_mmap_offset(gem_obj);
> + if (ret)
> + goto err_create_mmap_offset;
> +
> + return cma_obj;
> +
> +err_create_mmap_offset:
> + drm_gem_object_release(gem_obj);
> +
> +err_obj_init:
> + drm_gem_cma_buf_destroy(drm, cma_obj);
> +
> +err_dma_alloc:
> + kfree(cma_obj);
> +
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_create);

[snip]

> +/*
> + * drm_gem_cma_mmap - (struct file_operation)->mmap callback function
> + */
> +int drm_gem_cma_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + int ret;
> +
> + ret = drm_gem_mmap(filp, vma);
> + if (ret)
> + return ret;
> +
> + vma->vm_flags &= ~VM_PFNMAP;
> + vma->vm_flags |= VM_MIXEDMAP;

Why is this a mixed map ?

> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);

My implementation maps the whole buffer in one go at mmap time, not page by 
page at page fault time. Isn't that more efficient when mapping frame buffer 
memory ?

[snip]

> diff --git a/include/drm/drm_gem_cma_helper.h
> b/include/drm/drm_gem_cma_helper.h new file mode 100644
> index 000..53b007c
> --- /dev/null
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -0,0 +1,47 @@
> +#ifndef __DRM_GEM_DMA_ALLOC_HELPER_H__
> +#define __DRM_GEM_DMA_ALLOC_HELPER_H__

Should this be __DRM_GEM_CMA_HELPER_H__ ?

> +
> +struct drm_gem_cma_obj {
> + struct drm_gem_object base;
> + dma_addr_t paddr;
> + void __iomem *vaddr;
> +};

All drm objects end with _object, would it be better to rename this to struct 
drm_gem_cma_object ?

-- 
Regards,

Laurent Pinchart

Lots of i915/drm spew on 3.4

[Dave Jones]

On this hardware:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated 
Graphics Controller (rev 02)

I get this every boot with Linus current tree (up to 
af56e0aa35f3ae2a4c1a6d1000702df1dd78cb76)

[8.046291] udevadm used greatest stack depth: 4952 bytes left
[8.153209] [drm] Initialized drm 1.1.0 20060810
[8.491107] i915 :00:02.0: setting latency timer to 64
[8.495118] console_init used greatest stack depth: 4784 bytes left
[8.751664] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[8.751756] [drm] Driver supports precise vblank timestamp query.
[8.754836] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[8.992409] [ cut here ]
[8.992519] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[8.992634] Hardware name: 
[8.992702] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[8.992877] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[8.992989] Pid: 126, comm: udevd Not tainted 3.4.0+ #3
[8.993711] Call Trace:
[8.993790]  [] warn_slowpath_common+0x7f/0xc0
[8.993872]  [] warn_slowpath_fmt+0x46/0x50
[8.993971]  [] drm_object_attach_property+0x4d/0x50 [drm]
[8.994113]  [] drm_connector_attach_property+0x15/0x20 
[drm]
[8.994270]  [] 
intel_sdvo_create_enhance_property+0xde4/0xe20 [i915]
[8.994404]  [] ? drm_property_add_enum+0xca/0x140 [drm]
[8.994524]  [] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[8.994643]  [] intel_sdvo_init+0x4fd/0x7c0 [i915]
[8.994759]  [] intel_modeset_init+0xdcb/0xea0 [i915]
[8.994868]  [] i915_driver_load+0xa2e/0xb50 [i915]
[8.994965]  [] ? drm_get_minor+0x261/0x300 [drm]
[8.995105]  [] drm_get_pci_dev+0x186/0x2d0 [drm]
[8.995189]  [] ? trace_hardirqs_on+0xd/0x10
[8.995302]  [] i915_pci_probe+0x16/0x20 [i915]
[8.995385]  [] local_pci_probe+0x5c/0xd0
[8.995464]  [] pci_device_probe+0x111/0x120
[8.995547]  [] driver_probe_device+0x92/0x390
[8.995628]  [] __driver_attach+0xab/0xb0
[8.995708]  [] ? driver_probe_device+0x390/0x390
[8.995788]  [] bus_for_each_dev+0x55/0x90
[8.995867]  [] ? 0xa00f1fff
[8.995945]  [] driver_attach+0x1e/0x20
[8.996068]  [] bus_add_driver+0x1b8/0x2b0
[8.996151]  [] ? 0xa00f1fff
[8.996230]  [] driver_register+0x77/0x150
[8.996309]  [] ? 0xa00f1fff
[8.996388]  [] __pci_register_driver+0x6f/0xf0
[8.996468]  [] ? 0xa00f1fff
[8.996561]  [] drm_pci_init+0x11a/0x130 [drm]
[8.996642]  [] ? 0xa00f1fff
[8.996751]  [] i915_init+0x8b/0x8d [i915]
[8.996833]  [] do_one_initcall+0x12a/0x180
[8.996915]  [] sys_init_module+0x1116/0x2210
[8.996996]  [] ? ddebug_proc_open+0xd0/0xd0
[8.997119]  [] ? lock_release_holdtime.part.26+0xf/0x180
[8.997208]  [] system_call_fastpath+0x16/0x1b
[8.997284] ---[ end trace 533bf7565e4f928e ]---
[9.002178] [ cut here ]
[9.002272] WARNING: at drivers/gpu/drm/drm_crtc.c:2886 
drm_object_attach_property+0x4d/0x50 [drm]()
[9.002385] Hardware name: 
[9.002453] Failed to attach object property (type: 0xc0c0c0c0). Please 
increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see this message on the 
same object type.
[9.002626] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm 
i2c_core
[9.002738] Pid: 126, comm: udevd Tainted: GW3.4.0+ #3
[9.002811] Call Trace:
[9.002885]  [] warn_slowpath_common+0x7f/0xc0
[9.002965]  [] warn_slowpath_fmt+0x46/0x50
[9.003105]  [] drm_object_attach_property+0x4d/0x50 [drm]
[9.003205]  [] drm_connector_attach_property+0x15/0x20 
[drm]
[9.003358]  [] 
intel_sdvo_create_enhance_property+0x1fe/0xe20 [i915]
[9.003491]  [] ? drm_property_add_enum+0xca/0x140 [drm]
[9.003611]  [] intel_sdvo_tv_init+0x1b6/0x1e0 [i915]
[9.003729]  [] intel_sdvo_init+0x4fd/0x7c0 [i915]
[9.003845]  [] intel_modeset_init+0xdcb/0xea0 [i915]
[9.003953]  [] i915_driver_load+0xa2e/0xb50 [i915]
[9.004094]  [] ? drm_get_minor+0x261/0x300 [drm]
[9.004194]  [] drm_get_pci_dev+0x186/0x2d0 [drm]
[9.004275]  [] ? trace_hardirqs_on+0xd/0x10
[9.004388]  [] i915_pci_probe+0x16/0x20 [i915]
[9.004469]  [] local_pci_probe+0x5c/0xd0
[9.004549]  [] pci_device_probe+0x111/0x120
[9.004630]  [] driver_probe_device+0x92/0x390
[9.004711]  [] __driver_attach+0xab/0xb0
[9.004790]  [] ? driver_probe_device+0x390/0x390
[9.004870]  [] bus_for_each_dev+0x55/0x90
[9.004949]  [] ? 0xa00f1fff
[9.005068]  [] driver_attach+0x1e/0x20
[9.005148]  [] bus_add_driver+0x1b8/0x2b0
[9.005227]  [] ? 0xa00f1fff
[9.005307]  [] driver_register+0x77/0x150
[9.005387]  

[PATCH v2] DRM: Add DRM kms/fb cma helper

[Lars-Peter Clausen]

This patch introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.

Signed-off-by: Lars-Peter Clausen 

---
Changes since v1:
* Some spelling fixes
* Add missing kfree in drm_fb_cma_alloc error path
* Add multi-plane support. drm_fb_cma_get_gem_obj now takes a second
  parameter to specify the plane.
---
 drivers/gpu/drm/Kconfig |   11 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/drm_fb_cma_helper.c |  384 +++
 include/drm/drm_fb_cma_helper.h |   27 +++
 4 files changed, 423 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_fb_cma_helper.c
 create mode 100644 include/drm/drm_fb_cma_helper.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a78dfbe..e7c0a3d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -41,6 +41,17 @@ config DRM_GEM_CMA_HELPER
help
  Choose this if you need the GEM cma helper functions

+config DRM_KMS_CMA_HELPER
+   tristate
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_HELPER
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   help
+ Choose this if you need the KMS cma helper functions
+
+
 config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6e9e948..5dcb1a5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o

 drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_i2c_helper.o
+drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o

 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
new file mode 100644
index 000..8821a98
--- /dev/null
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -0,0 +1,384 @@
+/*
+ * drm kms/fb cma (contiguous memory allocator) helper functions
+ *
+ * Copyright (C) 2012 Analog Device Inc.
+ *   Author: Lars-Peter Clausen 
+ *
+ * Based on udl_fbdev.c
+ *  Copyright (C) 2012 Red Hat
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_fb_cma {
+   struct drm_framebuffer  fb;
+   struct drm_gem_cma_obj  *obj[4];
+};
+
+struct drm_fbdev_cma {
+   struct drm_fb_helperfb_helper;
+   struct drm_fb_cma   *fb;
+};
+
+static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
+{
+   return container_of(helper, struct drm_fbdev_cma, fb_helper);
+}
+
+static inline struct drm_fb_cma *to_fb_cma(struct drm_framebuffer *fb)
+{
+   return container_of(fb, struct drm_fb_cma, fb);
+}
+
+static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
+{
+   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
+   int i;
+
+   for (i = 0; i < 4; i++) {
+   if (fb_cma->obj[i])
+   
drm_gem_object_unreference_unlocked(_cma->obj[i]->base);
+   }
+
+   drm_framebuffer_cleanup(fb);
+   kfree(fb_cma);
+}
+
+static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
+   struct drm_file *file_priv, unsigned int *handle)
+{
+   struct drm_fb_cma *fb_cma = to_fb_cma(fb);
+
+   return drm_gem_handle_create(file_priv,
+   _cma->obj[0]->base, handle);
+}
+
+static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
+   .destroy= drm_fb_cma_destroy,
+   .create_handle  = drm_fb_cma_create_handle,
+};
+
+static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
+   struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_cma_obj **obj,
+   unsigned int num_planes)
+{
+   struct drm_fb_cma *fb_cma;
+   int ret;
+   int i;
+
+   fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
+   if (!fb_cma)
+   return ERR_PTR(-ENOMEM);
+
+   ret = drm_framebuffer_init(dev, _cma->fb, _fb_cma_funcs);
+   if (ret) {
+   dev_err(dev->dev, "Failed to initalize framebuffer: %d\n", ret);
+   kfree(fb_cma);
+   return ERR_PTR(ret);
+   }
+
+   drm_helper_mode_fill_fb_struct(_cma->fb, mode_cmd);
+
+   for (i = 0; i < num_planes; i++)
+   fb_cma->obj[i] = obj[i];
+
+   return fb_cma;

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Ville Syrjälä]

On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> +static struct drm_framebuffer *
> +shmob_drm_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> + struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + const struct shmob_drm_format_info *format;
> + struct shmob_drm_framebuffer *sfb;
> + struct drm_framebuffer *fb;
> + struct drm_gem_object *obj;
> + unsigned int i;
> + int ret;
> +
> + format = shmob_drm_format_info(mode_cmd->pixel_format);
> + if (format == NULL) {
> + dev_dbg(dev->dev, "unsupported pixel format %08x\n",
> + mode_cmd->pixel_format);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + sfb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (sfb == NULL)
> + return ERR_PTR(-ENOMEM);
> +
> + sfb->format = format;
> + fb = >base;
> +
> + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> + obj = drm_gem_object_lookup(dev, file_priv,
> + mode_cmd->handles[i]);
> + if (obj == NULL) {
> + dev_dbg(dev->dev, "GEM object %u not found\n",
> + mode_cmd->handles[i]);
> + ret = -ENOENT;
> + goto error;
> + }
> + sfb->sobj[i] = to_shmob_gem_object(obj);
> + }

offsets[] not checked, nor is it handled in the code that calculates
the final offsets.

Based on the rest of the code, it seems that the hardware assumes
pitches[1] == pitches[0]*chroma_cpp. You should reject other values
here. Also it's not clear from the code if there are other stride
limitations that would need checking.

Also there are no checks to make sure the fb fits inside the gem object.
At one point I tried to cook up a generic function to help with such
checks. I probably need to revisit that issue and try to make something
that'd work for tiled formats as well.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Lars-Peter Clausen]

On 05/30/2012 04:45 PM, Lars-Peter Clausen wrote:
> On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
>> [...]
>> +for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
>> +obj = drm_gem_object_lookup(dev, file_priv,
>> +mode_cmd->handles[i]);
>> +if (obj == NULL) {
>> +dev_dbg(dev->dev, "GEM object %u not found\n",
>> +mode_cmd->handles[i]);
>> +ret = -ENOENT;
>> +goto error;
>> +}
>> +sfb->sobj[i] = to_shmob_gem_object(obj);
>> +}
>> +
> 
> I added multi-plane support the cma fb helper functions and it seems to
> work. But all other DRM drivers seem to assume that multi-plane formats
> still only have a single buffer, while yours seems to assume that there is a
> plane for each buffer. The exception is the Exynos driver, but it added a
> new set of formats which are identical to the other formats, but use one
> buffer per plane.
> 
> So I'm not sure how to implement this correctly in a generic fashion.
> 

This post by Ville Syrj?l? seems to explain it quite well:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021044.html

[PATCH 3/4] drm: Add NV24 and NV42 pixel formats

[Ville Syrjälä]

On Wed, May 30, 2012 at 03:20:09PM +0200, Laurent Pinchart wrote:
> Hi Ville,
> 
> Thank you for the review.
> 
> On Wednesday 30 May 2012 16:09:25 Ville Syrj?l? wrote:
> > On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  include/drm/drm_fourcc.h |2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > index bdf0152..fac7235 100644
> > > --- a/include/drm/drm_fourcc.h
> > > +++ b/include/drm/drm_fourcc.h
> > > @@ -106,6 +106,8 @@
> > > 
> > >  #define DRM_FORMAT_NV21  fourcc_code('N', 'V', '2', '1') /* 2x2
> > >  subsampled Cb:Cr plane */ #define DRM_FORMAT_NV16
> > > fourcc_code('N', 
> 'V',
> > >  '1', '6') /* 2x1 subsampled Cr:Cb plane */ #define
> > >  DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> > > subsampled 
> Cb:Cr
> > >  plane */> 
> > > +#define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /*
> > > non-subsampled Cr:Cb plane */ +#define DRM_FORMAT_NV42
> fourcc_code('N',
> > > 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> > If you want these to reach the driver you need to add them to
> > format_check().
> 
> Oops, my bad, indeed.
> 
> > Also you should update drm_format_num_planes() and drm_format_plane_cpp()
> > appropriately.
> 
> Will do.
> 
> I'm a bit puzzled by drm_format_plane_cpp(). I would have expected the return 
> value to be 1 for NV12/21 and NV16/61 formats (2 U/V components, but 1/2 
> horizontal subsampling). Is that a bug, or am I missing something ?

The way I used it originally was to calculate the minimum stride for a
plane. So the formula was something like this:
min_stride = width / plane_horiz_subsampling * plane_cpp

I guess you could also call it pixel stride (as opposed to line stride).
That is when you're walking the Cb (or Cr) samples you need to step two
bytes to the get to the next sample.

Or if you just think about the chroma plane as just another packed pixel
format then it also makes sense to have cpp=2.

YUYV and co. are more problematic though since you have the subsampled
and non-subsampled stuff in the same plane. There you could argue that
both 2 and 4 are sensible values. I used 2 there since it meant that I
didn't have to add special cases to the minimum stride calculations.

There might be a need to add drm_format_macropixel_size() or some such
function in the future which would return 4 for YUYV. Especially if
someone wants to add funky formats such as Y41P.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Lars-Peter Clausen]

On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
> [...]
> + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> + obj = drm_gem_object_lookup(dev, file_priv,
> + mode_cmd->handles[i]);
> + if (obj == NULL) {
> + dev_dbg(dev->dev, "GEM object %u not found\n",
> + mode_cmd->handles[i]);
> + ret = -ENOENT;
> + goto error;
> + }
> + sfb->sobj[i] = to_shmob_gem_object(obj);
> + }
> +

I added multi-plane support the cma fb helper functions and it seems to
work. But all other DRM drivers seem to assume that multi-plane formats
still only have a single buffer, while yours seems to assume that there is a
plane for each buffer. The exception is the Exynos driver, but it added a
new set of formats which are identical to the other formats, but use one
buffer per plane.

So I'm not sure how to implement this correctly in a generic fashion.

- Lars

[PATCH] drm/edid: Make the header fixup threshold tunable

[Adam Jackson]

6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.

Bugzilla: https://bugzilla.redhat.com/582559
Signed-off-by: Adam Jackson 
---
 drivers/gpu/drm/drm_edid.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 608bddf..1c28018 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -144,6 +144,10 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
 }
 EXPORT_SYMBOL(drm_edid_header_is_valid);

+static int edid_fixup __read_mostly = 6;
+module_param_named(edid_fixup, edid_fixup, int, 0400);
+MODULE_PARM_DESC(edid_fixup,
+"Minimum number of valid EDID header bytes (0-8, default 6)");

 /*
  * Sanity check the EDID block (base or extension).  Return 0 if the block
@@ -155,10 +159,13 @@ bool drm_edid_block_valid(u8 *raw_edid, int block)
u8 csum = 0;
struct edid *edid = (struct edid *)raw_edid;

+   if (edid_fixup > 8 || edid_fixup < 0)
+   edid_fixup = 6;
+
if (block == 0) {
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) ;
-   else if (score >= 6) {
+   else if (score >= edid_fixup) {
DRM_DEBUG("Fixing EDID header, your hardware may be 
failing\n");
memcpy(raw_edid, edid_header, sizeof(edid_header));
} else {
-- 
1.7.7.6

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

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=13170


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

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

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=13170


Alan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE




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

[Bug 13132] vbetool stops X from initialising

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=13132


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

[Bug 13132] vbetool stops X from initialising

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=13132


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||WILL_NOT_FIX




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

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Laurent Pinchart]

Hi Sascha,

On Wednesday 30 May 2012 15:43:24 Sascha Hauer wrote:
> Hi Laurent,
> 
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> > The SH Mobile LCD controller (LCDC) DRM driver supports the main
> > graphics plane in RGB and YUV formats, as well as the overlay planes (in
> > alpha-blending mode only).
> > 
> > Only flat panel outputs using the parallel interface are supported.
> > Support for SYS panels, HDMI and DSI is currently not implemented.
> 
> Have you seen
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023536.html
> 
> and
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023544.html

No I hadn't. Thanks for the information.

> The first patch is a generic gem helper for dma_alloc_* backed memory
> which could serve as a drop in replacement for your gem code. The
> latter is a generic helper for the framebuffer handling on these
> devices. I saw that your driver supports planes which Lars' patch
> currently doesn't, but it should be easy to add support for this.
> 
> I hope these are useful, if not, could you tell what's missing?

I'll try to use those and I'll report back.

-- 
Regards,

Laurent Pinchart

[PATCH 3/4] drm: Add NV24 and NV42 pixel formats

[Laurent Pinchart]

Hi Ville,

On Wednesday 30 May 2012 17:05:10 Ville Syrj?l? wrote:
> On Wed, May 30, 2012 at 03:20:09PM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 May 2012 16:09:25 Ville Syrj?l? wrote:
> > > On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > > > Signed-off-by: Laurent Pinchart 
> > > > ---
> > > > 
> > > >  include/drm/drm_fourcc.h |2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > > > index bdf0152..fac7235 100644
> > > > --- a/include/drm/drm_fourcc.h
> > > > +++ b/include/drm/drm_fourcc.h
> > > > @@ -106,6 +106,8 @@
> > > > 
> > > >  #define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') 
> > > > /* 2x2
> > > >  subsampled Cb:Cr plane */
> > > >  #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') 
> > > > /* 2x1
> > > >  subsampled Cr:Cb plane */
> > > >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') 
> > > > /* 2x1
> > > >  subsampled Cb:Cr plane */
> > > > +#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') 
> > > > /*
> > > > non-subsampled Cr:Cb plane */
> > > > +#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') 
> > > > /*
> > > > non-subsampled Cb:Cr plane */
> > > 
> > > If you want these to reach the driver you need to add them to
> > > format_check().
> > 
> > Oops, my bad, indeed.
> > 
> > > Also you should update drm_format_num_planes() and
> > > drm_format_plane_cpp()
> > > appropriately.
> > 
> > Will do.
> > 
> > I'm a bit puzzled by drm_format_plane_cpp(). I would have expected the
> > return value to be 1 for NV12/21 and NV16/61 formats (2 U/V components,
> > but 1/2 horizontal subsampling). Is that a bug, or am I missing something
> > ?
> The way I used it originally was to calculate the minimum stride for a
> plane. So the formula was something like this:
> min_stride = width / plane_horiz_subsampling * plane_cpp

I had missed the division by the horizontal subsampling factor in 
framebuffer_check(). It makes sense now.

> I guess you could also call it pixel stride (as opposed to line stride).
> That is when you're walking the Cb (or Cr) samples you need to step two
> bytes to the get to the next sample.
> 
> Or if you just think about the chroma plane as just another packed pixel
> format then it also makes sense to have cpp=2.
> 
> YUYV and co. are more problematic though since you have the subsampled
> and non-subsampled stuff in the same plane. There you could argue that
> both 2 and 4 are sensible values. I used 2 there since it meant that I
> didn't have to add special cases to the minimum stride calculations.
> 
> There might be a need to add drm_format_macropixel_size() or some such
> function in the future which would return 4 for YUYV. Especially if
> someone wants to add funky formats such as Y41P.

-- 
Regards,

Laurent Pinchart

[PATCH 3/4] drm: Add NV24 and NV42 pixel formats

[Ville Syrjälä]

On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart 
> ---
>  include/drm/drm_fourcc.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index bdf0152..fac7235 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -106,6 +106,8 @@
>  #define DRM_FORMAT_NV21  fourcc_code('N', 'V', '2', '1') /* 2x2 
> subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV16  fourcc_code('N', 'V', '1', '6') /* 2x1 
> subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV61  fourcc_code('N', 'V', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */

If you want these to reach the driver you need to add them to
format_check().

Also you should update drm_format_num_planes() and
drm_format_plane_cpp() appropriately.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Lars-Peter Clausen]

On 05/30/2012 03:43 PM, Sascha Hauer wrote:
> Hi Laurent,
> 
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
>> The SH Mobile LCD controller (LCDC) DRM driver supports the main
>> graphics plane in RGB and YUV formats, as well as the overlay planes (in
>> alpha-blending mode only).
>>
>> Only flat panel outputs using the parallel interface are supported.
>> Support for SYS panels, HDMI and DSI is currently not implemented.
> 
> Have you seen
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023536.html
> 
> and
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023544.html
> 
> The first patch is a generic gem helper for dma_alloc_* backed memory
> which could serve as a drop in replacement for your gem code. The
> latter is a generic helper for the framebuffer handling on these
> devices. I saw that your driver supports planes which Lars' patch
> currently doesn't, but it should be easy to add support for this.
> 

Yup, just added plane support, will repost the patch in a moment.

- Lars

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Sascha Hauer]

Hi Laurent,

On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
> 
> Only flat panel outputs using the parallel interface are supported.
> Support for SYS panels, HDMI and DSI is currently not implemented.

Have you seen

http://lists.freedesktop.org/archives/dri-devel/2012-May/023536.html

and

http://lists.freedesktop.org/archives/dri-devel/2012-May/023544.html

The first patch is a generic gem helper for dma_alloc_* backed memory
which could serve as a drop in replacement for your gem code. The
latter is a generic helper for the framebuffer handling on these
devices. I saw that your driver supports planes which Lars' patch
currently doesn't, but it should be easy to add support for this.

I hope these are useful, if not, could you tell what's missing?

Sascha

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

Fw: [Intel-gfx] [PATCH] intel: add a timed wait function

[Eric Anholt]

On Wed, 30 May 2012 21:07:57 +0200, Daniel Vetter  wrote:
> On Wed, May 30, 2012 at 7:41 PM, Eric Anholt  wrote:
> > I guess GL_ALREADY_SIGNALED handling will be done using a check for
> > bo_busy() before calling this.
> 
> I've just read through the mesa code and gl_already_signalled seems to
> be handled already by core mesa code in _mesa_ClientWaitSync (if the
> driver sets syncObject->Status correctly). So I guess the current
> kernel code should work as-is and only the libdrm interface needs some
> colour adjustments around the timeout parameter.

Yeah, matches what I found.

Did you want pointer for timeout in the userspace api?  I don't feel
strongly about it, I just didn't see a use.  The equivalent API I could
think of was select(), where apparently linux returns time unwaited,
while "everyone else" doesn't.  I don't see a strong recommendation
either way from that.

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

[PATCH 2/2] drm/i915: don't chnage the original mode in dp_mode_fixup

[Paul Menzel]

Am Mittwoch, den 30.05.2012, 13:52 +0200 schrieb Daniel Vetter:

Typo in ?change? in the commit message.

> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
> 
> After the prevous prep patch to use adjusted_mode->clock instead of

previous

> mode->clock the only thing left is to clean up things a bit. I've
> opted to pass in an adjust_mode param to dp_adjust_dithering because
> that way we can be sure to avoid duplicating this logic - which was
> the cause behind a dp link bw calculation bug in the past.
> 
> Also mark the mode argument of pch_panel_fitting const.
> 
> v2: Split up the mode->clock => adjusted_mode->clock change,
> as suggested by Chris Wilson.
> 
> Reported-by: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c|   12 ++--
>  drivers/gpu/drm/i915/intel_drv.h   |2 +-
>  drivers/gpu/drm/i915/intel_panel.c |2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/cce1bdbc/attachment.pgp>

[PATCH 3/4] drm: Add NV24 and NV42 pixel formats

[Laurent Pinchart]

Hi Ville,

Thank you for the review.

On Wednesday 30 May 2012 16:09:25 Ville Syrj?l? wrote:
> On Wed, May 30, 2012 at 02:32:58PM +0200, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  include/drm/drm_fourcc.h |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index bdf0152..fac7235 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -106,6 +106,8 @@
> > 
> >  #define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') /* 2x2
> >  subsampled Cb:Cr plane */ #define DRM_FORMAT_NV16  
> > fourcc_code('N', 
'V',
> >  '1', '6') /* 2x1 subsampled Cr:Cb plane */ #define
> >  DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
> > subsampled 
Cb:Cr
> >  plane */> 
> > +#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
> > non-subsampled Cr:Cb plane */ +#define DRM_FORMAT_NV42  
fourcc_code('N',
> > 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> If you want these to reach the driver you need to add them to
> format_check().

Oops, my bad, indeed.

> Also you should update drm_format_num_planes() and drm_format_plane_cpp()
> appropriately.

Will do.

I'm a bit puzzled by drm_format_plane_cpp(). I would have expected the return 
value to be 1 for NV12/21 and NV16/61 formats (2 U/V components, but 1/2 
horizontal subsampling). Is that a bug, or am I missing something ?

-- 
Regards,

Laurent Pinchart

[RFC] Documentation: DRM framework documentation

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 Documentation/drm.txt | 1265 +
 1 files changed, 1265 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/drm.txt

Hi everybody,

Here's the DRM kernel framework documentation I wrote while developing the
Renesas SH Mobile DRM driver. It hopefully covers most of what's needed to
write a simple DRM driver (although some areas are not documented, such as
properties or the fbdev compatibility layer).

I can convert the documentation to DocBook if needed and integrate it with the
existing "documentation stub". In that case I'm thinking of splitting the
DocBook documentation in two parts, userspace API documentation (that someone
would have to fill, any volunteer ? ;-)) and kernel API documentation. Would
that be fine ?

Last but not least, now that documentation exists (albeit in an incomplete
state), we need to make sure it won't get outdated too quickly. As nobody will
volunteer to maintain it (feel free to prove me wrong though), I'd like to
propose the same rule that we already follow in V4L: any patch that touches
the API won't get merged if it doesn't update the documentation. Do you think
this could work out ?

As usual, review will be appreciated.

diff --git a/Documentation/drm.txt b/Documentation/drm.txt
new file mode 100644
index 000..4d8843d
--- /dev/null
+++ b/Documentation/drm.txt
@@ -0,0 +1,1265 @@
+   Architecture of a DRM driver
+i  
+
+Written by Laurent Pinchart 
+Last revised: May 30, 2012
+
+
+1. Driver initialization
+
+
+- Create a static struct drm_driver instance and register it at probe() time
+  with drm_platform_init(). This will call the DRM driver load() method, if
+  provided (why would the method not be provided?).
+
+  - int (*load) (struct drm_device *, unsigned long flags)
+
+  The method takes two arguments, a pointer to the newly created drm_device
+  and flags. The flags are used to pass the driver_data field of the device id
+  corresponding to the device passed to drm_*_init(). Only PCI devices
+  currently use this, USB and platform DRM drivers have their load() method
+  called with flags to 0.
+
+  The load method is responsible for performing resource allocation, hardware
+  initialization and DRM initialization. See the IRQ registration and KMS
+  initialization sections.
+
+  - int (*firstopen) (struct drm_device *)
+  - void (*lastclose) (struct drm_device *)
+  - int (*open) (struct drm_device *, struct drm_file *)
+  - void (*preclose) (struct drm_device *, struct drm_file *)
+  - void (*postclose) (struct drm_device *, struct drm_file *)
+
+  Open and close handlers. None of those methods are mandatory.
+
+  The .firstopen() method is called by the DRM core when an application opens
+  a device that has no other opened file handle. Similarly the .lastclose()
+  method is called when the last application holding a file handle opened on
+  the device closes it. Both methods are mostly used for UMS (User Mode
+  Setting) drivers to acquire and release device resources which should be
+  done in the .load() and .unload() methods for KMS drivers.
+
+  Note that the .lastclose() method is also called at module unload time or,
+  for hot-pluggable devices, when the device is unplugged. The .firstopen()
+  and .lastclose() calls can thus be unbalanced.
+
+  The .open() method is called every time the device is opened by an
+  application. Drivers can allocate per-file private data in this method and
+  store them in the struct drm_file::driver_priv field. Note that the .open()
+  method is called before .firstopen().
+
+  The close operation is split into .preclose() and .postclose() methods.
+  Drivers must stop and cleanup all per-file operations in the .preclose()
+  method. For instance pending vertical blanking and page flip events must be
+  cancelled. No per-file operation is allowed on the file handle after
+  returning from the .preclose() method.
+
+  Finally the .postclose() method is called as the last step of the close
+  operation, right before calling the .lastclose() method if no other open
+  file handle exists for the device. Drivers that have allocated per-file
+  private data in the .open() method should free it here.
+
+  - int (*suspend) (struct drm_device *, pm_message_t state)
+  - int (*resume) (struct drm_device *)
+
+  Legacy suspend and resume methos. New driver should use the power management
+  interface provided by their bus type (usually through the struct
+  device_driver dev_pm_ops) and set these methods to NULL.
+
+  - int (*enable_vblank) (struct drm_device *dev, int crtc)
+  - void (*disable_vblank) (struct drm_device *dev, int crtc)
+  - u32 (*get_vblank_counter) (struct drm_device *dev, int crtc)
+
+  Enable and disable vertical blanking interrupts and get the value of the
+  vblank counter for the given CRTC. See the Vertical Blanking and Page
+  

[PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup

[Daniel Vetter]

On Wed, May 30, 2012 at 01:18:35PM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter  
> wrote:
> > ... instead of changing mode->clock, which we should leave as-is.
> > 
> > We only touch that if it's a panel, and then adjusted mode->clock
> > equals adjusted_mode->clock. Outside of intel_dp.c we only use
> > ajusted_mode->clock in the mode_set functions.
> > 
> > Within intel_dp.c we only use it to calculate the dp dithering
> > and link bw parameters, so that's the only thing we need to fix
> > up.
> > 
> > As a temporary ugliness (until the cleanup in the next patch) we
> > pass the adjusted_mode into dp_dither for both parameters (because
> > that one still looks at mode->clock).
> > 
> > Note that we do overwrite adjusted_mode->clock with the selected dp
> > link clock, but that only happens after we've calculated everything we
> > need based on the dotclock of the adjusted output configuration.
> > 
> > v2: Adjust the debug message to also use adjusted_mode->clock.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |   11 +++
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 296cfc2..a9dffa6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, 
> > struct drm_display_mode *mode,
> > intel_fixed_panel_mode(intel_dp->panel_fixed_mode, 
> > adjusted_mode);
> > intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
> > mode, adjusted_mode);
> > -   /*
> > -* the mode->clock is used to calculate the Data M/N
> > -* of the pipe. For the eDP the fixed clock should be used.
> > -*/
> > -   mode->clock = intel_dp->panel_fixed_mode->clock;
> 
> But in ironlake_crtc_mode_set() we have:
> 
>  if (is_cpu_edp) {
>  target_clock = mode->clock;
>  } else {
>if (is_dp)
>  target_clock = mode->clock;
>else
>  target_clock = adjusted_mode->clock;
>  }
> 
> It would seem like eDP would have had mode->clock adjusted previously.
> Similarly PCH eDP uses the adjusted mode->clock in intel_dp_set_m_n().

Well, adjusted_mode->clock after we've run intel_dp_mode_fixup should be
the same in all cases, because we overwrite it with the fixed dp link
clock we're selecting. The target_clock otoh looks more worrisome. I guess
I've managed to not hit this because I don't have an eDP panel (where we
change mode->clock), but still I guess we need to clean this up a bit.

I'll try to come up with a way to avoid this maze.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 4/4] drm: Renesas SH Mobile DRM driver

[Laurent Pinchart]

The SH Mobile LCD controller (LCDC) DRM driver supports the main
graphics plane in RGB and YUV formats, as well as the overlay planes (in
alpha-blending mode only).

Only flat panel outputs using the parallel interface are supported.
Support for SYS panels, HDMI and DSI is currently not implemented.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/shmobile/Kconfig   |8 +
 drivers/gpu/drm/shmobile/Makefile  |8 +
 drivers/gpu/drm/shmobile/shmob_drm_backlight.c |   89 +++
 drivers/gpu/drm/shmobile/shmob_drm_backlight.h |   23 +
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  746 
 drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |   59 ++
 drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  365 
 drivers/gpu/drm/shmobile/shmob_drm_drv.h   |   52 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.c   |  195 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.h   |   46 ++
 drivers/gpu/drm/shmobile/shmob_drm_kms.c   |  211 +++
 drivers/gpu/drm/shmobile/shmob_drm_kms.h   |   44 ++
 drivers/gpu/drm/shmobile/shmob_drm_plane.c |  240 
 drivers/gpu/drm/shmobile/shmob_drm_plane.h |   22 +
 drivers/gpu/drm/shmobile/shmob_drm_regs.h  |  304 ++
 include/drm/shmob_drm.h|   99 
 18 files changed, 2514 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/shmobile/Kconfig
 create mode 100644 drivers/gpu/drm/shmobile/Makefile
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
 create mode 100644 include/drm/shmob_drm.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 23120c0..347d860 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -192,3 +192,5 @@ source "drivers/gpu/drm/ast/Kconfig"
 source "drivers/gpu/drm/mgag200/Kconfig"

 source "drivers/gpu/drm/cirrus/Kconfig"
+
+source "drivers/gpu/drm/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f65f65e..0db4c0a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,4 +45,5 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
+obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
new file mode 100644
index 000..d3fb8df
--- /dev/null
+++ b/drivers/gpu/drm/shmobile/Kconfig
@@ -0,0 +1,8 @@
+config DRM_SHMOBILE
+   tristate "DRM Support for SH Mobile"
+   depends on DRM && (SUPERH || ARCH_SHMOBILE)
+   select DRM_KMS_HELPER
+   help
+ Choose this option if you have an SH Mobile chipset.
+ If M is selected the module will be called shmob-drm.
+
diff --git a/drivers/gpu/drm/shmobile/Makefile 
b/drivers/gpu/drm/shmobile/Makefile
new file mode 100644
index 000..6ecf33d
--- /dev/null
+++ b/drivers/gpu/drm/shmobile/Makefile
@@ -0,0 +1,8 @@
+shmob-drm-y := shmob_drm_backlight.o \
+  shmob_drm_crtc.o \
+  shmob_drm_drv.o \
+  shmob_drm_gem.o \
+  shmob_drm_kms.o \
+  shmob_drm_plane.o
+
+obj-$(CONFIG_DRM_SHMOBILE) += shmob-drm.o
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_backlight.c 
b/drivers/gpu/drm/shmobile/shmob_drm_backlight.c
new file mode 100644
index 000..4477a3b
--- /dev/null
+++ b/drivers/gpu/drm/shmobile/shmob_drm_backlight.c
@@ -0,0 +1,89 @@
+/*
+ * shmob_drm_backlight.c  --  SH Mobile DRM Backlight
+ *
+ * Copyright (C) 2012 Renesas Corporation
+ *
+ * Laurent Pinchart (laurent.pinchart at ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+
+#include "shmob_drm_backlight.h"
+#include "shmob_drm_crtc.h"
+#include "shmob_drm_drv.h"
+
+static int shmob_drm_backlight_update(struct backlight_device *bdev)
+{
+   struct shmob_drm_connector 

[PATCH 3/4] drm: Add NV24 and NV42 pixel formats

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 include/drm/drm_fourcc.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bdf0152..fac7235 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -106,6 +106,8 @@
 #define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') /* 2x2 
subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /* 2x1 
subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */

 /* 2 non contiguous plane YCbCr */
 #define DRM_FORMAT_NV12M   fourcc_code('N', 'M', '1', '2') /* 2x2 
subsampled Cr:Cb plane */
-- 
1.7.3.4

[PATCH 2/4] fbdev: sh_mobile_lcdc: Use MERAM operations wrappers

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 drivers/video/sh_mobile_lcdcfb.c |   18 +++---
 1 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 7a0b301..671685d 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -857,7 +857,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv 
*priv)
 * re-initialize them.
 */
if (ch->meram) {
-   mdev->ops->meram_unregister(mdev, ch->meram);
+   sh_mobile_meram_unregister(mdev, ch->meram);
ch->meram = NULL;
}

@@ -880,11 +880,11 @@ static int sh_mobile_lcdc_start(struct 
sh_mobile_lcdc_priv *priv)
break;
}

-   meram = mdev->ops->meram_register(mdev, ch->cfg->meram_cfg,
+   meram = sh_mobile_meram_register(mdev, ch->cfg->meram_cfg,
ch->pitch, ch->yres, pixelformat,
>pitch);
if (!IS_ERR(meram)) {
-   mdev->ops->meram_update(mdev, meram,
+   sh_mobile_meram_update(mdev, meram,
ch->base_addr_y, ch->base_addr_c,
>base_addr_y, >base_addr_c);
ch->meram = meram;
@@ -1070,14 +1070,10 @@ static int sh_mobile_fb_pan_display(struct 
fb_var_screeninfo *var,
base_addr_c += var->xoffset;
}

-   if (ch->meram) {
-   struct sh_mobile_meram_info *mdev;
-
-   mdev = priv->meram_dev;
-   mdev->ops->meram_update(mdev, ch->meram,
-   base_addr_y, base_addr_c,
-   _addr_y, _addr_c);
-   }
+   if (ch->meram)
+   sh_mobile_meram_update(priv->meram_dev, ch->meram,
+  base_addr_y, base_addr_c,
+  _addr_y, _addr_c);

ch->base_addr_y = base_addr_y;
ch->base_addr_c = base_addr_c;
-- 
1.7.3.4

[PATCH 1/4] fbdev: sh_mobile_meram: Add MERAM operations wrappers

[Laurent Pinchart]

Remove direct dependency on the MERAM driver implementation by
introducing inline wrappers for MERAM operations.

Signed-off-by: Laurent Pinchart 
---
 drivers/video/sh_mobile_meram.c |   24 
 include/video/sh_mobile_meram.h |   28 
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 82ba830..c51849f 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -444,11 +444,11 @@ static void meram_deinit(struct sh_mobile_meram_priv 
*priv,
  * Registration/unregistration
  */

-static void *sh_mobile_meram_register(struct sh_mobile_meram_info *pdata,
- const struct sh_mobile_meram_cfg *cfg,
- unsigned int xres, unsigned int yres,
- unsigned int pixelformat,
- unsigned int *pitch)
+static void *__sh_mobile_meram_register(struct sh_mobile_meram_info *pdata,
+   const struct sh_mobile_meram_cfg *cfg,
+   unsigned int xres, unsigned int yres,
+   unsigned int pixelformat,
+   unsigned int *pitch)
 {
struct sh_mobile_meram_fb_cache *cache;
struct sh_mobile_meram_priv *priv = pdata->priv;
@@ -495,7 +495,7 @@ err:
 }

 static void
-sh_mobile_meram_unregister(struct sh_mobile_meram_info *pdata, void *data)
+__sh_mobile_meram_unregister(struct sh_mobile_meram_info *pdata, void *data)
 {
struct sh_mobile_meram_fb_cache *cache = data;
struct sh_mobile_meram_priv *priv = pdata->priv;
@@ -513,9 +513,9 @@ sh_mobile_meram_unregister(struct sh_mobile_meram_info 
*pdata, void *data)
 }

 static void
-sh_mobile_meram_update(struct sh_mobile_meram_info *pdata, void *data,
-  unsigned long base_addr_y, unsigned long base_addr_c,
-  unsigned long *icb_addr_y, unsigned long *icb_addr_c)
+__sh_mobile_meram_update(struct sh_mobile_meram_info *pdata, void *data,
+unsigned long base_addr_y, unsigned long base_addr_c,
+unsigned long *icb_addr_y, unsigned long *icb_addr_c)
 {
struct sh_mobile_meram_fb_cache *cache = data;
struct sh_mobile_meram_priv *priv = pdata->priv;
@@ -530,9 +530,9 @@ sh_mobile_meram_update(struct sh_mobile_meram_info *pdata, 
void *data,

 static struct sh_mobile_meram_ops sh_mobile_meram_ops = {
.module = THIS_MODULE,
-   .meram_register = sh_mobile_meram_register,
-   .meram_unregister   = sh_mobile_meram_unregister,
-   .meram_update   = sh_mobile_meram_update,
+   .meram_register = __sh_mobile_meram_register,
+   .meram_unregister   = __sh_mobile_meram_unregister,
+   .meram_update   = __sh_mobile_meram_update,
 };

 /* 
-
diff --git a/include/video/sh_mobile_meram.h b/include/video/sh_mobile_meram.h
index 29b2fd3..b03f823 100644
--- a/include/video/sh_mobile_meram.h
+++ b/include/video/sh_mobile_meram.h
@@ -60,4 +60,32 @@ struct sh_mobile_meram_ops {
 unsigned long *icb_addr_c);
 };

+static inline void *
+sh_mobile_meram_register(struct sh_mobile_meram_info *mdev,
+const struct sh_mobile_meram_cfg *cfg,
+unsigned int xres, unsigned int yres,
+unsigned int pixelformat, unsigned int *pitch)
+{
+   if (mdev == NULL || mdev->ops == NULL || cfg == NULL)
+   return NULL;
+
+   return mdev->ops->meram_register(mdev, cfg, xres, yres, pixelformat,
+pitch);
+}
+
+static inline void
+sh_mobile_meram_unregister(struct sh_mobile_meram_info *mdev, void *data)
+{
+   mdev->ops->meram_unregister(mdev, data);
+}
+
+static inline void
+sh_mobile_meram_update(struct sh_mobile_meram_info *mdev, void *data,
+  unsigned long base_addr_y, unsigned long base_addr_c,
+  unsigned long *icb_addr_y, unsigned long *icb_addr_c)
+{
+   mdev->ops->meram_update(mdev, data, base_addr_y, base_addr_c,
+   icb_addr_y, icb_addr_c);
+}
+
 #endif /* __VIDEO_SH_MOBILE_MERAM_H__  */
-- 
1.7.3.4

[PATCH 0/4] Renesas SH Mobile DRM driver

[Laurent Pinchart]

Hi everybody,

Here's a new DRM driver for the Renesas SH Mobile display controller
(a.k.a. LCDC). The hardware is pretty simple and consists of a single CRTC and
four (non-scalable) planes that can be alpha-blended (first two planes only),
overlayed or composed using ROP3.

The first two patches will go through the fbdev tree, but I've included them
here in case someone woud like to compile the code. The third patch just
defines two new formats and could already go in, unless we have a policy not
to define formats until a driver uses them.

As this is my first attempt at writing a DRM driver I'm pretty sure I've made
many mistakes. Review will as usual be very appreciated.

I've modified the modetest application from the libdrm repository to test this
driver, I will submit patches for it right after cleaning them up.

Laurent Pinchart (4):
  fbdev: sh_mobile_meram: Add MERAM operations wrappers
  fbdev: sh_mobile_lcdc: Use MERAM operations wrappers
  drm: Add NV24 and NV42 pixel formats
  drm: Renesas SH Mobile DRM driver

 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/shmobile/Kconfig   |8 +
 drivers/gpu/drm/shmobile/Makefile  |8 +
 drivers/gpu/drm/shmobile/shmob_drm_backlight.c |   89 +++
 drivers/gpu/drm/shmobile/shmob_drm_backlight.h |   23 +
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  746 
 drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |   59 ++
 drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  365 
 drivers/gpu/drm/shmobile/shmob_drm_drv.h   |   52 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.c   |  195 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.h   |   46 ++
 drivers/gpu/drm/shmobile/shmob_drm_kms.c   |  211 +++
 drivers/gpu/drm/shmobile/shmob_drm_kms.h   |   44 ++
 drivers/gpu/drm/shmobile/shmob_drm_plane.c |  240 
 drivers/gpu/drm/shmobile/shmob_drm_plane.h |   22 +
 drivers/gpu/drm/shmobile/shmob_drm_regs.h  |  304 ++
 drivers/video/sh_mobile_lcdcfb.c   |   18 +-
 drivers/video/sh_mobile_meram.c|   24 +-
 include/drm/drm_fourcc.h   |2 +
 include/drm/shmob_drm.h|   99 
 include/video/sh_mobile_meram.h|   28 +
 22 files changed, 2563 insertions(+), 23 deletions(-)
 create mode 100644 drivers/gpu/drm/shmobile/Kconfig
 create mode 100644 drivers/gpu/drm/shmobile/Makefile
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
 create mode 100644 include/drm/shmob_drm.h

-- 
Regards,

Laurent Pinchart

[Bug 12796] via driver (?) fails to handle interrupt

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=12796


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

[Bug 12796] via driver (?) fails to handle interrupt

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=12796


Jonathan Nieder  changed:

   What|Removed |Added

 CC||jrnieder at gmail.com

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||INSUFFICIENT_DATA
 Regression|--- |No




--- Comment #1 from Jonathan Nieder   2011-08-05 
16:37:37 ---
(In reply to comment #0)

> irq 16: nobody cared (try booting with the "irqpoll" option)

Hmm, as always that is of course worrisome.  Nothing seems to have happened
under driver/gpu/drm/via recently, unfortunately.

Vincent: Does the same thing happen with v3.0 or more recent snapshots?

Others: Any hints for debugging this (e.g., kernel command line parameters to
get more information about IRQ handling)?

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

[PATCH 2/2] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

After the prevous prep patch to use adjusted_mode->clock instead of
mode->clock the only thing left is to clean up things a bit. I've
opted to pass in an adjust_mode param to dp_adjust_dithering because
that way we can be sure to avoid duplicating this logic - which was
the cause behind a dp link bw calculation bug in the past.

Also mark the mode argument of pch_panel_fitting const.

v2: Split up the mode->clock => adjusted_mode->clock change,
as suggested by Chris Wilson.

Reported-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c|   12 ++--
 drivers/gpu/drm/i915/intel_drv.h   |2 +-
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a9dffa6..c5c5669 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 static bool
 intel_dp_adjust_dithering(struct intel_dp *intel_dp,
  struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ bool adjust_mode)
 {
int max_link_clock = 
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -236,8 +236,8 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
if (mode_rate > max_rate)
return false;

-   if (adjusted_mode)
-   adjusted_mode->private_flags
+   if (adjust_mode)
+   mode->private_flags
|= INTEL_MODE_DP_FORCE_6BPC;

return true;
@@ -260,7 +260,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}

-   if (!intel_dp_adjust_dithering(intel_dp, mode, NULL))
+   if (!intel_dp_adjust_dithering(intel_dp, mode, false))
return MODE_CLOCK_HIGH;

if (mode->clock < 1)
@@ -700,14 +700,14 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
mode, adjusted_mode);
}

-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;

DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %02x pixel clock %iKHz\n",
  max_lane_count, bws[max_clock], adjusted_mode->clock);

-   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, true))
return false;

bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3e09188..3e3b60c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -372,7 +372,7 @@ extern void intel_fixed_panel_mode(struct drm_display_mode 
*fixed_mode,
   struct drm_display_mode *adjusted_mode);
 extern void intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
 extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
 extern u32 intel_panel_get_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 2a1625d..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -56,7 +56,7 @@ intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
 void
 intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-- 
1.7.10

[PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup

[Daniel Vetter]

... instead of changing mode->clock, which we should leave as-is.

We only touch that if it's a panel, and then adjusted mode->clock
equals adjusted_mode->clock. Outside of intel_dp.c we only use
ajusted_mode->clock in the mode_set functions.

Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.

As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).

Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.

v2: Adjust the debug message to also use adjusted_mode->clock.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..a9dffa6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_fixed_panel_mode(intel_dp->panel_fixed_mode, 
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
-   /*
-* the mode->clock is used to calculate the Data M/N
-* of the pipe. For the eDP the fixed clock should be used.
-*/
-   mode->clock = intel_dp->panel_fixed_mode->clock;
}

if (mode->flags & DRM_MODE_FLAG_DBLCLK)
@@ -710,13 +705,13 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,

DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %02x pixel clock %iKHz\n",
- max_lane_count, bws[max_clock], mode->clock);
+ max_lane_count, bws[max_clock], adjusted_mode->clock);

-   if (!intel_dp_adjust_dithering(intel_dp, mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, adjusted_mode))
return false;

bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
-   mode_rate = intel_dp_link_required(mode->clock, bpp);
+   mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);

for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
for (clock = 0; clock <= max_clock; clock++) {
-- 
1.7.10

[PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

On Wed, May 30, 2012 at 11:58:43AM +0100, Chris Wilson wrote:
> On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter  
> wrote:
> > We should only frob adjusted_mode. This is in preparation of
> > a massive patch by Laurent Pinchart to make the mode argument
> > const.
> > 
> > The only thing we actually touch is mode->clock, but only if
> > it's a panel. And in that case we also set adjusted_mode->clock
> > to the same value. All the generic code already uses the
> > adjusted_mode exclusively, so we only have to move the dp
> > link bw calculations over to that. This requires a small
> > changes so that the shared code with mode_valid doesn't
> > touch the mode argument.
> 
> Separate patch please, I'm sure you are right, but that is the scary
> one...

Will do.

> > Also mark the mode argument of pch_panel_fitting const.
> > 
> > Reported-by: Laurent Pinchart 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c|   19 +++
> >  drivers/gpu/drm/i915/intel_drv.h   |2 +-
> >  drivers/gpu/drm/i915/intel_panel.c |2 +-
> >  3 files changed, 9 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 296cfc2..05c4748 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > max_lanes)
> >  static bool
> >  intel_dp_adjust_dithering(struct intel_dp *intel_dp,
> >   struct drm_display_mode *mode,
> > - struct drm_display_mode *adjusted_mode)
> > + bool adjust_mode)
> 
> Would this look more pleasant if you rewrote this function so that the
> adjustment of flags was done in the caller?

Well, I've added the adjusted_mode parameter originally to exactly avoid
this duplication of code between mode_fixup and mode_valid (which caused a
bug). Atm we could just pass back a needs_6bpc_dither flag, but I guess
we'll eventually need similar logic for higher bpc (and maybe other funky
stuff). So I think setting the flag here is ok and the least ugly version.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Intel-gfx] [PATCH] intel: add a timed wait function

[Ben Widawsky]

On Wed, 30 May 2012 21:07:57 +0200
Daniel Vetter  wrote:

> On Wed, May 30, 2012 at 7:41 PM, Eric Anholt  wrote:
> > I guess GL_ALREADY_SIGNALED handling will be done using a check for
> > bo_busy() before calling this.
> 
> I've just read through the mesa code and gl_already_signalled seems to
> be handled already by core mesa code in _mesa_ClientWaitSync (if the
> driver sets syncObject->Status correctly). So I guess the current
> kernel code should work as-is and only the libdrm interface needs some
> colour adjustments around the timeout parameter.
> -Daniel

What have we all agreed on for the color?

-- 
Ben Widawsky, Intel Open Source Technology Center

[PATCH/RFC] drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

[Michel Dänzer]

On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote: 
> DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
> for KMS drivers.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_irq.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> My understanding of the DRM framework tells me that calling
> DRM_IOCTL_MODESET_CTL on a KMS driver is not only unneeded, but could also
> mess up its internal state. Did I get it right ?

Yes, good catch.


> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c798eea..03f16f3 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -974,7 +974,6 @@ EXPORT_SYMBOL(drm_vblank_off);
>   * drm_vblank_pre_modeset - account for vblanks across mode sets
>   * @dev: DRM device
>   * @crtc: CRTC in question
> - * @post: post or pre mode set?
>   *
>   * Account for vblank events across mode setting events, which will likely
>   * reset the hardware frame counter.

This hunk should really be in a separate patch, but other than that

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 1/2] drm/i915: adjusted_mode->clock in the dp mode_fixup

[Chris Wilson]

On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter  
wrote:
> ... instead of changing mode->clock, which we should leave as-is.
> 
> We only touch that if it's a panel, and then adjusted mode->clock
> equals adjusted_mode->clock. Outside of intel_dp.c we only use
> ajusted_mode->clock in the mode_set functions.
> 
> Within intel_dp.c we only use it to calculate the dp dithering
> and link bw parameters, so that's the only thing we need to fix
> up.
> 
> As a temporary ugliness (until the cleanup in the next patch) we
> pass the adjusted_mode into dp_dither for both parameters (because
> that one still looks at mode->clock).
> 
> Note that we do overwrite adjusted_mode->clock with the selected dp
> link clock, but that only happens after we've calculated everything we
> need based on the dotclock of the adjusted output configuration.
> 
> v2: Adjust the debug message to also use adjusted_mode->clock.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 296cfc2..a9dffa6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
> drm_display_mode *mode,
>   intel_fixed_panel_mode(intel_dp->panel_fixed_mode, 
> adjusted_mode);
>   intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
>   mode, adjusted_mode);
> - /*
> -  * the mode->clock is used to calculate the Data M/N
> -  * of the pipe. For the eDP the fixed clock should be used.
> -  */
> - mode->clock = intel_dp->panel_fixed_mode->clock;

But in ironlake_crtc_mode_set() we have:

 if (is_cpu_edp) {
 target_clock = mode->clock;
 } else {
   if (is_dp)
 target_clock = mode->clock;
   else
 target_clock = adjusted_mode->clock;
 }

It would seem like eDP would have had mode->clock adjusted previously.
Similarly PCH eDP uses the adjusted mode->clock in intel_dp_set_m_n().
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 12677] radeon DRM module oopses the kernel, 2.6.28/powerpc

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=12677


Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

[Bug 12677] radeon DRM module oopses the kernel, 2.6.28/powerpc

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=12677


Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution||OBSOLETE
 Regression|--- |No




--- Comment #1 from Alan   2012-05-30 13:05:23 ---
Closing as obsolete, please re-open if seen with modern kernels

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

[PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

The only thing we actually touch is mode->clock, but only if
it's a panel. And in that case we also set adjusted_mode->clock
to the same value. All the generic code already uses the
adjusted_mode exclusively, so we only have to move the dp
link bw calculations over to that. This requires a small
changes so that the shared code with mode_valid doesn't
touch the mode argument.

Also mark the mode argument of pch_panel_fitting const.

Reported-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c|   19 +++
 drivers/gpu/drm/i915/intel_drv.h   |2 +-
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..05c4748 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 static bool
 intel_dp_adjust_dithering(struct intel_dp *intel_dp,
  struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ bool adjust_mode)
 {
int max_link_clock = 
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -236,8 +236,8 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
if (mode_rate > max_rate)
return false;

-   if (adjusted_mode)
-   adjusted_mode->private_flags
+   if (adjust_mode)
+   mode->private_flags
|= INTEL_MODE_DP_FORCE_6BPC;

return true;
@@ -260,7 +260,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}

-   if (!intel_dp_adjust_dithering(intel_dp, mode, NULL))
+   if (!intel_dp_adjust_dithering(intel_dp, mode, false))
return MODE_CLOCK_HIGH;

if (mode->clock < 1)
@@ -698,25 +698,20 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_fixed_panel_mode(intel_dp->panel_fixed_mode, 
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
-   /*
-* the mode->clock is used to calculate the Data M/N
-* of the pipe. For the eDP the fixed clock should be used.
-*/
-   mode->clock = intel_dp->panel_fixed_mode->clock;
}

-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;

DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %02x pixel clock %iKHz\n",
  max_lane_count, bws[max_clock], mode->clock);

-   if (!intel_dp_adjust_dithering(intel_dp, mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, true))
return false;

bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
-   mode_rate = intel_dp_link_required(mode->clock, bpp);
+   mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);

for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
for (clock = 0; clock <= max_clock; clock++) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3e09188..3e3b60c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -372,7 +372,7 @@ extern void intel_fixed_panel_mode(struct drm_display_mode 
*fixed_mode,
   struct drm_display_mode *adjusted_mode);
 extern void intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
 extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
 extern u32 intel_panel_get_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 2a1625d..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -56,7 +56,7 @@ intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
 void
 intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct 

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 12:11:49PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > > > The passed mode must not be modified by the operation, make it const.
> > > > > 
> > > > > Signed-off-by: Laurent Pinchart 
> > > > 
> > > > Acked-by: Daniel Vetter 
> > > 
> > > Thank you for the ack. Would you also be so kind as to tell me how to fix
> > > the related i915 issue (as briefly stated in the patch, the i915 driver
> > > modifies mode->clock in intel_dp_mode_fixup()) ? Or, even better, provide
> > > a patch for that ? :-)
> > 
> > Oops, lack of coffee. Patch is in the works.
> 
> No worries :-) As my patch should go on top of yours, could you please take 
> it 
> in your tree ?

Well I think that patch should go through Dave's tree directly. But I send
him regular -next pull requests, so that should stall your patch for long.
-Daniel

> > Btw, do you plan to constify other stuff?
> 
> Not immediately. When I tried to implement .mode_fixup() I wasn't sure 
> whether 
> drivers were allowed to modify the mode argument. After researching it I came 
> up to the conclusion that they should not, hence the patch. It would make 
> sense to constify other structures and function arguments as well though.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 1/2] DRM: Add DRM kms/fb cma helper

[Sascha Hauer]

On Tue, May 29, 2012 at 08:20:35PM +0200, Lars-Peter Clausen wrote:
> This patchset introduces a set of helper function for implementing the KMS
> framebuffer layer for drivers which use the drm gem CMA helper function.

I just integrated this into my series. Works great, thanks.
Would be great to have this mainline.

Only some nitpicking and one missing kfree below.

Sascha

> +static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
> +{
> + struct drm_fb_cma *fb_cma = to_fb_cma(fb);
> +
> + if (fb_cma->obj)
> + drm_gem_object_unreference_unlocked(_cma->obj->base);
> +
> + drm_framebuffer_cleanup(fb);
> + kfree(fb_cma);
> +}
> +
> +static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
> + struct drm_file *file_priv, unsigned int *handle)
> +{
> + struct drm_fb_cma *fb_cma = to_fb_cma(fb);
> +
> + return drm_gem_handle_create(file_priv,
> + _cma->obj->base, handle);
> +}
> +
> +static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
> + .destroy= drm_fb_cma_destroy,
> + .create_handle  = drm_fb_cma_create_handle,
> +};
> +
> +static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
> + struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_cma_obj *obj)
> +{
> + struct drm_fb_cma *fb_cma;
> + int ret;
> +
> + fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
> + if (!fb_cma)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = drm_framebuffer_init(dev, _cma->fb, _fb_cma_funcs);
> + if (ret) {
> + dev_err(dev->dev, "Failed to initalize framebuffer: %d\n", ret);

s/initalize/initialize/

kfree(fb_cma)?

> + return ERR_PTR(ret);
> + }
> +
> +
> +/**
> + * drm_fbdev_cma_init() - Allocate and initlaize a drm_fbdev_cma struct

s/initlaize/initialize/

> + * @dev: DRM device
> + * @prefered_bpp: Prefered bits per pixel for the device

s/prefered/preferred/

> + * @num_crtc: Number of CRTCs
> + * @max_conn_count: Maximum number of connectors
> + *
> + * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
> + */

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

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Laurent Pinchart]

Hi Daniel,

On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> > On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > > The passed mode must not be modified by the operation, make it const.
> > > > 
> > > > Signed-off-by: Laurent Pinchart 
> > > 
> > > Acked-by: Daniel Vetter 
> > 
> > Thank you for the ack. Would you also be so kind as to tell me how to fix
> > the related i915 issue (as briefly stated in the patch, the i915 driver
> > modifies mode->clock in intel_dp_mode_fixup()) ? Or, even better, provide
> > a patch for that ? :-)
> 
> Oops, lack of coffee. Patch is in the works.

No worries :-) As my patch should go on top of yours, could you please take it 
in your tree ?

> Btw, do you plan to constify other stuff?

Not immediately. When I tried to implement .mode_fixup() I wasn't sure whether 
drivers were allowed to modify the mode argument. After researching it I came 
up to the conclusion that they should not, hence the patch. It would make 
sense to constify other structures and function arguments as well though.

-- 
Regards,

Laurent Pinchart

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> > On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > > The passed mode must not be modified by the operation, make it const.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > 
> > Acked-by: Daniel Vetter 
> 
> Thank you for the ack. Would you also be so kind as to tell me how to fix the 
> related i915 issue (as briefly stated in the patch, the i915 driver modifies 
> mode->clock in intel_dp_mode_fixup()) ? Or, even better, provide a patch for 
> that ? :-)

Oops, lack of coffee. Patch is in the works. Btw, do you plan to constify
other stuff?
-Daneil
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Chris Wilson]

On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter  
wrote:
> We should only frob adjusted_mode. This is in preparation of
> a massive patch by Laurent Pinchart to make the mode argument
> const.
> 
> The only thing we actually touch is mode->clock, but only if
> it's a panel. And in that case we also set adjusted_mode->clock
> to the same value. All the generic code already uses the
> adjusted_mode exclusively, so we only have to move the dp
> link bw calculations over to that. This requires a small
> changes so that the shared code with mode_valid doesn't
> touch the mode argument.

Separate patch please, I'm sure you are right, but that is the scary
one...

> 
> Also mark the mode argument of pch_panel_fitting const.
> 
> Reported-by: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c|   19 +++
>  drivers/gpu/drm/i915/intel_drv.h   |2 +-
>  drivers/gpu/drm/i915/intel_panel.c |2 +-
>  3 files changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 296cfc2..05c4748 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>  static bool
>  intel_dp_adjust_dithering(struct intel_dp *intel_dp,
> struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> +   bool adjust_mode)

Would this look more pleasant if you rewrote this function so that the
adjustment of flags was done in the caller?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 43295] panic occurred switching back to text console ubuntu 11.10

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43295





--- Comment #3 from Alan   2012-05-30 11:26:43 ---
*** Bug 43288 has been marked as a duplicate of this bug. ***

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

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Laurent Pinchart]

Hi Daniel,

On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
> On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> > The passed mode must not be modified by the operation, make it const.
> > 
> > Signed-off-by: Laurent Pinchart 
> 
> Acked-by: Daniel Vetter 

Thank you for the ack. Would you also be so kind as to tell me how to fix the 
related i915 issue (as briefly stated in the patch, the i915 driver modifies 
mode->clock in intel_dp_mode_fixup()) ? Or, even better, provide a patch for 
that ? :-)

-- 
Regards,

Laurent Pinchart

[PATCH] drm: Add downclock quirk for Samsung LTN121AT10-301

[Sean Paul]

On Wed, May 30, 2012 at 10:16 AM, Adam Jackson  wrote:
> On 5/30/12 8:05 AM, Sean Paul wrote:
>
>> Yes, definitely. The reason I can't set it via xrandr (easily) is
>> because we look for lvds downclock modes (in i915) on the driver init.
>> Since the driver initializes way before we have a chance to add a new
>> mode via xrandr, the driver won't have a downclock mode.
>>
>> I suppose the other option is to hack the i915 driver to allow a
>> downclocked mode to be added after it's been initialized. I haven't
>> looked into this solution, it might be worth investigating.
>
>
> Just so I'm clear, is what you're looking for "I want this pair of timings,
> with the driver magically switching between them"? ?If all you wanted was
> the lower clock speed all the time you could just, you know, do that, so I
> assume that's not what you're after.
>

Yep, you got it.

> If binding two timings together like that is what you want, then that seems
> like a pretty reasonable device-specific ioctl at first glance. ?I think the
> only thing to be careful of would be copying the slower timings into the
> driver private of the faster, rather than keeping a pointer or copy of the
> object id, since modes aren't refcounted.
>
> How big of a power savings do you see with this? ?Wondering if it's worth
> trying to make some common tooling for finding downclocked modes, if it's
> going to be worthwhile on multiple panels.
>

I saw about 200mW savings with downclocking enabled. It's hard to say
how many panels this might apply to, some panels which report
downclocked states still flicker, and others that don't have it in the
EDID work just fine (like this Samsung panel).

LVDS downclocking is enabled by default in Fedora and ChromiumOS, so
making this more accessible might be useful for users of these
distros.

Sean



> - ajax

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
> The passed mode must not be modified by the operation, make it const.
> 
> Signed-off-by: Laurent Pinchart 
Acked-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 43295] panic occurred switching back to text console ubuntu 11.10

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=43295


Alan  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||alan at lxorguk.ukuu.org.uk
  Component|Bug Tracker |Video(DRI - non Intel)
 AssignedTo|bugme-admin at osdl.org|drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Product|Other   |Drivers




--- Comment #2 from Alan   2012-05-30 11:15:44 ---
Does the box hang at that point ?

Unfortunately the important data is off the top of the display so it would need
to be recovered by dmesg or similar

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

[Intel-gfx] [PATCH] intel: add a timed wait function

[Ben Widawsky]

On Wed, 30 May 2012 10:41:20 -0700
Eric Anholt  wrote:

> On Sun, 27 May 2012 13:16:54 -0700, Ben Widawsky  wrote:
> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> > index b776d2f..695a449 100644
> > --- a/intel/intel_bufmgr_gem.c
> > +++ b/intel/intel_bufmgr_gem.c
> > @@ -1478,6 +1478,32 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
> > drm_intel_gem_bo_start_gtt_access(bo, 1);
> >  }
> >  
> > +int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t *timeout_ns)
> > +{
> > +   drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)
> > bo->bufmgr;
> > +   drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> > +   struct drm_i915_gem_wait wait;
> > +   int ret;
> > +
> > +   if (!timeout_ns)
> > +   return -EINVAL;
> 
> At least for the GL case, timeout of 0 ns wants to turn into
> GL_TIMEOUT_EXPIRED or GL_ALREADY_SIGNALED.  -EINVAL doesn't sound like
> translating into either of those -- are you thinking that GL will
> special case 0 ns to not call this function?

Well, it's timeout of NULL, not 0. 0 should do what you want. I can turn
NULL into 0 just as easily, if you want?

> 
> > +
> > +   wait.bo_handle = bo_gem->gem_handle;
> > +   wait.timeout_ns = *timeout_ns;
> > +   wait.flags = 0;
> > +   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (wait.timeout_ns == 0) {
> > +   DBG("Wait timed out on buffer %d\n",
> > bo_gem->gem_handle);
> > +   *timeout_ns = 0;
> > +   } else
> > +   *timeout_ns = wait.timeout_ns;
> > +
> > +   return ret;
> > +}
> 
> Do we see any consumers wanting the unslept time?  GL doesn't care, and
> not passing a pointer would be more convenient for the caller.

That is how I originally had it, but Daniel Vetter requested otherwise.
I don't care either way. This interacts with your earlier comment as
well.

> 
> I guess GL_ALREADY_SIGNALED handling will be done using a check for
> bo_busy() before calling this.

It shouldn't have to.

I think the outcome is either, drop the return time, or convert NULLs to
0, and everything should be fine, right?


-- 
Ben Widawsky, Intel Open Source Technology Center

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

just regular fixes, bunch from intel, quieting some of the over zealous 
power warnings, and the rest just misc.

I've got another pull with the remaining dma-buf bits, since the vmap bits 
are in your tree now. I'll send tomorrow just to space things out a bit.

Dave.

The following changes since commit a01ee165a132fadb57659d26246e340d6ac53265:

  Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd (2012-05-28 
13:10:41 -0700)

are available in the git repository at:


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

for you to fetch changes up to bc42aabc6a01b92b0f961d65671564e0e1cd7592:

  drm/edid/quirks: ViewSonic VA2026w (2012-05-29 16:16:38 +0100)


Adam Jackson (1):
  drm/edid/quirks: ViewSonic VA2026w

Alex Deucher (2):
  drm/radeon: fix typo in trinity tiling setup
  drm/radeon: fix XFX quirk

Chris Wilson (4):
  drm/i915: Always update RPS interrupts thresholds along with frequency
  drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship
  drm/i915: Limit page allocations to lowmem (dma32) for i965
  drm/i915: Remove the error message for unbinding pinned buffers

Dan Carpenter (1):
  drm/udl: unlock before returning in udl_gem_mmap()

Daniel Vetter (7):
  drm/i915: be more careful when returning -ENXIO in gmbus transfer
  drm/i915: fix module unload since error_state rework
  drm/i915: properly handle interlaced bit for sdvo dtd conversion
  drm/i915: enable vdd when switching off the eDP panel
  drm/i915: wait for a vblank to pass after tv detect
  drm/i915: reject doubleclocked cea modes on dp
  drm/i915: tune down the noise of the RP irq limit fail

Dave Airlie (3):
  radeon: make radeon_cs_update_pages static.
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  drm/udl: remove unused variables.

Jan-Benedict Glaw (1):
  drm/i915: no lvds quirk for HP t5740e Thin Client

Jesse Barnes (1):
  drm/i915: always use RPNSWREQ for turbo change requests

Rodrigo Vivi (1):
  drm/i915: Adding TV Out Missing modes.

Ville Syrj?l? (2):
  drm: Constify params to format_check() and framebuffer_checks()
  drm: Use stdint types for consistency

 drivers/gpu/drm/drm_crtc.c   |8 ++--
 drivers/gpu/drm/drm_edid.c   |   22 --
 drivers/gpu/drm/i915/i915_debugfs.c  |2 +
 drivers/gpu/drm/i915/i915_gem.c  |   16 +---
 drivers/gpu/drm/i915/i915_irq.c  |   37 -
 drivers/gpu/drm/i915/intel_display.c |   56 +++---
 drivers/gpu/drm/i915/intel_dp.c  |   24 ++-
 drivers/gpu/drm/i915/intel_i2c.c |   21 +-
 drivers/gpu/drm/i915/intel_lvds.c|8 
 drivers/gpu/drm/i915/intel_pm.c  |   64 --
 drivers/gpu/drm/i915/intel_sdvo.c|   12 --
 drivers/gpu/drm/i915/intel_sdvo_regs.h   |5 +++
 drivers/gpu/drm/i915/intel_tv.c  |   53 +
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |1 -
 drivers/gpu/drm/radeon/radeon_atombios.c |4 +-
 drivers/gpu/drm/radeon/radeon_cs.c   |   27 -
 drivers/gpu/drm/radeon/radeon_ring.c |   25 
 drivers/gpu/drm/udl/udl_gem.c|4 +-
 19 files changed, 250 insertions(+), 141 deletions(-)

Fw: [Intel-gfx] [PATCH] intel: add a timed wait function

[Eric Anholt]

On Sun, 27 May 2012 13:16:54 -0700, Ben Widawsky  wrote:
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index b776d2f..695a449 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -1478,6 +1478,32 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
>   drm_intel_gem_bo_start_gtt_access(bo, 1);
>  }
>  
> +int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t *timeout_ns)
> +{
> + drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)
> bo->bufmgr;
> + drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> + struct drm_i915_gem_wait wait;
> + int ret;
> +
> + if (!timeout_ns)
> + return -EINVAL;

At least for the GL case, timeout of 0 ns wants to turn into
GL_TIMEOUT_EXPIRED or GL_ALREADY_SIGNALED.  -EINVAL doesn't sound like
translating into either of those -- are you thinking that GL will
special case 0 ns to not call this function?

> +
> + wait.bo_handle = bo_gem->gem_handle;
> + wait.timeout_ns = *timeout_ns;
> + wait.flags = 0;
> + ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, );
> + if (ret)
> + return ret;
> +
> + if (wait.timeout_ns == 0) {
> + DBG("Wait timed out on buffer %d\n",
> bo_gem->gem_handle);
> + *timeout_ns = 0;
> + } else
> + *timeout_ns = wait.timeout_ns;
> +
> + return ret;
> +}

Do we see any consumers wanting the unslept time?  GL doesn't care, and
not passing a pointer would be more convenient for the caller.

I guess GL_ALREADY_SIGNALED handling will be done using a check for
bo_busy() before calling this.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120530/8fe6d3e9/attachment-0001.pgp>

edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Mon, May 28, 2012 at 08:51:51PM +0200, Daniel Vetter wrote:
> On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds
>  wrote:
> > A new worry about excessively verbose i915 driver "errors" that don't
> > actually seem to be errors.
> >
> > I got myself a micro-DP to VGA adapter so that I can use my Macbook
> > Air for presentations.
> >
> > And testing it, hotplugging seems to work very nicely, and gone are
> > the days when you had to do xrandr and crap. Things "JustWork(tm)".
> >
> > Goodie.
> >
> > Until you start looking at the dmesg log. Then it gets ugly. It's full
> > of scary-looking stuff like
> >
> > ?[ cut here ]
> > ?WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 
> > intel_dp_check_edp+0x5d/0xb0()
> > ?Hardware name: MacBookAir4,1
> > ?eDP powered off while attempting aux channel communication.
> > ?Modules linked in: fuse rfcomm bnep nf_conntrack_netbios_ns
> > nf_conntrack_broadcast ..
> > ?Pid: 2126, comm: kworker/0:0 Tainted: G ? ? ? ?W ? ?3.4.0-08209-gae32adc #9
> > ?Call Trace:
> > ? ?warn_slowpath_common+0x7a/0xb0
> > ? ?warn_slowpath_fmt+0x41/0x50
> > ? ?intel_dp_check_edp+0x5d/0xb0
> > ? ?intel_dp_aux_ch+0x3f/0x330
> > ? ?intel_dp_aux_native_read_retry+0xad/0x130
> > ? ?intel_dp_detect+0x240/0x2c0
> > ? ?output_poll_execute+0xba/0x1a0
> > ? ?process_one_work+0x11b/0x3c0
> > ? ?worker_thread+0x12e/0x2d0
> > ? ?kthread+0x8e/0xa0
> > ? ?kernel_thread_helper+0x4/0x10
> > ?---[ end trace 5756a4d08d9e2a83 ]---
> >
> > which seems a bit extreme. I just unplugged the connector, I don't
> > think it should necessarily make quite this big a deal over it. What
> > does the WARN_ON() with the full call trace really buy us?
> 
> Well, all these edp checks (I presume all the other WARN backtraces
> yell around about edp, too) ensure that we have edp vdd or the panel
> power on while we try to do dp aux channel communication. And because
> we do need to talk to the monitor at tons of places, the backtrace is
> actually really useful to debug such edp vdd confusions.
> 
> The real problem here is that we think that the DP connector on your
> MBA is connected to an edp panel, which is pretty bogus. Cc'ing Chris
> and Keith who have the hw. Btw, you don't see all that dmesg spam
> until you connect something real because we check the hotplug pin
> status before we try to do use the dp aux channel (to get at the
> edid).

Ok, Chris couldn't reproduce this on his mba. Can you please boot with
drm.debug=0xe, reproduce the noise and then attach the full dmesg?

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: Add downclock quirk for Samsung LTN121AT10-301

[Adam Jackson]

On 5/30/12 8:05 AM, Sean Paul wrote:

> Yes, definitely. The reason I can't set it via xrandr (easily) is
> because we look for lvds downclock modes (in i915) on the driver init.
> Since the driver initializes way before we have a chance to add a new
> mode via xrandr, the driver won't have a downclock mode.
>
> I suppose the other option is to hack the i915 driver to allow a
> downclocked mode to be added after it's been initialized. I haven't
> looked into this solution, it might be worth investigating.

Just so I'm clear, is what you're looking for "I want this pair of 
timings, with the driver magically switching between them"?  If all you 
wanted was the lower clock speed all the time you could just, you know, 
do that, so I assume that's not what you're after.

If binding two timings together like that is what you want, then that 
seems like a pretty reasonable device-specific ioctl at first glance.  I 
think the only thing to be careful of would be copying the slower 
timings into the driver private of the faster, rather than keeping a 
pointer or copy of the object id, since modes aren't refcounted.

How big of a power savings do you see with this?  Wondering if it's 
worth trying to make some common tooling for finding downclocked modes, 
if it's going to be worthwhile on multiple panels.

- ajax

[PATCH] drm/radeon: fix regression in UMS CS ioctl

[alexdeuc...@gmail.com]

From: Alex Deucher 

radeon_cs_parser_init is called by both the legacy UMS
CS ioctl and the KMS CS ioctl.  Protect KMS specific
pieces of the code by checking that rdev is not NULL.

Reported-by: Michael Burian 

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_cs.c |   31 +--
 1 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0137689..142f894 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -147,6 +147,7 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser *p)
   sync_to_ring, p->ring);
 }

+/* XXX: note that this is called from the legacy UMS CS ioctl as well */
 int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
 {
struct drm_radeon_cs *cs = data;
@@ -245,22 +246,24 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, 
void *data)
}
}

-   if ((p->cs_flags & RADEON_CS_USE_VM) &&
-   !p->rdev->vm_manager.enabled) {
-   DRM_ERROR("VM not active on asic!\n");
-   return -EINVAL;
-   }
-
-   /* we only support VM on SI+ */
-   if ((p->rdev->family >= CHIP_TAHITI) &&
-   ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
-   DRM_ERROR("VM required on SI+!\n");
-   return -EINVAL;
-   }
+   /* these are KMS only */
+   if (p->rdev) {
+   if ((p->cs_flags & RADEON_CS_USE_VM) &&
+   !p->rdev->vm_manager.enabled) {
+   DRM_ERROR("VM not active on asic!\n");
+   return -EINVAL;
+   }

-   if (radeon_cs_get_ring(p, ring, priority))
-   return -EINVAL;
+   /* we only support VM on SI+ */
+   if ((p->rdev->family >= CHIP_TAHITI) &&
+   ((p->cs_flags & RADEON_CS_USE_VM) == 0)) {
+   DRM_ERROR("VM required on SI+!\n");
+   return -EINVAL;
+   }

+   if (radeon_cs_get_ring(p, ring, priority))
+   return -EINVAL;
+   }

/* deal with non-vm */
if ((p->chunk_ib_idx != -1) &&
-- 
1.7.7.5

i915: GPU hung (F14, Intel Core i5-670)

[Daniel Vetter]

On Tue, May 29, 2012 at 07:41:37PM -0700, Linus Torvalds wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson  
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an actual hw limit. As soon we try to use memory above
> > that value, the GPU decides not to listen to us any more.
> >
> > Fixed in xf86-video-intel 2.14.901
> 
> I really don't think that's the case.
> 
> I have run the F14 X server for a *long* time without these issues on
> this machine, and today I now got a second GPU hang with the current
> git tree. I was in the middle of just writing an email in chrome,
> nothing fancy going on at all.

Well, we've quite massively tuned our gpu address space handling in 3.5,
so it's a bit more likely to hit this problem. Relevant commits are
3ae5378330f5814
ffc62976d2158
dabdfe021ab1e985e

> So please please *please* take a second look. Because I think it's
> triggered by the i915 changes, or you undid a workaround that used to
> work fine.

Nope, and you've reported this exact problem previously already, e.g.

http://comments.gmane.org/gmane.comp.video.dri.devel/63082

Really, please upgrade your userspace - this is by far not the only bug
fixed since then that can result in a gpu hang.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

i915: GPU hung (F14, Intel Core i5-670)

[Linus Torvalds]

On Wed, May 30, 2012 at 12:25 AM, Chris Wilson  
wrote:
>
> You've reported this bug in the past, though maybe on a different machine:

It's quite likely the same machine - but in the past it may have
happened once per six months or something. Now it happened twice in
two days.

  Linus

i915: GPU hung (F14, Intel Core i5-670)

[Linus Torvalds]

On Wed, May 30, 2012 at 12:42 AM, Daniel Vetter  wrote:
>
> Really, please upgrade your userspace - this is by far not the only bug
> fixed since then that can result in a gpu hang.

I *can't* upgrade my userpsace.

F14 is the last one that has a sane window manager. After that, the
gnome3 shit happens, and my productivity goes to hell.

Gnome 3.4 in F17 is getting closer to usable, so I may be forced to
some day, but seriously - I want to have a modern kernel with usable
user space, and right now that means F14.

Linus

edp backtrace spam on MacBookAir4,1

[Linus Torvalds]

On Wed, May 30, 2012 at 9:00 AM, Daniel Vetter  wrote:
>
> Hm, that's pretty strange that you can't reproduce this any more. We check
> this has_edp stuff once at boot and then never touch it again.

Actually, I think I just figured out how to reproduce it: try to
suspend with the micro-DP <-> VGA dongle, and attached to the screen.
The suspend will fail, and the VGA screen does *not* come on again,
and the messages happen.

But I didn't have drm.debug on this time - but I suspect that Chris
will now be able to reproduce it easily with that information.

This time it also seems to be preceded by this message:

 [drm:intel_cpt_verify_modeset]  *ERROR* mode set failed: pipe 0 stuck

but that didn't happen last time so it may or may not be related.

 Linus

edp backtrace spam on MacBookAir4,1

[Linus Torvalds]

On Wed, May 30, 2012 at 1:27 AM, Daniel Vetter  wrote:
>
> Ok, Chris couldn't reproduce this on his mba. Can you please boot with
> drm.debug=0xe, reproduce the noise and then attach the full dmesg?

Hmm. Now *I* can't reproduce it either.

I have updated my system in the meantime, so maybe this is related to
that. However, I suspect it's more likely that it's some race
condition, because when I got it, I got a *lot* of it, but they were
all very tightly bunched together:

 [ 1588.996413] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1588.996650] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.000983] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.001225] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.005975] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.006218] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.010980] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.011224] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.015976] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.016211] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.020986] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()
 [ 1589.021232] WARNING: at drivers/gpu/drm/i915/intel_dp.c:350
intel_dp_check_edp+0x5d/0xb0()

ie that's 12 of those warnings (each of them with that huge backtrace
etc), but they are all within 0.03 seconds of each other. So I suspect
it needs to hit some particular timing window, and I was just
(un)lucky.

Because when I try it now with DRM debugging, I can't hit it. And just
to make sure, I re-did the test without debugging too (in case the
debugging would have changed timing), but can't reproduce it that way
either.

 Linus

i915: GPU hung (F14, Intel Core i5-670)

[Chris Wilson]

On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds  wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson  
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an actual hw limit. As soon we try to use memory above
> > that value, the GPU decides not to listen to us any more.
> >
> > Fixed in xf86-video-intel 2.14.901
> 
> I really don't think that's the case.
> 
> I have run the F14 X server for a *long* time without these issues on
> this machine, and today I now got a second GPU hang with the current
> git tree. I was in the middle of just writing an email in chrome,
> nothing fancy going on at all.

You've reported this bug in the past, though maybe on a different machine:
alpine.LFD.2.02.221437120.9111 at i5.linux-foundation.org
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

i915: GPU hung (F14, Intel Core i5-670)

[Chris Wilson]

On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds  wrote:
> On Mon, May 28, 2012 at 12:06 AM, Chris Wilson  
> wrote:
> >
> > No, the i915_error_state had everything I needed to see. It is the old
> > ddx bug that was hardcoding a maximum relocation address that never
> > corresponded with an actual hw limit. As soon we try to use memory above
> > that value, the GPU decides not to listen to us any more.
> >
> > Fixed in xf86-video-intel 2.14.901
> 
> I really don't think that's the case.
> 
> I have run the F14 X server for a *long* time without these issues on
> this machine, and today I now got a second GPU hang with the current
> git tree. I was in the middle of just writing an email in chrome,
> nothing fancy going on at all.
> 
> So please please *please* take a second look. Because I think it's
> triggered by the i915 changes, or you undid a workaround that used to
> work fine.

[PATCH] drm: Add downclock quirk for Samsung LTN121AT10-301

[Sean Paul]

On Wed, May 30, 2012 at 1:06 AM, Rafa? Mi?ecki  wrote:
> 2012/5/30 Sean Paul :
>> On Tue, May 29, 2012 at 5:23 PM, Alex Deucher  
>> wrote:
>>> On Tue, May 29, 2012 at 4:33 PM, Sean Paul  wrote:
 On Tue, May 29, 2012 at 10:43 AM, Alex Deucher  
 wrote:
> On Mon, May 28, 2012 at 1:20 PM, Sean Paul  
> wrote:
>> On Wed, Jan 18, 2012 at 10:06 AM, Sean Paul  
>> wrote:
>>> Add a quirk which adds a new downclocked mode to the EDID of Samsung
>>> LTN121AT10-301 panels. This allows the intel driver to apply 
>>> downclocking
>>> and save power.
>>>
>>
>> Is there any feedback on the patch? I'd like to get it merged if 
>> possible.
>
> This seems like something that should be specific to the intel driver
> rather than risking problems with this monitor on other drivers.
>

 Thanks for the feedback, Alex. I had originally put this in the intel
 driver, but moved it since it was a nasty hack. Furthermore, it was
 less obvious that the mode was available, since it was hidden to all
 layers above i915. The panel is just fine with the lower refresh rate,
 so it shouldn't have any issues with other drivers.
>>>
>>> Well it doesn't really seem like a quirk per se, the monitor works
>>> just fine without it. ?You are basically just adding an arbitrary new
>>> user defined mode that happens to work on the monitor. ?Seems like you
>>> should just be adding the mode with xrandr or equivalent.
>>>
>>
>> Unfortunately, adding it via xrandr won't take advantage of the i915
>> lvds downclocking feature, which is the motivation for the patch.
>>
>> At any rate, it doesn't look like there's any interest in picking this
>> patch up, so we'll just carry it locally in chromium-os :(
>
> May I ask why? AFAIU you're just copying PREFERRED mode and changing
> it's clock. xrandr allows you to set custom clock, doesn't it?
>

Yes, definitely. The reason I can't set it via xrandr (easily) is
because we look for lvds downclock modes (in i915) on the driver init.
Since the driver initializes way before we have a chance to add a new
mode via xrandr, the driver won't have a downclock mode.

I suppose the other option is to hack the i915 driver to allow a
downclocked mode to be added after it's been initialized. I haven't
looked into this solution, it might be worth investigating.

Sean


> --
> Rafa?

No subject

0x0314e050:  0x61010006: STATE_BASE_ADDRESS
0x0314e054:  0x0001:general state base address 0x
0x0314e058:  0x0001:surface state base address 0x
0x0314e05c:  0x0001:indirect state base address 0x
0x0314e060:  0x0001:instruction state base address 0x
0x0314e064:  0x1001:general state upper bound 0x1000
0x0314e068:  0x1001:indirect state upper bound 0x1000
0x0314e06c:  0x1001:instruction state upper bound 0x1000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e00016384 0048  000ab700 dirty purgeable render uncached
...
  11e3 4096 0011  000ab700 purgeable render uncached
  11e2b000 4096 0011  000ab700 purgeable render uncached
  10e43000 4096 0011  000ab700 render uncached
  10e44000 4096 0011  000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Add downclock quirk for Samsung LTN121AT10-301

[Rafał Miłecki]

2012/5/30 Sean Paul :
> On Tue, May 29, 2012 at 5:23 PM, Alex Deucher  
> wrote:
>> On Tue, May 29, 2012 at 4:33 PM, Sean Paul  wrote:
>>> On Tue, May 29, 2012 at 10:43 AM, Alex Deucher  
>>> wrote:
 On Mon, May 28, 2012 at 1:20 PM, Sean Paul  
 wrote:
> On Wed, Jan 18, 2012 at 10:06 AM, Sean Paul  
> wrote:
>> Add a quirk which adds a new downclocked mode to the EDID of Samsung
>> LTN121AT10-301 panels. This allows the intel driver to apply downclocking
>> and save power.
>>
>
> Is there any feedback on the patch? I'd like to get it merged if possible.

 This seems like something that should be specific to the intel driver
 rather than risking problems with this monitor on other drivers.

>>>
>>> Thanks for the feedback, Alex. I had originally put this in the intel
>>> driver, but moved it since it was a nasty hack. Furthermore, it was
>>> less obvious that the mode was available, since it was hidden to all
>>> layers above i915. The panel is just fine with the lower refresh rate,
>>> so it shouldn't have any issues with other drivers.
>>
>> Well it doesn't really seem like a quirk per se, the monitor works
>> just fine without it. ?You are basically just adding an arbitrary new
>> user defined mode that happens to work on the monitor. ?Seems like you
>> should just be adding the mode with xrandr or equivalent.
>>
>
> Unfortunately, adding it via xrandr won't take advantage of the i915
> lvds downclocking feature, which is the motivation for the patch.
>
> At any rate, it doesn't look like there's any interest in picking this
> patch up, so we'll just carry it locally in chromium-os :(

May I ask why? AFAIU you're just copying PREFERRED mode and changing
it's clock. xrandr allows you to set custom clock, doesn't it?

-- 
Rafa?

[Bug 50149] Faulty shaders on RS600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #12 from Roman ?makal  2012-05-29 
21:35:06 PDT ---
With this settings textures are rendered, but they are red-shaded instead, so
its not a fix for the issue

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

[RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Laurent Pinchart]

The passed mode must not be modified by the operation, make it const.

Signed-off-by: Laurent Pinchart 
---

This will break the i915 driver, as it modifies mode->clock in
intel_dp_mode_fixup(), hence the RFC state. Is this incorrect behaviour from
the i915 driver ?

 drivers/gpu/drm/exynos/exynos_drm_crtc.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h|2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|2 +-
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |2 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c  |2 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c |2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c  |2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.h  |2 +-
 drivers/gpu/drm/gma500/mdfld_intel_display.c|2 +-
 drivers/gpu/drm/gma500/oaktrail_crtc.c  |2 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c  |2 +-
 drivers/gpu/drm/gma500/psb_intel_display.c  |2 +-
 drivers/gpu/drm/gma500/psb_intel_drv.h  |2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c |2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |6 +++---
 drivers/gpu/drm/i2c/ch7006_drv.c|2 +-
 drivers/gpu/drm/i2c/ch7006_mode.c   |2 +-
 drivers/gpu/drm/i2c/sil164_drv.c|2 +-
 drivers/gpu/drm/i915/dvo.h  |2 +-
 drivers/gpu/drm/i915/intel_crt.c|2 +-
 drivers/gpu/drm/i915/intel_dp.c |3 ++-
 drivers/gpu/drm/i915/intel_drv.h|2 +-
 drivers/gpu/drm/i915/intel_dvo.c|2 +-
 drivers/gpu/drm/i915/intel_hdmi.c   |2 +-
 drivers/gpu/drm/i915/intel_lvds.c   |2 +-
 drivers/gpu/drm/i915/intel_panel.c  |2 +-
 drivers/gpu/drm/i915/intel_sdvo.c   |6 +++---
 drivers/gpu/drm/i915/intel_tv.c |3 ++-
 drivers/gpu/drm/nouveau/nv04_crtc.c |2 +-
 drivers/gpu/drm/nouveau/nv04_dac.c  |2 +-
 drivers/gpu/drm/nouveau/nv04_dfp.c  |2 +-
 drivers/gpu/drm/nouveau/nv17_tv.c   |2 +-
 drivers/gpu/drm/nouveau/nv50_crtc.c |2 +-
 drivers/gpu/drm/nouveau/nv50_dac.c  |3 ++-
 drivers/gpu/drm/nouveau/nv50_sor.c  |3 ++-
 drivers/gpu/drm/nouveau/nvd0_display.c  |8 +---
 drivers/gpu/drm/radeon/atombios_crtc.c  |2 +-
 drivers/gpu/drm/radeon/atombios_dp.c|2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  |4 ++--
 drivers/gpu/drm/radeon/radeon_display.c |4 ++--
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 +-
 drivers/gpu/drm/radeon/radeon_mode.h|4 ++--
 drivers/gpu/drm/udl/udl_encoder.c   |2 +-
 drivers/gpu/drm/udl/udl_modeset.c   |2 +-
 drivers/staging/omapdrm/omap_crtc.c |2 +-
 drivers/staging/omapdrm/omap_encoder.c  |2 +-
 include/drm/drm_crtc_helper.h   |4 ++--
 52 files changed, 68 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 4afb625..32a34c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -237,7 +237,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)

 static bool
 exynos_drm_crtc_mode_fixup(struct drm_crtc *crtc,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index c82c90c..277653d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -174,7 +174,7 @@ struct exynos_drm_manager_ops {
void (*apply)(struct device *subdrv_dev);
void (*mode_fixup)(struct device *subdrv_dev,
struct drm_connector *connector,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
void (*mode_set)(struct device *subdrv_dev, void *mode);
void (*get_max_resol)(struct device *subdrv_dev, unsigned int *width,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 23d5ad3..4a13a74 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ 

[PATCH/RFC] drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

[Laurent Pinchart]

DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
for KMS drivers.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_irq.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

My understanding of the DRM framework tells me that calling
DRM_IOCTL_MODESET_CTL on a KMS driver is not only unneeded, but could also
mess up its internal state. Did I get it right ?

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c798eea..03f16f3 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -974,7 +974,6 @@ EXPORT_SYMBOL(drm_vblank_off);
  * drm_vblank_pre_modeset - account for vblanks across mode sets
  * @dev: DRM device
  * @crtc: CRTC in question
- * @post: post or pre mode set?
  *
  * Account for vblank events across mode setting events, which will likely
  * reset the hardware frame counter.
@@ -1037,6 +1036,10 @@ int drm_modeset_ctl(struct drm_device *dev, void *data,
if (!dev->num_crtcs)
return 0;

+   /* KMS drivers handle this internally */
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return 0;
+
crtc = modeset->crtc;
if (crtc >= dev->num_crtcs)
return -EINVAL;
-- 
Regards,

Laurent Pinchart

[Bug 50149] Faulty shaders on RS600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from Tom Stellard  2012-05-29 16:39:47 
PDT ---
(In reply to comment #10)
> Created attachment 62189 [details]
> Lightsmark rant with RADEON_DEBUG=fp
> 
> There we go. I hope it will be usefull

I think I see the bug.  Do you still get errors in Lightsmark if you set the
env variable RADEON_TEX_GROUP=32

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

Re: PCI resources above 4GB

[Bjorn Helgaas]

On Mon, May 21, 2012 at 11:27 AM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18/05/12 10:08, Yinghai Lu wrote:
 On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu ying...@kernel.org
 wrote:
 On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org
 wrote:
 On Thu, May 17, 2012 at 5:34 AM, Steven Newbury
 st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE- Strange, the busn branch
 is merged with for-pci-res-alloc, but for some reason it
 isn't working.  Only the bridge is detected, not the devices
 behind it.

 Can you post the boot log ? maybe recently reordering patches
 applying sequence break it.

 Never mind, found the problem.

 updated for-pci-res-alloc branch. please check it.

 Tested and working fine now.

Can you attach dmesg logs without Yinghai's patches (where I assume it
doesn't work) and with them (where it *does* work) to the bugzilla?  I
assume https://bugzilla.kernel.org/show_bug.cgi?id=10461 is still the
relevant report.

I'm confused because I thought your _CRS showed no apertures above
4GB, and I'm trying to figure out how Yinghai's patches can help if
that's the case.

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

Re: i915: GPU hung (F14, Intel Core i5-670)

[Chris Wilson]

On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds 
torva...@linux-foundation.org wrote:
 On Mon, May 28, 2012 at 12:06 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 
  No, the i915_error_state had everything I needed to see. It is the old
  ddx bug that was hardcoding a maximum relocation address that never
  corresponded with an actual hw limit. As soon we try to use memory above
  that value, the GPU decides not to listen to us any more.
 
  Fixed in xf86-video-intel 2.14.901
 
 I really don't think that's the case.
 
 I have run the F14 X server for a *long* time without these issues on
 this machine, and today I now got a second GPU hang with the current
 git tree. I was in the middle of just writing an email in chrome,
 nothing fancy going on at all.
 
 So please please *please* take a second look. Because I think it's
 triggered by the i915 changes, or you undid a workaround that used to
 work fine.

From the error-state:

0x0314e050:  0x61010006: STATE_BASE_ADDRESS
0x0314e054:  0x0001:general state base address 0x
0x0314e058:  0x0001:surface state base address 0x
0x0314e05c:  0x0001:indirect state base address 0x
0x0314e060:  0x0001:instruction state base address 0x
0x0314e064:  0x1001:general state upper bound 0x1000
0x0314e068:  0x1001:indirect state upper bound 0x1000
0x0314e06c:  0x1001:instruction state upper bound 0x1000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e00016384 0048  000ab700 dirty purgeable render uncached
...
  11e3 4096 0011  000ab700 purgeable render uncached
  11e2b000 4096 0011  000ab700 purgeable render uncached
  10e43000 4096 0011  000ab700 render uncached
  10e44000 4096 0011  000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: GPU hung (F14, Intel Core i5-670)

[Chris Wilson]

On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds 
torva...@linux-foundation.org wrote:
 On Mon, May 28, 2012 at 12:06 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 
  No, the i915_error_state had everything I needed to see. It is the old
  ddx bug that was hardcoding a maximum relocation address that never
  corresponded with an actual hw limit. As soon we try to use memory above
  that value, the GPU decides not to listen to us any more.
 
  Fixed in xf86-video-intel 2.14.901
 
 I really don't think that's the case.
 
 I have run the F14 X server for a *long* time without these issues on
 this machine, and today I now got a second GPU hang with the current
 git tree. I was in the middle of just writing an email in chrome,
 nothing fancy going on at all.

You've reported this bug in the past, though maybe on a different machine:
alpine.lfd.2.02.221437120.9...@i5.linux-foundation.org
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: GPU hung (F14, Intel Core i5-670)

[Daniel Vetter]

On Tue, May 29, 2012 at 07:41:37PM -0700, Linus Torvalds wrote:
 On Mon, May 28, 2012 at 12:06 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 
  No, the i915_error_state had everything I needed to see. It is the old
  ddx bug that was hardcoding a maximum relocation address that never
  corresponded with an actual hw limit. As soon we try to use memory above
  that value, the GPU decides not to listen to us any more.
 
  Fixed in xf86-video-intel 2.14.901
 
 I really don't think that's the case.
 
 I have run the F14 X server for a *long* time without these issues on
 this machine, and today I now got a second GPU hang with the current
 git tree. I was in the middle of just writing an email in chrome,
 nothing fancy going on at all.

Well, we've quite massively tuned our gpu address space handling in 3.5,
so it's a bit more likely to hit this problem. Relevant commits are
3ae5378330f5814
ffc62976d2158
dabdfe021ab1e985e

 So please please *please* take a second look. Because I think it's
 triggered by the i915 changes, or you undid a workaround that used to
 work fine.

Nope, and you've reported this exact problem previously already, e.g.

http://comments.gmane.org/gmane.comp.video.dri.devel/63082

Really, please upgrade your userspace - this is by far not the only bug
fixed since then that can result in a gpu hang.

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

Re: edp backtrace spam on MacBookAir4,1

[Daniel Vetter]

On Mon, May 28, 2012 at 08:51:51PM +0200, Daniel Vetter wrote:
 On Mon, May 28, 2012 at 1:09 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:
  A new worry about excessively verbose i915 driver errors that don't
  actually seem to be errors.
 
  I got myself a micro-DP to VGA adapter so that I can use my Macbook
  Air for presentations.
 
  And testing it, hotplugging seems to work very nicely, and gone are
  the days when you had to do xrandr and crap. Things JustWork(tm).
 
  Goodie.
 
  Until you start looking at the dmesg log. Then it gets ugly. It's full
  of scary-looking stuff like
 
   [ cut here ]
   WARNING: at drivers/gpu/drm/i915/intel_dp.c:350 
  intel_dp_check_edp+0x5d/0xb0()
   Hardware name: MacBookAir4,1
   eDP powered off while attempting aux channel communication.
   Modules linked in: fuse rfcomm bnep nf_conntrack_netbios_ns
  nf_conntrack_broadcast ..
   Pid: 2126, comm: kworker/0:0 Tainted: G        W    3.4.0-08209-gae32adc #9
   Call Trace:
     warn_slowpath_common+0x7a/0xb0
     warn_slowpath_fmt+0x41/0x50
     intel_dp_check_edp+0x5d/0xb0
     intel_dp_aux_ch+0x3f/0x330
     intel_dp_aux_native_read_retry+0xad/0x130
     intel_dp_detect+0x240/0x2c0
     output_poll_execute+0xba/0x1a0
     process_one_work+0x11b/0x3c0
     worker_thread+0x12e/0x2d0
     kthread+0x8e/0xa0
     kernel_thread_helper+0x4/0x10
   ---[ end trace 5756a4d08d9e2a83 ]---
 
  which seems a bit extreme. I just unplugged the connector, I don't
  think it should necessarily make quite this big a deal over it. What
  does the WARN_ON() with the full call trace really buy us?
 
 Well, all these edp checks (I presume all the other WARN backtraces
 yell around about edp, too) ensure that we have edp vdd or the panel
 power on while we try to do dp aux channel communication. And because
 we do need to talk to the monitor at tons of places, the backtrace is
 actually really useful to debug such edp vdd confusions.
 
 The real problem here is that we think that the DP connector on your
 MBA is connected to an edp panel, which is pretty bogus. Cc'ing Chris
 and Keith who have the hw. Btw, you don't see all that dmesg spam
 until you connect something real because we check the hotplug pin
 status before we try to do use the dp aux channel (to get at the
 edid).

Ok, Chris couldn't reproduce this on his mba. Can you please boot with
drm.debug=0xe, reproduce the noise and then attach the full dmesg?

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
 The passed mode must not be modified by the operation, make it const.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Laurent Pinchart]

Hi Daniel,

On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
 On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
  The passed mode must not be modified by the operation, make it const.
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 
 Acked-by: Daniel Vetter daniel.vet...@ffwll.ch

Thank you for the ack. Would you also be so kind as to tell me how to fix the 
related i915 issue (as briefly stated in the patch, the i915 driver modifies 
mode-clock in intel_dp_mode_fixup()) ? Or, even better, provide a patch for 
that ? :-)

-- 
Regards,

Laurent Pinchart

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

Re: [RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
 Hi Daniel,
 
 On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
  On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
   The passed mode must not be modified by the operation, make it const.
   
   Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  
  Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 Thank you for the ack. Would you also be so kind as to tell me how to fix the 
 related i915 issue (as briefly stated in the patch, the i915 driver modifies 
 mode-clock in intel_dp_mode_fixup()) ? Or, even better, provide a patch for 
 that ? :-)

Oops, lack of coffee. Patch is in the works. Btw, do you plan to constify
other stuff?
-Daneil
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Laurent Pinchart]

Hi Daniel,

On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
 On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
  On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
   On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
The passed mode must not be modified by the operation, make it const.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
   
   Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
  
  Thank you for the ack. Would you also be so kind as to tell me how to fix
  the related i915 issue (as briefly stated in the patch, the i915 driver
  modifies mode-clock in intel_dp_mode_fixup()) ? Or, even better, provide
  a patch for that ? :-)
 
 Oops, lack of coffee. Patch is in the works.

No worries :-) As my patch should go on top of yours, could you please take it 
in your tree ?

 Btw, do you plan to constify other stuff?

Not immediately. When I tried to implement .mode_fixup() I wasn't sure whether 
drivers were allowed to modify the mode argument. After researching it I came 
up to the conclusion that they should not, hence the patch. It would make 
sense to constify other structures and function arguments as well though.

-- 
Regards,

Laurent Pinchart

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

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

just regular fixes, bunch from intel, quieting some of the over zealous 
power warnings, and the rest just misc.

I've got another pull with the remaining dma-buf bits, since the vmap bits 
are in your tree now. I'll send tomorrow just to space things out a bit.

Dave.

The following changes since commit a01ee165a132fadb57659d26246e340d6ac53265:

  Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd (2012-05-28 
13:10:41 -0700)

are available in the git repository at:


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

for you to fetch changes up to bc42aabc6a01b92b0f961d65671564e0e1cd7592:

  drm/edid/quirks: ViewSonic VA2026w (2012-05-29 16:16:38 +0100)


Adam Jackson (1):
  drm/edid/quirks: ViewSonic VA2026w

Alex Deucher (2):
  drm/radeon: fix typo in trinity tiling setup
  drm/radeon: fix XFX quirk

Chris Wilson (4):
  drm/i915: Always update RPS interrupts thresholds along with frequency
  drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationship
  drm/i915: Limit page allocations to lowmem (dma32) for i965
  drm/i915: Remove the error message for unbinding pinned buffers

Dan Carpenter (1):
  drm/udl: unlock before returning in udl_gem_mmap()

Daniel Vetter (7):
  drm/i915: be more careful when returning -ENXIO in gmbus transfer
  drm/i915: fix module unload since error_state rework
  drm/i915: properly handle interlaced bit for sdvo dtd conversion
  drm/i915: enable vdd when switching off the eDP panel
  drm/i915: wait for a vblank to pass after tv detect
  drm/i915: reject doubleclocked cea modes on dp
  drm/i915: tune down the noise of the RP irq limit fail

Dave Airlie (3):
  radeon: make radeon_cs_update_pages static.
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
  drm/udl: remove unused variables.

Jan-Benedict Glaw (1):
  drm/i915: no lvds quirk for HP t5740e Thin Client

Jesse Barnes (1):
  drm/i915: always use RPNSWREQ for turbo change requests

Rodrigo Vivi (1):
  drm/i915: Adding TV Out Missing modes.

Ville Syrjälä (2):
  drm: Constify params to format_check() and framebuffer_checks()
  drm: Use stdint types for consistency

 drivers/gpu/drm/drm_crtc.c   |8 ++--
 drivers/gpu/drm/drm_edid.c   |   22 --
 drivers/gpu/drm/i915/i915_debugfs.c  |2 +
 drivers/gpu/drm/i915/i915_gem.c  |   16 +---
 drivers/gpu/drm/i915/i915_irq.c  |   37 -
 drivers/gpu/drm/i915/intel_display.c |   56 +++---
 drivers/gpu/drm/i915/intel_dp.c  |   24 ++-
 drivers/gpu/drm/i915/intel_i2c.c |   21 +-
 drivers/gpu/drm/i915/intel_lvds.c|8 
 drivers/gpu/drm/i915/intel_pm.c  |   64 --
 drivers/gpu/drm/i915/intel_sdvo.c|   12 --
 drivers/gpu/drm/i915/intel_sdvo_regs.h   |5 +++
 drivers/gpu/drm/i915/intel_tv.c  |   53 +
 drivers/gpu/drm/radeon/ni.c  |2 +-
 drivers/gpu/drm/radeon/radeon.h  |1 -
 drivers/gpu/drm/radeon/radeon_atombios.c |4 +-
 drivers/gpu/drm/radeon/radeon_cs.c   |   27 -
 drivers/gpu/drm/radeon/radeon_ring.c |   25 
 drivers/gpu/drm/udl/udl_gem.c|4 +-
 19 files changed, 250 insertions(+), 141 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] DRM: Add DRM kms/fb cma helper

[Sascha Hauer]

On Tue, May 29, 2012 at 08:20:35PM +0200, Lars-Peter Clausen wrote:
 This patchset introduces a set of helper function for implementing the KMS
 framebuffer layer for drivers which use the drm gem CMA helper function.

I just integrated this into my series. Works great, thanks.
Would be great to have this mainline.

Only some nitpicking and one missing kfree below.

Sascha

 +static void drm_fb_cma_destroy(struct drm_framebuffer *fb)
 +{
 + struct drm_fb_cma *fb_cma = to_fb_cma(fb);
 +
 + if (fb_cma-obj)
 + drm_gem_object_unreference_unlocked(fb_cma-obj-base);
 +
 + drm_framebuffer_cleanup(fb);
 + kfree(fb_cma);
 +}
 +
 +static int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
 + struct drm_file *file_priv, unsigned int *handle)
 +{
 + struct drm_fb_cma *fb_cma = to_fb_cma(fb);
 +
 + return drm_gem_handle_create(file_priv,
 + fb_cma-obj-base, handle);
 +}
 +
 +static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
 + .destroy= drm_fb_cma_destroy,
 + .create_handle  = drm_fb_cma_create_handle,
 +};
 +
 +static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
 + struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_cma_obj *obj)
 +{
 + struct drm_fb_cma *fb_cma;
 + int ret;
 +
 + fb_cma = kzalloc(sizeof(*fb_cma), GFP_KERNEL);
 + if (!fb_cma)
 + return ERR_PTR(-ENOMEM);
 +
 + ret = drm_framebuffer_init(dev, fb_cma-fb, drm_fb_cma_funcs);
 + if (ret) {
 + dev_err(dev-dev, Failed to initalize framebuffer: %d\n, ret);

s/initalize/initialize/

kfree(fb_cma)?

 + return ERR_PTR(ret);
 + }
 +
 +
 +/**
 + * drm_fbdev_cma_init() - Allocate and initlaize a drm_fbdev_cma struct

s/initlaize/initialize/

 + * @dev: DRM device
 + * @prefered_bpp: Prefered bits per pixel for the device

s/prefered/preferred/

 + * @num_crtc: Number of CRTCs
 + * @max_conn_count: Maximum number of connectors
 + *
 + * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
 + */

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

Re: [RFC/PATCH] drm: Make the .mode_fixup() operations mode argument a const pointer

[Daniel Vetter]

On Wed, May 30, 2012 at 12:11:49PM +0200, Laurent Pinchart wrote:
 Hi Daniel,
 
 On Wednesday 30 May 2012 12:02:19 Daniel Vetter wrote:
  On Wed, May 30, 2012 at 11:24:50AM +0200, Laurent Pinchart wrote:
   On Wednesday 30 May 2012 11:18:56 Daniel Vetter wrote:
On Wed, May 30, 2012 at 01:01:08AM +0200, Laurent Pinchart wrote:
 The passed mode must not be modified by the operation, make it const.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
   
   Thank you for the ack. Would you also be so kind as to tell me how to fix
   the related i915 issue (as briefly stated in the patch, the i915 driver
   modifies mode-clock in intel_dp_mode_fixup()) ? Or, even better, provide
   a patch for that ? :-)
  
  Oops, lack of coffee. Patch is in the works.
 
 No worries :-) As my patch should go on top of yours, could you please take 
 it 
 in your tree ?

Well I think that patch should go through Dave's tree directly. But I send
him regular -next pull requests, so that should stall your patch for long.
-Daniel

  Btw, do you plan to constify other stuff?
 
 Not immediately. When I tried to implement .mode_fixup() I wasn't sure 
 whether 
 drivers were allowed to modify the mode argument. After researching it I came 
 up to the conclusion that they should not, hence the patch. It would make 
 sense to constify other structures and function arguments as well though.
 
 -- 
 Regards,
 
 Laurent Pinchart
 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

The only thing we actually touch is mode-clock, but only if
it's a panel. And in that case we also set adjusted_mode-clock
to the same value. All the generic code already uses the
adjusted_mode exclusively, so we only have to move the dp
link bw calculations over to that. This requires a small
changes so that the shared code with mode_valid doesn't
touch the mode argument.

Also mark the mode argument of pch_panel_fitting const.

Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c|   19 +++
 drivers/gpu/drm/i915/intel_drv.h   |2 +-
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..05c4748 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 static bool
 intel_dp_adjust_dithering(struct intel_dp *intel_dp,
  struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ bool adjust_mode)
 {
int max_link_clock = 
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -236,8 +236,8 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
if (mode_rate  max_rate)
return false;
 
-   if (adjusted_mode)
-   adjusted_mode-private_flags
+   if (adjust_mode)
+   mode-private_flags
|= INTEL_MODE_DP_FORCE_6BPC;
 
return true;
@@ -260,7 +260,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}
 
-   if (!intel_dp_adjust_dithering(intel_dp, mode, NULL))
+   if (!intel_dp_adjust_dithering(intel_dp, mode, false))
return MODE_CLOCK_HIGH;
 
if (mode-clock  1)
@@ -698,25 +698,20 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_fixed_panel_mode(intel_dp-panel_fixed_mode, 
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
-   /*
-* the mode-clock is used to calculate the DataLink M/N
-* of the pipe. For the eDP the fixed clock should be used.
-*/
-   mode-clock = intel_dp-panel_fixed_mode-clock;
}
 
-   if (mode-flags  DRM_MODE_FLAG_DBLCLK)
+   if (adjusted_mode-flags  DRM_MODE_FLAG_DBLCLK)
return false;
 
DRM_DEBUG_KMS(DP link computation with max lane count %i 
  max bw %02x pixel clock %iKHz\n,
  max_lane_count, bws[max_clock], mode-clock);
 
-   if (!intel_dp_adjust_dithering(intel_dp, mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, true))
return false;
 
bpp = adjusted_mode-private_flags  INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
-   mode_rate = intel_dp_link_required(mode-clock, bpp);
+   mode_rate = intel_dp_link_required(adjusted_mode-clock, bpp);
 
for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
for (clock = 0; clock = max_clock; clock++) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3e09188..3e3b60c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -372,7 +372,7 @@ extern void intel_fixed_panel_mode(struct drm_display_mode 
*fixed_mode,
   struct drm_display_mode *adjusted_mode);
 extern void intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
 extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
 extern u32 intel_panel_get_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 2a1625d..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -56,7 +56,7 @@ intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
 void
 intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode 

Re: [PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Chris Wilson]

On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
wrote:
 We should only frob adjusted_mode. This is in preparation of
 a massive patch by Laurent Pinchart to make the mode argument
 const.
 
 The only thing we actually touch is mode-clock, but only if
 it's a panel. And in that case we also set adjusted_mode-clock
 to the same value. All the generic code already uses the
 adjusted_mode exclusively, so we only have to move the dp
 link bw calculations over to that. This requires a small
 changes so that the shared code with mode_valid doesn't
 touch the mode argument.

Separate patch please, I'm sure you are right, but that is the scary
one...

 
 Also mark the mode argument of pch_panel_fitting const.
 
 Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_dp.c|   19 +++
  drivers/gpu/drm/i915/intel_drv.h   |2 +-
  drivers/gpu/drm/i915/intel_panel.c |2 +-
  3 files changed, 9 insertions(+), 14 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 296cfc2..05c4748 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
  static bool
  intel_dp_adjust_dithering(struct intel_dp *intel_dp,
 struct drm_display_mode *mode,
 -   struct drm_display_mode *adjusted_mode)
 +   bool adjust_mode)

Would this look more pleasant if you rewrote this function so that the
adjustment of flags was done in the caller?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43295] panic occurred switching back to text console ubuntu 11.10

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=43295


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |NEEDINFO
 CC||a...@lxorguk.ukuu.org.uk
  Component|Bug Tracker |Video(DRI - non Intel)
 AssignedTo|bugme-ad...@osdl.org|drivers_video-dri@kernel-bu
   ||gs.osdl.org
Product|Other   |Drivers




--- Comment #2 from Alan a...@lxorguk.ukuu.org.uk  2012-05-30 11:15:44 ---
Does the box hang at that point ?

Unfortunately the important data is off the top of the display so it would need
to be recovered by dmesg or similar

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

[Bug 43295] panic occurred switching back to text console ubuntu 11.10

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=43295





--- Comment #3 from Alan a...@lxorguk.ukuu.org.uk  2012-05-30 11:26:43 ---
*** Bug 43288 has been marked as a duplicate of this bug. ***

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

Re: [PATCH/RFC] drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

[Michel Dänzer]

On Mit, 2012-05-30 at 00:58 +0200, Laurent Pinchart wrote: 
 DRM_IOCTL_MODESET_CTL must only be used for UMS drivers. Make it a no-op
 for KMS drivers.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/gpu/drm/drm_irq.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)
 
 My understanding of the DRM framework tells me that calling
 DRM_IOCTL_MODESET_CTL on a KMS driver is not only unneeded, but could also
 mess up its internal state. Did I get it right ?

Yes, good catch.


 diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
 index c798eea..03f16f3 100644
 --- a/drivers/gpu/drm/drm_irq.c
 +++ b/drivers/gpu/drm/drm_irq.c
 @@ -974,7 +974,6 @@ EXPORT_SYMBOL(drm_vblank_off);
   * drm_vblank_pre_modeset - account for vblanks across mode sets
   * @dev: DRM device
   * @crtc: CRTC in question
 - * @post: post or pre mode set?
   *
   * Account for vblank events across mode setting events, which will likely
   * reset the hardware frame counter.

This hunk should really be in a separate patch, but other than that

Reviewed-by: Michel Dänzer mic...@daenzer.net


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

On Wed, May 30, 2012 at 11:58:43AM +0100, Chris Wilson wrote:
 On Wed, 30 May 2012 12:28:04 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
  We should only frob adjusted_mode. This is in preparation of
  a massive patch by Laurent Pinchart to make the mode argument
  const.
  
  The only thing we actually touch is mode-clock, but only if
  it's a panel. And in that case we also set adjusted_mode-clock
  to the same value. All the generic code already uses the
  adjusted_mode exclusively, so we only have to move the dp
  link bw calculations over to that. This requires a small
  changes so that the shared code with mode_valid doesn't
  touch the mode argument.
 
 Separate patch please, I'm sure you are right, but that is the scary
 one...

Will do.

  Also mark the mode argument of pch_panel_fitting const.
  
  Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/i915/intel_dp.c|   19 +++
   drivers/gpu/drm/i915/intel_drv.h   |2 +-
   drivers/gpu/drm/i915/intel_panel.c |2 +-
   3 files changed, 9 insertions(+), 14 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index 296cfc2..05c4748 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int 
  max_lanes)
   static bool
   intel_dp_adjust_dithering(struct intel_dp *intel_dp,
struct drm_display_mode *mode,
  - struct drm_display_mode *adjusted_mode)
  + bool adjust_mode)
 
 Would this look more pleasant if you rewrote this function so that the
 adjustment of flags was done in the caller?

Well, I've added the adjusted_mode parameter originally to exactly avoid
this duplication of code between mode_fixup and mode_valid (which caused a
bug). Atm we could just pass back a needs_6bpc_dither flag, but I guess
we'll eventually need similar logic for higher bpc (and maybe other funky
stuff). So I think setting the flag here is ok and the least ugly version.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/i915: adjusted_mode-clock in the dp mode_fixup

[Daniel Vetter]

... instead of changing mode-clock, which we should leave as-is.

We only touch that if it's a panel, and then adjusted mode-clock
equals adjusted_mode-clock. Outside of intel_dp.c we only use
ajusted_mode-clock in the mode_set functions.

Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.

As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode-clock).

Note that we do overwrite adjusted_mode-clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.

v2: Adjust the debug message to also use adjusted_mode-clock.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 296cfc2..a9dffa6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
intel_fixed_panel_mode(intel_dp-panel_fixed_mode, 
adjusted_mode);
intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
mode, adjusted_mode);
-   /*
-* the mode-clock is used to calculate the DataLink M/N
-* of the pipe. For the eDP the fixed clock should be used.
-*/
-   mode-clock = intel_dp-panel_fixed_mode-clock;
}
 
if (mode-flags  DRM_MODE_FLAG_DBLCLK)
@@ -710,13 +705,13 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
 
DRM_DEBUG_KMS(DP link computation with max lane count %i 
  max bw %02x pixel clock %iKHz\n,
- max_lane_count, bws[max_clock], mode-clock);
+ max_lane_count, bws[max_clock], adjusted_mode-clock);
 
-   if (!intel_dp_adjust_dithering(intel_dp, mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, adjusted_mode))
return false;
 
bpp = adjusted_mode-private_flags  INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
-   mode_rate = intel_dp_link_required(mode-clock, bpp);
+   mode_rate = intel_dp_link_required(adjusted_mode-clock, bpp);
 
for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
for (clock = 0; clock = max_clock; clock++) {
-- 
1.7.10

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

[PATCH 2/2] drm/i915: don't chnage the original mode in dp_mode_fixup

[Daniel Vetter]

We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

After the prevous prep patch to use adjusted_mode-clock instead of
mode-clock the only thing left is to clean up things a bit. I've
opted to pass in an adjust_mode param to dp_adjust_dithering because
that way we can be sure to avoid duplicating this logic - which was
the cause behind a dp link bw calculation bug in the past.

Also mark the mode argument of pch_panel_fitting const.

v2: Split up the mode-clock = adjusted_mode-clock change,
as suggested by Chris Wilson.

Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/intel_dp.c|   12 ++--
 drivers/gpu/drm/i915/intel_drv.h   |2 +-
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a9dffa6..c5c5669 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -222,7 +222,7 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 static bool
 intel_dp_adjust_dithering(struct intel_dp *intel_dp,
  struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+ bool adjust_mode)
 {
int max_link_clock = 
intel_dp_link_clock(intel_dp_max_link_bw(intel_dp));
int max_lanes = intel_dp_max_lane_count(intel_dp);
@@ -236,8 +236,8 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
if (mode_rate  max_rate)
return false;
 
-   if (adjusted_mode)
-   adjusted_mode-private_flags
+   if (adjust_mode)
+   mode-private_flags
|= INTEL_MODE_DP_FORCE_6BPC;
 
return true;
@@ -260,7 +260,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}
 
-   if (!intel_dp_adjust_dithering(intel_dp, mode, NULL))
+   if (!intel_dp_adjust_dithering(intel_dp, mode, false))
return MODE_CLOCK_HIGH;
 
if (mode-clock  1)
@@ -700,14 +700,14 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
mode, adjusted_mode);
}
 
-   if (mode-flags  DRM_MODE_FLAG_DBLCLK)
+   if (adjusted_mode-flags  DRM_MODE_FLAG_DBLCLK)
return false;
 
DRM_DEBUG_KMS(DP link computation with max lane count %i 
  max bw %02x pixel clock %iKHz\n,
  max_lane_count, bws[max_clock], adjusted_mode-clock);
 
-   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, adjusted_mode))
+   if (!intel_dp_adjust_dithering(intel_dp, adjusted_mode, true))
return false;
 
bpp = adjusted_mode-private_flags  INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3e09188..3e3b60c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -372,7 +372,7 @@ extern void intel_fixed_panel_mode(struct drm_display_mode 
*fixed_mode,
   struct drm_display_mode *adjusted_mode);
 extern void intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
 extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
 extern u32 intel_panel_get_backlight(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 2a1625d..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -56,7 +56,7 @@ intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
 void
 intel_pch_panel_fitting(struct drm_device *dev,
int fitting_mode,
-   struct drm_display_mode *mode,
+   const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
-- 
1.7.10

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

Re: [PATCH] drm: Add downclock quirk for Samsung LTN121AT10-301

[Sean Paul]

On Wed, May 30, 2012 at 1:06 AM, Rafał Miłecki zaj...@gmail.com wrote:
 2012/5/30 Sean Paul seanp...@chromium.org:
 On Tue, May 29, 2012 at 5:23 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Tue, May 29, 2012 at 4:33 PM, Sean Paul seanp...@chromium.org wrote:
 On Tue, May 29, 2012 at 10:43 AM, Alex Deucher alexdeuc...@gmail.com 
 wrote:
 On Mon, May 28, 2012 at 1:20 PM, Sean Paul seanp...@chromium.org wrote:
 On Wed, Jan 18, 2012 at 10:06 AM, Sean Paul seanp...@chromium.org 
 wrote:
 Add a quirk which adds a new downclocked mode to the EDID of Samsung
 LTN121AT10-301 panels. This allows the intel driver to apply 
 downclocking
 and save power.


 Is there any feedback on the patch? I'd like to get it merged if 
 possible.

 This seems like something that should be specific to the intel driver
 rather than risking problems with this monitor on other drivers.


 Thanks for the feedback, Alex. I had originally put this in the intel
 driver, but moved it since it was a nasty hack. Furthermore, it was
 less obvious that the mode was available, since it was hidden to all
 layers above i915. The panel is just fine with the lower refresh rate,
 so it shouldn't have any issues with other drivers.

 Well it doesn't really seem like a quirk per se, the monitor works
 just fine without it.  You are basically just adding an arbitrary new
 user defined mode that happens to work on the monitor.  Seems like you
 should just be adding the mode with xrandr or equivalent.


 Unfortunately, adding it via xrandr won't take advantage of the i915
 lvds downclocking feature, which is the motivation for the patch.

 At any rate, it doesn't look like there's any interest in picking this
 patch up, so we'll just carry it locally in chromium-os :(

 May I ask why? AFAIU you're just copying PREFERRED mode and changing
 it's clock. xrandr allows you to set custom clock, doesn't it?


Yes, definitely. The reason I can't set it via xrandr (easily) is
because we look for lvds downclock modes (in i915) on the driver init.
Since the driver initializes way before we have a chance to add a new
mode via xrandr, the driver won't have a downclock mode.

I suppose the other option is to hack the i915 driver to allow a
downclocked mode to be added after it's been initialized. I haven't
looked into this solution, it might be worth investigating.

Sean


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

Re: [PATCH 1/2] drm/i915: adjusted_mode-clock in the dp mode_fixup

[Chris Wilson]

On Wed, 30 May 2012 13:52:02 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
wrote:
 ... instead of changing mode-clock, which we should leave as-is.
 
 We only touch that if it's a panel, and then adjusted mode-clock
 equals adjusted_mode-clock. Outside of intel_dp.c we only use
 ajusted_mode-clock in the mode_set functions.
 
 Within intel_dp.c we only use it to calculate the dp dithering
 and link bw parameters, so that's the only thing we need to fix
 up.
 
 As a temporary ugliness (until the cleanup in the next patch) we
 pass the adjusted_mode into dp_dither for both parameters (because
 that one still looks at mode-clock).
 
 Note that we do overwrite adjusted_mode-clock with the selected dp
 link clock, but that only happens after we've calculated everything we
 need based on the dotclock of the adjusted output configuration.
 
 v2: Adjust the debug message to also use adjusted_mode-clock.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_dp.c |   11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 296cfc2..a9dffa6 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -698,11 +698,6 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
 drm_display_mode *mode,
   intel_fixed_panel_mode(intel_dp-panel_fixed_mode, 
 adjusted_mode);
   intel_pch_panel_fitting(dev, DRM_MODE_SCALE_FULLSCREEN,
   mode, adjusted_mode);
 - /*
 -  * the mode-clock is used to calculate the DataLink M/N
 -  * of the pipe. For the eDP the fixed clock should be used.
 -  */
 - mode-clock = intel_dp-panel_fixed_mode-clock;

But in ironlake_crtc_mode_set() we have:

 if (is_cpu_edp) {
 target_clock = mode-clock;
 } else {
   if (is_dp)
 target_clock = mode-clock;
   else
 target_clock = adjusted_mode-clock;
 }

It would seem like eDP would have had mode-clock adjusted previously.
Similarly PCH eDP uses the adjusted mode-clock in intel_dp_set_m_n().
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] Renesas SH Mobile DRM driver

[Laurent Pinchart]

Hi everybody,

Here's a new DRM driver for the Renesas SH Mobile display controller
(a.k.a. LCDC). The hardware is pretty simple and consists of a single CRTC and
four (non-scalable) planes that can be alpha-blended (first two planes only),
overlayed or composed using ROP3.

The first two patches will go through the fbdev tree, but I've included them
here in case someone woud like to compile the code. The third patch just
defines two new formats and could already go in, unless we have a policy not
to define formats until a driver uses them.

As this is my first attempt at writing a DRM driver I'm pretty sure I've made
many mistakes. Review will as usual be very appreciated.

I've modified the modetest application from the libdrm repository to test this
driver, I will submit patches for it right after cleaning them up.

Laurent Pinchart (4):
  fbdev: sh_mobile_meram: Add MERAM operations wrappers
  fbdev: sh_mobile_lcdc: Use MERAM operations wrappers
  drm: Add NV24 and NV42 pixel formats
  drm: Renesas SH Mobile DRM driver

 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/shmobile/Kconfig   |8 +
 drivers/gpu/drm/shmobile/Makefile  |8 +
 drivers/gpu/drm/shmobile/shmob_drm_backlight.c |   89 +++
 drivers/gpu/drm/shmobile/shmob_drm_backlight.h |   23 +
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  746 
 drivers/gpu/drm/shmobile/shmob_drm_crtc.h  |   59 ++
 drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  365 
 drivers/gpu/drm/shmobile/shmob_drm_drv.h   |   52 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.c   |  195 ++
 drivers/gpu/drm/shmobile/shmob_drm_gem.h   |   46 ++
 drivers/gpu/drm/shmobile/shmob_drm_kms.c   |  211 +++
 drivers/gpu/drm/shmobile/shmob_drm_kms.h   |   44 ++
 drivers/gpu/drm/shmobile/shmob_drm_plane.c |  240 
 drivers/gpu/drm/shmobile/shmob_drm_plane.h |   22 +
 drivers/gpu/drm/shmobile/shmob_drm_regs.h  |  304 ++
 drivers/video/sh_mobile_lcdcfb.c   |   18 +-
 drivers/video/sh_mobile_meram.c|   24 +-
 include/drm/drm_fourcc.h   |2 +
 include/drm/shmob_drm.h|   99 
 include/video/sh_mobile_meram.h|   28 +
 22 files changed, 2563 insertions(+), 23 deletions(-)
 create mode 100644 drivers/gpu/drm/shmobile/Kconfig
 create mode 100644 drivers/gpu/drm/shmobile/Makefile
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_gem.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
 create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
 create mode 100644 include/drm/shmob_drm.h

-- 
Regards,

Laurent Pinchart

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