[PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>  wrote:
>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
>>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>>  wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  
 wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
>> wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/plat-omap/Makefile
>>> +++ b/arch/arm/plat-omap/Makefile
>>> @@ -4,7 +4,7 @@
>>>
>>> ?# Common support
>>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>>> - ? ? ? ?usb.o fb.o counter_32k.o
>>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>
>> Should be something like this:
>> obj-$(CONFIG_DRM_OMAP) += drm.o
>
> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
> plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).
>>>
>>> oh, but this won't work, because common.c has to call
>>> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
>>> works).. so I think it has to stay the way it is in this patch.
>>
>> #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
>> extern void omapdrm_reserve_vram(void);
>> #else
>> static inline void omapdrm_reserve_vram(void) { }
>> #endif
>>
>> Like how it's done with DSP stuff.
>
> right, but then you'd miss the omapdrm_reserve_vram() call at startup..

Why?

-- 
Felipe Contreras

[PATCH] drm/i915: kill i915_mem.c

[Daniel Vetter]

On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
> Some decent history digging indicates that this was to be used for the
> GLX_MESA_allocate_memory extension but never actually implemented for
> any released i915 userspace code.
> 
> So just rip it out.
> 
> Cc: Dave Airlie 
> Cc: Keith Whitwell 
> Signed-Off-by: Daniel Vetter 

Can some bored soul take a look at this and do the history
double-checking? And maybe notice that the Makefile change is missing ...

/me would like to kill this cruft

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_ioctl.c |2 +
>  drivers/gpu/drm/i915/i915_dma.c |   13 +-
>  drivers/gpu/drm/i915/i915_drv.h |   13 --
>  drivers/gpu/drm/i915/i915_mem.c |  387 
> ---
>  4 files changed, 6 insertions(+), 409 deletions(-)
>  delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 904d7e9..6bfc5ce 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -37,6 +37,7 @@
>  #include "drm_core.h"
>  
>  #include "linux/pci.h"
> +#include "linux/export.h"
>  
>  /**
>   * Get the bus id.
> @@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
>   DRM_DEBUG("\n");
>   return 0;
>  }
> +EXPORT_SYMBOL(drm_noop);
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a9ae374..71a1946 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
>  
>   i915_gem_lastclose(dev);
>  
> - if (dev_priv->agp_heap)
> - i915_mem_takedown(&(dev_priv->agp_heap));
> -
>   i915_dma_cleanup(dev);
>  }
>  
> @@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, 
> struct drm_file *file_priv)
>  {
>   drm_i915_private_t *dev_priv = dev->dev_private;
>   i915_gem_release(dev, file_priv);
> - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - i915_mem_release(dev, file_priv, dev_priv->agp_heap);
>  }
>  
>  void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
> @@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> - DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  i915_mem_destroy_heap, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> + DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE,  i915_vblank_pipe_set, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE,  i915_vblank_pipe_get, 
> DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 554bef7..0dceb4a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -327,7 +327,6 @@ typedef struct drm_i915_private {
>  
>   int tex_lru_log_granularity;
>   int allow_batchbuffer;
> - struct mem_block *agp_heap;
>   unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
>   int vblank_pipe;
>   int num_pipe;
> @@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device 
> *dev);
>  #endif
>  
>  
> -/* i915_mem.c */
> -extern int i915_mem_alloc(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv);
> -extern int i915_mem_free(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv);
> -extern int i915_mem_init_heap(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv);
> -extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv);
> -extern void i915_mem_takedown(struct mem_block **heap);
> -extern void i915_mem_release(struct drm_device * dev,
> -  struct drm_file *file_priv, struct mem_block 
> *heap);
>  /* i915_gem.c */
>  int i915_gem_init_ioctl(struct drm_device *dev, void *data,
>   struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/i915/i915_mem.c b/drivers/gpu/drm/i915/i915_mem.c
> deleted file mode 

[Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Daniel Vetter]

Hi Dave,

Is it ok if I merge this through my -next tree? Otherwise please consider
merging this for 3.4.

Yours, Daniel

On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. We can do this by catching the -ENXIO
> error, provided by i2c_algo_bit:bit_doAddress call.
> 
> Within the bit_doAddress we already try 3 times to get the edid data, so
> if the routine tells us that bus is not responding, it is mostly pointless
> to keep re-trying those attempts over and over again until we reach final
> number of retries.
> 
> This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
> and improve overall edid detection timing by 10-30% in most cases, and by
> a much larger margin in case of phantom outputs (up to 30x in one worst
> case).
> 
> Timing results for i915-powered machines for 'time xrandr' command:
> Machine 1: from 0.840s to 0.290s
> Machine 2: from 0.315s to 0.280s
> Machine 3: from +/- 4s to 0.184s
> 
> Timing results for HD5770 with 'time xrandr' command:
> Machine 4: from 3.210s to 1.060s
> 
> Reviewed-by: Chris Wilson 
> Reviewed-by: Keith Packard 
> Tested-by: Sean Finney 
> Tested-by: Soren Hansen 
> Tested-by: Hernando Torque 
> Tested-by: Mike Lothian 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
> Signed-off-by: Eugeni Dodonov 
> ---
>  drivers/gpu/drm/drm_edid.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3e927ce..fb6c26c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
> unsigned char *buf,
>   }
>   };
>   ret = i2c_transfer(adapter, msgs, 2);
> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }
>   } while (ret != 2 && --retries);
>  
>   return ret == 2 ? 0 : -1;
> -- 
> 1.7.8
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

New drm-intel-next tree

[Daniel Vetter]

Hi all,

Because Keith is routinely really busy with all kinds of things, notably
gathering fixes for drm-intel-fixes, the patch merge process for the next
release cycle sometimes falls behind. To support him and improve things I've
been volunteered to take over handling the -next tree. 

The main aim is to shift the drm/i915 -next merge process massively ahead with
the goals to:
- Reduce pressure to merge questionable patches into -rc kernels because the
  -next tree is not yet open for patches.
- Allow our QA at Intel and also the community to actually test things before
  they land in mainline. The lack of such testing has severly bitten us in the
  past few releases.
- Refocus -fixes on handling regressions with absolute top priority (as it
  should).
- And generally get a steady and predictable patch-flow towards mainline back
  into gears.

I plan to run this -next tree with a few simple rules:
- I'll open the drm/i915 -next tree around -rc1 (maybe earlier in the future)
  and cut regular new trees about every 2nd week or so. 2 weeks should be enough
  for both our qa and the community to give it some decent testing.

- I intend to send out the previous -next to Dave Airlie (assuming it tests ok)
  so that he has a good check on the stuff that's going on in i915-land. A few
  other people also asked for a better overview of what's going on on drm/i915 -
  I'll plan to announce every new -next tree with a short mail (maybe together
  with the pull request to Dave for the old one).

- -next will close about 1-2 weeks before the merge opens. No new features after
  that point for a given release cycle.

- To make this really work we also need to cut down on what can go into -fixes.
  drm/i915 unfortunately has the reputation that deserves it a bunch of
  draconian rules (which are stricter than drm/* in general):

  - Only fixes for serious issues and regressions after the -next tree went to
Dave.
  - After -rc2 regression fixes only. It simply happend why too often that an
"obvious" patch blew up late in the -rc release cycle, my patches included.
  - After -rc4/5 only reverts and disable patches. Imo it's way too late to play
games by then, the real fix should go straight to -next (which will close
only a few weeks afterwards already).

- Regressions have top priority, if they get neglected due to ongoing work
  headed for -next I'll refuse to merge the patches.

- We have a test-suite in the intel-gpu-tools package for the kernel. Expect me
  to be annoying about patches that should have testcases for them but don't.
  This includes new features, but also bugs that can be reproduced with a
  reasonable amount of effort.

- To avoid me pushing utter crack I will only merge my own patches after they
  have gathered sufficient review on intel-gfx. Please yell at me at the top of
  your voice (and in public) if I violate this.

- The main discussion list for patches to drm/i915 is
  intel-gfx at lists.freedesktop.org - I don't keep up with lkml usually.

- I'll reserve my human right to act like an incompetent arrogant fool once in a
  while.

Last but not least, the new tree is available at

http://cgit.freedesktop.org/~danvet/drm-intel
git://people.freedesktop.org/~danvet/drm-intel

drm-intel-next is the main branch, but I expect at least a for-airlied branch
for pull requests and maybe other branches with proposed patches to show up.

Comments, flames and suggestions highly welcome.

Yours, Daniel

PS: Quick version for people with too short attentation spans:

- -next will open around -rc1, a new tree should show up about every second
  week. -next trees that are tested will regurarly be forwarded to Dave.

- No stuff in -fixes that should go into -next instead.

- -next will close for features about 1-2 weeks ahead of the upstream merge 
window.

- Regressions have top priority.

- Implementing proper tests is required.

- Hit me hard if I break these rules for my own patches.

- Sometimes I'll screw things up badly.

Now grab the tree from

git://people.freedesktop.org/~danvet/drm-intel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 42580] [radeon RS690] resume fails when radeon firmware is not available

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

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


J?r?me Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WILL_NOT_FIX




--- Comment #2 from J?r?me Glisse   2012-01-16 
20:36:47 ---
Btw, to be clear, we won't fix the no firmware case. So closing.

-- 
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 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

--- Comment #12 from GhostlyDeath  2012-01-16 
12:36:30 PST ---
I still get rendering errors with PrBoom with the patch applied. Do you have a
complete patch that can be applied to a more recent git revision?

By the way, I rebuilt with:
# make clean
# make distclean
# patch -p1 < befixes1.patch
# patch -p1 < befixes2.patch
# ./configure --prefix=/opt/xorg --with-dri-driverdir=/opt/xorg/lib/dri/ 
--with-gallium-drivers=r300,r600,swrast  --enable-glx-tls --enable-gles1
--enable-gles2 --enable-openvg --enable-xorg --enable-gallium-egl --with-x
# make
# rm -rf /opt/xorg
# make install

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

[Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Dave Airlie]

On Mon, Jan 16, 2012 at 7:59 PM, Paulo Zanoni  wrote:
> Hi
>
> 2012/1/5 Jakob Bornecrantz :
>> Couldn't this be done by just adding a property instead of a ioctl?
>>
>
> So I've discussed this with Jesse and it seems the best way to turn
> this into a property is to add support for CRTC properties, then add a
> "rotation" property for the i915 driver. This will actually introduce
> 2 new ioctls: one to list the properties and one to change them.

Okay I must have missed the bit where you explain why a connector
property isn't used?

Dave.

[Bug 42580] [radeon RS690] resume fails when radeon firmware is not available

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

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


J?r?me Glisse  changed:

   What|Removed |Added

 CC||glisse at freedesktop.org




--- Comment #1 from J?r?me Glisse   2012-01-16 
20:29:05 ---
I am pondering on completely disabling KMS if firmware are not present. That
would avoid time waste on our side.

-- 
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 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

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

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

--- Comment #9 from Marko Kohtala  2012-01-16 
11:43:20 PST ---
Created attachment 55651
  --> https://bugs.freedesktop.org/attachment.cgi?id=55651
Artefacts in X, screencapture

This capture was with the enable_mtrr_cleanup mtrr_spare_reg_nr=1 to kernel.
Here I started the X server from command line and only an xterm and a window
manager. 

The artefacts appear to the window while I scroll the window pressing enter.

There was some constantly running horizontal artefacts, but they were
flickering and got erased immediately thus leaving no mark. Seems like it could
be ramdac reading bad for some scanlines, but more likely it goes on in the
framebuffer. The blue part lower in the window could be one of those caught. I
wonder if the squares in the xterm window are a result of that flickering, but
due to scrolling it does not get erased.

The blue and green spots came one by one slowly while doing something else in
the xterm. They stayed.

This happens only with this CAICOS card (I have an older radeon X300 that has
no problems, as well as a nVidia card goes without these problems). So I'd
expect whatever memory corruption there is, it is somehow in the CAICOS support
in kernel.

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

[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

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

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

--- Comment #8 from Marko Kohtala  2012-01-16 
11:26:00 PST ---
Created attachment 55650
  --> https://bugs.freedesktop.org/attachment.cgi?id=55650
dmesg with enable_mtrr_cleanup

Attached the dmesg with The /proc/mtrr is 

reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable

and with enable_mtrr_cleanup mtrr_spare_reg_nr=1 options

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c000 ( 3072MB), size=  512MB, count=1: write-back
reg03: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x0e000 ( 3584MB), size=  256MB, count=1: write-combining

It makes no difference.

I installed 32-bit debian 3.1.0 kernel and compiled fglrx for it and am now
reporting this with it. It does not have the artefacts, but is not quite
perfect either (gnome-shell 3.2.1 animations flicker like scaling of windows
does not work as expected, but no artifacts, possibly of no interest to you).

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

[PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
>>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>>  wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
 wrote:
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 9a58461..b86e6cb 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -4,7 +4,7 @@
>
> ?# Common support
> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
> - ? ? ? ?usb.o fb.o counter_32k.o
> + ? ? ? ?usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o
>>>
>>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>>> plat-omap module?
>>
>> Yes, and platform drivers are supposed to be loaded automatically at
>> boot-time by udev (or similar).
>
> oh, but this won't work, because common.c has to call
> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
> works).. so I think it has to stay the way it is in this patch.

#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
extern void omapdrm_reserve_vram(void);
#else
static inline void omapdrm_reserve_vram(void) { }
#endif

Like how it's done with DSP stuff.

-- 
Felipe Contreras

[Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Paulo Zanoni]

2012/1/16 Dave Airlie :
>
> Okay I must have missed the bit where you explain why a connector
> property isn't used?

The registers that contain the rotation information are the pipe
registers and, as far as I understood, each pipe is associated with
only one crtc. We can have more than one connector associated with one
crtc. So, in a case where we have two different connectors associated
with the same crtc, we would have to keep synchronizing the property
value between the two connectors: this doesn't sound like the best
solution and it could also create confusion (imagine the case where
connectors A and B are associated with the same crtc, and you set
connector_a.rotation to 0 and then connector_b.rotation to 180, then
you'll read connector_a.rotation and it will be 180, not what you just
set).

(and by the way, the three patches were sent just to dri-devel@)


-- 
Paulo Zanoni

[PATCH 2/3] drm: add CRTC properties

[Paulo Zanoni]

Three comments about the design are inline:

> +void drm_crtc_attach_property(struct drm_crtc *crtc,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_property *property, uint64_t 
> init_val)
> +{
> + ? ? ? int i;
> +
> + ? ? ? for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++) {
> + ? ? ? ? ? ? ? if (crtc->property_ids[i] == 0) {
> + ? ? ? ? ? ? ? ? ? ? ? crtc->property_ids[i] = property->base.id;
> + ? ? ? ? ? ? ? ? ? ? ? crtc->property_values[i] = init_val;
> + ? ? ? ? ? ? ? ? ? ? ? return;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> + ? ? ? BUG_ON(1);

I looked at drm_connector_attach_property and saw that instead of
BUG_ON(1), it tries to return -EINVAL. The problem is that only zero
callers check for the return value of drm_connector_attach_property. I
can provide a patch for drm_connector_attach_property changing the
-EINVAL for BUG_ON(1) if no one objects. Or I can also add -EINVAL to
drm_crtc_attach_property and, to be consistent, not check for it :)

>
> +int drm_mode_crtc_get_properties_ioctl(struct drm_device *dev, void *data,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv)
> +{
... (same function) ...
> +
> + ? ? ? for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++)
> + ? ? ? ? ? ? ? if (crtc->property_ids[i] != 0)
> + ? ? ? ? ? ? ? ? ? ? ? props_count++;
... (same function) ...
> + ? ? ? ? ? ? ? for (i = 0; i < props_count; i++) {
> + ? ? ? ? ? ? ? ? ? ? ? if (put_user(crtc->property_ids[i],
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?props_ptr + copied)) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = -EFAULT;
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? goto out;
> + ? ? ? ? ? ? ? ? ? ? ? }

If you look at the connector properties (and now crtc properties),
you'll see that they're stored in "property_ids" arrays, and invalid
IDs are "0". There is code to add properties, but I didn't find code
to remove them. But if you look at the connector code, you'll that it
is implemented in a way that if the array is something like: [
valid_id, 0, valid_id, 0, 0, 0 ... ], the code will work (even with a
zero in the middle of two valid ids). While this makes the code more
resistant to mistakes, it also makes some loops longer (you don't need
to stop at the first invalid id, you need to keep looking). And, as
far as I found, we don't ever reach the [ valid, 0, valid ] case
because we never remove properties. Even if we start removing
properties, we can try to avoid the [valid, 0, valid] case. In my
patch, this condition is not valid for the crtc properties, so we can
make loops shorter (and I see I could still improve one of the loops).
Which way do we prefer?

> + ? ? ? DRM_IOCTL_DEF(DRM_IOCTL_MODE_CRTC_GETPROPERTIES, 
> drm_mode_crtc_get_properties_ioctl, 
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + ? ? ? DRM_IOCTL_DEF(DRM_IOCTL_MODE_CRTC_SETPROPERTY, 
> drm_mode_crtc_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)

I'm not sure about how we want these flags. I just copied from
connector properties ioctls.

-- 
Paulo Zanoni

[PATCH 2/3] drm: add CRTC properties

[Paulo Zanoni]

From: Paulo Zanoni 

Code based on the connector properties code.

Two new ioctls:
- DRM_IOCTL_MODE_CRTC_GETPROPERTIES
- DRM_IOCTL_MODE_CRTC_SETPROPERTY

The i915 driver needs this (for the rotation property). Other drivers
might need this too.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_crtc.c |  116 
 drivers/gpu/drm/drm_drv.c  |4 +-
 include/drm/drm.h  |2 +
 include/drm/drm_crtc.h |   22 -
 include/drm/drm_mode.h |   13 +
 5 files changed, 155 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cd155e9..5112921 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2685,6 +2685,22 @@ int drm_connector_attach_property(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_property);

+void drm_crtc_attach_property(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t init_val)
+{
+   int i;
+
+   for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++) {
+   if (crtc->property_ids[i] == 0) {
+   crtc->property_ids[i] = property->base.id;
+   crtc->property_values[i] = init_val;
+   return;
+   }
+   }
+   BUG_ON(1);
+}
+EXPORT_SYMBOL(drm_crtc_attach_property);
+
 int drm_connector_property_set_value(struct drm_connector *connector,
  struct drm_property *property, uint64_t value)
 {
@@ -2992,6 +3008,106 @@ out:
return ret;
 }

+int drm_mode_crtc_get_properties_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_priv)
+{
+   struct drm_mode_crtc_get_properties *arg = data;
+   struct drm_mode_object *obj;
+   struct drm_crtc *crtc;
+   int ret = 0;
+   int i;
+   int copied = 0;
+   int props_count = 0;
+   uint32_t __user *props_ptr;
+   uint64_t __user *prop_values_ptr;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(>mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg->crtc_id, DRM_MODE_OBJECT_CRTC);
+   if (!obj) {
+   ret = -EINVAL;
+   goto out;
+   }
+   crtc = obj_to_crtc(obj);
+
+   for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++)
+   if (crtc->property_ids[i] != 0)
+   props_count++;
+
+   /* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it. */
+   if ((arg->count_props >= props_count) && props_count) {
+   copied = 0;
+   props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
+   prop_values_ptr = (uint64_t __user *)(unsigned long)
+ (arg->prop_values_ptr);
+   for (i = 0; i < props_count; i++) {
+   if (put_user(crtc->property_ids[i],
+props_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   if (put_user(crtc->property_values[i],
+prop_values_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   }
+   }
+   arg->count_props = props_count;
+out:
+   mutex_unlock(>mode_config.mutex);
+   return ret;
+}
+
+int drm_mode_crtc_set_property_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_mode_crtc_set_property *arg = data;
+   struct drm_mode_object *obj;
+   struct drm_property *property;
+   struct drm_crtc *crtc;
+   int ret = -EINVAL;
+   int i;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(>mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg->crtc_id, DRM_MODE_OBJECT_CRTC);
+   if (!obj)
+   goto out;
+   crtc = obj_to_crtc(obj);
+
+   for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++)
+   if (crtc->property_ids[i] == arg->prop_id)
+   break;
+
+   if (i == DRM_CRTC_MAX_PROPERTY)
+   goto out;
+
+   obj = drm_mode_object_find(dev, arg->prop_id, DRM_MODE_OBJECT_PROPERTY);
+   if (!obj)
+   goto out;
+   property = obj_to_property(obj);
+
+   if (!drm_property_change_is_valid(property, arg->value))
+   goto out;
+
+   if (crtc->funcs->set_property)
+   ret = crtc->funcs->set_property(crtc, property, arg->value);
+   if (!ret) {
+   crtc->property_values[i] = arg->value;
+   }
+out:
+   mutex_unlock(>mode_config.mutex);
+ 

[PATCH 1/3] drm: add drm_property_change_is_valid

[Paulo Zanoni]

From: Paulo Zanoni 

Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_crtc.c |   41 +
 1 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e818a8..cd155e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2917,6 +2917,26 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+static int drm_property_change_is_valid(struct drm_property *property,
+   __u64 value)
+{
+   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   return 0;
+   if (property->flags & DRM_MODE_PROP_RANGE) {
+   if (value < property->values[0])
+   return 0;
+   if (value > property->values[1])
+   return 0;
+   return 1;
+   } else {
+   int i;
+   for (i = 0; i < property->num_values; i++)
+   if (property->values[i] == value)
+   return 1;
+   return 0;
+   }
+}
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -2953,28 +2973,9 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
}
property = obj_to_property(obj);

-   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   if (!drm_property_change_is_valid(property, out_resp->value))
goto out;

-   if (property->flags & DRM_MODE_PROP_RANGE) {
-   if (out_resp->value < property->values[0])
-   goto out;
-
-   if (out_resp->value > property->values[1])
-   goto out;
-   } else {
-   int found = 0;
-   for (i = 0; i < property->num_values; i++) {
-   if (property->values[i] == out_resp->value) {
-   found = 1;
-   break;
-   }
-   }
-   if (!found) {
-   goto out;
-   }
-   }
-
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
if (connector->funcs->dpms)
-- 
1.7.8.3

[RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Paulo Zanoni]

Hi

2012/1/5 Jakob Bornecrantz :
> Couldn't this be done by just adding a property instead of a ioctl?
>

So I've discussed this with Jesse and it seems the best way to turn
this into a property is to add support for CRTC properties, then add a
"rotation" property for the i915 driver. This will actually introduce
2 new ioctls: one to list the properties and one to change them.

I'll send three Kernel patches to this list in the next minutes. One
just moves code around (so we can reuse it), another adds CRTC
properties in drm/ and the other adds the rotation property for i915.

I also wrote patches for libdrm (implement the ioctls, change
tests/modetest to call these ioctls, and some janitor work on modetest
and libdrm) and xf86-video-intel (use the rotation property). The drm
patches are applied to this tree:
http://cgit.freedesktop.org/~pzanoni/drm/ . I was only planning to
send them to the list after I get some review on the kernel patches.
The full list of patches I wrote so far is here:
http://people.freedesktop.org/~pzanoni/rotation/ .

For those asking more information about the problem: these bits are
somehow needed by the embedded VNC: it needs to know how the screen is
rotated. More information:
http://en.wikipedia.org/wiki/Intel_Active_Management_Technology#VNC-based_KVM_remote_control

Cheers,
Paulo

-- 
Paulo Zanoni

New drm-intel-next tree

[Eugeni Dodonov]

On Mon, Jan 16, 2012 at 17:41, Daniel Vetter  wrote:
>
> Hi all,
>
> Because Keith is routinely really busy with all kinds of things, notably
> gathering fixes for drm-intel-fixes, the patch merge process for the next
> release cycle sometimes falls behind. To support him and improve things I've
> been volunteered to take over handling the -next tree.
>
> The main aim is to shift the drm/i915 -next merge process massively ahead with
> the goals to:
> - Reduce pressure to merge questionable patches into -rc kernels because the
> ?-next tree is not yet open for patches.
> - Allow our QA at Intel and also the community to actually test things before
> ?they land in mainline. The lack of such testing has severly bitten us in the
> ?past few releases.
> - Refocus -fixes on handling regressions with absolute top priority (as it
> ?should).
> - And generally get a steady and predictable patch-flow towards mainline back
> ?into gears.

Following up on Daniel's mail, I discussed with him, and from now on I
intend to include the -next patches into the -drm-intel-backports [1]
as well, to simplify testing for ones of you running stable kernels
who want to test the latest breakages^w features :).

[1] http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/7961

--
Eugeni Dodonov

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

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

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

--- Comment #18 from Valter  2012-01-16 
09:22:40 PST ---
Hello to everybody, again.

I stand corrected.

After further tests, after rebooting, it is sufficient only to give the
command:

xrandr - output DVI-0 - mode 1920x1080R

so that the monitor is fine.

Why doesn't it execute the last command?

Does it exist another way to make the setting permanent?

And how?

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

[Bug 44499] r280 and xbmc - choppy menu and video playback

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

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

--- Comment #9 from smoki  2012-01-16 16:37:29 UTC ---
Created attachment 55656
  --> https://bugs.freedesktop.org/attachment.cgi?id=55656
oprofiled fog

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

[PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/plat-omap/Makefile
>>> +++ b/arch/arm/plat-omap/Makefile
>>> @@ -4,7 +4,7 @@
>>>
>>> ?# Common support
>>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>>> - ? ? ? ?usb.o fb.o counter_32k.o
>>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>
>> Should be something like this:
>> obj-$(CONFIG_DRM_OMAP) += drm.o
>
> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
> plat-omap module?

Yes, and platform drivers are supposed to be loaded automatically at
boot-time by udev (or similar).

-- 
Felipe Contreras

[next] Null pointer dereference in nouveau_vm_map_sg

[Jerome Glisse]

On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
> reproduce, so I can test patches if needed.
> 
>   Martin
> 

How do you trigger this ?

Cheers,
Jerome

> 
> 
> [  216.546584] BUG: unable to handle kernel NULL pointer dereference at 
> 00d0
> [  216.546613] IP: [] nouveau_vm_map_sg+0x2c/0x130
> [  216.546631] PGD 5b155067 PUD 5ab71067 PMD 0 
> [  216.546647] Oops:  [#1] SMP 
> [  216.546659] CPU 1 
> [  216.546664] Modules linked in: tun iwl4965 iwlegacy mac80211 cfg80211 tg3 
> psmouse rtc_cmos evdev ehci_hcd uhci_hcd usbcore usb_common [last unloaded: 
> scsi_wait_scan]
> [  216.546721] 
> [  216.546727] Pid: 3327, comm: Xorg Not tainted 3.2.0-next-20120113 #56 Dell 
> Inc. XPS M1330   /0PU073
> [  216.546749] RIP: 0010:[]  [] 
> nouveau_vm_map_sg+0x2c/0x130
> [  216.546770] RSP: 0018:88005b0c9858  EFLAGS: 00010246
> [  216.546780] RAX: 88005bf84620 RBX: 88005ab08d20 RCX: 
> 
> [  216.546791] RDX: 0001 RSI:  RDI: 
> 
> [  216.546802] RBP: 88005b0c98a8 R08:  R09: 
> 
> [  216.546813] R10: 0001 R11: 0001 R12: 
> 4000
> [  216.546823] R13: 88005bf84dc8 R14: 88007838c000 R15: 
> 
> [  216.546835] FS:  7f5f728a8880() GS:88007fd0() 
> knlGS:
> [  216.546848] CS:  0010 DS:  ES:  CR0: 80050033
> [  216.546857] CR2: 00d0 CR3: 6c1bb000 CR4: 
> 06e0
> [  216.546869] DR0:  DR1:  DR2: 
> 
> [  216.546880] DR3:  DR6: 0ff0 DR7: 
> 0400
> [  216.546892] Process Xorg (pid: 3327, threadinfo 88005b0c8000, task 
> 8800655da180)
> [  216.546904] Stack:
> [  216.546909]  88005b0c9960 880037180368  
> 
> [  216.546930]  88005b0c98d8 88005bf84dc8 88005b0c9960 
> 88007838c240
> [  216.546949]  88007838c000  88005b0c98d8 
> 81481bdf
> [  216.546969] Call Trace:
> [  216.546979]  [] nouveau_bo_move_ntfy+0x7f/0xb0
> [  216.546991]  [] ttm_bo_handle_move_mem+0x204/0x3d0
> [  216.547003]  [] ttm_bo_evict+0x1bd/0x2a0
> [  216.547015]  [] ? drm_mm_kmalloc+0x37/0xd0
> [  216.547027]  [] ttm_mem_evict_first+0x171/0x230
> [  216.547039]  [] ttm_bo_mem_space+0x30d/0x420
> [  216.547056]  [] ttm_bo_move_buffer+0xe8/0x160
> [  216.547069]  [] ? __lock_release+0x6b/0xe0
> [  216.547080]  [] ? drm_mm_kmalloc+0x37/0xd0
> [  216.547091]  [] ttm_bo_validate+0xe7/0xf0
> [  216.547102]  [] ttm_bo_init+0x1d4/0x2a0
> [  216.547113]  [] ? nouveau_bo_new+0x51/0x1c0
> [  216.547124]  [] nouveau_bo_new+0x15c/0x1c0
> [  216.547135]  [] ? nouveau_ttm_tt_create+0x80/0x80
> [  216.547148]  [] ? avc_has_perm_noaudit+0xfa/0x290
> [  216.547160]  [] nouveau_gem_new+0x53/0x120
> [  216.548008]  [] ? __lock_release+0xc1/0xe0
> [  216.548008]  [] ? might_fault+0x57/0xb0
> [  216.548008]  [] nouveau_gem_ioctl_new+0x69/0x170
> [  216.548008]  [] ? might_fault+0x57/0xb0
> [  216.548008]  [] drm_ioctl+0x444/0x510
> [  216.548008]  [] ? nouveau_gem_new+0x120/0x120
> [  216.548008]  [] do_vfs_ioctl+0x87/0x330
> [  216.548008]  [] ? selinux_file_ioctl+0x68/0x140
> [  216.548008]  [] sys_ioctl+0x91/0xa0
> [  216.555939]  [] system_call_fastpath+0x16/0x1b
> [  216.555939] Code: 48 89 e5 41 57 49 89 cf 41 56 41 55 49 89 fd 41 54 49 89 
> d4 ba 01 00 00 00 53 41 89 d3 48 83 ec 28 48 8b 47 20 48 8b 5f 18 31 ff <4c> 
> 8b b1 d0 00 00 00 0f b6 48 30 44 8b 48 34 8b 83 20 01 00 00 
> [  216.555939] RIP  [] nouveau_vm_map_sg+0x2c/0x130
> [  216.555939]  RSP 
> [  216.555939] CR2: 00d0
> [  216.581301] ---[ end trace 0d910003d5fb1cd8 ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
  wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  
> wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
>>> wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

 ?# Common support
 ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 - ? ? ? ?usb.o fb.o counter_32k.o
 + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>>
>>> Should be something like this:
>>> obj-$(CONFIG_DRM_OMAP) += drm.o
>>
>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>> plat-omap module?
>
> Yes, and platform drivers are supposed to be loaded automatically at
> boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.
>>>
>>> #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
>>> extern void omapdrm_reserve_vram(void);
>>> #else
>>> static inline void omapdrm_reserve_vram(void) { }
>>> #endif
>>>
>>> Like how it's done with DSP stuff.
>>
>> right, but then you'd miss the omapdrm_reserve_vram() call at startup..
>
> Why?

I guess drm.o is ending up in a module, but the code that calls that
(in common.c) is not in a module, so you get an unresolved symbol at
link

BR,
-R

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

[Bug 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)

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

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

--- Comment #8 from Alex Deucher  2012-01-16 06:16:23 PST 
---
Is this still an issue on newer versions of r600g?

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

[Bug 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)

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

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

--- Comment #7 from Tom Simnett  2012-01-16 
05:40:18 PST ---
Created attachment 55636
  --> https://bugs.freedesktop.org/attachment.cgi?id=55636
artefacts under -nouveau

This appears to happen in -nouveau too. Screenshot attached. What additional
information do you need? I'm running xorg-edgers PPA versions of everything on
Ubuntu.

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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

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

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

--- Comment #17 from Valter  2012-01-16 
05:39:36 PST ---
Ok.
I made ??the suggestion of Alex in this way:

1) I gave the following terminal commands:
xrandr - newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088  +
hsync-vsync
xrandr - DVI-0 addmode 1920x1080R
xrandr - output DVI-0 - mode 1920x1080R

The monitor works fine as well!

2) Then I wrote these commands:

sudo nano / etc / gdm / Init / Default

After the lines:

PATH = / usr / bin: $ PATH
IFS = $ OLD_IFS

and then I saved.

3) After restarting the monitor does not work anymore, but if I run the
commands from the terminal

xrandr - DVI-0 addmode 1920x1080R
xrandr - output DVI-0 - mode 1920x1080R

Then everything works!

What's wrong?

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

[PATCH 5/5] drm/omap: updates for DSS fifomerge API changes

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_crtc.c  |2 +-
 drivers/staging/omapdrm/omap_drv.h   |6 ++
 drivers/staging/omapdrm/omap_plane.c |   33 -
 3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 3cee04e..17ca163 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -81,7 +81,7 @@ static int omap_crtc_mode_set(struct drm_crtc *crtc,
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_plane *plane = omap_crtc->plane;

-   return plane->funcs->update_plane(plane, crtc, crtc->fb,
+   return omap_plane_mode_set(plane, crtc, crtc->fb,
0, 0, mode->hdisplay, mode->vdisplay,
x << 16, y << 16,
mode->hdisplay << 16, mode->vdisplay << 16);
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 48f6fce..61fe022 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -69,6 +69,12 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
struct omap_overlay *ovl, unsigned int possible_crtcs,
bool priv);
 int omap_plane_dpms(struct drm_plane *plane, int mode);
+int omap_plane_mode_set(struct drm_plane *plane,
+   struct drm_crtc *crtc, struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h);

 struct drm_encoder *omap_encoder_init(struct drm_device *dev,
struct omap_overlay_manager *mgr);
diff --git a/drivers/staging/omapdrm/omap_plane.c 
b/drivers/staging/omapdrm/omap_plane.c
index 66eed75..9790912 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -85,7 +85,7 @@ static int commit(struct drm_plane *plane)
}
}

-   if (info->enabled) {
+   if (ovl->is_enabled(ovl)) {
omap_framebuffer_flush(plane->fb, info->pos_x, info->pos_y,
info->out_width, info->out_height);
}
@@ -115,7 +115,7 @@ static void update_manager(struct drm_plane *plane)
}

if (ovl->manager != mgr) {
-   bool enabled = omap_plane->info.enabled;
+   bool enabled = ovl->is_enabled(ovl);

/* don't switch things around with enabled overlays: */
if (enabled)
@@ -168,7 +168,8 @@ static void update_scanout(struct drm_plane *plane)
if (ret) {
dev_err(plane->dev->dev,
"could not pin fb: %d\n", ret);
-   omap_plane->info.enabled = false;
+   omap_plane_dpms(plane, DRM_MODE_DPMS_OFF);
+   return;
}

omap_framebuffer_update_scanout(plane->fb,
@@ -180,7 +181,7 @@ static void update_scanout(struct drm_plane *plane)
info->screen_width);
 }

-static int omap_plane_update(struct drm_plane *plane,
+int omap_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
@@ -195,7 +196,6 @@ static int omap_plane_update(struct drm_plane *plane,
src_w = src_w >> 16;
src_h = src_h >> 16;

-   omap_plane->info.enabled = true;
omap_plane->info.pos_x = crtc_x;
omap_plane->info.pos_y = crtc_y;
omap_plane->info.out_width = crtc_w;
@@ -214,11 +214,22 @@ static int omap_plane_update(struct drm_plane *plane,

update_scanout(plane);
update_manager(plane);
-   commit(plane);

return 0;
 }

+static int omap_plane_update(struct drm_plane *plane,
+   struct drm_crtc *crtc, struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h)
+{
+   omap_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y, crtc_w, crtc_h,
+   src_x, src_y, src_w, src_h);
+   return omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
+}
+
 static int omap_plane_disable(struct drm_plane *plane)
 {
return omap_plane_dpms(plane, DRM_MODE_DPMS_OFF);
@@ -236,18 +247,22 @@ static void omap_plane_destroy(struct drm_plane *plane)
 int omap_plane_dpms(struct drm_plane *plane, int mode)
 {
struct omap_plane *omap_plane = to_omap_plane(plane);
+   struct omap_overlay *ovl = omap_plane->ovl;
+   int r;

DBG("%s: %d", omap_plane->ovl->name, mode);

if (mode == DRM_MODE_DPMS_ON) {
update_scanout(plane);
-   

[PATCH 4/5] drm/omap: multiplanar and YUV support

[Rob Clark]

From: Rob Clark 

Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12).  Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinned when they are not being scanned out.  Now, before start
of scanout the plane calls omap_framebuffer_pin() which takes care
to pin all the backing bo's, then omap_framebuffer_update_scanout()
however many times to update the scanout address(es), etc, and then
when finished omap_framebuffer_unpin().

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_crtc.c  |2 +-
 drivers/staging/omapdrm/omap_drv.h   |8 +-
 drivers/staging/omapdrm/omap_fb.c|  149 +++---
 drivers/staging/omapdrm/omap_gem.c   |5 +
 drivers/staging/omapdrm/omap_plane.c |   53 +
 5 files changed, 149 insertions(+), 68 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index a91c788..3cee04e 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -168,7 +168,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
omap_crtc->event = event;
crtc->fb = fb;

-   omap_gem_op_async(omap_framebuffer_bo(fb), OMAP_GEM_READ,
+   omap_gem_op_async(omap_framebuffer_bo(fb, 0), OMAP_GEM_READ,
page_flip_cb, crtc);

return 0;
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index e2b1b55..48f6fce 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -90,9 +90,11 @@ struct drm_framebuffer *omap_framebuffer_create(struct 
drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
-struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
-int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
-   void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
+struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
+int omap_framebuffer_pin(struct drm_framebuffer *fb);
+void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
+   struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_framebuffer *fb, struct drm_connector *from);
 void omap_framebuffer_flush(struct drm_framebuffer *fb,
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 805a18e..d021a7e 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,14 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
 };

+/* per-plane info for the fb: */
+struct plane {
+   struct drm_gem_object *bo;
+   uint32_t pitch;
+   uint32_t offset;
+   dma_addr_t paddr;
+};
+
 #define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)

 struct omap_framebuffer {
struct drm_framebuffer base;
-   struct drm_gem_object *bo;
-   int size;
-   dma_addr_t paddr;
const struct format *format;
+   struct plane planes[4];
 };

 static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
@@ -74,22 +80,23 @@ static int omap_framebuffer_create_handle(struct 
drm_framebuffer *fb,
unsigned int *handle)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-return drm_gem_handle_create(file_priv, omap_fb->bo, handle);
+   return drm_gem_handle_create(file_priv,
+   omap_fb->planes[0].bo, handle);
 }

 static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
 {
-   struct drm_device *dev = fb->dev;
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+   int i, n = drm_format_num_planes(omap_fb->format->pixel_format);

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

drm_framebuffer_cleanup(fb);

-   if (omap_fb->bo) {
-   if (omap_fb->paddr && omap_gem_put_paddr(omap_fb->bo))
-   dev_err(dev->dev, "could not unmap!\n");
-   drm_gem_object_unreference_unlocked(omap_fb->bo);
+   for (i = 0; i < n; i++) {
+   struct plane *plane = _fb->planes[i];
+   if (plane->bo)
+   drm_gem_object_unreference_unlocked(plane->bo);
}

kfree(omap_fb);
@@ -116,37 +123,76 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
 };

-/* returns the buffer size */

[PATCH 3/5] drm/omap: add drm_plane support

[Rob Clark]

From: Rob Clark 

Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane object
is used by the CRTC object.  This avoids code duplication between the
plane and CRTC.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  189 +
 drivers/staging/omapdrm/omap_drv.c   |   53 ---
 drivers/staging/omapdrm/omap_drv.h   |8 +-
 drivers/staging/omapdrm/omap_plane.c |  308 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 6 files changed, 403 insertions(+), 168 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 592cf69..d9cdc12 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -7,6 +7,7 @@ ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
omap_debugfs.o \
omap_crtc.o \
+   omap_plane.o \
omap_encoder.o \
omap_connector.o \
omap_fb.o \
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index cffdf5e..a91c788 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -27,196 +27,95 @@

 struct omap_crtc {
struct drm_crtc base;
-   struct omap_overlay *ovl;
-   struct omap_overlay_info info;
+   struct drm_plane *plane;
+   const char *name;
int id;

-   /* if there is a pending flip, this will be non-null: */
+   /* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
+   struct drm_framebuffer *old_fb;
 };

-/* push changes down to dss2 */
-static int commit(struct drm_crtc *crtc)
-{
-   struct drm_device *dev = crtc->dev;
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   struct omap_overlay *ovl = omap_crtc->ovl;
-   struct omap_overlay_info *info = _crtc->info;
-   int ret;
-
-   DBG("%s", omap_crtc->ovl->name);
-   DBG("%dx%d -> %dx%d (%d)", info->width, info->height, info->out_width,
-   info->out_height, info->screen_width);
-   DBG("%d,%d %08x", info->pos_x, info->pos_y, info->paddr);
-
-   /* NOTE: do we want to do this at all here, or just wait
-* for dpms(ON) since other CRTC's may not have their mode
-* set yet, so fb dimensions may still change..
-*/
-   ret = ovl->set_overlay_info(ovl, info);
-   if (ret) {
-   dev_err(dev->dev, "could not set overlay info\n");
-   return ret;
-   }
-
-   /* our encoder doesn't necessarily get a commit() after this, in
-* particular in the dpms() and mode_set_base() cases, so force the
-* manager to update:
-*
-* could this be in the encoder somehow?
-*/
-   if (ovl->manager) {
-   ret = ovl->manager->apply(ovl->manager);
-   if (ret) {
-   dev_err(dev->dev, "could not apply settings\n");
-   return ret;
-   }
-   }
-
-   if (info->enabled) {
-   omap_framebuffer_flush(crtc->fb, crtc->x, crtc->y,
-   crtc->fb->width, crtc->fb->height);
-   }
-
-   return 0;
-}
-
-/* update parameters that are dependent on the framebuffer dimensions and
- * position within the fb that this crtc scans out from. This is called
- * when framebuffer dimensions or x,y base may have changed, either due
- * to our mode, or a change in another crtc that is scanning out of the
- * same fb.
- */
-static void update_scanout(struct drm_crtc *crtc)
-{
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   dma_addr_t paddr;
-   unsigned int screen_width;
-
-   omap_framebuffer_get_buffer(crtc->fb, crtc->x, crtc->y,
-   NULL, , _width);
-
-   DBG("%s: %d,%d: %08x (%d)", omap_crtc->ovl->name,
-   crtc->x, crtc->y, (u32)paddr, screen_width);
-
-   omap_crtc->info.paddr = paddr;
-   omap_crtc->info.screen_width = screen_width;
-}
-
 static void omap_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green, u16 *blue, uint32_t start, uint32_t size)
 {
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG("%s", omap_crtc->ovl->name);
+   /* not supported.. at least not yet */
 }

 static void omap_crtc_destroy(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG("%s", omap_crtc->ovl->name);
+   omap_crtc->plane->funcs->destroy(omap_crtc->plane);
drm_crtc_cleanup(crtc);
kfree(omap_crtc);
 }

 static void 

[PATCH 2/5] drm/omap: drm API update: addfb2

[Rob Clark]

From: Rob Clark 

Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |   30 +-
 drivers/staging/omapdrm/omap_fb.c|  103 ++
 drivers/staging/omapdrm/omap_fbdev.c |   55 ---
 3 files changed, 143 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 76c4251..4ad2ae5 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "omap_drm.h"
 #include "omap_priv.h"

@@ -80,9 +81,9 @@ void omap_connector_flush(struct drm_connector *connector,
int x, int y, int w, int h);

 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
-   struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+   struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
-   struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+   struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
 int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -132,4 +133,29 @@ static inline int align_pitch(int pitch, int width, int 
bpp)
return ALIGN(pitch, 8 * bytespp);
 }

+/* should these be made into common util helpers?
+ */
+
+static inline int objects_lookup(struct drm_device *dev,
+   struct drm_file *filp, uint32_t pixel_format,
+   struct drm_gem_object **bos, uint32_t *handles)
+{
+   int i, n = drm_format_num_planes(pixel_format);
+
+   for (i = 0; i < n; i++) {
+   bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+   if (!bos[i]) {
+   goto fail;
+   }
+   }
+
+   return 0;
+
+fail:
+   while (--i > 0) {
+   drm_gem_object_unreference_unlocked(bos[i]);
+   }
+   return -ENOENT;
+}
+
 #endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..805a18e 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,43 @@
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"

-
 /*
  * framebuffer funcs
  */

+/* per-format info: */
+struct format {
+   enum omap_color_mode dss_format;
+   uint32_t pixel_format;
+   struct {
+   int stride_bpp;   /* this times width is stride */
+   int sub_y;/* sub-sample in y dimension */
+   } planes[4];
+   bool yuv;
+};
+
+static const struct format formats[] = {
+   /* 16bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGB16,   DRM_FORMAT_RGB565,   {{2, 1}}, false }, 
/* RGB16-565 */
+   { OMAP_DSS_COLOR_RGB12U,  DRM_FORMAT_RGBX, {{2, 1}}, false }, 
/* RGB12x- */
+   { OMAP_DSS_COLOR_RGBX16,  DRM_FORMAT_XRGB, {{2, 1}}, false }, 
/* xRGB12- */
+   { OMAP_DSS_COLOR_RGBA16,  DRM_FORMAT_RGBA, {{2, 1}}, false }, 
/* RGBA12- */
+   { OMAP_DSS_COLOR_ARGB16,  DRM_FORMAT_ARGB, {{2, 1}}, false }, 
/* ARGB16- */
+   { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, {{2, 1}}, false }, 
/* xRGB15-1555 */
+   { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, {{2, 1}}, false }, 
/* ARGB16-1555 */
+   /* 24bpp RGB: */
+   { OMAP_DSS_COLOR_RGB24P,  DRM_FORMAT_RGB888,   {{3, 1}}, false }, 
/* RGB24-888 */
+   /* 32bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGBX32,  DRM_FORMAT_RGBX, {{4, 1}}, false }, 
/* RGBx24- */
+   { OMAP_DSS_COLOR_RGB24U,  DRM_FORMAT_XRGB, {{4, 1}}, false }, 
/* xRGB24- */
+   { OMAP_DSS_COLOR_RGBA32,  DRM_FORMAT_RGBA, {{4, 1}}, false }, 
/* RGBA32- */
+   { OMAP_DSS_COLOR_ARGB32,  DRM_FORMAT_ARGB, {{4, 1}}, false }, 
/* ARGB32- */
+   /* YUV: */
+   { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, {{1, 1}, {1, 2}}, 
true },
+   { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, {{2, 1}}, true },
+   { OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
+};
+
 #define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)

 struct omap_framebuffer {
@@ -34,6 +66,7 @@ struct omap_framebuffer {
struct drm_gem_object *bo;
int size;
dma_addr_t paddr;
+   const struct format *format;
 };

 static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
@@ -91,7 +124,7 @@ int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, 
int x, int y,
int bpp = fb->bits_per_pixel / 8;

[PATCH 1/5] drm/omap: drm API update: make fops struct const

[Rob Clark]

From: Rob Clark 

Update to reflect changes in:
"Make the per-driver file_operations struct const"

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.c |   24 +---
 1 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 602aa2d..4db40f7 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -708,6 +708,18 @@ static struct vm_operations_struct omap_gem_vm_ops = {
.close = drm_gem_vm_close,
 };

+static const struct file_operations omapdriver_fops = {
+   .owner = THIS_MODULE,
+   .open = drm_open,
+   .unlocked_ioctl = drm_ioctl,
+   .release = drm_release,
+   .mmap = omap_gem_mmap,
+   .poll = drm_poll,
+   .fasync = drm_fasync,
+   .read = drm_read,
+   .llseek = noop_llseek,
+};
+
 static struct drm_driver omap_drm_driver = {
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
@@ -738,17 +750,7 @@ static struct drm_driver omap_drm_driver = {
.dumb_destroy = omap_gem_dumb_destroy,
.ioctls = ioctls,
.num_ioctls = DRM_OMAP_NUM_IOCTLS,
-   .fops = {
-   .owner = THIS_MODULE,
-   .open = drm_open,
-   .unlocked_ioctl = drm_ioctl,
-   .release = drm_release,
-   .mmap = omap_gem_mmap,
-   .poll = drm_poll,
-   .fasync = drm_fasync,
-   .read = drm_read,
-   .llseek = noop_llseek,
-   },
+   .fops = _fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
-- 
1.7.5.4

[PATCH 0/5] drm/omap: updates for latest master

[Rob Clark]

From: Rob Clark 

Now that drm and fbdev (omapdss) next trees have been pulled by Linus,
here are the updates to keep omapdrm compiling.

The first four are re-sends of what was sent earlier, and the fifth
takes care of some API changes in omapdss contained in the fbdev pull.

Rob Clark (5):
  drm/omap: drm API update: make fops struct const
  drm/omap: drm API update: addfb2
  drm/omap: add drm_plane support
  drm/omap: multiplanar and YUV support
  drm/omap: updates for DSS fifomerge API changes

 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  191 +--
 drivers/staging/omapdrm/omap_drv.c   |   77 +---
 drivers/staging/omapdrm/omap_drv.h   |   52 +-
 drivers/staging/omapdrm/omap_fb.c|  224 --
 drivers/staging/omapdrm/omap_fbdev.c |   55 --
 drivers/staging/omapdrm/omap_gem.c   |5 +
 drivers/staging/omapdrm/omap_plane.c |  344 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 9 files changed, 699 insertions(+), 262 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

-- 
1.7.5.4

[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

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

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

--- Comment #7 from Michel D?nzer  2012-01-16 03:23:43 
PST ---
The panic backtrace doesn't look obviously related to the radeon driver ? all
the symptoms sound like something might be scribbling more or less randomly
over memory.

I wonder if the line

 mtrr: type mismatch for e000,1000 old: write-back new: write-combining

in dmesg might be relevant. Can you try resolving that, e.g. using
https://linuxindetails.wordpress.com/2010/06/27/mtrr-type-mismatch-for-e0001000-old-write-back-new-write-combining/
and see if that helps? Might be interesting seeing the contents of /proc/mtrr
before and afterwards (if it changes).

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

[PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
  wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
> wrote:
>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>> index 9a58461..b86e6cb 100644
>> --- a/arch/arm/plat-omap/Makefile
>> +++ b/arch/arm/plat-omap/Makefile
>> @@ -4,7 +4,7 @@
>>
>> ?# Common support
>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>> - ? ? ? ?usb.o fb.o counter_32k.o
>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>
> Should be something like this:
> obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
 plat-omap module?
>>>
>>> Yes, and platform drivers are supposed to be loaded automatically at
>>> boot-time by udev (or similar).
>>
>> oh, but this won't work, because common.c has to call
>> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
>> works).. so I think it has to stay the way it is in this patch.
>
> #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
> extern void omapdrm_reserve_vram(void);
> #else
> static inline void omapdrm_reserve_vram(void) { }
> #endif
>
> Like how it's done with DSP stuff.

right, but then you'd miss the omapdrm_reserve_vram() call at startup..

BR,
-R

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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

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

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

--- Comment #16 from Michel D?nzer  2012-01-16 02:43:18 
PST ---
(In reply to comment #15)
> X Error of failed request:  BadName (named color or font does not exist)
>   Major opcode of failed request:  150 (RANDR)
>   Minor opcode of failed request:  16 (RRCreateMode)

This means a mode of that name exists already.

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

[PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

 ?# Common support
 ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 - ? ? ? ?usb.o fb.o counter_32k.o
 + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>>
>>> Should be something like this:
>>> obj-$(CONFIG_DRM_OMAP) += drm.o
>>
>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>> plat-omap module?
>
> Yes, and platform drivers are supposed to be loaded automatically at
> boot-time by udev (or similar).

oh, but this won't work, because common.c has to call
omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
works).. so I think it has to stay the way it is in this patch.

I guess this is the reason that omapfb (fb.c is the example I copied)
device is setup in the same way.

BR,
-R

> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

--- Comment #16 from Michel Dänzer mic...@daenzer.net 2012-01-16 02:43:18 PST 
---
(In reply to comment #15)
 X Error of failed request:  BadName (named color or font does not exist)
   Major opcode of failed request:  150 (RANDR)
   Minor opcode of failed request:  16 (RRCreateMode)

This means a mode of that name exists already.

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

[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer mic...@daenzer.net 2012-01-16 03:23:43 PST 
---
The panic backtrace doesn't look obviously related to the radeon driver — all
the symptoms sound like something might be scribbling more or less randomly
over memory.

I wonder if the line

 mtrr: type mismatch for e000,1000 old: write-back new: write-combining

in dmesg might be relevant. Can you try resolving that, e.g. using
https://linuxindetails.wordpress.com/2010/06/27/mtrr-type-mismatch-for-e0001000-old-write-back-new-write-combining/
and see if that helps? Might be interesting seeing the contents of /proc/mtrr
before and afterwards (if it changes).

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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

--- Comment #17 from Valter valter.giovanne...@alice.it 2012-01-16 05:39:36 
PST ---
Ok.
I made ​​the suggestion of Alex in this way:

1) I gave the following terminal commands:
xrandr - newmode 1920x1080R 138.50 1920 1968 2000 2080 1080 1083 1088  +
hsync-vsync
xrandr - DVI-0 addmode 1920x1080R
xrandr - output DVI-0 - mode 1920x1080R

The monitor works fine as well!

2) Then I wrote these commands:

sudo nano / etc / gdm / Init / Default

After the lines:

PATH = / usr / bin: $ PATH
IFS = $ OLD_IFS

and then I saved.

3) After restarting the monitor does not work anymore, but if I run the
commands from the terminal

xrandr - DVI-0 addmode 1920x1080R
xrandr - output DVI-0 - mode 1920x1080R

Then everything works!

What's wrong?

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

[Bug 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)

[bugzilla-daemon]

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

--- Comment #7 from Tom Simnett tom+freedesk...@simnett.com 2012-01-16 
05:40:18 PST ---
Created attachment 55636
  -- https://bugs.freedesktop.org/attachment.cgi?id=55636
artefacts under -nouveau

This appears to happen in -nouveau too. Screenshot attached. What additional
information do you need? I'm running xorg-edgers PPA versions of everything on
Ubuntu.

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

Re: [PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

Yes, and platform drivers are supposed to be loaded automatically at
boot-time by udev (or similar).

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

Re: [PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

oh, but this won't work, because common.c has to call
omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
works).. so I think it has to stay the way it is in this patch.

I guess this is the reason that omapfb (fb.c is the example I copied)
device is setup in the same way.

BR,
-R

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

Re: [PATCH 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
extern void omapdrm_reserve_vram(void);
#else
static inline void omapdrm_reserve_vram(void) { }
#endif

Like how it's done with DSP stuff.

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

Re: [PATCH 1/2] omap2+: add drm device

[Rob Clark]

On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

right, but then you'd miss the omapdrm_reserve_vram() call at startup..

BR,
-R

 --
 Felipe Contreras
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

--- Comment #18 from Valter valter.giovanne...@alice.it 2012-01-16 09:22:40 
PST ---
Hello to everybody, again.

I stand corrected.

After further tests, after rebooting, it is sufficient only to give the
command:

xrandr - output DVI-0 - mode 1920x1080R

so that the monitor is fine.

Why doesn't it execute the last command?

Does it exist another way to make the setting permanent?

And how?

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

[PATCH 0/5] drm/omap: updates for latest master

[Rob Clark]

From: Rob Clark r...@ti.com

Now that drm and fbdev (omapdss) next trees have been pulled by Linus,
here are the updates to keep omapdrm compiling.

The first four are re-sends of what was sent earlier, and the fifth
takes care of some API changes in omapdss contained in the fbdev pull.

Rob Clark (5):
  drm/omap: drm API update: make fops struct const
  drm/omap: drm API update: addfb2
  drm/omap: add drm_plane support
  drm/omap: multiplanar and YUV support
  drm/omap: updates for DSS fifomerge API changes

 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  191 +--
 drivers/staging/omapdrm/omap_drv.c   |   77 +---
 drivers/staging/omapdrm/omap_drv.h   |   52 +-
 drivers/staging/omapdrm/omap_fb.c|  224 --
 drivers/staging/omapdrm/omap_fbdev.c |   55 --
 drivers/staging/omapdrm/omap_gem.c   |5 +
 drivers/staging/omapdrm/omap_plane.c |  344 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 9 files changed, 699 insertions(+), 262 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

-- 
1.7.5.4

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

[PATCH 1/5] drm/omap: drm API update: make fops struct const

[Rob Clark]

From: Rob Clark r...@ti.com

Update to reflect changes in:
Make the per-driver file_operations struct const

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/omap_drv.c |   24 +---
 1 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.c 
b/drivers/staging/omapdrm/omap_drv.c
index 602aa2d..4db40f7 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -708,6 +708,18 @@ static struct vm_operations_struct omap_gem_vm_ops = {
.close = drm_gem_vm_close,
 };
 
+static const struct file_operations omapdriver_fops = {
+   .owner = THIS_MODULE,
+   .open = drm_open,
+   .unlocked_ioctl = drm_ioctl,
+   .release = drm_release,
+   .mmap = omap_gem_mmap,
+   .poll = drm_poll,
+   .fasync = drm_fasync,
+   .read = drm_read,
+   .llseek = noop_llseek,
+};
+
 static struct drm_driver omap_drm_driver = {
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
@@ -738,17 +750,7 @@ static struct drm_driver omap_drm_driver = {
.dumb_destroy = omap_gem_dumb_destroy,
.ioctls = ioctls,
.num_ioctls = DRM_OMAP_NUM_IOCTLS,
-   .fops = {
-   .owner = THIS_MODULE,
-   .open = drm_open,
-   .unlocked_ioctl = drm_ioctl,
-   .release = drm_release,
-   .mmap = omap_gem_mmap,
-   .poll = drm_poll,
-   .fasync = drm_fasync,
-   .read = drm_read,
-   .llseek = noop_llseek,
-   },
+   .fops = omapdriver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
-- 
1.7.5.4

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

[PATCH 2/5] drm/omap: drm API update: addfb2

[Rob Clark]

From: Rob Clark r...@ti.com

Update to reflect changes in:
drm: add an fb creation ioctl that takes a pixel format v5

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/omap_drv.h   |   30 +-
 drivers/staging/omapdrm/omap_fb.c|  103 ++
 drivers/staging/omapdrm/omap_fbdev.c |   55 ---
 3 files changed, 143 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 76c4251..4ad2ae5 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -24,6 +24,7 @@
 #include linux/module.h
 #include linux/types.h
 #include drm/drmP.h
+#include drm/drm_crtc_helper.h
 #include omap_drm.h
 #include omap_priv.h
 
@@ -80,9 +81,9 @@ void omap_connector_flush(struct drm_connector *connector,
int x, int y, int w, int h);
 
 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
-   struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+   struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
-   struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+   struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
 int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -132,4 +133,29 @@ static inline int align_pitch(int pitch, int width, int 
bpp)
return ALIGN(pitch, 8 * bytespp);
 }
 
+/* should these be made into common util helpers?
+ */
+
+static inline int objects_lookup(struct drm_device *dev,
+   struct drm_file *filp, uint32_t pixel_format,
+   struct drm_gem_object **bos, uint32_t *handles)
+{
+   int i, n = drm_format_num_planes(pixel_format);
+
+   for (i = 0; i  n; i++) {
+   bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+   if (!bos[i]) {
+   goto fail;
+   }
+   }
+
+   return 0;
+
+fail:
+   while (--i  0) {
+   drm_gem_object_unreference_unlocked(bos[i]);
+   }
+   return -ENOENT;
+}
+
 #endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..805a18e 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,43 @@
 #include drm_crtc.h
 #include drm_crtc_helper.h
 
-
 /*
  * framebuffer funcs
  */
 
+/* per-format info: */
+struct format {
+   enum omap_color_mode dss_format;
+   uint32_t pixel_format;
+   struct {
+   int stride_bpp;   /* this times width is stride */
+   int sub_y;/* sub-sample in y dimension */
+   } planes[4];
+   bool yuv;
+};
+
+static const struct format formats[] = {
+   /* 16bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGB16,   DRM_FORMAT_RGB565,   {{2, 1}}, false }, 
/* RGB16-565 */
+   { OMAP_DSS_COLOR_RGB12U,  DRM_FORMAT_RGBX, {{2, 1}}, false }, 
/* RGB12x- */
+   { OMAP_DSS_COLOR_RGBX16,  DRM_FORMAT_XRGB, {{2, 1}}, false }, 
/* xRGB12- */
+   { OMAP_DSS_COLOR_RGBA16,  DRM_FORMAT_RGBA, {{2, 1}}, false }, 
/* RGBA12- */
+   { OMAP_DSS_COLOR_ARGB16,  DRM_FORMAT_ARGB, {{2, 1}}, false }, 
/* ARGB16- */
+   { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, {{2, 1}}, false }, 
/* xRGB15-1555 */
+   { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, {{2, 1}}, false }, 
/* ARGB16-1555 */
+   /* 24bpp RGB: */
+   { OMAP_DSS_COLOR_RGB24P,  DRM_FORMAT_RGB888,   {{3, 1}}, false }, 
/* RGB24-888 */
+   /* 32bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGBX32,  DRM_FORMAT_RGBX, {{4, 1}}, false }, 
/* RGBx24- */
+   { OMAP_DSS_COLOR_RGB24U,  DRM_FORMAT_XRGB, {{4, 1}}, false }, 
/* xRGB24- */
+   { OMAP_DSS_COLOR_RGBA32,  DRM_FORMAT_RGBA, {{4, 1}}, false }, 
/* RGBA32- */
+   { OMAP_DSS_COLOR_ARGB32,  DRM_FORMAT_ARGB, {{4, 1}}, false }, 
/* ARGB32- */
+   /* YUV: */
+   { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, {{1, 1}, {1, 2}}, 
true },
+   { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, {{2, 1}}, true },
+   { OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
+};
+
 #define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)
 
 struct omap_framebuffer {
@@ -34,6 +66,7 @@ struct omap_framebuffer {
struct drm_gem_object *bo;
int size;
dma_addr_t paddr;
+   const struct format *format;
 };
 
 static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
@@ -91,7 +124,7 @@ int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, 
int x, 

[PATCH 3/5] drm/omap: add drm_plane support

[Rob Clark]

From: Rob Clark r...@ti.com

Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane object
is used by the CRTC object.  This avoids code duplication between the
plane and CRTC.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  189 +
 drivers/staging/omapdrm/omap_drv.c   |   53 ---
 drivers/staging/omapdrm/omap_drv.h   |8 +-
 drivers/staging/omapdrm/omap_plane.c |  308 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 6 files changed, 403 insertions(+), 168 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 592cf69..d9cdc12 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -7,6 +7,7 @@ ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
omap_debugfs.o \
omap_crtc.o \
+   omap_plane.o \
omap_encoder.o \
omap_connector.o \
omap_fb.o \
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index cffdf5e..a91c788 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -27,196 +27,95 @@
 
 struct omap_crtc {
struct drm_crtc base;
-   struct omap_overlay *ovl;
-   struct omap_overlay_info info;
+   struct drm_plane *plane;
+   const char *name;
int id;
 
-   /* if there is a pending flip, this will be non-null: */
+   /* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
+   struct drm_framebuffer *old_fb;
 };
 
-/* push changes down to dss2 */
-static int commit(struct drm_crtc *crtc)
-{
-   struct drm_device *dev = crtc-dev;
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   struct omap_overlay *ovl = omap_crtc-ovl;
-   struct omap_overlay_info *info = omap_crtc-info;
-   int ret;
-
-   DBG(%s, omap_crtc-ovl-name);
-   DBG(%dx%d - %dx%d (%d), info-width, info-height, info-out_width,
-   info-out_height, info-screen_width);
-   DBG(%d,%d %08x, info-pos_x, info-pos_y, info-paddr);
-
-   /* NOTE: do we want to do this at all here, or just wait
-* for dpms(ON) since other CRTC's may not have their mode
-* set yet, so fb dimensions may still change..
-*/
-   ret = ovl-set_overlay_info(ovl, info);
-   if (ret) {
-   dev_err(dev-dev, could not set overlay info\n);
-   return ret;
-   }
-
-   /* our encoder doesn't necessarily get a commit() after this, in
-* particular in the dpms() and mode_set_base() cases, so force the
-* manager to update:
-*
-* could this be in the encoder somehow?
-*/
-   if (ovl-manager) {
-   ret = ovl-manager-apply(ovl-manager);
-   if (ret) {
-   dev_err(dev-dev, could not apply settings\n);
-   return ret;
-   }
-   }
-
-   if (info-enabled) {
-   omap_framebuffer_flush(crtc-fb, crtc-x, crtc-y,
-   crtc-fb-width, crtc-fb-height);
-   }
-
-   return 0;
-}
-
-/* update parameters that are dependent on the framebuffer dimensions and
- * position within the fb that this crtc scans out from. This is called
- * when framebuffer dimensions or x,y base may have changed, either due
- * to our mode, or a change in another crtc that is scanning out of the
- * same fb.
- */
-static void update_scanout(struct drm_crtc *crtc)
-{
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   dma_addr_t paddr;
-   unsigned int screen_width;
-
-   omap_framebuffer_get_buffer(crtc-fb, crtc-x, crtc-y,
-   NULL, paddr, screen_width);
-
-   DBG(%s: %d,%d: %08x (%d), omap_crtc-ovl-name,
-   crtc-x, crtc-y, (u32)paddr, screen_width);
-
-   omap_crtc-info.paddr = paddr;
-   omap_crtc-info.screen_width = screen_width;
-}
-
 static void omap_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green, u16 *blue, uint32_t start, uint32_t size)
 {
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG(%s, omap_crtc-ovl-name);
+   /* not supported.. at least not yet */
 }
 
 static void omap_crtc_destroy(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG(%s, omap_crtc-ovl-name);
+   omap_crtc-plane-funcs-destroy(omap_crtc-plane);
drm_crtc_cleanup(crtc);
kfree(omap_crtc);
 }
 
 static void omap_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
+  

[PATCH 5/5] drm/omap: updates for DSS fifomerge API changes

[Rob Clark]

From: Rob Clark r...@ti.com

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/omap_crtc.c  |2 +-
 drivers/staging/omapdrm/omap_drv.h   |6 ++
 drivers/staging/omapdrm/omap_plane.c |   33 -
 3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 3cee04e..17ca163 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -81,7 +81,7 @@ static int omap_crtc_mode_set(struct drm_crtc *crtc,
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_plane *plane = omap_crtc-plane;
 
-   return plane-funcs-update_plane(plane, crtc, crtc-fb,
+   return omap_plane_mode_set(plane, crtc, crtc-fb,
0, 0, mode-hdisplay, mode-vdisplay,
x  16, y  16,
mode-hdisplay  16, mode-vdisplay  16);
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 48f6fce..61fe022 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -69,6 +69,12 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
struct omap_overlay *ovl, unsigned int possible_crtcs,
bool priv);
 int omap_plane_dpms(struct drm_plane *plane, int mode);
+int omap_plane_mode_set(struct drm_plane *plane,
+   struct drm_crtc *crtc, struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h);
 
 struct drm_encoder *omap_encoder_init(struct drm_device *dev,
struct omap_overlay_manager *mgr);
diff --git a/drivers/staging/omapdrm/omap_plane.c 
b/drivers/staging/omapdrm/omap_plane.c
index 66eed75..9790912 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -85,7 +85,7 @@ static int commit(struct drm_plane *plane)
}
}
 
-   if (info-enabled) {
+   if (ovl-is_enabled(ovl)) {
omap_framebuffer_flush(plane-fb, info-pos_x, info-pos_y,
info-out_width, info-out_height);
}
@@ -115,7 +115,7 @@ static void update_manager(struct drm_plane *plane)
}
 
if (ovl-manager != mgr) {
-   bool enabled = omap_plane-info.enabled;
+   bool enabled = ovl-is_enabled(ovl);
 
/* don't switch things around with enabled overlays: */
if (enabled)
@@ -168,7 +168,8 @@ static void update_scanout(struct drm_plane *plane)
if (ret) {
dev_err(plane-dev-dev,
could not pin fb: %d\n, ret);
-   omap_plane-info.enabled = false;
+   omap_plane_dpms(plane, DRM_MODE_DPMS_OFF);
+   return;
}
 
omap_framebuffer_update_scanout(plane-fb,
@@ -180,7 +181,7 @@ static void update_scanout(struct drm_plane *plane)
info-screen_width);
 }
 
-static int omap_plane_update(struct drm_plane *plane,
+int omap_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
@@ -195,7 +196,6 @@ static int omap_plane_update(struct drm_plane *plane,
src_w = src_w  16;
src_h = src_h  16;
 
-   omap_plane-info.enabled = true;
omap_plane-info.pos_x = crtc_x;
omap_plane-info.pos_y = crtc_y;
omap_plane-info.out_width = crtc_w;
@@ -214,11 +214,22 @@ static int omap_plane_update(struct drm_plane *plane,
 
update_scanout(plane);
update_manager(plane);
-   commit(plane);
 
return 0;
 }
 
+static int omap_plane_update(struct drm_plane *plane,
+   struct drm_crtc *crtc, struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h)
+{
+   omap_plane_mode_set(plane, crtc, fb, crtc_x, crtc_y, crtc_w, crtc_h,
+   src_x, src_y, src_w, src_h);
+   return omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
+}
+
 static int omap_plane_disable(struct drm_plane *plane)
 {
return omap_plane_dpms(plane, DRM_MODE_DPMS_OFF);
@@ -236,18 +247,22 @@ static void omap_plane_destroy(struct drm_plane *plane)
 int omap_plane_dpms(struct drm_plane *plane, int mode)
 {
struct omap_plane *omap_plane = to_omap_plane(plane);
+   struct omap_overlay *ovl = omap_plane-ovl;
+   int r;
 
DBG(%s: %d, omap_plane-ovl-name, mode);
 
if (mode == DRM_MODE_DPMS_ON) {
update_scanout(plane);
-   omap_plane-info.enabled = true;
+

[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

[bugzilla-daemon]

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

--- Comment #8 from Marko Kohtala marko.koht...@gmail.com 2012-01-16 11:26:00 
PST ---
Created attachment 55650
  -- https://bugs.freedesktop.org/attachment.cgi?id=55650
dmesg with enable_mtrr_cleanup

Attached the dmesg with The /proc/mtrr is 

reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable

and with enable_mtrr_cleanup mtrr_spare_reg_nr=1 options

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c000 ( 3072MB), size=  512MB, count=1: write-back
reg03: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x0e000 ( 3584MB), size=  256MB, count=1: write-combining

It makes no difference.

I installed 32-bit debian 3.1.0 kernel and compiled fglrx for it and am now
reporting this with it. It does not have the artefacts, but is not quite
perfect either (gnome-shell 3.2.1 animations flicker like scaling of windows
does not work as expected, but no artifacts, possibly of no interest to you).

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

[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes

[bugzilla-daemon]

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

--- Comment #9 from Marko Kohtala marko.koht...@gmail.com 2012-01-16 11:43:20 
PST ---
Created attachment 55651
  -- https://bugs.freedesktop.org/attachment.cgi?id=55651
Artefacts in X, screencapture

This capture was with the enable_mtrr_cleanup mtrr_spare_reg_nr=1 to kernel.
Here I started the X server from command line and only an xterm and a window
manager. 

The artefacts appear to the window while I scroll the window pressing enter.

There was some constantly running horizontal artefacts, but they were
flickering and got erased immediately thus leaving no mark. Seems like it could
be ramdac reading bad for some scanlines, but more likely it goes on in the
framebuffer. The blue part lower in the window could be one of those caught. I
wonder if the squares in the xterm window are a result of that flickering, but
due to scrolling it does not get erased.

The blue and green spots came one by one slowly while doing something else in
the xterm. They stayed.

This happens only with this CAICOS card (I have an older radeon X300 that has
no problems, as well as a nVidia card goes without these problems). So I'd
expect whatever memory corruption there is, it is somehow in the CAICOS support
in kernel.

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

Re: New drm-intel-next tree

[Eugeni Dodonov]

On Mon, Jan 16, 2012 at 17:41, Daniel Vetter dan...@ffwll.ch wrote:

 Hi all,

 Because Keith is routinely really busy with all kinds of things, notably
 gathering fixes for drm-intel-fixes, the patch merge process for the next
 release cycle sometimes falls behind. To support him and improve things I've
 been volunteered to take over handling the -next tree.

 The main aim is to shift the drm/i915 -next merge process massively ahead with
 the goals to:
 - Reduce pressure to merge questionable patches into -rc kernels because the
  -next tree is not yet open for patches.
 - Allow our QA at Intel and also the community to actually test things before
  they land in mainline. The lack of such testing has severly bitten us in the
  past few releases.
 - Refocus -fixes on handling regressions with absolute top priority (as it
  should).
 - And generally get a steady and predictable patch-flow towards mainline back
  into gears.

Following up on Daniel's mail, I discussed with him, and from now on I
intend to include the -next patches into the -drm-intel-backports [1]
as well, to simplify testing for ones of you running stable kernels
who want to test the latest breakages^w features :).

[1] http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/7961

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

Re: [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Paulo Zanoni]

Hi

2012/1/5 Jakob Bornecrantz ja...@vmware.com:
 Couldn't this be done by just adding a property instead of a ioctl?


So I've discussed this with Jesse and it seems the best way to turn
this into a property is to add support for CRTC properties, then add a
rotation property for the i915 driver. This will actually introduce
2 new ioctls: one to list the properties and one to change them.

I'll send three Kernel patches to this list in the next minutes. One
just moves code around (so we can reuse it), another adds CRTC
properties in drm/ and the other adds the rotation property for i915.

I also wrote patches for libdrm (implement the ioctls, change
tests/modetest to call these ioctls, and some janitor work on modetest
and libdrm) and xf86-video-intel (use the rotation property). The drm
patches are applied to this tree:
http://cgit.freedesktop.org/~pzanoni/drm/ . I was only planning to
send them to the list after I get some review on the kernel patches.
The full list of patches I wrote so far is here:
http://people.freedesktop.org/~pzanoni/rotation/ .

For those asking more information about the problem: these bits are
somehow needed by the embedded VNC: it needs to know how the screen is
rotated. More information:
http://en.wikipedia.org/wiki/Intel_Active_Management_Technology#VNC-based_KVM_remote_control

Cheers,
Paulo

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

[PATCH 1/3] drm: add drm_property_change_is_valid

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/drm_crtc.c |   41 +
 1 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e818a8..cd155e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2917,6 +2917,26 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+static int drm_property_change_is_valid(struct drm_property *property,
+   __u64 value)
+{
+   if (property-flags  DRM_MODE_PROP_IMMUTABLE)
+   return 0;
+   if (property-flags  DRM_MODE_PROP_RANGE) {
+   if (value  property-values[0])
+   return 0;
+   if (value  property-values[1])
+   return 0;
+   return 1;
+   } else {
+   int i;
+   for (i = 0; i  property-num_values; i++)
+   if (property-values[i] == value)
+   return 1;
+   return 0;
+   }
+}
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -2953,28 +2973,9 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
}
property = obj_to_property(obj);
 
-   if (property-flags  DRM_MODE_PROP_IMMUTABLE)
+   if (!drm_property_change_is_valid(property, out_resp-value))
goto out;
 
-   if (property-flags  DRM_MODE_PROP_RANGE) {
-   if (out_resp-value  property-values[0])
-   goto out;
-
-   if (out_resp-value  property-values[1])
-   goto out;
-   } else {
-   int found = 0;
-   for (i = 0; i  property-num_values; i++) {
-   if (property-values[i] == out_resp-value) {
-   found = 1;
-   break;
-   }
-   }
-   if (!found) {
-   goto out;
-   }
-   }
-
/* Do DPMS ourselves */
if (property == connector-dev-mode_config.dpms_property) {
if (connector-funcs-dpms)
-- 
1.7.8.3

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

[PATCH 2/3] drm: add CRTC properties

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

Code based on the connector properties code.

Two new ioctls:
- DRM_IOCTL_MODE_CRTC_GETPROPERTIES
- DRM_IOCTL_MODE_CRTC_SETPROPERTY

The i915 driver needs this (for the rotation property). Other drivers
might need this too.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/drm_crtc.c |  116 
 drivers/gpu/drm/drm_drv.c  |4 +-
 include/drm/drm.h  |2 +
 include/drm/drm_crtc.h |   22 -
 include/drm/drm_mode.h |   13 +
 5 files changed, 155 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cd155e9..5112921 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2685,6 +2685,22 @@ int drm_connector_attach_property(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL(drm_connector_attach_property);
 
+void drm_crtc_attach_property(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t init_val)
+{
+   int i;
+
+   for (i = 0; i  DRM_CRTC_MAX_PROPERTY; i++) {
+   if (crtc-property_ids[i] == 0) {
+   crtc-property_ids[i] = property-base.id;
+   crtc-property_values[i] = init_val;
+   return;
+   }
+   }
+   BUG_ON(1);
+}
+EXPORT_SYMBOL(drm_crtc_attach_property);
+
 int drm_connector_property_set_value(struct drm_connector *connector,
  struct drm_property *property, uint64_t value)
 {
@@ -2992,6 +3008,106 @@ out:
return ret;
 }
 
+int drm_mode_crtc_get_properties_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_priv)
+{
+   struct drm_mode_crtc_get_properties *arg = data;
+   struct drm_mode_object *obj;
+   struct drm_crtc *crtc;
+   int ret = 0;
+   int i;
+   int copied = 0;
+   int props_count = 0;
+   uint32_t __user *props_ptr;
+   uint64_t __user *prop_values_ptr;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(dev-mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg-crtc_id, DRM_MODE_OBJECT_CRTC);
+   if (!obj) {
+   ret = -EINVAL;
+   goto out;
+   }
+   crtc = obj_to_crtc(obj);
+
+   for (i = 0; i  DRM_CRTC_MAX_PROPERTY; i++)
+   if (crtc-property_ids[i] != 0)
+   props_count++;
+
+   /* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it. */
+   if ((arg-count_props = props_count)  props_count) {
+   copied = 0;
+   props_ptr = (uint32_t __user *)(unsigned long)(arg-props_ptr);
+   prop_values_ptr = (uint64_t __user *)(unsigned long)
+ (arg-prop_values_ptr);
+   for (i = 0; i  props_count; i++) {
+   if (put_user(crtc-property_ids[i],
+props_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   if (put_user(crtc-property_values[i],
+prop_values_ptr + copied)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   }
+   }
+   arg-count_props = props_count;
+out:
+   mutex_unlock(dev-mode_config.mutex);
+   return ret;
+}
+
+int drm_mode_crtc_set_property_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+   struct drm_mode_crtc_set_property *arg = data;
+   struct drm_mode_object *obj;
+   struct drm_property *property;
+   struct drm_crtc *crtc;
+   int ret = -EINVAL;
+   int i;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(dev-mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg-crtc_id, DRM_MODE_OBJECT_CRTC);
+   if (!obj)
+   goto out;
+   crtc = obj_to_crtc(obj);
+
+   for (i = 0; i  DRM_CRTC_MAX_PROPERTY; i++)
+   if (crtc-property_ids[i] == arg-prop_id)
+   break;
+
+   if (i == DRM_CRTC_MAX_PROPERTY)
+   goto out;
+
+   obj = drm_mode_object_find(dev, arg-prop_id, DRM_MODE_OBJECT_PROPERTY);
+   if (!obj)
+   goto out;
+   property = obj_to_property(obj);
+
+   if (!drm_property_change_is_valid(property, arg-value))
+   goto out;
+
+   if (crtc-funcs-set_property)
+   ret = crtc-funcs-set_property(crtc, property, arg-value);
+   if (!ret) {
+   crtc-property_values[i] = arg-value;
+   }
+out:
+   mutex_unlock(dev-mode_config.mutex);

[PATCH 3/3] drm/i915: add 'rotation' CRTC property

[Paulo Zanoni]

From: Paulo Zanoni paulo.r.zan...@intel.com

This property is needed by to inform the KVMr feature about our
current rotation: whenever we change the rotation, we should change
that property so that the KVMr knows that the screen is rotated.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |5 +++
 drivers/gpu/drm/i915/intel_display.c |   57 ++
 drivers/gpu/drm/i915/intel_drv.h |2 +
 3 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c3afb78..49e4f10 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2324,6 +2324,11 @@
 #define   PIPECONF_INTERLACE_FIELD_0_ONLY  (7  21)
 #define   PIPECONF_INTERLACE_MASK  (7  21)
 #define   PIPECONF_CXSR_DOWNCLOCK  (116)
+#define   PIPECONF_ROTATION_MASK   (3  14)
+#define   PIPECONF_ROTATION_0  (0  14)
+#define   PIPECONF_ROTATION_90 (1  14)
+#define   PIPECONF_ROTATION_180(2  14)
+#define   PIPECONF_ROTATION_270(3  14)
 #define   PIPECONF_BPP_MASK(0x00e0)
 #define   PIPECONF_BPP_8   (05)
 #define   PIPECONF_BPP_10  (15)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 29743de..7ec1b18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7072,6 +7072,8 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
kfree(work);
}
 
+   drm_property_destroy(dev, intel_crtc-rotation_property);
+
drm_crtc_cleanup(crtc);
 
kfree(intel_crtc);
@@ -7529,6 +7531,49 @@ static void intel_crtc_reset(struct drm_crtc *crtc)
intel_sanitize_modesetting(dev, intel_crtc-pipe, intel_crtc-plane);
 }
 
+static void intel_crtc_set_rotation(struct drm_crtc *crtc,
+   uint64_t rotation)
+{
+   struct drm_device *dev = crtc-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int reg = PIPECONF(intel_crtc-pipe);
+   u32 val = I915_READ(reg);
+
+   val = ~PIPECONF_ROTATION_MASK;
+
+   switch (rotation) {
+   case 0:
+   val |= PIPECONF_ROTATION_0;
+   break;
+   case 90:
+   val |= PIPECONF_ROTATION_90;
+   break;
+   case 180:
+   val |= PIPECONF_ROTATION_180;
+   break;
+   case 270:
+   val |= PIPECONF_ROTATION_270;
+   break;
+   default:
+   DRM_ERROR(Unsupported rotation: %Lu\n, rotation);
+   val |= PIPECONF_ROTATION_0;
+   }
+
+   I915_WRITE(reg, val);
+}
+
+static int intel_crtc_set_property(struct drm_crtc *crtc,
+  struct drm_property *property,
+  uint64_t val)
+{
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+   if (property == intel_crtc-rotation_property)
+   intel_crtc_set_rotation(crtc, val);
+   return 0;
+}
+
 static struct drm_crtc_helper_funcs intel_helper_funcs = {
.dpms = intel_crtc_dpms,
.mode_fixup = intel_crtc_mode_fixup,
@@ -7547,12 +7592,14 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = intel_crtc_destroy,
.page_flip = intel_crtc_page_flip,
+   .set_property = intel_crtc_set_property,
 };
 
 static void intel_crtc_init(struct drm_device *dev, int pipe)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc;
+   struct drm_property *prop;
int i;
 
intel_crtc = kzalloc(sizeof(struct intel_crtc) + (INTELFB_CONN_LIMIT * 
sizeof(struct drm_connector *)), GFP_KERNEL);
@@ -7568,6 +7615,16 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc-lut_b[i] = i;
}
 
+   prop = drm_property_create(dev, DRM_MODE_PROP_RANGE, rotation, 2);
+   if (prop == NULL) {
+   DRM_ERROR(Failed to create rotation property!\n);
+   BUG();
+   }
+   prop-values[0] = 0;
+   prop-values[1] = 359;
+   drm_crtc_attach_property(intel_crtc-base, prop, 0);
+   intel_crtc-rotation_property = prop;
+
/* Swap pipes  planes for FBC on pre-965 */
intel_crtc-pipe = pipe;
intel_crtc-plane = pipe;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5ac8a16..26bdc65 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -176,6 +176,8 @@ struct intel_crtc {
 
bool no_pll; /* tertiary pipe for IVB */
bool use_pll_a;
+
+   struct drm_property *rotation_property;
 };
 
 struct intel_plane {
-- 
1.7.8.3

___
dri-devel mailing list

Re: [next] Null pointer dereference in nouveau_vm_map_sg

[Jerome Glisse]

On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
 In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
 at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
 reproduce, so I can test patches if needed.
 
   Martin
 

How do you trigger this ?

Cheers,
Jerome

 
 
 [  216.546584] BUG: unable to handle kernel NULL pointer dereference at 
 00d0
 [  216.546613] IP: [814a87ec] nouveau_vm_map_sg+0x2c/0x130
 [  216.546631] PGD 5b155067 PUD 5ab71067 PMD 0 
 [  216.546647] Oops:  [#1] SMP 
 [  216.546659] CPU 1 
 [  216.546664] Modules linked in: tun iwl4965 iwlegacy mac80211 cfg80211 tg3 
 psmouse rtc_cmos evdev ehci_hcd uhci_hcd usbcore usb_common [last unloaded: 
 scsi_wait_scan]
 [  216.546721] 
 [  216.546727] Pid: 3327, comm: Xorg Not tainted 3.2.0-next-20120113 #56 Dell 
 Inc. XPS M1330   /0PU073
 [  216.546749] RIP: 0010:[814a87ec]  [814a87ec] 
 nouveau_vm_map_sg+0x2c/0x130
 [  216.546770] RSP: 0018:88005b0c9858  EFLAGS: 00010246
 [  216.546780] RAX: 88005bf84620 RBX: 88005ab08d20 RCX: 
 
 [  216.546791] RDX: 0001 RSI:  RDI: 
 
 [  216.546802] RBP: 88005b0c98a8 R08:  R09: 
 
 [  216.546813] R10: 0001 R11: 0001 R12: 
 4000
 [  216.546823] R13: 88005bf84dc8 R14: 88007838c000 R15: 
 
 [  216.546835] FS:  7f5f728a8880() GS:88007fd0() 
 knlGS:
 [  216.546848] CS:  0010 DS:  ES:  CR0: 80050033
 [  216.546857] CR2: 00d0 CR3: 6c1bb000 CR4: 
 06e0
 [  216.546869] DR0:  DR1:  DR2: 
 
 [  216.546880] DR3:  DR6: 0ff0 DR7: 
 0400
 [  216.546892] Process Xorg (pid: 3327, threadinfo 88005b0c8000, task 
 8800655da180)
 [  216.546904] Stack:
 [  216.546909]  88005b0c9960 880037180368  
 
 [  216.546930]  88005b0c98d8 88005bf84dc8 88005b0c9960 
 88007838c240
 [  216.546949]  88007838c000  88005b0c98d8 
 81481bdf
 [  216.546969] Call Trace:
 [  216.546979]  [81481bdf] nouveau_bo_move_ntfy+0x7f/0xb0
 [  216.546991]  [81470614] ttm_bo_handle_move_mem+0x204/0x3d0
 [  216.547003]  [8147099d] ttm_bo_evict+0x1bd/0x2a0
 [  216.547015]  [81460de7] ? drm_mm_kmalloc+0x37/0xd0
 [  216.547027]  [81470bf1] ttm_mem_evict_first+0x171/0x230
 [  216.547039]  [814714ed] ttm_bo_mem_space+0x30d/0x420
 [  216.547056]  [814716e8] ttm_bo_move_buffer+0xe8/0x160
 [  216.547069]  [8108df2b] ? __lock_release+0x6b/0xe0
 [  216.547080]  [81460de7] ? drm_mm_kmalloc+0x37/0xd0
 [  216.547091]  [81471847] ttm_bo_validate+0xe7/0xf0
 [  216.547102]  [81471a24] ttm_bo_init+0x1d4/0x2a0
 [  216.547113]  [81482481] ? nouveau_bo_new+0x51/0x1c0
 [  216.547124]  [8148258c] nouveau_bo_new+0x15c/0x1c0
 [  216.547135]  [81481eb0] ? nouveau_ttm_tt_create+0x80/0x80
 [  216.547148]  [81338bba] ? avc_has_perm_noaudit+0xfa/0x290
 [  216.547160]  [81485cf3] nouveau_gem_new+0x53/0x120
 [  216.548008]  [8108df81] ? __lock_release+0xc1/0xe0
 [  216.548008]  [81112a97] ? might_fault+0x57/0xb0
 [  216.548008]  [81485e29] nouveau_gem_ioctl_new+0x69/0x170
 [  216.548008]  [81112a97] ? might_fault+0x57/0xb0
 [  216.548008]  [814553e4] drm_ioctl+0x444/0x510
 [  216.548008]  [81485dc0] ? nouveau_gem_new+0x120/0x120
 [  216.548008]  [81150b17] do_vfs_ioctl+0x87/0x330
 [  216.548008]  [8133b528] ? selinux_file_ioctl+0x68/0x140
 [  216.548008]  [81150e51] sys_ioctl+0x91/0xa0
 [  216.555939]  [817c1722] system_call_fastpath+0x16/0x1b
 [  216.555939] Code: 48 89 e5 41 57 49 89 cf 41 56 41 55 49 89 fd 41 54 49 89 
 d4 ba 01 00 00 00 53 41 89 d3 48 83 ec 28 48 8b 47 20 48 8b 5f 18 31 ff 4c 
 8b b1 d0 00 00 00 0f b6 48 30 44 8b 48 34 8b 83 20 01 00 00 
 [  216.555939] RIP  [814a87ec] nouveau_vm_map_sg+0x2c/0x130
 [  216.555939]  RSP 88005b0c9858
 [  216.555939] CR2: 00d0
 [  216.581301] ---[ end trace 0d910003d5fb1cd8 ]---
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42580] [radeon RS690] resume fails when radeon firmware is not available

[bugzilla-daemon]

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


Jérôme Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 CC||gli...@freedesktop.org




--- Comment #1 from Jérôme Glisse gli...@freedesktop.org  2012-01-16 20:29:05 
---
I am pondering on completely disabling KMS if firmware are not present. That
would avoid time waste on our side.

-- 
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 2/3] drm: add CRTC properties

[Paulo Zanoni]

Three comments about the design are inline:

 +void drm_crtc_attach_property(struct drm_crtc *crtc,
 +                             struct drm_property *property, uint64_t 
 init_val)
 +{
 +       int i;
 +
 +       for (i = 0; i  DRM_CRTC_MAX_PROPERTY; i++) {
 +               if (crtc-property_ids[i] == 0) {
 +                       crtc-property_ids[i] = property-base.id;
 +                       crtc-property_values[i] = init_val;
 +                       return;
 +               }
 +       }
 +       BUG_ON(1);

I looked at drm_connector_attach_property and saw that instead of
BUG_ON(1), it tries to return -EINVAL. The problem is that only zero
callers check for the return value of drm_connector_attach_property. I
can provide a patch for drm_connector_attach_property changing the
-EINVAL for BUG_ON(1) if no one objects. Or I can also add -EINVAL to
drm_crtc_attach_property and, to be consistent, not check for it :)


 +int drm_mode_crtc_get_properties_ioctl(struct drm_device *dev, void *data,
 +                                      struct drm_file *file_priv)
 +{
... (same function) ...
 +
 +       for (i = 0; i  DRM_CRTC_MAX_PROPERTY; i++)
 +               if (crtc-property_ids[i] != 0)
 +                       props_count++;
... (same function) ...
 +               for (i = 0; i  props_count; i++) {
 +                       if (put_user(crtc-property_ids[i],
 +                                    props_ptr + copied)) {
 +                               ret = -EFAULT;
 +                               goto out;
 +                       }

If you look at the connector properties (and now crtc properties),
you'll see that they're stored in property_ids arrays, and invalid
IDs are 0. There is code to add properties, but I didn't find code
to remove them. But if you look at the connector code, you'll that it
is implemented in a way that if the array is something like: [
valid_id, 0, valid_id, 0, 0, 0 ... ], the code will work (even with a
zero in the middle of two valid ids). While this makes the code more
resistant to mistakes, it also makes some loops longer (you don't need
to stop at the first invalid id, you need to keep looking). And, as
far as I found, we don't ever reach the [ valid, 0, valid ] case
because we never remove properties. Even if we start removing
properties, we can try to avoid the [valid, 0, valid] case. In my
patch, this condition is not valid for the crtc properties, so we can
make loops shorter (and I see I could still improve one of the loops).
Which way do we prefer?

 +       DRM_IOCTL_DEF(DRM_IOCTL_MODE_CRTC_GETPROPERTIES, 
 drm_mode_crtc_get_properties_ioctl, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 +       DRM_IOCTL_DEF(DRM_IOCTL_MODE_CRTC_SETPROPERTY, 
 drm_mode_crtc_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED)

I'm not sure about how we want these flags. I just copied from
connector properties ioctls.

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

Re: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding

[Daniel Vetter]

Hi Dave,

Is it ok if I merge this through my -next tree? Otherwise please consider
merging this for 3.4.

Yours, Daniel

On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
 This allows to avoid talking to a non-responding bus repeatedly until we
 finally timeout after 15 attempts. We can do this by catching the -ENXIO
 error, provided by i2c_algo_bit:bit_doAddress call.
 
 Within the bit_doAddress we already try 3 times to get the edid data, so
 if the routine tells us that bus is not responding, it is mostly pointless
 to keep re-trying those attempts over and over again until we reach final
 number of retries.
 
 This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
 and improve overall edid detection timing by 10-30% in most cases, and by
 a much larger margin in case of phantom outputs (up to 30x in one worst
 case).
 
 Timing results for i915-powered machines for 'time xrandr' command:
 Machine 1: from 0.840s to 0.290s
 Machine 2: from 0.315s to 0.280s
 Machine 3: from +/- 4s to 0.184s
 
 Timing results for HD5770 with 'time xrandr' command:
 Machine 4: from 3.210s to 1.060s
 
 Reviewed-by: Chris Wilson ch...@hchris-wilson.co.uk
 Reviewed-by: Keith Packard kei...@keithp.com
 Tested-by: Sean Finney sean...@seanius.net
 Tested-by: Soren Hansen so...@linux2go.dk
 Tested-by: Hernando Torque sir...@sonnenkinder.org
 Tested-by: Mike Lothian m...@fireburn.co.uk
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
 ---
  drivers/gpu/drm/drm_edid.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 3e927ce..fb6c26c 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
 unsigned char *buf,
   }
   };
   ret = i2c_transfer(adapter, msgs, 2);
 + if (ret == -ENXIO) {
 + DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
 + adapter-name);
 + break;
 + }
   } while (ret != 2  --retries);
  
   return ret == 2 ? 0 : -1;
 -- 
 1.7.8
 
 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Dave Airlie]

On Mon, Jan 16, 2012 at 7:59 PM, Paulo Zanoni przan...@gmail.com wrote:
 Hi

 2012/1/5 Jakob Bornecrantz ja...@vmware.com:
 Couldn't this be done by just adding a property instead of a ioctl?


 So I've discussed this with Jesse and it seems the best way to turn
 this into a property is to add support for CRTC properties, then add a
 rotation property for the i915 driver. This will actually introduce
 2 new ioctls: one to list the properties and one to change them.

Okay I must have missed the bit where you explain why a connector
property isn't used?

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

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

[bugzilla-daemon]

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

--- Comment #12 from GhostlyDeath ghostlyde...@gmail.com 2012-01-16 12:36:30 
PST ---
I still get rendering errors with PrBoom with the patch applied. Do you have a
complete patch that can be applied to a more recent git revision?

By the way, I rebuilt with:
# make clean
# make distclean
# patch -p1  befixes1.patch
# patch -p1  befixes2.patch
# ./configure --prefix=/opt/xorg --with-dri-driverdir=/opt/xorg/lib/dri/ 
--with-gallium-drivers=r300,r600,swrast  --enable-glx-tls --enable-gles1
--enable-gles2 --enable-openvg --enable-xorg --enable-gallium-egl --with-x
# make
# rm -rf /opt/xorg
# make install

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

[Bug 42580] [radeon RS690] resume fails when radeon firmware is not available

[bugzilla-daemon]

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


Jérôme Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WILL_NOT_FIX




--- Comment #2 from Jérôme Glisse gli...@freedesktop.org  2012-01-16 20:36:47 
---
Btw, to be clear, we won't fix the no firmware case. So closing.

-- 
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 1/2] omap2+: add drm device

[Felipe Contreras]

On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

 #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
 extern void omapdrm_reserve_vram(void);
 #else
 static inline void omapdrm_reserve_vram(void) { }
 #endif

 Like how it's done with DSP stuff.

 right, but then you'd miss the omapdrm_reserve_vram() call at startup..

Why?

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

Re: [Intel-gfx] [RFC] drm: implement DRM_IOCTL_MODE_SETROTATION

[Paulo Zanoni]

2012/1/16 Dave Airlie airl...@gmail.com:

 Okay I must have missed the bit where you explain why a connector
 property isn't used?

The registers that contain the rotation information are the pipe
registers and, as far as I understood, each pipe is associated with
only one crtc. We can have more than one connector associated with one
crtc. So, in a case where we have two different connectors associated
with the same crtc, we would have to keep synchronizing the property
value between the two connectors: this doesn't sound like the best
solution and it could also create confusion (imagine the case where
connectors A and B are associated with the same crtc, and you set
connector_a.rotation to 0 and then connector_b.rotation to 180, then
you'll read connector_a.rotation and it will be 180, not what you just
set).

(and by the way, the three patches were sent just to dri-devel@)


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

Re: [PATCH] drm/i915: kill i915_mem.c

[Daniel Vetter]

On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
 Some decent history digging indicates that this was to be used for the
 GLX_MESA_allocate_memory extension but never actually implemented for
 any released i915 userspace code.
 
 So just rip it out.
 
 Cc: Dave Airlie airl...@gmail.com
 Cc: Keith Whitwell kei...@vmware.com
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch

Can some bored soul take a look at this and do the history
double-checking? And maybe notice that the Makefile change is missing ...

/me would like to kill this cruft

Cheers, Daniel
 ---
  drivers/gpu/drm/drm_ioctl.c |2 +
  drivers/gpu/drm/i915/i915_dma.c |   13 +-
  drivers/gpu/drm/i915/i915_drv.h |   13 --
  drivers/gpu/drm/i915/i915_mem.c |  387 
 ---
  4 files changed, 6 insertions(+), 409 deletions(-)
  delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
 
 diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
 index 904d7e9..6bfc5ce 100644
 --- a/drivers/gpu/drm/drm_ioctl.c
 +++ b/drivers/gpu/drm/drm_ioctl.c
 @@ -37,6 +37,7 @@
  #include drm_core.h
  
  #include linux/pci.h
 +#include linux/export.h
  
  /**
   * Get the bus id.
 @@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
   DRM_DEBUG(\n);
   return 0;
  }
 +EXPORT_SYMBOL(drm_noop);
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index a9ae374..71a1946 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
  
   i915_gem_lastclose(dev);
  
 - if (dev_priv-agp_heap)
 - i915_mem_takedown((dev_priv-agp_heap));
 -
   i915_dma_cleanup(dev);
  }
  
 @@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, 
 struct drm_file *file_priv)
  {
   drm_i915_private_t *dev_priv = dev-dev_private;
   i915_gem_release(dev, file_priv);
 - if (!drm_core_check_feature(dev, DRIVER_MODESET))
 - i915_mem_release(dev, file_priv, dev_priv-agp_heap);
  }
  
  void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
 @@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 - DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 + DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
 + DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
 + DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
 - DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  i915_mem_destroy_heap, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 + DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP,  drm_noop, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE,  i915_vblank_pipe_set, 
 DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
   DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE,  i915_vblank_pipe_get, 
 DRM_AUTH),
   DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 554bef7..0dceb4a 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -327,7 +327,6 @@ typedef struct drm_i915_private {
  
   int tex_lru_log_granularity;
   int allow_batchbuffer;
 - struct mem_block *agp_heap;
   unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
   int vblank_pipe;
   int num_pipe;
 @@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device 
 *dev);
  #endif
  
  
 -/* i915_mem.c */
 -extern int i915_mem_alloc(struct drm_device *dev, void *data,
 -   struct drm_file *file_priv);
 -extern int i915_mem_free(struct drm_device *dev, void *data,
 -  struct drm_file *file_priv);
 -extern int i915_mem_init_heap(struct drm_device *dev, void *data,
 -   struct drm_file *file_priv);
 -extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
 -  struct drm_file *file_priv);
 -extern void i915_mem_takedown(struct mem_block **heap);
 -extern void i915_mem_release(struct drm_device * dev,
 -  struct drm_file *file_priv, struct mem_block 
 *heap);
  /* i915_gem.c */
  int i915_gem_init_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 diff --git a/drivers/gpu/drm/i915/i915_mem.c b/drivers/gpu/drm/i915/i915_mem.c
 deleted file mode 100644
 index cc8f6d4..000
 --- a/drivers/gpu/drm/i915/i915_mem.c
 +++ 

[Bug 44499] r280 and xbmc - choppy menu and video playback

[bugzilla-daemon]

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

--- Comment #8 from smoki smoki00...@gmail.com 2012-01-16 16:36:23 PST ---
Created attachment 55655
  -- https://bugs.freedesktop.org/attachment.cgi?id=55655
oprofiled blender

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

[Bug 44499] r280 and xbmc - choppy menu and video playback

[bugzilla-daemon]

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

--- Comment #9 from smoki smoki00...@gmail.com 2012-01-16 16:37:29 UTC ---
Created attachment 55656
  -- https://bugs.freedesktop.org/attachment.cgi?id=55656
oprofiled fog

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

[Bug 44848] New: OpenArena brightness control does not work

[bugzilla-daemon]

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

 Bug #: 44848
   Summary: OpenArena brightness control does not work
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: lve...@gmail.com


The option accessed via Setup → System → Dysplay → Brightness on
OpenArena has no effect.

Hardware here: Radeon HD 4870

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.0-devel
OpenGL shading language version string: 1.20

I am using xorg-edgers ppa.

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

[PATCH 0/4] drm/exynos: fixed minor bugs.

[Inki Dae]

this patch set fixes the issues that two drivers use same hardware, FIMD and 
HDMI,
and also I'd like to add my colleagues who dedicated to developing and improving
Exynos DRM Driver to maintainer entry.

this is based on git repository below:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
branch name: drm-fixes
commit-id: 081794564e3000e602de290d1121792c33b475a4

and you can refer to our working repository below:
http://git.infradead.org/users/kmpark/linux-2.6-samsung,
branch name: exynos-drm-fixes

Inki Dae (2):
  drm/exynos: fixed build dependency for DRM_EXYNOS_FIMD
  MAINTAINERS: added maintainer entry for Exynos DRM Driver.

Seung-Woo Kim (2):
  drm/exynos: use release_mem_region instead of release_resource
  drm/exynos: fix build dependency for DRM_EXYNOS_HDMI

 MAINTAINERS  |3 +++
 drivers/gpu/drm/exynos/Kconfig   |4 ++--
 drivers/gpu/drm/exynos/exynos_hdmi.c |8 
 3 files changed, 9 insertions(+), 6 deletions(-)

-- 
1.7.4.1

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

[PATCH 2/4] drm/exynos: fix build dependency for DRM_EXYNOS_HDMI

[Inki Dae]

From: Seung-Woo Kim sw0312@samsung.com

DRM_EXYNOS_HDMI driver and VIDEO_SAMSUNG_S5P_TV driver should be
not enabled at once because they use same HW blocks. So dependency
for DRM_EXYNOS_HDMI is fixed to check VIDEO_SAMSUNG_S5P_TV=n.

Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index f9aaa56..4ab915e 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -21,7 +21,7 @@ config DRM_EXYNOS_FIMD
 
 config DRM_EXYNOS_HDMI
tristate Exynos DRM HDMI
-   depends on DRM_EXYNOS
+   depends on DRM_EXYNOS  !VIDEO_SAMSUNG_S5P_TV
help
  Choose this option if you want to use Exynos HDMI for DRM.
  If M is selected, the module will be called exynos_drm_hdmi
-- 
1.7.4.1

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