date:20111115

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

 Bug #: 42960
   Summary: Display does not work when resuming from suspend
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: sandy.8925 at gmail.com


I have an ASUS K53TA laptop.

Relevant specs: AMD A6-3400M APU with integrated Radeon HD6520G and a discrete
Radeon HD6650M. Both are connected through Crossfire (I think). Laptop display
is though the integrated card.

Software info:
Ubuntu 11.04 64 bit using Linux 3.2-rc1 kernel from kernel.org and xorg-edgers
PPA

After resuming from suspend, display does not work.

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

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
> On Tue, 15 Nov 2011 14:57:02 +0200
> Ville Syrj?l?  wrote:
> > I'm fine with fourccs as long as the defines are named and documented
> > in way that avoids guesswork.
> > 
> > So what I'm thinking is something like this:
> > 
> > DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
> > DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
> > DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
> > DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
> > DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
> > 
> > DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
> > DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
> > 
> > DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
> > DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
> > DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
> > DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
> > 
> > That leaves no room for guesswork.
> 
> Looks great.  Want to send Dave an incremental patch?  I'll apply the
> final version to libdrm for use by userland code.

What I listed there doesn't match what v4l2 has. So I'm not sure what
to put in a patch.

It looks like the v4l2 fourccs have explicit endianness (ie. LE or BE).
If we follow that, and assuming people still want to use hardware byte
swappers, it means user space needs some ifdefs to select the approriate
format based on the host endianness. Or, we could do that in the header
file itself, so we would provide three definitions for each format LE,
BE, and NE (which would point to LE or BE depending on host endianness).

One extra issue I just realized is that the 8bpp and 16bpp v4l2 formats
are in fact BGR nor RGB, that is the component order is such that blue
occupies the most significant bit, red the lsb. I've never even seen
a PC graphics card that supports such formats. Adding insult to injury
PIX_FMT_RGB444 is defined the opposite way, ie. matching what most
graphics cards would expect.

-- 
Ville Syrj?l?
Intel OTC

[git pull] drm/vgaarb fixes

2011-11-15 Thread Dave Airlie


Hi Linus,

Fix for a vgaarb bridge detect problem I found playing in qemu, a radeon 
oops fix, missing PCI IDs, and a fix from the -rt guys that I've forgotten 
to send 2 or 3 times now.

Dave.

The following changes since commit a7c36fd8c5ee6dcca584137cb81aeefd785a0721:

  drm/radeon/kms/combios: fix dynamic allocation of PM clock modes (2011-11-12 
17:46:40 +)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (3):
  drm/radeon: add some missing FireMV pci ids
  drm/radeon/kms: fix up gpio i2c mask bits for r4xx
  drm/radeon/kms: fix segfault in pm rework

Dave Airlie (1):
  vgaarb: a NULL bridge is acceptable for root devices.

Thomas Gleixner (1):
  drm: Remove utterly bogus preempt_disable() sections

 drivers/gpu/drm/drm_irq.c|9 --
 drivers/gpu/drm/radeon/radeon_atombios.c |   32 +++--
 drivers/gpu/vga/vgaarb.c |   44 ++---
 include/drm/drm_pciids.h |2 +
 4 files changed, 40 insertions(+), 47 deletions(-)

DRM KMS Modesetting

2011/11/15 Kristian H?gsberg :
> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes  
> wrote:
>> On Mon, 14 Nov 2011 21:47:09 +0100
>> David Herrmann  wrote:
>>> > I had to modify the resolution the test was searching for
>>> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
>>> > monitor, and fix the connector id, but other than that it seemed to
>>> > work fine.
>>>
>>> Thanks for testing. At least my code seems right now, but I still
>>> cannot get it to work on my machine. The output of modetest is:
>>> https://gist.github.com/1365083
>>>
>>> There is only one connected connector+encoder+mode so I don't know
>>> where the problem exactly is. Are there any debug options? Is it
>>> possible to query the EGLImage for width/height?
>>
>> Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
>> width/stride correctly somewhere then. ?You'd have to walk through the
>> gbm_dri2.c and egl_dri2.c code and see where the width is going off
>> into the weeds.
>
> Could be, I know I've run Wayland on Pineview though, so that works at
> least. ?David, did you try eglkms from mesa demos?
>
> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

I tried it now. I get a black screen and in the left quarter there is
one white triangle which fades to black. But again, the right 3/4 of
the screen are black.

> Kristian
>

I will try to debug my mesa package but this will probably take some
time. If someone has an idea how to find the bug faster, just tell me
;)

Regards
David

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #3 from Kai  2011-11-15 11:47:33 PST 
---
(In reply to comment #2)
> does xrandr to a new mode and back help?

Yes, that restores a normal screen. AFAICT there is no vestige of the
corruption left.

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

[PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

On Tue, Nov 15, 2011 at 4:07 PM, Konrad Rzeszutek Wilk
 wrote:
> On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.glisse at gmail.com wrote:
>> From: Jerome Glisse 
>>
>> Move dma data to a superset ttm_dma_tt structure which herit
>
> inherit
>
>> from ttm_tt. This allow driver that don't use dma functionalities
>> to not have to waste memory for it.
>>
>> V2 Rebase on top of no memory account changes (where/when is my
>> ? ?delorean when i need it ?)
>> V3 Make sure page list is initialized empty
>>
>> Signed-off-by: Jerome Glisse 
>> Reviewed-by: Thomas Hellstrom 
> .. snip..
>
>> +void ttm_tt_fini(struct ttm_tt *ttm)
>> +{
>> + ? ? drm_free_large(ttm->pages);
>> + ? ? ttm->pages = NULL;
>> +}
>> +EXPORT_SYMBOL(ttm_tt_fini);
>> +
>> +int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
>> + ? ? ? ? ? ? unsigned long size, uint32_t page_flags,
>> + ? ? ? ? ? ? struct page *dummy_read_page)
>> +{
>> + ? ? struct ttm_tt *ttm = _dma->ttm;
>> +
>> + ? ? ttm->bdev = bdev;
>> + ? ? ttm->glob = bdev->glob;
>> + ? ? ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> + ? ? ttm->caching_state = tt_cached;
>> + ? ? ttm->page_flags = page_flags;
>> + ? ? ttm->dummy_read_page = dummy_read_page;
>> + ? ? ttm->state = tt_unpopulated;
>> +
>> + ? ? INIT_LIST_HEAD(_dma->pages_list);
>> + ? ? ttm_dma_tt_alloc_page_directory(ttm_dma);
>> + ? ? if (!ttm->pages || !ttm_dma->dma_address) {
>> + ? ? ? ? ? ? ttm_tt_destroy(ttm);
>> + ? ? ? ? ? ? printk(KERN_ERR TTM_PFX "Failed allocating page table\n");
>> + ? ? ? ? ? ? return -ENOMEM;
>> + ? ? }
>> + ? ? return 0;
>> +}
>> +EXPORT_SYMBOL(ttm_dma_tt_init);
>
> EXPORT_SYMBOL_GPL ?
>
>> +
>> +void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
>> +{
>> + ? ? struct ttm_tt *ttm = _dma->ttm;
>> +
>> + ? ? drm_free_large(ttm->pages);
>> + ? ? ttm->pages = NULL;
>> + ? ? drm_free_large(ttm_dma->dma_address);
>> + ? ? ttm_dma->dma_address = NULL;
>> +}
>> +EXPORT_SYMBOL(ttm_dma_tt_fini);
>> +
>
> EXPORT_SYMBOL_GPL?
>
>
>> ?void ttm_tt_unbind(struct ttm_tt *ttm)
>> ?{
>> ? ? ? int ret;
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> index 3986d74..1e2c0fb 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> @@ -168,6 +168,7 @@ static void vmw_ttm_destroy(struct ttm_tt *ttm)
>> ?{
>> ? ? ? struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, ttm);
>>
>> + ? ? ttm_tt_fini(ttm);
>> ? ? ? kfree(vmw_be);
>> ?}
>>
>> @@ -191,6 +192,7 @@ struct ttm_tt *vmw_ttm_tt_create(struct ttm_bo_device 
>> *bdev,
>> ? ? ? vmw_be->dev_priv = container_of(bdev, struct vmw_private, bdev);
>>
>> ? ? ? if (ttm_tt_init(_be->ttm, bdev, size, page_flags, 
>> dummy_read_page)) {
>> + ? ? ? ? ? ? kfree(vmw_be);
>> ? ? ? ? ? ? ? return NULL;
>> ? ? ? }
>>
>> diff --git a/include/drm/ttm/ttm_bo_driver.h 
>> b/include/drm/ttm/ttm_bo_driver.h
>> index beef9ab..89caa48 100644
>> --- a/include/drm/ttm/ttm_bo_driver.h
>> +++ b/include/drm/ttm/ttm_bo_driver.h
>> @@ -104,7 +104,6 @@ enum ttm_caching_state {
>> ? * @caching_state: The current caching state of the pages.
>> ? * @state: The current binding state of the pages.
>> ? * @dma_address: The DMA (bus) addresses of the pages (if 
>> TTM_PAGE_FLAG_DMA32)
>> - * @alloc_list: used by some page allocation backend
>> ? *
>> ? * This is a structure holding the pages, caching- and aperture binding
>> ? * status for a buffer object that isn't backed by fixed (VRAM / AGP)
>> @@ -127,8 +126,23 @@ struct ttm_tt {
>> ? ? ? ? ? ? ? tt_unbound,
>> ? ? ? ? ? ? ? tt_unpopulated,
>> ? ? ? } state;
>> +};
>> +
>> +/**
>> + * struct ttm_dma_tt
>> + *
>> + * @ttm: Base ttm_tt struct.
>> + * @dma_address: The DMA (bus) addresses of the pages (if 
>> TTM_PAGE_FLAG_DMA32)
>
> Not anymore (the TTM_PAGE_FLAG_DMA32 comment).
>
>> + * @pages_list: used by some page allocation backend
>> + *
>> + * This is a structure holding the pages, caching- and aperture binding
>> + * status for a buffer object that isn't backed by fixed (VRAM / AGP)
>> + * memory.
>> + */
>> +struct ttm_dma_tt {
>> + ? ? struct ttm_tt ttm;
>> ? ? ? dma_addr_t *dma_address;
>> - ? ? struct list_head alloc_list;
>> + ? ? struct list_head pages_list;
>> ?};
>>
>> ?#define TTM_MEMTYPE_FLAG_FIXED ? ? ? ? (1 << 0) ? ? ?/* Fixed (on-card) PCI 
>> memory */
>> @@ -595,6 +609,19 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
>> mask)
>> ?extern int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>> ? ? ? ? ? ? ? ? ? ? ? unsigned long size, uint32_t page_flags,
>> ? ? ? ? ? ? ? ? ? ? ? struct page *dummy_read_page);
>> +extern int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device 
>> *bdev,
>> + ? ? ? ? ? ? ? ? ? ? ? ?unsigned long size, uint32_t page_flags,
>> + ? ? ? ? ? ? ? ? ? ? ? ?struct page *dummy_read_page);
>> +
>> +/**
>> + * ttm_tt_fini
>> + *
>> + * @ttm: The struct ttm_tt.
>> + *
>> + * Free memory of ttm_tt structu
>
> structure
>> + */
>>

RFC: Radeon multi ring support branch

2011/11/15 Christian K?nig :
> On 15.11.2011 20:32, Jerome Glisse wrote:
>>
>> On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
>>>
>>> Hello everybody,
>>>
>>> to support multiple compute rings, async DMA engines and UVD we need
>>> to teach the radeon kernel module how to sync buffers between
>>> different rings and make some changes to the command submission
>>> ioctls.
>>>
>>> Since we can't release any documentation about async DMA or UVD
>>> (yet), my current branch concentrates on getting the additional
>>> compute rings on cayman running. Unfortunately those rings have
>>> hardware bugs that can't be worked around, so they are actually not
>>> very useful in a production environment, but they should do quite
>>> well for this testing purpose.
>>>
>>> The branch can be found here:
>>> http://cgit.freedesktop.org/~deathsimple/linux/log/
>>>
>>> Since some of the patches are quite intrusive, constantly rebaseing
>>> them could get a bit painful. So I would like to see most of the
>>> stuff included into drm-next, even if we don't make use of the new
>>> functionality right now.
>>>
>>> Comments welcome,
>>> Christian.
>>
>> So i have been looking back at all this and now there is somethings
>> puzzling me. So if semaphore wait for a non null value at gpu address
>> provided in the packet than the current implementation for the cs
>> ioctl doesn't work when there is more than 2 rings to sync.
>
> Semaphores are counters, so each signal operation is atomically incrementing
> the counter, while each wait operation is (atomically) checking if the
> counter is above zero and if it is decrement it. So you can signal/wait on
> the same address multiple times.

Yup i did understand that right.

>>
>> As it will use only one semaphore so first ring to finish will
>> mark the semaphore as done even if there is still other ring not
>> done.
>
> Nope, each wait operation will wait for a separate signal operation (at
> least I think so).

Well as we don't specify on which value semaphore should wait on, i am
prety sure the first ring to increment the semaphore will unblock all
waiter. So if you have ring1 that want to wait on ring2 and ring3 as
soon as ring2 or ring3 is done ring1 will go one while either ring2 or
ring3 might not be done. I will test that tomorrow but from doc i have
it seems so. Thus it will be broken with more than one ring, that
would mean you have to allocate one semaphore for each ring couple you
want to synchronize. Note that the usual case will likely be sync btw
2 ring.

>>
>> This all make me wonder if some change to cs ioctl would make
>> all this better. So idea of semaphore is to wait for some other
>> ring to finish something. So let say we have following scenario:
>> Application submit following to ring1: csA, csB
>> Application now submit to ring2: cs1, cs2
>> And application want csA to be done for cs1 and csB to be done
>> for cs2.
>>
>> To achieve such usage pattern we would need to return fence seq
>> or similar from the cs ioctl. So user application would know
>> ringid+fence_seq for csA& ?csB and provide this when scheduling
>> cs1& ?cs2. Here i am assuming MEM_WRITE/WAIT_REG_MEM packet
>> are as good as MEM_SEMAPHORE packet. Ie the semaphore packet
>> doesn't give us much more than MEM_WRITE/WAIT_REG_MEM would.
>>
>> To achieve that each ring got it's fence scratch addr where to
>> write seq number. And then we use WAIT_REG_MEM on this addr
>> and with the specific seq for the other ring that needs
>> synchronization. This would simplify the semaphore code as
>> we wouldn't need somethings new beside helper function and
>> maybe extending the fence structure.
>
> I played around with the same Idea before implementing the whole semaphore
> stuff, but the killer argument against it is that not all rings support the
> WAIT_REG_MEM command.
>
> Also the semaphores are much more efficient than the WAIT_REG_MEM command,
> because all semaphore commands from the different rings are send to a
> central semaphore block, so that constant polling, and with it constant
> memory access can be avoided. Additional to that the WAIT_REG_MEM command
> has a minimum latency of Wait_Interval*16 clock cycles, while semaphore need
> 4 clock cycles for the command and 4 clock cycles for the result, so it
> definitely has a much lower latency.

Yup that was my guess too that semaphore block optimize things

> We should also keep in mind that the semaphore block is not only capable to
> sync between different rings inside a single GPU, but can also communicate
> with another semaphore block in a second GPU. So it is a key part in a multi
> GPU environment.
>
>> Anyway i put updating ring patch at :
>> http://people.freedesktop.org/~glisse/mrings/
>> It rebased on top of linus tree and it has several space
>> indentation fixes and also a fix for no semaphore allocated
>> issue (patch 5)
>>
> Thanks, I will try to integrate the changes tomorrow.
>

After retesting the first patch

radeon/kms: black screen when loading radeon with modeset=1

2011-11-15 Thread Deucher, Alexander

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-November/016498.html

Alex

> -Original Message-
> From: Sergey V. [mailto:sftp.mtuci at gmail.com]
> Sent: Tuesday, November 15, 2011 2:05 PM
> To: David Airlie
> Cc: Deucher, Alexander; dri-devel at lists.freedesktop.org; linux-
> kernel at vger.kernel.org
> Subject: radeon/kms: black screen when loading radeon with modeset=1
> 
> Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b
> 
> Loading radeon module with modeset=1 causes black screen.
> 
> Usually it happens at boot time, but if run kernel with radeon.modeset=0
> then `rmmod radeon; modprobe radeon modeset=1` I can get dmesg over
> ssh (thanks to glisse from #radeon for help).
> 
> Backtrace below:
> 
> [   89.905890] BUG: unable to handle kernel NULL pointer dereference at
> 0008
> [   89.906016] IP: []
> radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
> [   89.906016] PGD 6a0e1067 PUD 6a09d067 PMD 0
> [   89.906016] Oops: 0002 [#1] SMP
> [   89.906016] CPU 0
> [   89.906016] Modules linked in: radeon(+) snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss ipv6 btrfs cpufreq_ondemand powernow_k8 freq_table
> mperf lp ppdev parport_pc parport fuse snd_hda_codec_hdmi
> snd_hda_codec_realtek processor ttm drm_kms_helper drm thermal
> i2c_piix4 joydev agpgart video snd_hda_intel r8169 thermal_sys i2c_algo_bit
> i2c_core k8temp battery sdhci_pci snd_hda_codec evdev hwmon mii button
> ac shpchp sdhci snd_hwdep snd_pcm psmouse serio_raw mmc_core
> snd_timer sg snd soundcore snd_page_alloc [last unloaded: radeon]
> [   89.906016]
> [   89.906016] Pid: 2189, comm: modprobe Tainted: GW3.2.0-rc1+ #4
> Micro-Star International PR210/MS-1222
> [   89.906016] RIP: 0010:[]  []
> radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
> [   89.906016] RSP: 0018:880075959948  EFLAGS: 00010246
> [   89.906016] RAX:  RBX: 880075b72000 RCX:
> 
> [   89.906016] RDX:  RSI:  RDI:
> 880076c73c00
> [   89.906016] RBP: 880075959a98 R08:  R09:
> 880076c73a00
> [   89.906016] R10: 8800758a R11: 0006 R12:
> 8800758aadde
> [   89.906016] R13: 8800758aadde R14:  R15:
> 
> [   89.906016] FS:  7f57d0b27720() GS:88007bc0()
> knlGS:f702a6d0
> [   89.906016] CS:  0010 DS:  ES:  CR0: 8005003b
> [   89.906016] CR2: 0008 CR3: 6a0a6000 CR4:
> 06f0
> [   89.906016] DR0:  DR1:  DR2:
> 
> [   89.906016] DR3:  DR6: 0ff0 DR7:
> 0400
> [   89.906016] Process modprobe (pid: 2189, threadinfo 880075958000, task
> 880075abc6d0)
> [   89.906016] Stack:
> [   89.906016]  8800 8800768f400a 8800
> 00ff
> [   89.906016]  880037653663 880075b73158 880075b73174
> 000675959acf
> [   89.906016]  81b6112c 880075959a38 81b6112e
> 880075959ad5
> [   89.906016] Call Trace:
> [   89.906016]  [] ? vsnprintf+0x31e/0x5d0
> [   89.906016]  [] ? vsnprintf+0x31e/0x5d0
> [   89.906016]  [] ? up+0x31/0x50
> [   89.906016]  [] ? console_unlock+0x1c4/0x230
> [   89.906016]  []
> radeon_atombios_get_power_modes+0x228/0x8e0 [radeon]
> [   89.906016]  [] radeon_pm_init+0x3b1/0x590 [radeon]
> [   89.906016]  [] ? rs600_irq_set+0x109/0x180 [radeon]
> [   89.906016]  [] radeon_modeset_init+0x4c9/0x8a0
> [radeon]
> [   89.906016]  [] ? radeon_acpi_init+0x8c/0xbc [radeon]
> [   89.906016]  [] radeon_driver_load_kms+0x120/0x170
> [radeon]
> [   89.906016]  [] drm_get_pci_dev+0x18e/0x2c0 [drm]
> [   89.906016]  [] radeon_pci_probe+0xad/0xb5 [radeon]
> [   89.906016]  [] local_pci_probe+0x5f/0xd0
> [   89.906016]  [] pci_device_probe+0x88/0xb0
> [   89.906016]  [] ? driver_sysfs_add+0x7a/0xb0
> [   89.906016]  [] driver_probe_device+0x96/0x1b0
> [   89.906016]  [] __driver_attach+0xa3/0xb0
> [   89.906016]  [] ? driver_probe_device+0x1b0/0x1b0
> [   89.906016]  [] bus_for_each_dev+0x5e/0x90
> [   89.906016]  [] driver_attach+0x1e/0x20
> [   89.906016]  [] bus_add_driver+0x155/0x280
> [   89.906016]  [] driver_register+0x76/0x140
> [   89.906016]  [] __pci_register_driver+0x55/0xd0
> [   89.906016]  [] drm_pci_init+0x111/0x120 [drm]
> [   89.906016]  [] ? 0xa0638fff
> [   89.906016]  [] ? 0xa0638fff
> [   89.906016]  [] radeon_init+0xec/0xee [radeon]
> [   89.906016]  [] do_one_initcall+0x44/0x170
> [   89.906016]  [] sys_init_module+0x92/0x1e0
> [   89.906016]  [] system_call_fastpath+0x16/0x1b
> [   89.906016] Code: 16 44 3b b5 ec fe ff ff 0f 8d 40 01 00 00 48 8b 83 58 11
> 00 00 49 63 cf 48 89 ca 48 c1 e1 06 48 c1 e2 04 48 29 d1 48 8b 44 08 08 
> 40 08 00 00 00 00 0f b6 45 8f 3c 02 75 ac 4c 8b 83 58 11 00
> [

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #2 from Dave Airlie  2011-11-15 
09:34:49 PST ---
does xrandr to a new mode and back help?

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

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

--- Comment #11 from kao_chen  2011-11-15 09:03:51 PST 
---
Sorry I have done a mistake, the libtxc-dxtn library was not installed properly
on my PC.

I found the source code here:
http://debian-multimedia.org/pool/main/libt/libtxc-dxtn/libtxc-dxtn.php

It's working better for me on both Unigine Heaven and Unigine Oilrush game. I
still have some graphics artifacts but they probably  come from another bug.

Here:
Unigine Heaven with wrong shadows:
http://pix.toile-libre.org/upload/original/1321376279.png

And

Oilrush, the crane is flying
http://pix.toile-libre.org/upload/original/1321376118.png

Regards
Kao

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

[PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

On Tue, Nov 15, 2011 at 04:07:46PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.glisse at gmail.com wrote:
> > From: Jerome Glisse 
> > 
> > Move dma data to a superset ttm_dma_tt structure which herit
> 
> inherit
> 
> > from ttm_tt. This allow driver that don't use dma functionalities
> > to not have to waste memory for it.
> > 
> > V2 Rebase on top of no memory account changes (where/when is my
> >delorean when i need it ?)
> > V3 Make sure page list is initialized empty
> > 
> > Signed-off-by: Jerome Glisse 
> > Reviewed-by: Thomas Hellstrom 
> .. snip..
> 
> > +void ttm_tt_fini(struct ttm_tt *ttm)
> > +{
> > +   drm_free_large(ttm->pages);
> > +   ttm->pages = NULL;
> > +}
> > +EXPORT_SYMBOL(ttm_tt_fini);
> > +
> > +int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
> > +   unsigned long size, uint32_t page_flags,
> > +   struct page *dummy_read_page)
> > +{
> > +   struct ttm_tt *ttm = _dma->ttm;
> > +
> > +   ttm->bdev = bdev;
> > +   ttm->glob = bdev->glob;
> > +   ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > +   ttm->caching_state = tt_cached;
> > +   ttm->page_flags = page_flags;
> > +   ttm->dummy_read_page = dummy_read_page;
> > +   ttm->state = tt_unpopulated;
> > +
> > +   INIT_LIST_HEAD(_dma->pages_list);
> > +   ttm_dma_tt_alloc_page_directory(ttm_dma);
> > +   if (!ttm->pages || !ttm_dma->dma_address) {
> > +   ttm_tt_destroy(ttm);
> > +   printk(KERN_ERR TTM_PFX "Failed allocating page table\n");
> > +   return -ENOMEM;
> > +   }
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(ttm_dma_tt_init);
> 
> EXPORT_SYMBOL_GPL ?

TTM is BSD licensed too. As a rule the whole drm is under BSD license
too.

> 
> > +
> > +void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
> > +{
> > +   struct ttm_tt *ttm = _dma->ttm;
> > +
> > +   drm_free_large(ttm->pages);
> > +   ttm->pages = NULL;
> > +   drm_free_large(ttm_dma->dma_address);
> > +   ttm_dma->dma_address = NULL;
> > +}
> > +EXPORT_SYMBOL(ttm_dma_tt_fini);
> > +
> 
> EXPORT_SYMBOL_GPL?
> 
> 
> >  void ttm_tt_unbind(struct ttm_tt *ttm)
> >  {
> > int ret;
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> > index 3986d74..1e2c0fb 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> > @@ -168,6 +168,7 @@ static void vmw_ttm_destroy(struct ttm_tt *ttm)
> >  {
> > struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, ttm);
> >  
> > +   ttm_tt_fini(ttm);
> > kfree(vmw_be);
> >  }
> >  
> > @@ -191,6 +192,7 @@ struct ttm_tt *vmw_ttm_tt_create(struct ttm_bo_device 
> > *bdev,
> > vmw_be->dev_priv = container_of(bdev, struct vmw_private, bdev);
> >  
> > if (ttm_tt_init(_be->ttm, bdev, size, page_flags, dummy_read_page)) 
> > {
> > +   kfree(vmw_be);
> > return NULL;
> > }
> >  
> > diff --git a/include/drm/ttm/ttm_bo_driver.h 
> > b/include/drm/ttm/ttm_bo_driver.h
> > index beef9ab..89caa48 100644
> > --- a/include/drm/ttm/ttm_bo_driver.h
> > +++ b/include/drm/ttm/ttm_bo_driver.h
> > @@ -104,7 +104,6 @@ enum ttm_caching_state {
> >   * @caching_state: The current caching state of the pages.
> >   * @state: The current binding state of the pages.
> >   * @dma_address: The DMA (bus) addresses of the pages (if 
> > TTM_PAGE_FLAG_DMA32)
> > - * @alloc_list: used by some page allocation backend
> >   *
> >   * This is a structure holding the pages, caching- and aperture binding
> >   * status for a buffer object that isn't backed by fixed (VRAM / AGP)
> > @@ -127,8 +126,23 @@ struct ttm_tt {
> > tt_unbound,
> > tt_unpopulated,
> > } state;
> > +};
> > +
> > +/**
> > + * struct ttm_dma_tt
> > + *
> > + * @ttm: Base ttm_tt struct.
> > + * @dma_address: The DMA (bus) addresses of the pages (if 
> > TTM_PAGE_FLAG_DMA32)
> 
> Not anymore (the TTM_PAGE_FLAG_DMA32 comment).
> 
> > + * @pages_list: used by some page allocation backend
> > + *
> > + * This is a structure holding the pages, caching- and aperture binding
> > + * status for a buffer object that isn't backed by fixed (VRAM / AGP)
> > + * memory.
> > + */
> > +struct ttm_dma_tt {
> > +   struct ttm_tt ttm;
> > dma_addr_t *dma_address;
> > -   struct list_head alloc_list;
> > +   struct list_head pages_list;
> >  };
> >  
> >  #define TTM_MEMTYPE_FLAG_FIXED (1 << 0)/* Fixed (on-card) PCI 
> > memory */
> > @@ -595,6 +609,19 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
> > mask)
> >  extern int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
> > unsigned long size, uint32_t page_flags,
> > struct page *dummy_read_page);
> > +extern int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
> > ttm_bo_device *bdev,
> > +  unsigned long size, uint32_t page_flags,
> > +  struct page

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #1 from Kai  2011-11-15 08:38:49 PST 
---
Todays run showed one difference in what was reported by Piglit:
> Probe at (0,0)
>   Expected: 0.00 1.00 0.00 0.00
>   Observed: 0.00 0.00 0.00 1.00
> PIGLIT: {'result': 'fail' }
apart from that, the screen is still corrupted (a KDM restart fixes the screen
again; also non-X TTYs aren't affected either).

Used stack:
Mesa: Git/9d4d9d34
libdrm: 2.4.27-1
Kernel: 3.1.1
X.org: 1.11.1.902-1

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

DRM KMS Modesetting

2011/11/15 David Herrmann :
> 2011/11/15 Kristian H?gsberg :
>> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes  
>> wrote:
>>> On Mon, 14 Nov 2011 21:47:09 +0100
>>> David Herrmann  wrote:
 > I had to modify the resolution the test was searching for
 > to 1920x1200 instead of 1024x600 since I tested on a DP attached
 > monitor, and fix the connector id, but other than that it seemed to
 > work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?
>>>
>>> Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
>>> width/stride correctly somewhere then. ?You'd have to walk through the
>>> gbm_dri2.c and egl_dri2.c code and see where the width is going off
>>> into the weeds.
>>
>> Could be, I know I've run Wayland on Pineview though, so that works at
>> least. ?David, did you try eglkms from mesa demos?
>>
>> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c
>
> I tried it now. I get a black screen and in the left quarter there is
> one white triangle which fades to black. But again, the right 3/4 of
> the screen are black.
>
>> Kristian
>>
>
> I will try to debug my mesa package but this will probably take some
> time. If someone has an idea how to find the bug faster, just tell me
> ;)

It's all very odd.  The gbm allocation ends up in intel_create_image
in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to
compare the stride, width and height there with what modetest uses.

Kristiain

[Bug 42908] r600g: glx-shader-sharing causes segfault

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

Kai  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #1 from Kai  2011-11-15 08:31:35 PST 
---
Sorry for the noise, seems appending "-auto" to the invocation fixes this.

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

[PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

2011-11-15 Thread Konrad Rzeszutek Wilk

On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
> 
> Move dma data to a superset ttm_dma_tt structure which herit

inherit

> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
> 
> V2 Rebase on top of no memory account changes (where/when is my
>delorean when i need it ?)
> V3 Make sure page list is initialized empty
> 
> Signed-off-by: Jerome Glisse 
> Reviewed-by: Thomas Hellstrom 
.. snip..

> +void ttm_tt_fini(struct ttm_tt *ttm)
> +{
> + drm_free_large(ttm->pages);
> + ttm->pages = NULL;
> +}
> +EXPORT_SYMBOL(ttm_tt_fini);
> +
> +int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
> + unsigned long size, uint32_t page_flags,
> + struct page *dummy_read_page)
> +{
> + struct ttm_tt *ttm = _dma->ttm;
> +
> + ttm->bdev = bdev;
> + ttm->glob = bdev->glob;
> + ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> + ttm->caching_state = tt_cached;
> + ttm->page_flags = page_flags;
> + ttm->dummy_read_page = dummy_read_page;
> + ttm->state = tt_unpopulated;
> +
> + INIT_LIST_HEAD(_dma->pages_list);
> + ttm_dma_tt_alloc_page_directory(ttm_dma);
> + if (!ttm->pages || !ttm_dma->dma_address) {
> + ttm_tt_destroy(ttm);
> + printk(KERN_ERR TTM_PFX "Failed allocating page table\n");
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(ttm_dma_tt_init);

EXPORT_SYMBOL_GPL ?

> +
> +void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
> +{
> + struct ttm_tt *ttm = _dma->ttm;
> +
> + drm_free_large(ttm->pages);
> + ttm->pages = NULL;
> + drm_free_large(ttm_dma->dma_address);
> + ttm_dma->dma_address = NULL;
> +}
> +EXPORT_SYMBOL(ttm_dma_tt_fini);
> +

EXPORT_SYMBOL_GPL?


>  void ttm_tt_unbind(struct ttm_tt *ttm)
>  {
>   int ret;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> index 3986d74..1e2c0fb 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
> @@ -168,6 +168,7 @@ static void vmw_ttm_destroy(struct ttm_tt *ttm)
>  {
>   struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, ttm);
>  
> + ttm_tt_fini(ttm);
>   kfree(vmw_be);
>  }
>  
> @@ -191,6 +192,7 @@ struct ttm_tt *vmw_ttm_tt_create(struct ttm_bo_device 
> *bdev,
>   vmw_be->dev_priv = container_of(bdev, struct vmw_private, bdev);
>  
>   if (ttm_tt_init(_be->ttm, bdev, size, page_flags, dummy_read_page)) 
> {
> + kfree(vmw_be);
>   return NULL;
>   }
>  
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index beef9ab..89caa48 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -104,7 +104,6 @@ enum ttm_caching_state {
>   * @caching_state: The current caching state of the pages.
>   * @state: The current binding state of the pages.
>   * @dma_address: The DMA (bus) addresses of the pages (if 
> TTM_PAGE_FLAG_DMA32)
> - * @alloc_list: used by some page allocation backend
>   *
>   * This is a structure holding the pages, caching- and aperture binding
>   * status for a buffer object that isn't backed by fixed (VRAM / AGP)
> @@ -127,8 +126,23 @@ struct ttm_tt {
>   tt_unbound,
>   tt_unpopulated,
>   } state;
> +};
> +
> +/**
> + * struct ttm_dma_tt
> + *
> + * @ttm: Base ttm_tt struct.
> + * @dma_address: The DMA (bus) addresses of the pages (if 
> TTM_PAGE_FLAG_DMA32)

Not anymore (the TTM_PAGE_FLAG_DMA32 comment).

> + * @pages_list: used by some page allocation backend
> + *
> + * This is a structure holding the pages, caching- and aperture binding
> + * status for a buffer object that isn't backed by fixed (VRAM / AGP)
> + * memory.
> + */
> +struct ttm_dma_tt {
> + struct ttm_tt ttm;
>   dma_addr_t *dma_address;
> - struct list_head alloc_list;
> + struct list_head pages_list;
>  };
>  
>  #define TTM_MEMTYPE_FLAG_FIXED (1 << 0)  /* Fixed (on-card) PCI 
> memory */
> @@ -595,6 +609,19 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
> mask)
>  extern int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>   unsigned long size, uint32_t page_flags,
>   struct page *dummy_read_page);
> +extern int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device 
> *bdev,
> +unsigned long size, uint32_t page_flags,
> +struct page *dummy_read_page);
> +
> +/**
> + * ttm_tt_fini
> + *
> + * @ttm: The struct ttm_tt.
> + *
> + * Free memory of ttm_tt structu

structure
> + */
> +extern void ttm_tt_fini(struct ttm_tt *ttm);
> +extern void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma);


.. snip..
>   * Initialize pool allocator.
>   */
>  int ttm_page_alloc_init(struct ttm_mem_global *glob,

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 01:22:10PM -0800, Jesse Barnes wrote:
> On Mon, 14 Nov 2011 23:16:44 +0200
> Ville Syrj?l?  wrote:
> 
> > On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > > +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
> > > +   ((u32)(c) << 16) | ((u32)(d) << 24))
> > > +
> > > +/* RGB codes */
> > > +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
> > > +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
> > > +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
> > > +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
> > > +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
> > > +
> > > +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
> > > +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')
> > 
> > I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
> > formats, so why do we need the RGB/BGR32 variants? If the difference
> > is in the alpha channel, I'd like to document that fact in the name.
> > 
> > Could we call them ARGB, XRGB, XRGB1555 etc.?
> 
> Yeah, the fourcc naming isn't very good, I'd have no problem changing
> the names to something more descriptive for 24 and 32.  fourcc.org
> itself seems ambiguous about the 24 bit format

AFAICS fourcc.org only has three RGB fourccs; RGB2, RGBA and RGBT. None
of which specify anything about the bpp or component order. The only
thing they seem to specify is which components are present.

> > Also the channel and byte order should be documented clearly.

> Supposedly the fourcc code is supposed to provide that?

As I said the RGB fourccs don't seem to specify either of these.
The YUV fourccs generally seem to be specify the byte order. For
RGB you typically specify the component order within a pixel.
Also AYUV seems to follow the "RGB way", and I think generally
three byte 24 bpp RGB formats follow the "YUV way".

But videodev2.h lists big endian variants for 555 and 565 format, which
leads me to think they intended everything else to be little endian.
Of course I can't be sure because it's not clearly documented. What a mess!

Also reading videodev2.h leads me to think that they intended
RGB24/BGR24 to be three byte formats in reality. How I came to that
conclusion? Look at the comment about depth. It lists depth=16 for all
the 16bpp formats regardless of their actual depth. So I think they
meant to write bpp when they wrote depth.

> > And one other thing. I probably wouldn't call these fourccs
> > since they don't actually match the official fourccs. Not that
> > there is anything sensible defined for RGB formats in the
> > official list anyway. In fact, I'm not sure what we gain by
> > cooking our own fourccs when we know most of them won't match
> > the official list. AFAICS a simple running number would do
> > just as well as the format identifier.
> 
> They seem to match what's at fourcc.org, though I don't see the upper
> byte documented, and also share values with the v4l stuff, which I was
> assuming had the right fourcc codes.
> 
> If we don't match, we should strive to.  I'm just using what I find at
> fourcc.org and in the v4l code to check...

I'm fine with fourccs as long as the defines are named and documented
in way that avoids guesswork.

So what I'm thinking is something like this:

DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */

DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */

DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */

That leaves no room for guesswork.

-- 
Ville Syrj?l?
Intel OTC

[patch 2/2] drm: avoid switching to text console if there is no panic timeout

2011-11-15 Thread a...@linux-foundation.org

From: Hugh Dickins 
Subject: drm: avoid switching to text console if there is no panic timeout

Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
we're going to reboot immediately, the user will not be able to see the
messages anyway, and messing with the video mode may display artifacts,
and certainly get into several layers of complexity (including mutexes and
memory allocations) which we shall be much safer to avoid.

[msb at chromium.org: edited commit message and modified to short-circuit 
panic_timeout < 0 instead of testing panic_timeout >= 0]
Signed-off-by: Hugh Dickins 
Signed-off-by: Mandeep Singh Baines 
Cc: Dave Airlie 
Acked-by: David Rientjes 
Acked-by: St?phane Marchesin 
Cc: Dave Young 
Signed-off-by: Andrew Morton 
---

 drivers/gpu/drm/drm_fb_helper.c |7 +++
 1 file changed, 7 insertions(+)

diff -puN 
drivers/gpu/drm/drm_fb_helper.c~drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout
 drivers/gpu/drm/drm_fb_helper.c
--- 
a/drivers/gpu/drm/drm_fb_helper.c~drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout
+++ a/drivers/gpu/drm/drm_fb_helper.c
@@ -255,6 +255,13 @@ bool drm_fb_helper_force_kernel_mode(voi
 int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
void *panic_str)
 {
+   /*
+* It's a waste of time and effort to switch back to text console
+* if the kernel should reboot before panic messages can be seen.
+*/
+   if (panic_timeout < 0)
+   return 0;
+
printk(KERN_ERR "panic occurred, switching back to text console\n");
return drm_fb_helper_force_kernel_mode();
 }
_

[patch 1/2] drivers/gpu/vga/vgaarb.c: add missing kfree

2011-11-15 Thread a...@linux-foundation.org

From: Julia Lawall 
Subject: drivers/gpu/vga/vgaarb.c: add missing kfree

kbuf is a buffer that is local to this function, so all of the error paths
leaving the function should release it.

Signed-off-by: Julia Lawall 
Cc: Dave Airlie 
Cc: Jesper Juhl 
Signed-off-by: Andrew Morton 
---

 drivers/gpu/vga/vgaarb.c |   18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff -puN drivers/gpu/vga/vgaarb.c~drivers-gpu-vga-vgaarbc-add-missing-kfree 
drivers/gpu/vga/vgaarb.c
--- a/drivers/gpu/vga/vgaarb.c~drivers-gpu-vga-vgaarbc-add-missing-kfree
+++ a/drivers/gpu/vga/vgaarb.c
@@ -993,14 +993,20 @@ static ssize_t vga_arb_write(struct file
uc = >cards[i];
}

-   if (!uc)
-   return -EINVAL;
+   if (!uc) {
+   ret_val = -EINVAL;
+   goto done;
+   }

-   if (io_state & VGA_RSRC_LEGACY_IO && uc->io_cnt == 0)
-   return -EINVAL;
+   if (io_state & VGA_RSRC_LEGACY_IO && uc->io_cnt == 0) {
+   ret_val = -EINVAL;
+   goto done;
+   }

-   if (io_state & VGA_RSRC_LEGACY_MEM && uc->mem_cnt == 0)
-   return -EINVAL;
+   if (io_state & VGA_RSRC_LEGACY_MEM && uc->mem_cnt == 0) {
+   ret_val = -EINVAL;
+   goto done;
+   }

vga_put(pdev, io_state);

_

[PATCH] hugetlb: release pages in the error path of hugetlb_cow()

2011-11-15 Thread Hillf Danton

commit ea4039a34c4c206d015d34a49d0b00868e37db1d upstream.

If we fail to prepare an anon_vma, the {new, old}_page should be released,
or they will leak.

Signed-off-by: Hillf Danton 
Reviewed-by: Andrea Arcangeli 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
---
 mm/hugetlb.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bfcf153..2b57cd9 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2415,6 +2415,8 @@ retry_avoidcopy:
 * anon_vma prepared.
 */
if (unlikely(anon_vma_prepare(vma))) {
+   page_cache_release(new_page);
+   page_cache_release(old_page);
/* Caller expects lock to be held */
spin_lock(>page_table_lock);
return VM_FAULT_OOM;
-- 
1.7.7.3


-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic

Fwd: [PATCH] i915: Fix bug where screen brightness is not restored

2011-11-15 Thread Linus Torvalds

Email sent to wrong people/list,

Linus

-- Forwarded message --
From: Alex Davis 
Date: Tue, Nov 15, 2011 at 12:42 AM
Subject: [PATCH] i915: Fix bug where screen brightness is not restored
To: "linux-kernel at vger.kernel.org" ,
"torvalds at linux-foundation.org" 

From: Alex Davis

This patch fixes an issue where the screen would remain dark when

a key was pressed when the laptop lid was reopened or after the
laptop had gone into power-save mode.

It seems that there are a number of people with different machines
that have this problem:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
https://launchpad.net/~kamalmostafa/+archive/stuck-backlight
and https://bugs.freedesktop.org/show_bug.cgi?id=41926

This patch is against Linux 3.1

Putting printk's in ./drivers/gpu/drm/i915/intel_panel.c showed that
intel_get_brightness was being called after the panel was disabled,
which caused a 0 to be saved as the value to restore the brightness.
intel_panel_disable_backlight merely sets the brightness to 0. Commenting
out this call allows the correct brightness value to be saved.

Signed-off-by: Alex Davis 
Tested-by: Kamal Mostafa 
-
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..6f56676 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -262,8 +262,6 @@ void intel_panel_disable_backlight(struct drm_device *dev)
??? dev_priv->backlight_level = intel_panel_get_backlight(dev);
??? dev_priv->backlight_enabled = false;
??? }
-
-?? intel_panel_set_backlight(dev, 0);
?}

?void intel_panel_enable_backlight(struct drm_device *dev)

I code, therefore I am

RFC: Radeon multi ring support branch

On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
> Hello everybody,
> 
> to support multiple compute rings, async DMA engines and UVD we need
> to teach the radeon kernel module how to sync buffers between
> different rings and make some changes to the command submission
> ioctls.
> 
> Since we can't release any documentation about async DMA or UVD
> (yet), my current branch concentrates on getting the additional
> compute rings on cayman running. Unfortunately those rings have
> hardware bugs that can't be worked around, so they are actually not
> very useful in a production environment, but they should do quite
> well for this testing purpose.
> 
> The branch can be found here:
> http://cgit.freedesktop.org/~deathsimple/linux/log/
> 
> Since some of the patches are quite intrusive, constantly rebaseing
> them could get a bit painful. So I would like to see most of the
> stuff included into drm-next, even if we don't make use of the new
> functionality right now.
> 
> Comments welcome,
> Christian.

So i have been looking back at all this and now there is somethings
puzzling me. So if semaphore wait for a non null value at gpu address
provided in the packet than the current implementation for the cs
ioctl doesn't work when there is more than 2 rings to sync.

http://cgit.freedesktop.org/~deathsimple/linux/commit/?h=multi-ring-testing=bae372811c697a889ff0cf9128f52fe914d0fe1b

As it will use only one semaphore so first ring to finish will
mark the semaphore as done even if there is still other ring not
done.

This all make me wonder if some change to cs ioctl would make
all this better. So idea of semaphore is to wait for some other
ring to finish something. So let say we have following scenario:
Application submit following to ring1: csA, csB
Application now submit to ring2: cs1, cs2 
And application want csA to be done for cs1 and csB to be done
for cs2.

To achieve such usage pattern we would need to return fence seq
or similar from the cs ioctl. So user application would know
ringid+fence_seq for csA & csB and provide this when scheduling
cs1 & cs2. Here i am assuming MEM_WRITE/WAIT_REG_MEM packet
are as good as MEM_SEMAPHORE packet. Ie the semaphore packet
doesn't give us much more than MEM_WRITE/WAIT_REG_MEM would.

To achieve that each ring got it's fence scratch addr where to
write seq number. And then we use WAIT_REG_MEM on this addr
and with the specific seq for the other ring that needs
synchronization. This would simplify the semaphore code as
we wouldn't need somethings new beside helper function and
maybe extending the fence structure.

Anyway i put updating ring patch at :
http://people.freedesktop.org/~glisse/mrings/
It rebased on top of linus tree and it has several space
indentation fixes and also a fix for no semaphore allocated
issue (patch 5)

Cheers,
Jerome

radeon/kms: black screen when loading radeon with modeset=1

2011-11-15 Thread Alex Deucher

On Tue, Nov 15, 2011 at 2:05 PM, Sergey V.  wrote:
> Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b
>
> Loading radeon module with modeset=1 causes black screen.
>
> Usually it happens at boot time, but if run kernel with radeon.modeset=0 then
> `rmmod radeon; modprobe radeon modeset=1` I can get dmesg over ssh (thanks to
> glisse from #radeon for help).

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-November/016498.html

Alex

>
> Backtrace below:
>
> [ ? 89.905890] BUG: unable to handle kernel NULL pointer dereference at
> 0008
> [ ? 89.906016] IP: []
> radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
> [ ? 89.906016] PGD 6a0e1067 PUD 6a09d067 PMD 0
> [ ? 89.906016] Oops: 0002 [#1] SMP
> [ ? 89.906016] CPU 0
> [ ? 89.906016] Modules linked in: radeon(+) snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 btrfs
> cpufreq_ondemand powernow_k8 freq_table mperf lp ppdev parport_pc parport fuse
> snd_hda_codec_hdmi snd_hda_codec_realtek processor ttm drm_kms_helper drm
> thermal i2c_piix4 joydev agpgart video snd_hda_intel r8169 thermal_sys
> i2c_algo_bit i2c_core k8temp battery sdhci_pci snd_hda_codec evdev hwmon mii
> button ac shpchp sdhci snd_hwdep snd_pcm psmouse serio_raw mmc_core snd_timer
> sg snd soundcore snd_page_alloc [last unloaded: radeon]
> [ ? 89.906016]
> [ ? 89.906016] Pid: 2189, comm: modprobe Tainted: G ? ? ? ?W ? ?3.2.0-rc1+ #4
> Micro-Star International PR210/MS-1222
> [ ? 89.906016] RIP: 0010:[] ?[]
> radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
> [ ? 89.906016] RSP: 0018:880075959948 ?EFLAGS: 00010246
> [ ? 89.906016] RAX:  RBX: 880075b72000 RCX:
> 
> [ ? 89.906016] RDX:  RSI:  RDI:
> 880076c73c00
> [ ? 89.906016] RBP: 880075959a98 R08:  R09:
> 880076c73a00
> [ ? 89.906016] R10: 8800758a R11: 0006 R12:
> 8800758aadde
> [ ? 89.906016] R13: 8800758aadde R14:  R15:
> 
> [ ? 89.906016] FS: ?7f57d0b27720() GS:88007bc0()
> knlGS:f702a6d0
> [ ? 89.906016] CS: ?0010 DS:  ES:  CR0: 8005003b
> [ ? 89.906016] CR2: 0008 CR3: 6a0a6000 CR4:
> 06f0
> [ ? 89.906016] DR0:  DR1:  DR2:
> 
> [ ? 89.906016] DR3:  DR6: 0ff0 DR7:
> 0400
> [ ? 89.906016] Process modprobe (pid: 2189, threadinfo 880075958000, task
> 880075abc6d0)
> [ ? 89.906016] Stack:
> [ ? 89.906016] ?8800 8800768f400a 8800
> 00ff
> [ ? 89.906016] ?880037653663 880075b73158 880075b73174
> 000675959acf
> [ ? 89.906016] ?81b6112c 880075959a38 81b6112e
> 880075959ad5
> [ ? 89.906016] Call Trace:
> [ ? 89.906016] ?[] ? vsnprintf+0x31e/0x5d0
> [ ? 89.906016] ?[] ? vsnprintf+0x31e/0x5d0
> [ ? 89.906016] ?[] ? up+0x31/0x50
> [ ? 89.906016] ?[] ? console_unlock+0x1c4/0x230
> [ ? 89.906016] ?[]
> radeon_atombios_get_power_modes+0x228/0x8e0 [radeon]
> [ ? 89.906016] ?[] radeon_pm_init+0x3b1/0x590 [radeon]
> [ ? 89.906016] ?[] ? rs600_irq_set+0x109/0x180 [radeon]
> [ ? 89.906016] ?[] radeon_modeset_init+0x4c9/0x8a0 [radeon]
> [ ? 89.906016] ?[] ? radeon_acpi_init+0x8c/0xbc [radeon]
> [ ? 89.906016] ?[] radeon_driver_load_kms+0x120/0x170
> [radeon]
> [ ? 89.906016] ?[] drm_get_pci_dev+0x18e/0x2c0 [drm]
> [ ? 89.906016] ?[] radeon_pci_probe+0xad/0xb5 [radeon]
> [ ? 89.906016] ?[] local_pci_probe+0x5f/0xd0
> [ ? 89.906016] ?[] pci_device_probe+0x88/0xb0
> [ ? 89.906016] ?[] ? driver_sysfs_add+0x7a/0xb0
> [ ? 89.906016] ?[] driver_probe_device+0x96/0x1b0
> [ ? 89.906016] ?[] __driver_attach+0xa3/0xb0
> [ ? 89.906016] ?[] ? driver_probe_device+0x1b0/0x1b0
> [ ? 89.906016] ?[] bus_for_each_dev+0x5e/0x90
> [ ? 89.906016] ?[] driver_attach+0x1e/0x20
> [ ? 89.906016] ?[] bus_add_driver+0x155/0x280
> [ ? 89.906016] ?[] driver_register+0x76/0x140
> [ ? 89.906016] ?[] __pci_register_driver+0x55/0xd0
> [ ? 89.906016] ?[] drm_pci_init+0x111/0x120 [drm]
> [ ? 89.906016] ?[] ? 0xa0638fff
> [ ? 89.906016] ?[] ? 0xa0638fff
> [ ? 89.906016] ?[] radeon_init+0xec/0xee [radeon]
> [ ? 89.906016] ?[] do_one_initcall+0x44/0x170
> [ ? 89.906016] ?[] sys_init_module+0x92/0x1e0
> [ ? 89.906016] ?[] system_call_fastpath+0x16/0x1b
> [ ? 89.906016] Code: 16 44 3b b5 ec fe ff ff 0f 8d 40 01 00 00 48 8b 83 58 11
> 00 00 49 63 cf 48 89 ca 48 c1 e1 06 48 c1 e2 04 48 29 d1 48 8b 44 08 08 
> 40 08 00 00 00 00 0f b6 45 8f 3c 02 75 ac 4c 8b 83 58 11 00
> [ ? 89.906016] RIP ?[]
> radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
> [ ? 89.906016] ?RSP 
> [ ? 89.906016] CR2: 0008
> [ ? 89.918682] ---[ end trace 758728fd12807b58 ]---
>
> Whole dmesg output attached.
>
>

[PATCH 1/2] drm: add plane support v2

On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
> On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
> > Planes are a bit like half-CRTCs.  They have a location and fb, but
> > don't drive outputs directly.  Add support for handling them to the core
> > KMS code.
> Out of curiosity, lets say you have a *really* stupid hardware overlay
> that can't do scaling (or even, has limited scaling capabilities),
> should we provide some way to expose this to userspace?

I think yes. In fact I'd like drm_plane to replace drm_crtc as far as
scanout is concerned. That's how a lot of embedded hardware is laid
out already, and I think it's a lot cleaner approach than what we
have currently. Stuff like borders then become a simple matter or
positioning the "CRTC plane" within the larger active video area,
and panel fitters could be exposed through drm_plane scaling.

Se either we need to think ahead more with the GETPLANE ioctl
structure, or we could add a PLANE_CAPS ioctl later to expose
additional details about the hardware.

-- 
Ville Syrj?l?
Intel OTC

max PWM is zero

2011-11-15 Thread Marcos Paulo de Souza

Hi lkml,

I'm using the kernel 3.2-rc1 and I'm getting the following message in my 
dmesg:
fixme: max PWM is zero.

I don't remember if this message was here before...

I'm trying to verify what is causing this. I found this waring message in 
the drivers/gpu/drm/i915/intel_panel.c.

There is a comment above  this message, talking about put a code to query 
mode clock or hw clock to set the max PWM.

Bellow is my lspci.

I will be happy if you continue to cc me, and if you need any test, I'm 
able to do this.

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub (rev 09)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0a 
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at f800 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0
Memory at f840 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at 1820 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at 1840 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 19
I/O ports at 1860 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 (rev 03) (prog-if 20 [EHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 19
Memory at f8704000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci_hcd

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
Controller (rev 03)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at f870 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel
Kernel modules: snd-hda-intel

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 
(rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: f400-f5ff
Prefetchable memory behind bridge: f000-f1ff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Gammagraphx, Inc. (or missing ID) Device 

Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Root Complex Link
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 22:30:36 +0200
Ville Syrj?l?  wrote:

> On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
> > On Tue, 15 Nov 2011 14:57:02 +0200
> > Ville Syrj?l?  wrote:
> > > I'm fine with fourccs as long as the defines are named and documented
> > > in way that avoids guesswork.
> > > 
> > > So what I'm thinking is something like this:
> > > 
> > > DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
> > > DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
> > > DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
> > > DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
> > > DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
> > > 
> > > DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
> > > DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
> > > 
> > > DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
> > > DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
> > > DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
> > > DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
> > > 
> > > That leaves no room for guesswork.
> > 
> > Looks great.  Want to send Dave an incremental patch?  I'll apply the
> > final version to libdrm for use by userland code.
> 
> What I listed there doesn't match what v4l2 has. So I'm not sure what
> to put in a patch.
> 
> It looks like the v4l2 fourccs have explicit endianness (ie. LE or BE).
> If we follow that, and assuming people still want to use hardware byte
> swappers, it means user space needs some ifdefs to select the approriate
> format based on the host endianness. Or, we could do that in the header
> file itself, so we would provide three definitions for each format LE,
> BE, and NE (which would point to LE or BE depending on host endianness).
> 
> One extra issue I just realized is that the 8bpp and 16bpp v4l2 formats
> are in fact BGR nor RGB, that is the component order is such that blue
> occupies the most significant bit, red the lsb. I've never even seen
> a PC graphics card that supports such formats. Adding insult to injury
> PIX_FMT_RGB444 is defined the opposite way, ie. matching what most
> graphics cards would expect.

Heh, well you can just pick whatever makes sense then for RGB, and
remove the _FOURCC_ strings to make it clear we're using sane RGB
definitions and not some half-specified fourcc stuff.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2015/806f9103/attachment.pgp>

[PATCH 1/2] drm: add plane support v2

2011-11-15 Thread Ben Skeggs

On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
> Planes are a bit like half-CRTCs.  They have a location and fb, but
> don't drive outputs directly.  Add support for handling them to the core
> KMS code.
Out of curiosity, lets say you have a *really* stupid hardware overlay
that can't do scaling (or even, has limited scaling capabilities),
should we provide some way to expose this to userspace?

I've recently looked at the hardware overlay on recent NVIDIA GPUs with
the intention of implementing this API in nouveau.  However, while there
is indeed an overlay, it only accepts a couple of RGB formats and does
simple clipping - and *no* scaling that I've found so far.

[PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

2011-11-15 Thread Andy Furniss

Christian Schmidt wrote:

Tested with all three applied and they work well on my TV all modes 
work, which was not the case previously if I added manually the modes 
listed in xorg log (I have three bogus/not working modes logged by xorg).

I do have a small problem with the interlaced modes - I assumed this was 
a radeon driver issue (the audio part obviously is - but the top line 
part is independent of audio)

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

I mention it just in case there is some link to the cae spec interlaced 
timings interpretation/implementation.

[PATCH] drm/fb: don't call driver set_config if display isn't panned

This is just a minor optimization to the fb panning code.  In debugging
some other issues, I noticed a lot of no-op calls to the set_config
routine with all the same parameters and tracked down the source to the
fb helper pan routine.

So add an additional check for actual panning relative to the current
crtc config to avoid unnecessary set_config calls.

Signed-off-by: Jesse Barnes 

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..4dd81f3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -739,7 +739,8 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
modeset->x = var->xoffset;
modeset->y = var->yoffset;

-   if (modeset->num_connectors) {
+   if (((modeset->x != crtc->x) || (modeset->y != crtc->y)) &&
+   modeset->num_connectors) {
ret = crtc->funcs->set_config(modeset);
if (!ret) {
info->var.xoffset = var->xoffset;
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2015/5a94b364/attachment.pgp>

DRM KMS Modesetting

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes  
wrote:
> On Mon, 14 Nov 2011 21:47:09 +0100
> David Herrmann  wrote:
>> > I had to modify the resolution the test was searching for
>> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
>> > monitor, and fix the connector id, but other than that it seemed to
>> > work fine.
>>
>> Thanks for testing. At least my code seems right now, but I still
>> cannot get it to work on my machine. The output of modetest is:
>> https://gist.github.com/1365083
>>
>> There is only one connected connector+encoder+mode so I don't know
>> where the problem exactly is. Are there any debug options? Is it
>> possible to query the EGLImage for width/height?
>
> Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
> width/stride correctly somewhere then. ?You'd have to walk through the
> gbm_dri2.c and egl_dri2.c code and see where the width is going off
> into the weeds.

Could be, I know I've run Wayland on Pineview though, so that works at
least.  David, did you try eglkms from mesa demos?

http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

Kristian

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 14:57:02 +0200
Ville Syrj?l?  wrote:
> I'm fine with fourccs as long as the defines are named and documented
> in way that avoids guesswork.
> 
> So what I'm thinking is something like this:
> 
> DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
> DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
> DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
> DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
> DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
> 
> DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
> DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
> 
> DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
> DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
> DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
> DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
> 
> That leaves no room for guesswork.

Looks great.  Want to send Dave an incremental patch?  I'll apply the
final version to libdrm for use by userland code.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2015/5b63f1b5/attachment.pgp>

[PATCH 1/2] drm: add plane support v2

On Tue, 15 Nov 2011 13:42:40 +0200
Ville Syrj?l?  wrote:

> On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
> > On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
> > > Planes are a bit like half-CRTCs.  They have a location and fb, but
> > > don't drive outputs directly.  Add support for handling them to the core
> > > KMS code.
> > Out of curiosity, lets say you have a *really* stupid hardware overlay
> > that can't do scaling (or even, has limited scaling capabilities),
> > should we provide some way to expose this to userspace?
> 
> I think yes. In fact I'd like drm_plane to replace drm_crtc as far as
> scanout is concerned. That's how a lot of embedded hardware is laid
> out already, and I think it's a lot cleaner approach than what we
> have currently. Stuff like borders then become a simple matter or
> positioning the "CRTC plane" within the larger active video area,
> and panel fitters could be exposed through drm_plane scaling.
> 
> Se either we need to think ahead more with the GETPLANE ioctl
> structure, or we could add a PLANE_CAPS ioctl later to expose
> additional details about the hardware.

There are going to be all sorts of device specific bits we can expose
with driver ioctls too (e.g. the alpha blend with restrictions on Intel
stuff).

But overall, yes you can definitely support overlays w/o scalers with
these interfaces.  We could add a plane property to expose the scaling
factors supported if that helps, otherwise you could just return
-ENOSUPP for any configuration where the crtc size and source size
don't match.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2015/1e3bf73e/attachment-0001.pgp>

[PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

> "CS" == Christian Schmidt  writes:

CS> The current logic misunderstands the spec about CEA 18byte descriptors.
CS> First, the spec doesn't state "detailed timing descriptors" but "18 byte
CS> descriptors", so any data record could be stored, mixed timings and
CS> other data, just as in the standard EDID.
CS> Second, the lower four bit of byte 3 of the CEA record do not contain
CS> the number of descriptors, but "the total number of DTDs defining native
CS> formats in the whole EDID [...], starting with the first DTD in the DTD
CS> list (which starts in the base EDID block)." A device can of course
CS> support non-native formats.

CS> As such the number can't be used to determine n, and the existing code
CS> will filter non-timing 18byte descriptors anyway.

CS> V2 removes an unused variable warning.

CS> Signed-off-by: Christian Schmidt 

Tested-by: James Cloos 

Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


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

[PATCH] drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on

> "CS" == Christian Schmidt  writes:

CS> CEA datablocks are only defined from revision 3 onwards. Only check for
CS> them if the revision says so.

CS> Signed-of-by: Christian Schmidt 

Tested-by: James Cloos 

Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

[PATCH] drm_edid: support CEA video modes

> "CS" == Christian Schmidt  writes:

CS> TFT/plasma televisions and projectors have become commonplace, and so
CS> has the use of PCs to drive them. Add the video modes specified by an
CS> EDID's CEA extension to the mode database for a connector.

CS> Signed-off-by: Christian Schmidt 

Tested-by: James Cloos 

Works fine here on top of Linus? 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

The new modes not previously seen, as reported by libdrm?s modetest are:

:; diff -U0 a/mt.out b/mt.out
--- a/mt.out2011-11-14 17:25:21.785708725 -0500
+++ b/mt.out2011-11-14 18:41:22.023562219 -0500
@@ -11 +11 @@
-15 14  connected   HDMI-A  820x460 17  14
+15 14  connected   HDMI-A  820x460 22  14
@@ -15 +15,2 @@
-  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125
+  1920x1080 60 1920 2008 2052 2200 1080 1084 1094 1125
+  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125
@@ -19,0 +21 @@
+  1280x720 60 1280 1390 1430 1650 720 725 730 750
@@ -22,0 +25 @@
+  1440x480 60 1440 1478 1602 1716 480 488 494 525
@@ -26,0 +30 @@
+  720x480 60 720 736 798 858 480 489 495 525
@@ -29,0 +34 @@
+  640x480 60 640 656 752 800 480 490 492 525
@@ -41,2 +46,2 @@
-10 35  (0,0)   (0x0)
-   0 1920 2008 2052 2200 1080 1084 1089 1125
+10 19  (0,0)   (0x0)
+  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125


-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

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

--- Comment #62 from Rafael ?vila de Esp?ndola  
2011-11-14 19:54:15 PST ---
Created attachment 53564
  --> https://bugs.freedesktop.org/attachment.cgi?id=53564
dmesg with linus tree (7f80850d3f9fd8fda23a317044aef3a6bafab06b)

Got the same problem with linus tree and KMS. dmesg attached, let me know if
there is anything I should try.

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

No subject

2011-11-15 Thread

some other method before passing the frame off to the overlay.

Rather disappointing, and seemingly not of too much use.  But, I'd like
to expose what functionality there is in any case.

Ben.

> 
> v2: fix ABI of get_plane - move format_type_ptr to the end
> 
> Acked-by: Alan Cox 
> Reviewed-by: Rob Clark 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/drm_crtc.c |  257 
> +++-
>  drivers/gpu/drm/drm_drv.c  |3 +
>  include/drm/drm.h  |3 +
>  include/drm/drm_crtc.h |   75 +-
>  include/drm/drm_mode.h |   33 ++
>  5 files changed, 368 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fe738f0..804ef12 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
>   struct drm_device *dev = fb->dev;
>   struct drm_crtc *crtc;
> + struct drm_plane *plane;
>   struct drm_mode_set set;
>   int ret;
>  
> @@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>   }
>   }
>  
> + list_for_each_entry(plane, >mode_config.plane_list, head) {
> + if (plane->fb == fb) {
> + /* should turn off the crtc */
> + ret = plane->funcs->disable_plane(plane);
> + if (ret)
> + DRM_ERROR("failed to disable plane with busy 
> fb\n");
> + }
> + }
> +
>   drm_mode_object_put(dev, >base);
>   list_del(>head);
>   dev->mode_config.num_fb--;
> @@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
>  
> +int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> +unsigned long possible_crtcs,
> +const struct drm_plane_funcs *funcs,
> +uint32_t *formats, uint32_t format_count)
> +{
> + mutex_lock(>mode_config.mutex);
> +
> + plane->dev = dev;
> + drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
> + plane->funcs = funcs;
> + plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> +   GFP_KERNEL);
> + if (!plane->format_types) {
> + DRM_DEBUG_KMS("out of memory when allocating plane\n");
> + drm_mode_object_put(dev, >base);
> + return -ENOMEM;
> + }
> +
> + memcpy(plane->format_types, formats, format_count);
> + plane->format_count = format_count;
> + plane->possible_crtcs = possible_crtcs;
> +
> + list_add_tail(>head, >mode_config.plane_list);
> + dev->mode_config.num_plane++;
> +
> + mutex_unlock(>mode_config.mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_init);
> +
> +void drm_plane_cleanup(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + mutex_lock(>mode_config.mutex);
> + kfree(plane->format_types);
> + drm_mode_object_put(dev, >base);
> + list_del(>head);
> + dev->mode_config.num_plane--;
> + mutex_unlock(>mode_config.mutex);
> +}
> +EXPORT_SYMBOL(drm_plane_cleanup);
> +
>  /**
>   * drm_mode_create - create a new display mode
>   * @dev: DRM device
> @@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
>   INIT_LIST_HEAD(>mode_config.encoder_list);
>   INIT_LIST_HEAD(>mode_config.property_list);
>   INIT_LIST_HEAD(>mode_config.property_blob_list);
> + INIT_LIST_HEAD(>mode_config.plane_list);
>   idr_init(>mode_config.crtc_idr);
>  
>   mutex_lock(>mode_config.mutex);
> @@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   struct drm_encoder *encoder, *enct;
>   struct drm_framebuffer *fb, *fbt;
>   struct drm_property *property, *pt;
> + struct drm_plane *plane, *plt;
>  
>   list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
>head) {
> @@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   crtc->funcs->destroy(crtc);
>   }
>  
> + list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
> +  head) {
> + plane->funcs->destroy(plane);
> + }
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>  
> @@ -1466,6 +1526,197 @@ out:
>  }
>  
>  /**
> + * drm_mode_getplane_res - get plane info
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
> + *
> + * Return an plane count and set of IDs.
> + */
> +int drm_mode_getplane_res(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_get_plane_res *plane_resp = data;
> + struct drm_mode_config *config;
> + struct drm_plane *plane;
> + uint32_t __user *plane_ptr;
> + int copied =

[PATCH] drm_edid: support CEA video modes

2011-11-15 Thread alanwww1

sync (37.5 kHz)
[   324.852] (II) intel(0): Modeline "1280x720"x60.0   74.25  1280
1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz)
[   324.852] (II) intel(0): Modeline "1440x576"x50.0   54.00  1440
1464 1592 1728  576 581 586 625 -hsync -vsync (31.2 kHz)
[   324.852] (II) intel(0): Modeline "1440x480"x59.9   54.00  1440
1472 1596 1716  480 489 495 525 -hsync -vsync (31.5 kHz)
[   324.852] (II) intel(0): Modeline "720x576"x50.0   27.00  720 732
796 864  576 581 586 625 -hsync -vsync (31.2 kHz)
[   324.852] (II) intel(0): Modeline "720x480"x59.9   27.00  720 736
798 858  480 489 495 525 -hsync -vsync (31.5 kHz)
[   324.852] (II) intel(0): Modeline "640x480"x60.0   25.20  640 656
752 800  480 490 492 525 -hsync -vsync (31.5 kHz)


Full logs:

- Stock Kernel 3.2 RC1:
dmesg: http://paste.ubuntu.com/738790/
xorg.log: http://paste.ubuntu.com/738784/

- Patched with the CEA patch:
dmesg: http://paste.ubuntu.com/738786/
xorg.log: http://paste.ubuntu.com/738775/

Thanks for the great work!!!  Would be awesome if somehow this could sneak
into the final 3.2. If not, users won't be using this unti Ubuntu 12.11 !
In one year.

Just as a sidenote: There is fully Xorg issue I think. Independently from
this patch. Xorg makes some strange DDC cheked modelines, where the
modeline is correct, but it does not contain the refresh rate, It is just
zeroed out. Is it normal ?

[13.456] (II) Quirked EDID physical size to 0x0 cm
[13.456] (II) intel(0): EDID vendor "ONK", prod id 2147
[13.456] (II) intel(0): Using hsync ranges from config file
[13.456] (II) intel(0): Using vrefresh ranges from config file
[13.456] (II) intel(0): Printing DDC gathered Modelines:
[13.456] (II) intel(0): Modeline "1920x1080"x0.0  148.50  1920
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[13.456] (II) intel(0): Modeline "1280x720"x0.0   74.25  1280 1390
1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz)
[13.456] (II) intel(0): Modeline "1280x720"x0.0   74.25  1280 1720
1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz)
[13.456] (II) intel(0): Modeline "1920x1080i"x0.0   74.25  1920
2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz)
[13.456] (II) intel(0): Modeline "1920x1080i"x0.0   74.25  1920
2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz)
[13.456] (II) intel(0): Modeline "640x480"x0.0   25.18  640 656
752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[13.456] (II) intel(0): Modeline "720x576"x0.0   27.00  720 732
796 864  576 581 586 625 -hsync -vsync (31.2 kHz)
[13.456] (II) intel(0): Modeline "1920x1080"x0.0   74.25  1920
2558 2602 2750  1080 1084 1089 1125 +hsync +vsync (27.0 kHz)
[13.456] (II) intel(0): Modeline "1440x480i"x0.0   27.00  1440
1478 1602 1716  480 488 494 525 interlace -hsync -vsync (15.7 kHz)
[13.456] (II) intel(0): Modeline "1440x576i"x0.0   27.00  1440
1464 1590 1728  576 580 586 625 interlace -hsync -vsync (15.6 kHz)
[13.456] (II) intel(0): Modeline "1920x1080"x0.0   74.25  1920
2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (28.1 kHz)
[13.456] (II) intel(0): Modeline "1920x1080"x0.0   74.25  1920
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (33.8 kHz)
[13.456] (II) intel(0): Modeline "2880x480"x0.0  108.00  2880 2944
3192 3432  480 489 495 525 -hsync -vsync (31.5 kHz)
[13.456] (II) intel(0): Modeline "1920x1080"x0.0  148.50  1920
2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz)
[13.456] (II) intel(0): Modeline "2880x576"x0.0  108.00  2880 2928
3184 3456  576 581 586 625 -hsync -vsync (31.2 kHz)
[13.456] (II) intel(0): Modeline "1920x1080i"x0.0   72.00  1920
1952 2120 2304  1080 1126 1136 1250 interlace +hsync -vsync (31.2 kHz)



2011/11/14 Adam Jackson 

> On Sun, 2011-11-13 at 01:31 +0100, Christian Schmidt wrote:
> > TFT/plasma televisions and projectors have become commonplace, and so
> > has the use of PCs to drive them. Add the video modes specified by an
> > EDID's CEA extension to the mode database for a connector.
>
> Thanks for finishing this up.  The mode list was indeed mechanically
> generated (pdf2text on the spec and then some python to bash it all
> together).  It's probably worth noting in the comment that it's from
> CEA-861-D, as I suspect subsequent revisions have added more timings (I
> haven't bought it yet to check).
>
> Reviewed-by: Adam Jackson 
>
> - ajax
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2015/9b383d54/attachment.htm>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
> On Mon, 14 Nov 2011 23:24:55 +0200
> Ville Syrj?l?  wrote:
> 
> > On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > > +struct drm_mode_fb_cmd2 {
> > > + __u32 fb_id;
> > > + __u32 width, height;
> > > + __u32 pixel_format; /* fourcc code from videodev2.h */
> > > +
> > > + /*
> > > +  * In case of planar formats, this ioctl allows up to 4
> > > +  * buffer objects with offets and pitches per plane.
> > > +  * The pitch and offset order is dictated by the fourcc,
> > > +  * e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
> > > +  *
> > > +  *   YUV 4:2:0 image with a plane of 8 bit Y samples
> > > +  *   followed by an interleaved U/V plane containing
> > > +  *   8 bit 2x2 subsampled colour difference samples.
> > > +  *
> > > +  * So it would consist of Y as offset[0] and UV as
> > > +  * offeset[1].  Note that offset[0] will generally
> > > +  * be 0.
> > > +  */
> > > + __u32 handles[4];
> > > + __u32 pitches[4]; /* pitch for each plane */
> > > + __u32 offsets[4]; /* offset of each plane */
> > > +};
> > 
> > Hey, what about those interlaced buffers? We talked privately about
> > adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
> > drm_mode_set_plane.
> > 
> > We could stick something like these to those flags:
> > fb_cmd2.flags:
> > #define DRM_MODE_FB_INTERLACED 0x1
> > 
> > set_plane.flags:
> > #define DRM_MODE_PRESENT_TOP_FIELD 0x1
> > #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
> 
> Oh sorry I lost track of the internal discussion.
> 
> Are those attributes of the fb or of each object?  E.g. could you mix
> interlaced and non-interlaced buffers in a planar format?

I suppose it might be possible that you'd want to treat luma as
interlaced and chroma as progressive under some circumstances.
But I can't see why simply defining another flag for that wouldn't
be enough.

> Maybe I need to rename this ioctl to addfb_swissarmyknife :)

Now I'm just waiting for someone to jump in and say that they 
want independent buffers for each interlaced field :)

Me? I'll be happy with just those two flags members... for now at least ;)

-- 
Ville Syrj?l?
Intel OTC

[Bug 34969] [nouveau] Card lockup on openarena

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

--- Comment #19 from Andrew Randrianasulu  2011-11-14 
16:36:06 PST ---
Created attachment 53562
  --> https://bugs.freedesktop.org/attachment.cgi?id=53562
hand-typed "log"

While trying some self-made liveCD based on slackware-current, I found
Slackware's Mesa works fine for both Celestia, and Q3 timedemo demo002.
Slackware currently uses Mesa 7.10.2/libdrm 2.4.24/ and some nouveau DDX from
march, 2011. I've compiled 7.11 branch , and discovered it hang videocard like
7.12 does on my main system. Then I just set good commit at last one from Luca.
And even if i keep all other components the same
(libdrm-2.4.27/xf86-video-nouveau few comments behind git/kernel 3.2.0-rc1
mainline) freeze go on and off with just mesa versions.My bisect compilation
was without any llvm stuff (normal compilation has llvm 2.9). nice mistery, and
thanfully  whole machine not locked up hard, only videocard, it seems.

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

[Bug 34969] [nouveau] Card lockup on openarena

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

--- Comment #18 from Andrew Randrianasulu  2011-11-14 
16:06:19 PST ---
(In reply to comment #17)
> (In reply to comment #16)
> > So, I bisected mesa tree (7.11 branch)
> > 
> > Result:
> > 
> > 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
> > commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
> > Author: Marek Olk 
> > Date:   Sun Dec 26 04:30:51 2010 +0100
> > 
> > st/mesa: set vertex arrays state only when necessary
> 
> I guess the bisection failed in this case, because that commit contains a bug
> that was fixed later.

gallium: notify drivers about possible changes in user buffer contents ? It was
well-masked for Q3 arena until extension sorting exposed it there, but I run my
./vertexrate (reduced) test, and you can see whole bisect log... May be nvfx
played too much with mesa/gallium internals.

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

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

 CS == Christian Schmidt schm...@digadd.de writes:

CS The current logic misunderstands the spec about CEA 18byte descriptors.
CS First, the spec doesn't state detailed timing descriptors but 18 byte
CS descriptors, so any data record could be stored, mixed timings and
CS other data, just as in the standard EDID.
CS Second, the lower four bit of byte 3 of the CEA record do not contain
CS the number of descriptors, but the total number of DTDs defining native
CS formats in the whole EDID [...], starting with the first DTD in the DTD
CS list (which starts in the base EDID block). A device can of course
CS support non-native formats.

CS As such the number can't be used to determine n, and the existing code
CS will filter non-timing 18byte descriptors anyway.

CS V2 removes an unused variable warning.

CS Signed-off-by: Christian Schmidt schmidt@digadd,de

Tested-by: James Cloos cl...@jhcloos.com

Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


CS ___
CS dri-devel mailing list
CS dri-devel@lists.freedesktop.org
CS 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] drm_edid_to_eld: check for CEA data blocks only from structure revision 3 on

 CS == Christian Schmidt schm...@digadd.de writes:

CS CEA datablocks are only defined from revision 3 onwards. Only check for
CS them if the revision says so.

CS Signed-of-by: Christian Schmidt schm...@digadd.de

Tested-by: James Cloos cl...@jhcloos.com

Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_edid: support CEA video modes

 CS == Christian Schmidt schm...@digadd.de writes:

CS TFT/plasma televisions and projectors have become commonplace, and so
CS has the use of PCs to drive them. Add the video modes specified by an
CS EDID's CEA extension to the mode database for a connector.

CS Signed-off-by: Christian Schmidt schm...@digadd.de

Tested-by: James Cloos cl...@jhcloos.com

Works fine here on top of Linus’ 7f80850d3f9f with a Radeon HD 4290 and
an hdmi-connected tv.

The new modes not previously seen, as reported by libdrm’s modetest are:

:; diff -U0 a/mt.out b/mt.out
--- a/mt.out2011-11-14 17:25:21.785708725 -0500
+++ b/mt.out2011-11-14 18:41:22.023562219 -0500
@@ -11 +11 @@
-15 14  connected   HDMI-A  820x460 17  14
+15 14  connected   HDMI-A  820x460 22  14
@@ -15 +15,2 @@
-  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125
+  1920x1080 60 1920 2008 2052 2200 1080 1084 1094 1125
+  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125
@@ -19,0 +21 @@
+  1280x720 60 1280 1390 1430 1650 720 725 730 750
@@ -22,0 +25 @@
+  1440x480 60 1440 1478 1602 1716 480 488 494 525
@@ -26,0 +30 @@
+  720x480 60 720 736 798 858 480 489 495 525
@@ -29,0 +34 @@
+  640x480 60 640 656 752 800 480 490 492 525
@@ -41,2 +46,2 @@
-10 35  (0,0)   (0x0)
-   0 1920 2008 2052 2200 1080 1084 1089 1125
+10 19  (0,0)   (0x0)
+  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125


-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

DRM KMS Modesetting

Hi

I thought it's better to ask this question here again as it is easier
to comment via mail.

I tried writing a simple kms modesetting program. I have written it similar to:
http://virtuousgeek.org/blog/index.php/jbarnes?blog=2title=writing_stanalone_programs_with_egl_and_
and wayland compositor-drm.c
and modetest.c in libdrm/tests

My problem is, the program compiles and runs fine, however, the
framebuffer is only displayed on the left quarter of the screen. The
vertical size is perfect but the horizontal size is just the left
quarter. I've double checked all the drm parameters and they are equal
to the ones in modetest.c and compositor-drm.c.

./modetest runs fine and also reports only a single mode and encoder
for my connector so I cannot choose the wrong mode, either.

The code is here:
https://gist.github.com/1364994
It should compile fine with:
gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`

I would be glad if someone could run this or look over the code.

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

Re: DRM KMS Modesetting

On Mon, Nov 14, 2011 at 9:38 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 14 Nov 2011 21:25:56 +0100
David Herrmann dh.herrm...@googlemail.com wrote:

I thought it's better to ask this question here again as it is easier
to comment via mail.

I tried writing a simple kms modesetting program. I have written it similar
to:
http://virtuousgeek.org/blog/index.php/jbarnes?blog=2title=writing_stanalone_programs_with_egl_and_
and wayland compositor-drm.c
and modetest.c in libdrm/tests

My problem is, the program compiles and runs fine, however, the
framebuffer is only displayed on the left quarter of the screen. The
vertical size is perfect but the horizontal size is just the left
quarter. I've double checked all the drm parameters and they are equal
to the ones in modetest.c and compositor-drm.c.

./modetest runs fine and also reports only a single mode and encoder
for my connector so I cannot choose the wrong mode, either.

The code is here:
https://gist.github.com/1364994
It should compile fine with:
gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`

I would be glad if someone could run this or look over the code.

Hm I get a full white screen with a gray triangle in the lower right
hand corner.

Yes, thats what should be displayed.

I had to modify the resolution the test was searching for
to 1920x1200 instead of 1024x600 since I tested on a DP attached
monitor, and fix the connector id, but other than that it seemed to
work fine.

Thanks for testing. At least my code seems right now, but I still
cannot get it to work on my machine. The output of modetest is:
https://gist.github.com/1365083

There is only one connected connector+encoder+mode so I don't know
where the problem exactly is. Are there any debug options? Is it
possible to query the EGLImage for width/height?

--
Jesse Barnes, Intel Open Source Technology Center

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

Re: [PATCH 1/2] drm: add plane support v2

On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
 On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
  Planes are a bit like half-CRTCs.  They have a location and fb, but
  don't drive outputs directly.  Add support for handling them to the core
  KMS code.
 Out of curiosity, lets say you have a *really* stupid hardware overlay
 that can't do scaling (or even, has limited scaling capabilities),
 should we provide some way to expose this to userspace?

I think yes. In fact I'd like drm_plane to replace drm_crtc as far as
scanout is concerned. That's how a lot of embedded hardware is laid
out already, and I think it's a lot cleaner approach than what we
have currently. Stuff like borders then become a simple matter or
positioning the CRTC plane within the larger active video area,
and panel fitters could be exposed through drm_plane scaling.

Se either we need to think ahead more with the GETPLANE ioctl
structure, or we could add a PLANE_CAPS ioctl later to expose
additional details about the hardware.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 01:22:10PM -0800, Jesse Barnes wrote:
 On Mon, 14 Nov 2011 23:16:44 +0200
 Ville Syrjälä ville.syrj...@linux.intel.com wrote:
 
  On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
   +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b)  8) | \
   +   ((u32)(c)  16) | ((u32)(d)  24))
   +
   +/* RGB codes */
   +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
   +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
   +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
   +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
   +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
   +
   +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
   +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')
  
  I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
  formats, so why do we need the RGB/BGR32 variants? If the difference
  is in the alpha channel, I'd like to document that fact in the name.
  
  Could we call them ARGB, XRGB, XRGB1555 etc.?
 
 Yeah, the fourcc naming isn't very good, I'd have no problem changing
 the names to something more descriptive for 24 and 32.  fourcc.org
 itself seems ambiguous about the 24 bit format

AFAICS fourcc.org only has three RGB fourccs; RGB2, RGBA and RGBT. None
of which specify anything about the bpp or component order. The only
thing they seem to specify is which components are present.

  Also the channel and byte order should be documented clearly.
 
 Supposedly the fourcc code is supposed to provide that?

As I said the RGB fourccs don't seem to specify either of these.
The YUV fourccs generally seem to be specify the byte order. For
RGB you typically specify the component order within a pixel.
Also AYUV seems to follow the RGB way, and I think generally
three byte 24 bpp RGB formats follow the YUV way.

But videodev2.h lists big endian variants for 555 and 565 format, which
leads me to think they intended everything else to be little endian.
Of course I can't be sure because it's not clearly documented. What a mess!

Also reading videodev2.h leads me to think that they intended
RGB24/BGR24 to be three byte formats in reality. How I came to that
conclusion? Look at the comment about depth. It lists depth=16 for all
the 16bpp formats regardless of their actual depth. So I think they
meant to write bpp when they wrote depth.

  And one other thing. I probably wouldn't call these fourccs
  since they don't actually match the official fourccs. Not that
  there is anything sensible defined for RGB formats in the
  official list anyway. In fact, I'm not sure what we gain by
  cooking our own fourccs when we know most of them won't match
  the official list. AFAICS a simple running number would do
  just as well as the format identifier.
 
 They seem to match what's at fourcc.org, though I don't see the upper
 byte documented, and also share values with the v4l stuff, which I was
 assuming had the right fourcc codes.
 
 If we don't match, we should strive to.  I'm just using what I find at
 fourcc.org and in the v4l code to check...

I'm fine with fourccs as long as the defines are named and documented
in way that avoids guesswork.

So what I'm thinking is something like this:

DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */

DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */

DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */

That leaves no room for guesswork.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

2011-11-15 Thread Andy Furniss


Christian Schmidt wrote:

Tested with all three applied and they work well on my TV all modes 
work, which was not the case previously if I added manually the modes 
listed in xorg log (I have three bogus/not working modes logged by xorg).


I do have a small problem with the interlaced modes - I assumed this was 
a radeon driver issue (the audio part obviously is - but the top line 
part is independent of audio)


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

I mention it just in case there is some link to the cae spec interlaced 
timings interpretation/implementation.

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

Re: DRM KMS Modesetting

On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Mon, 14 Nov 2011 21:47:09 +0100
 David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

 Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
 width/stride correctly somewhere then.  You'd have to walk through the
 gbm_dri2.c and egl_dri2.c code and see where the width is going off
 into the weeds.

Could be, I know I've run Wayland on Pineview though, so that works at
least.  David, did you try eglkms from mesa demos?

http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

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

Re: [PATCH 1/2] drm: add plane support v2

On Tue, 15 Nov 2011 13:42:40 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
  On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
   Planes are a bit like half-CRTCs.  They have a location and fb, but
   don't drive outputs directly.  Add support for handling them to the core
   KMS code.
  Out of curiosity, lets say you have a *really* stupid hardware overlay
  that can't do scaling (or even, has limited scaling capabilities),
  should we provide some way to expose this to userspace?
 
 I think yes. In fact I'd like drm_plane to replace drm_crtc as far as
 scanout is concerned. That's how a lot of embedded hardware is laid
 out already, and I think it's a lot cleaner approach than what we
 have currently. Stuff like borders then become a simple matter or
 positioning the CRTC plane within the larger active video area,
 and panel fitters could be exposed through drm_plane scaling.
 
 Se either we need to think ahead more with the GETPLANE ioctl
 structure, or we could add a PLANE_CAPS ioctl later to expose
 additional details about the hardware.

There are going to be all sorts of device specific bits we can expose
with driver ioctls too (e.g. the alpha blend with restrictions on Intel
stuff).

But overall, yes you can definitely support overlays w/o scalers with
these interfaces.  We could add a plane property to expose the scaling
factors supported if that helps, otherwise you could just return
-ENOSUPP for any configuration where the crtc size and source size
don't match.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 14:57:02 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
 I'm fine with fourccs as long as the defines are named and documented
 in way that avoids guesswork.
 
 So what I'm thinking is something like this:
 
 DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
 DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
 DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
 DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
 DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
 
 DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
 DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
 
 DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
 DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
 DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
 DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
 
 That leaves no room for guesswork.

Looks great.  Want to send Dave an incremental patch?  I'll apply the
final version to libdrm for use by userland code.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


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

[Bug 42908] r600g: glx-shader-sharing causes segfault

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

Kai deb...@carbon-project.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #1 from Kai deb...@carbon-project.org 2011-11-15 08:31:35 PST ---
Sorry for the noise, seems appending -auto to the invocation fixes this.

-- 
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

max PWM is zero

2011-11-15 Thread Marcos Paulo de Souza


Hi lkml,

I'm using the kernel 3.2-rc1 and I'm getting the following message in my 
dmesg:

fixme: max PWM is zero.

I don't remember if this message was here before...

I'm trying to verify what is causing this. I found this waring message in 
the drivers/gpu/drm/i915/intel_panel.c.


There is a comment above  this message, talking about put a code to query 
mode clock or hw clock to set the max PWM.


Bellow is my lspci.

I will be happy if you continue to cc me, and if you need any test, I'm 
able to do this.


00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub (rev 09)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0a ?
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0, IRQ 44
Memory at f800 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 09)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0
Memory at f840 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at 1820 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at 1840 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 (rev 03) (prog-if 00 [UHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 19
I/O ports at 1860 [size=32]
Capabilities: [50] PCI Advanced Features
Kernel driver in use: uhci_hcd

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 (rev 03) (prog-if 20 [EHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, medium devsel, latency 0, IRQ 19
Memory at f8704000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci_hcd

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
Controller (rev 03)
Subsystem: FIRST INTERNATIONAL Computer Inc Device 3009
Flags: bus master, fast devsel, latency 0, IRQ 43
Memory at f870 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [130] Root Complex Link
Kernel driver in use: snd_hda_intel
Kernel modules: snd-hda-intel

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 
(rev 03) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: f400-f5ff
Prefetchable memory behind bridge: f000-f1ff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Gammagraphx, Inc. (or missing ID) Device 

Capabilities: [a0] Power Management version 2
Capabilities: [100] Virtual Channel
Capabilities: [180] Root Complex Link
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.5 PCI bridge: Intel

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #1 from Kai deb...@carbon-project.org 2011-11-15 08:38:49 PST ---
Todays run showed one difference in what was reported by Piglit:
 Probe at (0,0)
   Expected: 0.00 1.00 0.00 0.00
   Observed: 0.00 0.00 0.00 1.00
 PIGLIT: {'result': 'fail' }
apart from that, the screen is still corrupted (a KDM restart fixes the screen
again; also non-X TTYs aren't affected either).

Used stack:
Mesa: Git/9d4d9d34
libdrm: 2.4.27-1
Kernel: 3.1.1
X.org: 1.11.1.902-1

-- 
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 41744] Unigine Heaven shows black textures (Radeon HD4250)

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

--- Comment #11 from kao_chen kaoch...@gmail.com 2011-11-15 09:03:51 PST ---
Sorry I have done a mistake, the libtxc-dxtn library was not installed properly
on my PC.

I found the source code here:
http://debian-multimedia.org/pool/main/libt/libtxc-dxtn/libtxc-dxtn.php

It's working better for me on both Unigine Heaven and Unigine Oilrush game. I
still have some graphics artifacts but they probably  come from another bug.

Here:
Unigine Heaven with wrong shadows:
http://pix.toile-libre.org/upload/original/1321376279.png

And

Oilrush, the crane is flying
http://pix.toile-libre.org/upload/original/1321376118.png

Regards
Kao

-- 
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 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #2 from Dave Airlie airl...@freedesktop.org 2011-11-15 09:34:49 
PST ---
does xrandr to a new mode and back help?

-- 
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] drm/fb: don't call driver set_config if display isn't panned

This is just a minor optimization to the fb panning code.  In debugging
some other issues, I noticed a lot of no-op calls to the set_config
routine with all the same parameters and tracked down the source to the
fb helper pan routine.

So add an additional check for actual panning relative to the current
crtc config to avoid unnecessary set_config calls.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..4dd81f3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -739,7 +739,8 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
modeset-x = var-xoffset;
modeset-y = var-yoffset;
 
-   if (modeset-num_connectors) {
+   if (((modeset-x != crtc-x) || (modeset-y != crtc-y)) 
+   modeset-num_connectors) {
ret = crtc-funcs-set_config(modeset);
if (!ret) {
info-var.xoffset = var-xoffset;


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

[PATCH] drm, i915: Fix memory leak in i915_gem_busy_ioctl().

2011-11-15 Thread Rakib Mullick


A call to i915_add_request() has been made in function i915_gem_busy_ioctl(). 
i915_add_request can fail,
so in it's exit path previously allocated memory needs to be freed.

Signed-off-by: Rakib Mullick rakib.mull...@gmail.com
---

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d18b07a..2dc24ab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3512,9 +3512,11 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
 * so emit a request to do so.
 */
request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (request)
+   if (request) {
ret = i915_add_request(obj-ring, NULL, 
request);
-   else
+   if (ret)
+   kfree(request);
+   } else
ret = -ENOMEM;
}
 


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

Re: DRM KMS Modesetting

2011/11/15 Kristian Høgsberg k...@bitplanet.net:
 On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 On Mon, 14 Nov 2011 21:47:09 +0100
 David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

 Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
 width/stride correctly somewhere then.  You'd have to walk through the
 gbm_dri2.c and egl_dri2.c code and see where the width is going off
 into the weeds.

 Could be, I know I've run Wayland on Pineview though, so that works at
 least.  David, did you try eglkms from mesa demos?

 http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

I tried it now. I get a black screen and in the left quarter there is
one white triangle which fades to black. But again, the right 3/4 of
the screen are black.

 Kristian


I will try to debug my mesa package but this will probably take some
time. If someone has an idea how to find the bug faster, just tell me
;)

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

Re: radeon/kms: black screen when loading radeon with modeset=1

2011-11-15 Thread Alex Deucher

On Tue, Nov 15, 2011 at 2:05 PM, Sergey V. sftp.mt...@gmail.com wrote:
 Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b

 Loading radeon module with modeset=1 causes black screen.

 Usually it happens at boot time, but if run kernel with radeon.modeset=0 then
 `rmmod radeon; modprobe radeon modeset=1` I can get dmesg over ssh (thanks to
 glisse from #radeon for help).

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-November/016498.html

Alex


 Backtrace below:

 [   89.905890] BUG: unable to handle kernel NULL pointer dereference at
 0008
 [   89.906016] IP: [a05998ed]
 radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
 [   89.906016] PGD 6a0e1067 PUD 6a09d067 PMD 0
 [   89.906016] Oops: 0002 [#1] SMP
 [   89.906016] CPU 0
 [   89.906016] Modules linked in: radeon(+) snd_seq_dummy snd_seq_oss
 snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 btrfs
 cpufreq_ondemand powernow_k8 freq_table mperf lp ppdev parport_pc parport fuse
 snd_hda_codec_hdmi snd_hda_codec_realtek processor ttm drm_kms_helper drm
 thermal i2c_piix4 joydev agpgart video snd_hda_intel r8169 thermal_sys
 i2c_algo_bit i2c_core k8temp battery sdhci_pci snd_hda_codec evdev hwmon mii
 button ac shpchp sdhci snd_hwdep snd_pcm psmouse serio_raw mmc_core snd_timer
 sg snd soundcore snd_page_alloc [last unloaded: radeon]
 [   89.906016]
 [   89.906016] Pid: 2189, comm: modprobe Tainted: G        W    3.2.0-rc1+ #4
 Micro-Star International PR210/MS-1222
 [   89.906016] RIP: 0010:[a05998ed]  [a05998ed]
 radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
 [   89.906016] RSP: 0018:880075959948  EFLAGS: 00010246
 [   89.906016] RAX:  RBX: 880075b72000 RCX:
 
 [   89.906016] RDX:  RSI:  RDI:
 880076c73c00
 [   89.906016] RBP: 880075959a98 R08:  R09:
 880076c73a00
 [   89.906016] R10: 8800758a R11: 0006 R12:
 8800758aadde
 [   89.906016] R13: 8800758aadde R14:  R15:
 
 [   89.906016] FS:  7f57d0b27720() GS:88007bc0()
 knlGS:f702a6d0
 [   89.906016] CS:  0010 DS:  ES:  CR0: 8005003b
 [   89.906016] CR2: 0008 CR3: 6a0a6000 CR4:
 06f0
 [   89.906016] DR0:  DR1:  DR2:
 
 [   89.906016] DR3:  DR6: 0ff0 DR7:
 0400
 [   89.906016] Process modprobe (pid: 2189, threadinfo 880075958000, task
 880075abc6d0)
 [   89.906016] Stack:
 [   89.906016]  8800 8800768f400a 8800
 00ff
 [   89.906016]  880037653663 880075b73158 880075b73174
 000675959acf
 [   89.906016]  81b6112c 880075959a38 81b6112e
 880075959ad5
 [   89.906016] Call Trace:
 [   89.906016]  [81289dce] ? vsnprintf+0x31e/0x5d0
 [   89.906016]  [81289dce] ? vsnprintf+0x31e/0x5d0
 [   89.906016]  [81076511] ? up+0x31/0x50
 [   89.906016]  [81050494] ? console_unlock+0x1c4/0x230
 [   89.906016]  [a059cb98]
 radeon_atombios_get_power_modes+0x228/0x8e0 [radeon]
 [   89.906016]  [a05e7e01] radeon_pm_init+0x3b1/0x590 [radeon]
 [   89.906016]  [a05d0039] ? rs600_irq_set+0x109/0x180 [radeon]
 [   89.906016]  [a05b7ca9] radeon_modeset_init+0x4c9/0x8a0 [radeon]
 [   89.906016]  [a05fb3dc] ? radeon_acpi_init+0x8c/0xbc [radeon]
 [   89.906016]  [a0598760] radeon_driver_load_kms+0x120/0x170
 [radeon]
 [   89.906016]  [a024d82e] drm_get_pci_dev+0x18e/0x2c0 [drm]
 [   89.906016]  [a05fb4b9] radeon_pci_probe+0xad/0xb5 [radeon]
 [   89.906016]  [812a8edf] local_pci_probe+0x5f/0xd0
 [   89.906016]  [812a97b8] pci_device_probe+0x88/0xb0
 [   89.906016]  [81331bca] ? driver_sysfs_add+0x7a/0xb0
 [   89.906016]  [81331ed6] driver_probe_device+0x96/0x1b0
 [   89.906016]  [81332093] __driver_attach+0xa3/0xb0
 [   89.906016]  [81331ff0] ? driver_probe_device+0x1b0/0x1b0
 [   89.906016]  [81330e9e] bus_for_each_dev+0x5e/0x90
 [   89.906016]  [81331b4e] driver_attach+0x1e/0x20
 [   89.906016]  [81331745] bus_add_driver+0x155/0x280
 [   89.906016]  [81332676] driver_register+0x76/0x140
 [   89.906016]  [812a9a45] __pci_register_driver+0x55/0xd0
 [   89.906016]  [a024da71] drm_pci_init+0x111/0x120 [drm]
 [   89.906016]  [a0639000] ? 0xa0638fff
 [   89.906016]  [a0639000] ? 0xa0638fff
 [   89.906016]  [a06390ec] radeon_init+0xec/0xee [radeon]
 [   89.906016]  [810002d4] do_one_initcall+0x44/0x170
 [   89.906016]  [8108c332] sys_init_module+0x92/0x1e0
 [   89.906016]  [817fba6b] system_call_fastpath+0x16/0x1b
 [   89.906016] Code: 16 44 3b b5 ec fe ff ff

Re: RFC: Radeon multi ring support branch

On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian König wrote:
 Hello everybody,
 
 to support multiple compute rings, async DMA engines and UVD we need
 to teach the radeon kernel module how to sync buffers between
 different rings and make some changes to the command submission
 ioctls.
 
 Since we can't release any documentation about async DMA or UVD
 (yet), my current branch concentrates on getting the additional
 compute rings on cayman running. Unfortunately those rings have
 hardware bugs that can't be worked around, so they are actually not
 very useful in a production environment, but they should do quite
 well for this testing purpose.
 
 The branch can be found here:
 http://cgit.freedesktop.org/~deathsimple/linux/log/
 
 Since some of the patches are quite intrusive, constantly rebaseing
 them could get a bit painful. So I would like to see most of the
 stuff included into drm-next, even if we don't make use of the new
 functionality right now.
 
 Comments welcome,
 Christian.

So i have been looking back at all this and now there is somethings
puzzling me. So if semaphore wait for a non null value at gpu address
provided in the packet than the current implementation for the cs
ioctl doesn't work when there is more than 2 rings to sync.

http://cgit.freedesktop.org/~deathsimple/linux/commit/?h=multi-ring-testingid=bae372811c697a889ff0cf9128f52fe914d0fe1b

As it will use only one semaphore so first ring to finish will
mark the semaphore as done even if there is still other ring not
done.

This all make me wonder if some change to cs ioctl would make
all this better. So idea of semaphore is to wait for some other
ring to finish something. So let say we have following scenario:
Application submit following to ring1: csA, csB
Application now submit to ring2: cs1, cs2 
And application want csA to be done for cs1 and csB to be done
for cs2.

To achieve such usage pattern we would need to return fence seq
or similar from the cs ioctl. So user application would know
ringid+fence_seq for csA  csB and provide this when scheduling
cs1  cs2. Here i am assuming MEM_WRITE/WAIT_REG_MEM packet
are as good as MEM_SEMAPHORE packet. Ie the semaphore packet
doesn't give us much more than MEM_WRITE/WAIT_REG_MEM would.

To achieve that each ring got it's fence scratch addr where to
write seq number. And then we use WAIT_REG_MEM on this addr
and with the specific seq for the other ring that needs
synchronization. This would simplify the semaphore code as
we wouldn't need somethings new beside helper function and
maybe extending the fence structure.

Anyway i put updating ring patch at :
http://people.freedesktop.org/~glisse/mrings/
It rebased on top of linus tree and it has several space
indentation fixes and also a fix for no semaphore allocated
issue (patch 5)

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

RE: radeon/kms: black screen when loading radeon with modeset=1

2011-11-15 Thread Deucher, Alexander

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-November/016498.html

Alex

 -Original Message-
 From: Sergey V. [mailto:sftp.mt...@gmail.com]
 Sent: Tuesday, November 15, 2011 2:05 PM
 To: David Airlie
 Cc: Deucher, Alexander; dri-devel@lists.freedesktop.org; linux-
 ker...@vger.kernel.org
 Subject: radeon/kms: black screen when loading radeon with modeset=1
 
 Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b
 
 Loading radeon module with modeset=1 causes black screen.
 
 Usually it happens at boot time, but if run kernel with radeon.modeset=0
 then `rmmod radeon; modprobe radeon modeset=1` I can get dmesg over
 ssh (thanks to glisse from #radeon for help).
 
 Backtrace below:
 
 [   89.905890] BUG: unable to handle kernel NULL pointer dereference at
 0008
 [   89.906016] IP: [a05998ed]
 radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
 [   89.906016] PGD 6a0e1067 PUD 6a09d067 PMD 0
 [   89.906016] Oops: 0002 [#1] SMP
 [   89.906016] CPU 0
 [   89.906016] Modules linked in: radeon(+) snd_seq_dummy snd_seq_oss
 snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
 snd_mixer_oss ipv6 btrfs cpufreq_ondemand powernow_k8 freq_table
 mperf lp ppdev parport_pc parport fuse snd_hda_codec_hdmi
 snd_hda_codec_realtek processor ttm drm_kms_helper drm thermal
 i2c_piix4 joydev agpgart video snd_hda_intel r8169 thermal_sys i2c_algo_bit
 i2c_core k8temp battery sdhci_pci snd_hda_codec evdev hwmon mii button
 ac shpchp sdhci snd_hwdep snd_pcm psmouse serio_raw mmc_core
 snd_timer sg snd soundcore snd_page_alloc [last unloaded: radeon]
 [   89.906016]
 [   89.906016] Pid: 2189, comm: modprobe Tainted: GW3.2.0-rc1+ #4
 Micro-Star International PR210/MS-1222
 [   89.906016] RIP: 0010:[a05998ed]  [a05998ed]
 radeon_atombios_parse_power_table_1_3+0x13d/0x810 [radeon]
 [   89.906016] RSP: 0018:880075959948  EFLAGS: 00010246
 [   89.906016] RAX:  RBX: 880075b72000 RCX:
 
 [   89.906016] RDX:  RSI:  RDI:
 880076c73c00
 [   89.906016] RBP: 880075959a98 R08:  R09:
 880076c73a00
 [   89.906016] R10: 8800758a R11: 0006 R12:
 8800758aadde
 [   89.906016] R13: 8800758aadde R14:  R15:
 
 [   89.906016] FS:  7f57d0b27720() GS:88007bc0()
 knlGS:f702a6d0
 [   89.906016] CS:  0010 DS:  ES:  CR0: 8005003b
 [   89.906016] CR2: 0008 CR3: 6a0a6000 CR4:
 06f0
 [   89.906016] DR0:  DR1:  DR2:
 
 [   89.906016] DR3:  DR6: 0ff0 DR7:
 0400
 [   89.906016] Process modprobe (pid: 2189, threadinfo 880075958000, task
 880075abc6d0)
 [   89.906016] Stack:
 [   89.906016]  8800 8800768f400a 8800
 00ff
 [   89.906016]  880037653663 880075b73158 880075b73174
 000675959acf
 [   89.906016]  81b6112c 880075959a38 81b6112e
 880075959ad5
 [   89.906016] Call Trace:
 [   89.906016]  [81289dce] ? vsnprintf+0x31e/0x5d0
 [   89.906016]  [81289dce] ? vsnprintf+0x31e/0x5d0
 [   89.906016]  [81076511] ? up+0x31/0x50
 [   89.906016]  [81050494] ? console_unlock+0x1c4/0x230
 [   89.906016]  [a059cb98]
 radeon_atombios_get_power_modes+0x228/0x8e0 [radeon]
 [   89.906016]  [a05e7e01] radeon_pm_init+0x3b1/0x590 [radeon]
 [   89.906016]  [a05d0039] ? rs600_irq_set+0x109/0x180 [radeon]
 [   89.906016]  [a05b7ca9] radeon_modeset_init+0x4c9/0x8a0
 [radeon]
 [   89.906016]  [a05fb3dc] ? radeon_acpi_init+0x8c/0xbc [radeon]
 [   89.906016]  [a0598760] radeon_driver_load_kms+0x120/0x170
 [radeon]
 [   89.906016]  [a024d82e] drm_get_pci_dev+0x18e/0x2c0 [drm]
 [   89.906016]  [a05fb4b9] radeon_pci_probe+0xad/0xb5 [radeon]
 [   89.906016]  [812a8edf] local_pci_probe+0x5f/0xd0
 [   89.906016]  [812a97b8] pci_device_probe+0x88/0xb0
 [   89.906016]  [81331bca] ? driver_sysfs_add+0x7a/0xb0
 [   89.906016]  [81331ed6] driver_probe_device+0x96/0x1b0
 [   89.906016]  [81332093] __driver_attach+0xa3/0xb0
 [   89.906016]  [81331ff0] ? driver_probe_device+0x1b0/0x1b0
 [   89.906016]  [81330e9e] bus_for_each_dev+0x5e/0x90
 [   89.906016]  [81331b4e] driver_attach+0x1e/0x20
 [   89.906016]  [81331745] bus_add_driver+0x155/0x280
 [   89.906016]  [81332676] driver_register+0x76/0x140
 [   89.906016]  [812a9a45] __pci_register_driver+0x55/0xd0
 [   89.906016]  [a024da71] drm_pci_init+0x111/0x120 [drm]
 [   89.906016]  [a0639000] ? 0xa0638fff
 [   89.906016]  [a0639000] ? 0xa0638fff
 [   89.906016]  [a06390ec] radeon_init+0xec/0xee [radeon]
 [

[Bug 42913] r600g: glx-swap-pixmap causes screen corruption

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

--- Comment #3 from Kai deb...@carbon-project.org 2011-11-15 11:47:33 PST ---
(In reply to comment #2)
 does xrandr to a new mode and back help?

Yes, that restores a normal screen. AFAICT there is no vestige of the
corruption left.

-- 
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: radeon/kms: black screen when loading radeon with modeset=1

2011-11-15 Thread Sergey V.

On Tuesday 15 of November 2011 23:21:10 Alex Deucher wrote:
 On Tue, Nov 15, 2011 at 2:05 PM, Sergey V. sftp.mt...@gmail.com wrote:
  Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b
 
  Loading radeon module with modeset=1 causes black screen.
 
  Usually it happens at boot time, but if run kernel with radeon.modeset=0 
then
  `rmmod radeon; modprobe radeon modeset=1` I can get dmesg over ssh (thanks 
to
  glisse from #radeon for help).
 
 Fixed with this patch:
 http://lists.freedesktop.org/archives/dri-devel/2011-November/016498.html
 
 Alex
 

Thank you! I tested the patch and it helped.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
 On Tue, 15 Nov 2011 14:57:02 +0200
 Ville Syrjälä ville.syrj...@linux.intel.com wrote:
  I'm fine with fourccs as long as the defines are named and documented
  in way that avoids guesswork.
  
  So what I'm thinking is something like this:
  
  DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
  DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
  DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
  DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
  DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
  
  DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
  DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
  
  DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
  DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
  DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
  DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
  
  That leaves no room for guesswork.
 
 Looks great.  Want to send Dave an incremental patch?  I'll apply the
 final version to libdrm for use by userland code.

What I listed there doesn't match what v4l2 has. So I'm not sure what
to put in a patch.

It looks like the v4l2 fourccs have explicit endianness (ie. LE or BE).
If we follow that, and assuming people still want to use hardware byte
swappers, it means user space needs some ifdefs to select the approriate
format based on the host endianness. Or, we could do that in the header
file itself, so we would provide three definitions for each format LE,
BE, and NE (which would point to LE or BE depending on host endianness).

One extra issue I just realized is that the 8bpp and 16bpp v4l2 formats
are in fact BGR nor RGB, that is the component order is such that blue
occupies the most significant bit, red the lsb. I've never even seen
a PC graphics card that supports such formats. Adding insult to injury
PIX_FMT_RGB444 is defined the opposite way, ie. matching what most
graphics cards would expect.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm/vgaarb fixes

2011-11-15 Thread Dave Airlie


Hi Linus,

Fix for a vgaarb bridge detect problem I found playing in qemu, a radeon 
oops fix, missing PCI IDs, and a fix from the -rt guys that I've forgotten 
to send 2 or 3 times now.

Dave.

The following changes since commit a7c36fd8c5ee6dcca584137cb81aeefd785a0721:

  drm/radeon/kms/combios: fix dynamic allocation of PM clock modes (2011-11-12 
17:46:40 +)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (3):
  drm/radeon: add some missing FireMV pci ids
  drm/radeon/kms: fix up gpio i2c mask bits for r4xx
  drm/radeon/kms: fix segfault in pm rework

Dave Airlie (1):
  vgaarb: a NULL bridge is acceptable for root devices.

Thomas Gleixner (1):
  drm: Remove utterly bogus preempt_disable() sections

 drivers/gpu/drm/drm_irq.c|9 --
 drivers/gpu/drm/radeon/radeon_atombios.c |   32 +++--
 drivers/gpu/vga/vgaarb.c |   44 ++---
 include/drm/drm_pciids.h |2 +
 4 files changed, 40 insertions(+), 47 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 22:30:36 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
  On Tue, 15 Nov 2011 14:57:02 +0200
  Ville Syrjälä ville.syrj...@linux.intel.com wrote:
   I'm fine with fourccs as long as the defines are named and documented
   in way that avoids guesswork.
   
   So what I'm thinking is something like this:
   
   DRM_FOURCC_RGB332  ... /* [7:0] R:G:B 3:3:2 */
   DRM_FOURCC_XRGB1555... /* [15:0] x:R:G:B 1:5:5:5, native endian */
   DRM_FOURCC_RGB565  ... /* [15:0] R:G:B 5:6:5, native endian */
   DRM_FOURCC_XRGB... /* [31:0] x:R:G:B 8:8:8:8, native endian */
   DRM_FOURCC_XRGB2101010 ... /* [31:0] x:R:G:B 2:10:10:10, native endian */
   
   DRM_FOURCC_RGB888  ... /* [23:0] R:G:B 8:8:8, little endian */
   DRM_FOURCC_BGR888  ... /* [23:0] B:G:R 8:8:8, little endian */
   
   DRM_FOURCC_YUYV... /* [31:0] Cr:Y1:Cb:Y0 8:8:8:8, little endian */
   DRM_FOURCC_UYVY... /* [31:0] Y1:Cr:Y0:Cb 8:8:8:8, little endian */
   DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
   DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
   
   That leaves no room for guesswork.
  
  Looks great.  Want to send Dave an incremental patch?  I'll apply the
  final version to libdrm for use by userland code.
 
 What I listed there doesn't match what v4l2 has. So I'm not sure what
 to put in a patch.
 
 It looks like the v4l2 fourccs have explicit endianness (ie. LE or BE).
 If we follow that, and assuming people still want to use hardware byte
 swappers, it means user space needs some ifdefs to select the approriate
 format based on the host endianness. Or, we could do that in the header
 file itself, so we would provide three definitions for each format LE,
 BE, and NE (which would point to LE or BE depending on host endianness).
 
 One extra issue I just realized is that the 8bpp and 16bpp v4l2 formats
 are in fact BGR nor RGB, that is the component order is such that blue
 occupies the most significant bit, red the lsb. I've never even seen
 a PC graphics card that supports such formats. Adding insult to injury
 PIX_FMT_RGB444 is defined the opposite way, ie. matching what most
 graphics cards would expect.

Heh, well you can just pick whatever makes sense then for RGB, and
remove the _FOURCC_ strings to make it clear we're using sane RGB
definitions and not some half-specified fourcc stuff.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

2011-11-15 Thread Konrad Rzeszutek Wilk

On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com
 
 Move dma data to a superset ttm_dma_tt structure which herit

inherit

 from ttm_tt. This allow driver that don't use dma functionalities
 to not have to waste memory for it.
 
 V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
 V3 Make sure page list is initialized empty
 
 Signed-off-by: Jerome Glisse jgli...@redhat.com
 Reviewed-by: Thomas Hellstrom thellst...@vmware.com
.. snip..

 +void ttm_tt_fini(struct ttm_tt *ttm)
 +{
 + drm_free_large(ttm-pages);
 + ttm-pages = NULL;
 +}
 +EXPORT_SYMBOL(ttm_tt_fini);
 +
 +int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
 + unsigned long size, uint32_t page_flags,
 + struct page *dummy_read_page)
 +{
 + struct ttm_tt *ttm = ttm_dma-ttm;
 +
 + ttm-bdev = bdev;
 + ttm-glob = bdev-glob;
 + ttm-num_pages = (size + PAGE_SIZE - 1)  PAGE_SHIFT;
 + ttm-caching_state = tt_cached;
 + ttm-page_flags = page_flags;
 + ttm-dummy_read_page = dummy_read_page;
 + ttm-state = tt_unpopulated;
 +
 + INIT_LIST_HEAD(ttm_dma-pages_list);
 + ttm_dma_tt_alloc_page_directory(ttm_dma);
 + if (!ttm-pages || !ttm_dma-dma_address) {
 + ttm_tt_destroy(ttm);
 + printk(KERN_ERR TTM_PFX Failed allocating page table\n);
 + return -ENOMEM;
 + }
 + return 0;
 +}
 +EXPORT_SYMBOL(ttm_dma_tt_init);

EXPORT_SYMBOL_GPL ?

 +
 +void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
 +{
 + struct ttm_tt *ttm = ttm_dma-ttm;
 +
 + drm_free_large(ttm-pages);
 + ttm-pages = NULL;
 + drm_free_large(ttm_dma-dma_address);
 + ttm_dma-dma_address = NULL;
 +}
 +EXPORT_SYMBOL(ttm_dma_tt_fini);
 +

EXPORT_SYMBOL_GPL?


  void ttm_tt_unbind(struct ttm_tt *ttm)
  {
   int ret;
 diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
 b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
 index 3986d74..1e2c0fb 100644
 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
 +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
 @@ -168,6 +168,7 @@ static void vmw_ttm_destroy(struct ttm_tt *ttm)
  {
   struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, ttm);
  
 + ttm_tt_fini(ttm);
   kfree(vmw_be);
  }
  
 @@ -191,6 +192,7 @@ struct ttm_tt *vmw_ttm_tt_create(struct ttm_bo_device 
 *bdev,
   vmw_be-dev_priv = container_of(bdev, struct vmw_private, bdev);
  
   if (ttm_tt_init(vmw_be-ttm, bdev, size, page_flags, dummy_read_page)) 
 {
 + kfree(vmw_be);
   return NULL;
   }
  
 diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
 index beef9ab..89caa48 100644
 --- a/include/drm/ttm/ttm_bo_driver.h
 +++ b/include/drm/ttm/ttm_bo_driver.h
 @@ -104,7 +104,6 @@ enum ttm_caching_state {
   * @caching_state: The current caching state of the pages.
   * @state: The current binding state of the pages.
   * @dma_address: The DMA (bus) addresses of the pages (if 
 TTM_PAGE_FLAG_DMA32)
 - * @alloc_list: used by some page allocation backend
   *
   * This is a structure holding the pages, caching- and aperture binding
   * status for a buffer object that isn't backed by fixed (VRAM / AGP)
 @@ -127,8 +126,23 @@ struct ttm_tt {
   tt_unbound,
   tt_unpopulated,
   } state;
 +};
 +
 +/**
 + * struct ttm_dma_tt
 + *
 + * @ttm: Base ttm_tt struct.
 + * @dma_address: The DMA (bus) addresses of the pages (if 
 TTM_PAGE_FLAG_DMA32)

Not anymore (the TTM_PAGE_FLAG_DMA32 comment).

 + * @pages_list: used by some page allocation backend
 + *
 + * This is a structure holding the pages, caching- and aperture binding
 + * status for a buffer object that isn't backed by fixed (VRAM / AGP)
 + * memory.
 + */
 +struct ttm_dma_tt {
 + struct ttm_tt ttm;
   dma_addr_t *dma_address;
 - struct list_head alloc_list;
 + struct list_head pages_list;
  };
  
  #define TTM_MEMTYPE_FLAG_FIXED (1  0)  /* Fixed (on-card) PCI 
 memory */
 @@ -595,6 +609,19 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
 mask)
  extern int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
   unsigned long size, uint32_t page_flags,
   struct page *dummy_read_page);
 +extern int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device 
 *bdev,
 +unsigned long size, uint32_t page_flags,
 +struct page *dummy_read_page);
 +
 +/**
 + * ttm_tt_fini
 + *
 + * @ttm: The struct ttm_tt.
 + *
 + * Free memory of ttm_tt structu

structure
 + */
 +extern void ttm_tt_fini(struct ttm_tt *ttm);
 +extern void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma);


.. snip..
   * Initialize pool allocator.
   */
  int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages);
 @@ -107,8 +78,8 @@ void ttm_dma_page_alloc_fini(void);
   */
  extern int

Re: DRM KMS Modesetting

2011/11/15 David Herrmann dh.herrm...@googlemail.com:
 2011/11/15 Kristian Høgsberg k...@bitplanet.net:
 On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes jbar...@virtuousgeek.org 
 wrote:
 On Mon, 14 Nov 2011 21:47:09 +0100
 David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.

 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083

 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

 Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
 width/stride correctly somewhere then.  You'd have to walk through the
 gbm_dri2.c and egl_dri2.c code and see where the width is going off
 into the weeds.

 Could be, I know I've run Wayland on Pineview though, so that works at
 least.  David, did you try eglkms from mesa demos?

 http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl/eglkms.c

 I tried it now. I get a black screen and in the left quarter there is
 one white triangle which fades to black. But again, the right 3/4 of
 the screen are black.

 Kristian


 I will try to debug my mesa package but this will probably take some
 time. If someone has an idea how to find the bug faster, just tell me
 ;)

It's all very odd.  The gbm allocation ends up in intel_create_image
in src/mesa/drivers/dri/intel/intel_screen.c, so you can try to
compare the stride, width and height there with what modetest uses.

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

Re: [PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3

On Tue, Nov 15, 2011 at 04:07:46PM -0500, Konrad Rzeszutek Wilk wrote:
 On Fri, Nov 11, 2011 at 05:47:48PM -0500, j.gli...@gmail.com wrote:
  From: Jerome Glisse jgli...@redhat.com
  
  Move dma data to a superset ttm_dma_tt structure which herit
 
 inherit
 
  from ttm_tt. This allow driver that don't use dma functionalities
  to not have to waste memory for it.
  
  V2 Rebase on top of no memory account changes (where/when is my
 delorean when i need it ?)
  V3 Make sure page list is initialized empty
  
  Signed-off-by: Jerome Glisse jgli...@redhat.com
  Reviewed-by: Thomas Hellstrom thellst...@vmware.com
 .. snip..
 
  +void ttm_tt_fini(struct ttm_tt *ttm)
  +{
  +   drm_free_large(ttm-pages);
  +   ttm-pages = NULL;
  +}
  +EXPORT_SYMBOL(ttm_tt_fini);
  +
  +int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device *bdev,
  +   unsigned long size, uint32_t page_flags,
  +   struct page *dummy_read_page)
  +{
  +   struct ttm_tt *ttm = ttm_dma-ttm;
  +
  +   ttm-bdev = bdev;
  +   ttm-glob = bdev-glob;
  +   ttm-num_pages = (size + PAGE_SIZE - 1)  PAGE_SHIFT;
  +   ttm-caching_state = tt_cached;
  +   ttm-page_flags = page_flags;
  +   ttm-dummy_read_page = dummy_read_page;
  +   ttm-state = tt_unpopulated;
  +
  +   INIT_LIST_HEAD(ttm_dma-pages_list);
  +   ttm_dma_tt_alloc_page_directory(ttm_dma);
  +   if (!ttm-pages || !ttm_dma-dma_address) {
  +   ttm_tt_destroy(ttm);
  +   printk(KERN_ERR TTM_PFX Failed allocating page table\n);
  +   return -ENOMEM;
  +   }
  +   return 0;
  +}
  +EXPORT_SYMBOL(ttm_dma_tt_init);
 
 EXPORT_SYMBOL_GPL ?

TTM is BSD licensed too. As a rule the whole drm is under BSD license
too.

 
  +
  +void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
  +{
  +   struct ttm_tt *ttm = ttm_dma-ttm;
  +
  +   drm_free_large(ttm-pages);
  +   ttm-pages = NULL;
  +   drm_free_large(ttm_dma-dma_address);
  +   ttm_dma-dma_address = NULL;
  +}
  +EXPORT_SYMBOL(ttm_dma_tt_fini);
  +
 
 EXPORT_SYMBOL_GPL?
 
 
   void ttm_tt_unbind(struct ttm_tt *ttm)
   {
  int ret;
  diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
  b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
  index 3986d74..1e2c0fb 100644
  --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
  +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
  @@ -168,6 +168,7 @@ static void vmw_ttm_destroy(struct ttm_tt *ttm)
   {
  struct vmw_ttm_tt *vmw_be = container_of(ttm, struct vmw_ttm_tt, ttm);
   
  +   ttm_tt_fini(ttm);
  kfree(vmw_be);
   }
   
  @@ -191,6 +192,7 @@ struct ttm_tt *vmw_ttm_tt_create(struct ttm_bo_device 
  *bdev,
  vmw_be-dev_priv = container_of(bdev, struct vmw_private, bdev);
   
  if (ttm_tt_init(vmw_be-ttm, bdev, size, page_flags, dummy_read_page)) 
  {
  +   kfree(vmw_be);
  return NULL;
  }
   
  diff --git a/include/drm/ttm/ttm_bo_driver.h 
  b/include/drm/ttm/ttm_bo_driver.h
  index beef9ab..89caa48 100644
  --- a/include/drm/ttm/ttm_bo_driver.h
  +++ b/include/drm/ttm/ttm_bo_driver.h
  @@ -104,7 +104,6 @@ enum ttm_caching_state {
* @caching_state: The current caching state of the pages.
* @state: The current binding state of the pages.
* @dma_address: The DMA (bus) addresses of the pages (if 
  TTM_PAGE_FLAG_DMA32)
  - * @alloc_list: used by some page allocation backend
*
* This is a structure holding the pages, caching- and aperture binding
* status for a buffer object that isn't backed by fixed (VRAM / AGP)
  @@ -127,8 +126,23 @@ struct ttm_tt {
  tt_unbound,
  tt_unpopulated,
  } state;
  +};
  +
  +/**
  + * struct ttm_dma_tt
  + *
  + * @ttm: Base ttm_tt struct.
  + * @dma_address: The DMA (bus) addresses of the pages (if 
  TTM_PAGE_FLAG_DMA32)
 
 Not anymore (the TTM_PAGE_FLAG_DMA32 comment).
 
  + * @pages_list: used by some page allocation backend
  + *
  + * This is a structure holding the pages, caching- and aperture binding
  + * status for a buffer object that isn't backed by fixed (VRAM / AGP)
  + * memory.
  + */
  +struct ttm_dma_tt {
  +   struct ttm_tt ttm;
  dma_addr_t *dma_address;
  -   struct list_head alloc_list;
  +   struct list_head pages_list;
   };
   
   #define TTM_MEMTYPE_FLAG_FIXED (1  0)/* Fixed (on-card) PCI 
  memory */
  @@ -595,6 +609,19 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
  mask)
   extern int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
  unsigned long size, uint32_t page_flags,
  struct page *dummy_read_page);
  +extern int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
  ttm_bo_device *bdev,
  +  unsigned long size, uint32_t page_flags,
  +  struct page *dummy_read_page);
  +
  +/**
  + * ttm_tt_fini
  + *
  + * @ttm: The struct ttm_tt.
  + *
  + * Free memory of ttm_tt structu
 
 structure
  + */
  +extern void ttm_tt_fini(struct ttm_tt *ttm);
  +extern void ttm_dma_tt_fini(struct ttm_dma_tt

[Bug 42960] New: Display does not work when resuming from suspend

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

 Bug #: 42960
   Summary: Display does not work when resuming from suspend
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: sandy.8...@gmail.com


I have an ASUS K53TA laptop.

Relevant specs: AMD A6-3400M APU with integrated Radeon HD6520G and a discrete
Radeon HD6650M. Both are connected through Crossfire (I think). Laptop display
is though the integrated card.

Software info:
Ubuntu 11.04 64 bit using Linux 3.2-rc1 kernel from kernel.org and xorg-edgers
PPA

After resuming from suspend, display does not work.

-- 
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 1/2] drivers/gpu/vga/vgaarb.c: add missing kfree

2011-11-15 Thread akpm

From: Julia Lawall ju...@diku.dk
Subject: drivers/gpu/vga/vgaarb.c: add missing kfree

kbuf is a buffer that is local to this function, so all of the error paths
leaving the function should release it.

Signed-off-by: Julia Lawall ju...@diku.dk
Cc: Dave Airlie airl...@redhat.com
Cc: Jesper Juhl j...@chaosbits.net
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/gpu/vga/vgaarb.c |   18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff -puN drivers/gpu/vga/vgaarb.c~drivers-gpu-vga-vgaarbc-add-missing-kfree 
drivers/gpu/vga/vgaarb.c
--- a/drivers/gpu/vga/vgaarb.c~drivers-gpu-vga-vgaarbc-add-missing-kfree
+++ a/drivers/gpu/vga/vgaarb.c
@@ -993,14 +993,20 @@ static ssize_t vga_arb_write(struct file
uc = priv-cards[i];
}
 
-   if (!uc)
-   return -EINVAL;
+   if (!uc) {
+   ret_val = -EINVAL;
+   goto done;
+   }
 
-   if (io_state  VGA_RSRC_LEGACY_IO  uc-io_cnt == 0)
-   return -EINVAL;
+   if (io_state  VGA_RSRC_LEGACY_IO  uc-io_cnt == 0) {
+   ret_val = -EINVAL;
+   goto done;
+   }
 
-   if (io_state  VGA_RSRC_LEGACY_MEM  uc-mem_cnt == 0)
-   return -EINVAL;
+   if (io_state  VGA_RSRC_LEGACY_MEM  uc-mem_cnt == 0) {
+   ret_val = -EINVAL;
+   goto done;
+   }
 
vga_put(pdev, io_state);
 
_
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 2/2] drm: avoid switching to text console if there is no panic timeout

2011-11-15 Thread akpm

From: Hugh Dickins hu...@chromium.org
Subject: drm: avoid switching to text console if there is no panic timeout

Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
we're going to reboot immediately, the user will not be able to see the
messages anyway, and messing with the video mode may display artifacts,
and certainly get into several layers of complexity (including mutexes and
memory allocations) which we shall be much safer to avoid.

[m...@chromium.org: edited commit message and modified to short-circuit 
panic_timeout  0 instead of testing panic_timeout = 0]
Signed-off-by: Hugh Dickins hu...@google.com
Signed-off-by: Mandeep Singh Baines m...@chromium.org
Cc: Dave Airlie airl...@redhat.com
Acked-by: David Rientjes rient...@google.com
Acked-by: Stéphane Marchesin marc...@chromium.org
Cc: Dave Young hidave.darks...@gmail.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/gpu/drm/drm_fb_helper.c |7 +++
 1 file changed, 7 insertions(+)

diff -puN 
drivers/gpu/drm/drm_fb_helper.c~drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout
 drivers/gpu/drm/drm_fb_helper.c
--- 
a/drivers/gpu/drm/drm_fb_helper.c~drm-avoid-switching-to-text-console-if-there-is-no-panic-timeout
+++ a/drivers/gpu/drm/drm_fb_helper.c
@@ -255,6 +255,13 @@ bool drm_fb_helper_force_kernel_mode(voi
 int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
void *panic_str)
 {
+   /*
+* It's a waste of time and effort to switch back to text console
+* if the kernel should reboot before panic messages can be seen.
+*/
+   if (panic_timeout  0)
+   return 0;
+
printk(KERN_ERR panic occurred, switching back to text console\n);
return drm_fb_helper_force_kernel_mode();
 }
_
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: Radeon multi ring support branch

2011-11-15 Thread Christian König


On 15.11.2011 20:32, Jerome Glisse wrote:

On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian König wrote:

Hello everybody,

to support multiple compute rings, async DMA engines and UVD we need
to teach the radeon kernel module how to sync buffers between
different rings and make some changes to the command submission
ioctls.

Since we can't release any documentation about async DMA or UVD
(yet), my current branch concentrates on getting the additional
compute rings on cayman running. Unfortunately those rings have
hardware bugs that can't be worked around, so they are actually not
very useful in a production environment, but they should do quite
well for this testing purpose.

The branch can be found here:
http://cgit.freedesktop.org/~deathsimple/linux/log/

Since some of the patches are quite intrusive, constantly rebaseing
them could get a bit painful. So I would like to see most of the
stuff included into drm-next, even if we don't make use of the new
functionality right now.

Comments welcome,
Christian.

So i have been looking back at all this and now there is somethings
puzzling me. So if semaphore wait for a non null value at gpu address
provided in the packet than the current implementation for the cs
ioctl doesn't work when there is more than 2 rings to sync.
Semaphores are counters, so each signal operation is atomically 
incrementing the counter, while each wait operation is (atomically) 
checking if the counter is above zero and if it is decrement it. So you 
can signal/wait on the same address multiple times.




As it will use only one semaphore so first ring to finish will
mark the semaphore as done even if there is still other ring not
done.
Nope, each wait operation will wait for a separate signal operation (at 
least I think so).


This all make me wonder if some change to cs ioctl would make
all this better. So idea of semaphore is to wait for some other
ring to finish something. So let say we have following scenario:
Application submit following to ring1: csA, csB
Application now submit to ring2: cs1, cs2
And application want csA to be done for cs1 and csB to be done
for cs2.

To achieve such usage pattern we would need to return fence seq
or similar from the cs ioctl. So user application would know
ringid+fence_seq for csA  csB and provide this when scheduling
cs1  cs2. Here i am assuming MEM_WRITE/WAIT_REG_MEM packet
are as good as MEM_SEMAPHORE packet. Ie the semaphore packet
doesn't give us much more than MEM_WRITE/WAIT_REG_MEM would.

To achieve that each ring got it's fence scratch addr where to
write seq number. And then we use WAIT_REG_MEM on this addr
and with the specific seq for the other ring that needs
synchronization. This would simplify the semaphore code as
we wouldn't need somethings new beside helper function and
maybe extending the fence structure.
I played around with the same Idea before implementing the whole 
semaphore stuff, but the killer argument against it is that not all 
rings support the WAIT_REG_MEM command.


Also the semaphores are much more efficient than the WAIT_REG_MEM 
command, because all semaphore commands from the different rings are 
send to a central semaphore block, so that constant polling, and with it 
constant memory access can be avoided. Additional to that the 
WAIT_REG_MEM command has a minimum latency of Wait_Interval*16 clock 
cycles, while semaphore need 4 clock cycles for the command and 4 clock 
cycles for the result, so it definitely has a much lower latency.


We should also keep in mind that the semaphore block is not only capable 
to sync between different rings inside a single GPU, but can also 
communicate with another semaphore block in a second GPU. So it is a key 
part in a multi GPU environment.



Anyway i put updating ring patch at :
http://people.freedesktop.org/~glisse/mrings/
It rebased on top of linus tree and it has several space
indentation fixes and also a fix for no semaphore allocated
issue (patch 5)


Thanks, I will try to integrate the changes tomorrow.

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

Re: RFC: Radeon multi ring support branch

2011/11/15 Christian König deathsim...@vodafone.de:
 On 15.11.2011 20:32, Jerome Glisse wrote:

 On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian König wrote:

 Hello everybody,

 to support multiple compute rings, async DMA engines and UVD we need
 to teach the radeon kernel module how to sync buffers between
 different rings and make some changes to the command submission
 ioctls.

 Since we can't release any documentation about async DMA or UVD
 (yet), my current branch concentrates on getting the additional
 compute rings on cayman running. Unfortunately those rings have
 hardware bugs that can't be worked around, so they are actually not
 very useful in a production environment, but they should do quite
 well for this testing purpose.

 The branch can be found here:
 http://cgit.freedesktop.org/~deathsimple/linux/log/

 Since some of the patches are quite intrusive, constantly rebaseing
 them could get a bit painful. So I would like to see most of the
 stuff included into drm-next, even if we don't make use of the new
 functionality right now.

 Comments welcome,
 Christian.

 So i have been looking back at all this and now there is somethings
 puzzling me. So if semaphore wait for a non null value at gpu address
 provided in the packet than the current implementation for the cs
 ioctl doesn't work when there is more than 2 rings to sync.

 Semaphores are counters, so each signal operation is atomically incrementing
 the counter, while each wait operation is (atomically) checking if the
 counter is above zero and if it is decrement it. So you can signal/wait on
 the same address multiple times.

Yup i did understand that right.


 As it will use only one semaphore so first ring to finish will
 mark the semaphore as done even if there is still other ring not
 done.

 Nope, each wait operation will wait for a separate signal operation (at
 least I think so).

Well as we don't specify on which value semaphore should wait on, i am
prety sure the first ring to increment the semaphore will unblock all
waiter. So if you have ring1 that want to wait on ring2 and ring3 as
soon as ring2 or ring3 is done ring1 will go one while either ring2 or
ring3 might not be done. I will test that tomorrow but from doc i have
it seems so. Thus it will be broken with more than one ring, that
would mean you have to allocate one semaphore for each ring couple you
want to synchronize. Note that the usual case will likely be sync btw
2 ring.


 This all make me wonder if some change to cs ioctl would make
 all this better. So idea of semaphore is to wait for some other
 ring to finish something. So let say we have following scenario:
 Application submit following to ring1: csA, csB
 Application now submit to ring2: cs1, cs2
 And application want csA to be done for cs1 and csB to be done
 for cs2.

 To achieve such usage pattern we would need to return fence seq
 or similar from the cs ioctl. So user application would know
 ringid+fence_seq for csA  csB and provide this when scheduling
 cs1  cs2. Here i am assuming MEM_WRITE/WAIT_REG_MEM packet
 are as good as MEM_SEMAPHORE packet. Ie the semaphore packet
 doesn't give us much more than MEM_WRITE/WAIT_REG_MEM would.

 To achieve that each ring got it's fence scratch addr where to
 write seq number. And then we use WAIT_REG_MEM on this addr
 and with the specific seq for the other ring that needs
 synchronization. This would simplify the semaphore code as
 we wouldn't need somethings new beside helper function and
 maybe extending the fence structure.

 I played around with the same Idea before implementing the whole semaphore
 stuff, but the killer argument against it is that not all rings support the
 WAIT_REG_MEM command.

 Also the semaphores are much more efficient than the WAIT_REG_MEM command,
 because all semaphore commands from the different rings are send to a
 central semaphore block, so that constant polling, and with it constant
 memory access can be avoided. Additional to that the WAIT_REG_MEM command
 has a minimum latency of Wait_Interval*16 clock cycles, while semaphore need
 4 clock cycles for the command and 4 clock cycles for the result, so it
 definitely has a much lower latency.

Yup that was my guess too that semaphore block optimize things

 We should also keep in mind that the semaphore block is not only capable to
 sync between different rings inside a single GPU, but can also communicate
 with another semaphore block in a second GPU. So it is a key part in a multi
 GPU environment.

 Anyway i put updating ring patch at :
 http://people.freedesktop.org/~glisse/mrings/
 It rebased on top of linus tree and it has several space
 indentation fixes and also a fix for no semaphore allocated
 issue (patch 5)

 Thanks, I will try to integrate the changes tomorrow.


After retesting the first patch  drm/radeon: fix debugfs handling is NAK
a complete no go.

Issue is that radeon_debugfs_cleanup is call after rdev is free. This
is why i used a static array. I

Re: [PATCH 13/14] drm/ttm: isolate dma data from ttm_tt V3