Re: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Semwal, Sumit]

Hi Konrad,

On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
 wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> sharing of this buffer object across devices.
>>
>> The framework allows:
>> - different devices to 'attach' themselves to this buffer, to facilitate
>>   backing storage negotiation, using dma_buf_attach() API.
>
> Any thoughts of adding facility to track them? So you can see who is using 
> what?
Not for version 1, but it would be a useful addition once we start
using this mechanism.

>
>> - association of a file pointer with each user-buffer and associated
>>    allocator-defined operations on that buffer. This operation is called the
>>    'export' operation.
>
>  'create'? or 'alloc' ?
>
> export implies an import somwhere and I don't think that is the case here.
I will rephrase it as suggested by Rob as well.

>
>> - this exported buffer-object to be shared with the other entity by asking 
>> for
>>    its 'file-descriptor (fd)', and sharing the fd across.
>> - a received fd to get the buffer object back, where it can be accessed using
>>    the associated exporter-defined operations.
>> - the exporter and user to share the scatterlist using map_dma_buf and
>>    unmap_dma_buf operations.
>>
>> Atleast one 'attach()' call is required to be made prior to calling the
>> map_dma_buf() operation.
>
> for the whole memory region or just for the device itself?
Rob has very eloquently and kindly explained it in his reply.

>
>>

>> +/*
>> + * is_dma_buf_file - Check if struct file* is associated with dma_buf
>> + */
>> +static inline int is_dma_buf_file(struct file *file)
>> +{
>> +     return file->f_op == &dma_buf_fops;
>> +}
>> +
>> +/**
>
> Wrong kerneldoc.
I looked into scripts/kernel-doc, and
Documentation/kernel-doc-na-HOWTO.txt => both these places mention
that the kernel-doc comments have to start with /**, and I couldn't
spot an error in what's wrong with my usage - would you please
elaborate on what you think is not right?
>

>> +/**
>> + * struct dma_buf_attachment - holds device-buffer attachment data
>
> OK, but what is the purpose of it?
I will add that in the comments.
>
>> + * @dmabuf: buffer for this attachment.
>> + * @dev: device attached to the buffer.
>                                ^^^ this
>> + * @node: list_head to allow manipulation of list of dma_buf_attachment.
>
> Just say: "list of dma_buf_attachment"'
ok.
>
>> + * @priv: exporter-specific attachment data.
>
> That "exporter-specific.." brings to my mind custom decleration forms. But 
> maybe that is me.
:) well, in context of dma-buf 'exporter', it makes sense.

>
>> + */
>> +struct dma_buf_attachment {
>> +     struct dma_buf *dmabuf;
>> +     struct device *dev;
>> +     struct list_head node;
>> +     void *priv;
>> +};
>
> Why don't you move the decleration of this below 'struct dma_buf'?
> It would easier than to read this structure..
I could do that, but then anyways I will have to do a
forward-declaration of dma_buf_attachment, since I have to use it in
dma_buf_ops. If it improves readability, I am happy to move it below
struct dma_buf.

>
>> +
>> +/**
>> + * struct dma_buf_ops - operations possible on struct dma_buf
>> + * @attach: allows different devices to 'attach' themselves to the given
>
> register?
>> + *       buffer. It might return -EBUSY to signal that backing storage
>> + *       is already allocated and incompatible with the requirements
>
> Wait.. allocated or attached?
This and above comment on 'register' are already answered by Rob in
his explanation of the sequence in earlier reply. [the Documentation
patch [2/2] also tries to explain it]

>
>> + *       of requesting device. [optional]
>
> What is optional? The return value? Or the 'attach' call? If the later , say
> that in the first paragraph.
>
ok, sure. it is meant for the attach op.
>
>> + * @detach: detach a given device from this buffer. [optional]
>> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount
>> + *            of the buffer. Requires atleast one attach to be called
>> + *            before. Returned sg list should already be mapped into
>> + *            _device_ address space. This call may sleep. May also return
>
> Ok, there is some __might_sleep macro you should put on the function.
>
That's a nice suggestion; I will add it to the wrapper function for
map_dma_buf().

>> + *            -EINTR.
>
> Ok. What is the return code if attach has _not_ been called?
Will document it to return -EINVAL if atleast on attach() hasn't been called.

>
>> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
>> + *              pages.
>> + * @release: release this buffer; to be called after the last dma_buf_put.
>> + * @sync_sg_for_cpu: sync the sg list for cpu.
>> + * @sync_sg_for_device: synch the sg list for

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Semwal, Sumit]

On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann  wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by 
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to buffer..

Thanks Rob - and the exporter can do the mmap outside of dma-buf
usage, right? I mean, we don't need to provide an mmap to dma_buf()
and restrict it to exporter, when the exporter has more 'control' of
the buffer anyways.
>
BR,
~Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

[Semwal, Sumit]

On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie  wrote:

>>
>> I think this is a really good v1 version of dma_buf. It contains all the
>> required bits (with well-specified semantics in the doc patch) to
>> implement some basic use-cases and start fleshing out the integration with
>> various subsystem (like drm and v4l). All the things still under
>> discussion like
>> - userspace mmap support
>> - more advanced (and more strictly specified) coherency models
>> - and shared infrastructure for implementing exporters
>> are imo much clearer once we have a few example drivers at hand and a
>> better understanding of some of the insane corner cases we need to be able
>> to handle.
>>
>> And I think any risk that the resulting clarifications will break a basic
>> use-case is really minimal, so I think it'd be great if this could go into
>> 3.3 (maybe as some kind of staging/experimental infrastructure).
>>
>> Hence for both patches:
>> Reviewed-by: Daniel Vetter 
>
> Yeah I'm with Daniel, I like this one, I can definitely build the drm
> buffer sharing layer on top of this.
>
> How do we see this getting merged? I'm quite happy to push it to Linus
> if we don't have an identified path, though it could go via a Linaro
> tree as well.
>
> so feel free to add:
> Reviewed-by: Dave Airlie 
Thanks Daniel and Dave!

I guess we can start with staging for 3.3, and see how it shapes up. I
will post the latest patch version pretty soon.

Arnd, Dave: do you have any preference on the path it takes to get
merged? In my mind, Linaro tree might make more sense, but I would
leave it upto you gentlemen.
>
> Dave.
Best regards,
~Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU hung with Linux-3.2-rc6

[Eugeni Dodonov]

On Thu, Dec 22, 2011 at 15:00, Keith Packard  wrote:

> On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg 
> wrote:
>
> > I quick google search suggests that at least some of them are too old to
> > support SNA.
>
> Sounds good. If you can capture the error as Daniel suggests, that would
> be great. In any case, I'll post a revert of the semaphore enable patch
> as it looks like that's still not working right...
>

Could we revert it for SNB, and leave it enabled for IVB?

It would be just the chunk which checks for intel_iommu status in the patch.

-- 
Eugeni Dodonov

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

Re: [PULL] remove drm_sman and some i815 fixes

[Daniel Vetter]

On Thu, Dec 22, 2011 at 11:22:00PM +, James Simmons wrote:
> 
> > > > Hi Dave,
> > > > 
> > > > I've failed to correctly fix the via hang in the reclaim buffers rework
> > > > till now, so I'm only submitting the drm_sman removal of my drm cruft
> > > > removal series.
> > > 
> > > Last attempt at your branch still had problem. Start I didn't have time 
> > > track down the exact issue. I'm cloning the below branch and will test it.
> > > Thanks for cleanup.
> > 
> > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > reported and noticed that the X server fails to start up (and that the
> > kernel hangs). Is that the same you're seeing?
> 
> What was just merged to drm-next works fine. Its the reclaim buffer 
> patches that cause the problem. In my case the X server starts but I get  
> a blank screen. I have full debug on so this is what happens.

Thanks for testing and gathering the logs.

Judging from the dmesg you've attached the via driver opens and closes the
via drm node at least twice while starting X. Which explains why things
blow up for you and Jakob already at startup. But ...

[snip]

> diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
> index bedb23d..f29d0c5 100644
> --- a/drivers/gpu/drm/via/via_mm.c
> +++ b/drivers/gpu/drm/via/via_mm.c
> @@ -215,6 +215,10 @@ void via_reclaim_buffers_locked(struct drm_device *dev,
>  {
>   struct via_file_private *file_priv = file->driver_priv;
>   struct via_memblock *entry, *next;
> + int release_idlelock = 0;
> +
> + if (file->master && file->master->lock.hw_lock)
> + drm_idlelock_take(&file->master->lock);

This is still the old version of the patch, which doesn't set
release_idlelock properly. I've made double-sure that my branch a

http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire

contains the right patches (now rebased onto drm-next). Alternatively you
can just apply the via reclaim_buffers patch on top of drm-next:

http://cgit.freedesktop.org/~danvet/drm/commit/?h=kill-with-fire&id=a00a2f313d6e99f6c35d2abed094aa4ec94431e2

Can you please retest with that and again grab the dmesg with full
logging? Jakob reported that this still blows up, so there's a problem
left somewhere. But I've rechecked the patches and couldn't see it.

I'll be offline next week.

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

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

[bugzilla-daemon]

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

--- Comment #5 from Stefano Teso  2011-12-23 07:29:54 
PST ---
> But I'm no Mesa/Piglit expert, so my assumption might be wrong.

I have the very same issue here on evergreen, 32-bit userland on i7; debian
unstable.

mesa: git 2eafd07323891944b9c012a17359cd5f07a87890 (cloned as of today)
libdrm: 2.4.29-1
kernel: 3.2-rc6
xorg: 1.11.2.902-1

(BTW, when using gnome-shell, the corruption is fixed automatically after half
a second or so; using fluxbox, the screen stays corrupted.)

HTH,

-- 
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: [PULL] remove drm_sman and some i815 fixes

[James Simmons]

> > > > Last attempt at your branch still had problem. Start I didn't have time 
> > > > track down the exact issue. I'm cloning the below branch and will test 
> > > > it.
> > > > Thanks for cleanup.
> > > 
> > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > > reported and noticed that the X server fails to start up (and that the
> > > kernel hangs). Is that the same you're seeing?
> > 
> > What was just merged to drm-next works fine. Its the reclaim buffer 
> > patches that cause the problem. In my case the X server starts but I get  
> > a blank screen. I have full debug on so this is what happens.
> 
> Thanks for testing and gathering the logs.
> 
> Judging from the dmesg you've attached the via driver opens and closes the
> via drm node at least twice while starting X. Which explains why things
> blow up for you and Jakob already at startup. But ...

> Can you please retest with that and again grab the dmesg with full
> logging? Jakob reported that this still blows up, so there's a problem
> left somewhere. But I've rechecked the patches and couldn't see it.

Done. Using your latest branch.

Initializing cgroup subsys cpu
Linux version 3.2.0-rc6-openchrome+ (jsimmons@debian) (gcc version 4.6.2 
(Debian 4.6.2-7) ) #42 SMP Fri Dec 23 10:16:38 EST 2011
Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f400 (usable)
 BIOS-e820: 0009f400 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7bef (usable)
 BIOS-e820: 7bef - 7bef3000 (ACPI NVS)
 BIOS-e820: 7bef3000 - 7bf0 (ACPI data)
 BIOS-e820: fec0 - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007
e820 update range:  - 0001 (usable) ==> (reserved)
e820 remove range: 000a - 0010 (usable)
AGP bridge at 00:00:00
Aperture from AGP @ e800 old size 32 MB
Aperture from AGP @ e800 size 128 MB (APSIZE f20)
last_pfn = 0x7bef0 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C7FFF write-protect
  C8000-CBFFF uncachable
  CC000-D3FFF write-back
  D4000-F uncachable
MTRR variable ranges enabled:
  0 base 00 mask FFC000 write-back
  1 base 004000 mask FFE000 write-back
  2 base 006000 mask FFF000 write-back
  3 base 007000 mask FFF800 write-back
  4 base 007800 mask FFFC00 write-back
  5 base 007BF0 mask F0 uncachable
  6 base 00E800 mask FFF800 write-combining
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 2000
Base memory trampoline at [8809d000] 9d000 size 8192
init_memory_mapping: -7bef
 00 - 007be0 page 2M
 007be0 - 007bef page 4k
kernel direct mapping tables up to 7bef @ 1fffc000-2000
RAMDISK: 37aba000 - 37d55000
ACPI: RSDP 000f78c0 00014 (v00 VIAK8M)
ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E)
ACPI: FACS 7bef 00040
ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: Local APIC address 0xfee0
 [ea00-ea0001bf] PMD -> [88007960-88007b1f] 
on node 0
Zone PFN ranges:
  DMA  0x0010 -> 0x1000
  DMA320x1000 -> 0x0010
  Normal   empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x0010 -> 0x009f
0: 0x0100 -> 0x0007bef0
On node 0 totalpages: 507519
  DMA zone: 56 pages used for memmap
  DMA zone: 2 pages reserved
  DMA zone: 3925 pages, LIFO batch:0
  DMA32 zone: 6885 pages used for memmap
  DMA32 zone: 496651 pages, LIFO batch:31
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_gsi

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Rob Clark]

On Fri, Dec 23, 2011 at 4:00 AM, Semwal, Sumit  wrote:
> On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann  wrote:
>> On Tuesday 20 December 2011, Daniel Vetter wrote:
>>> > I'm thinking for a first version, we can get enough mileage out of it by 
>>> > saying:
>>> > 1) only exporter can mmap to userspace
>>> > 2) only importers that do not need CPU access to buffer..
>
> Thanks Rob - and the exporter can do the mmap outside of dma-buf
> usage, right?

Yes

> I mean, we don't need to provide an mmap to dma_buf()
> and restrict it to exporter, when the exporter has more 'control' of
> the buffer anyways.

No, if it is only for the exporter, it really doesn't need to be in
dmabuf (ie. the exporter already knows how he is)

BR,
-R

>>
> BR,
> ~Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

[Rob Clark]

On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit  wrote:
> On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie  wrote:
> 
>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases and start fleshing out the integration with
>>> various subsystem (like drm and v4l). All the things still under
>>> discussion like
>>> - userspace mmap support
>>> - more advanced (and more strictly specified) coherency models
>>> - and shared infrastructure for implementing exporters
>>> are imo much clearer once we have a few example drivers at hand and a
>>> better understanding of some of the insane corner cases we need to be able
>>> to handle.
>>>
>>> And I think any risk that the resulting clarifications will break a basic
>>> use-case is really minimal, so I think it'd be great if this could go into
>>> 3.3 (maybe as some kind of staging/experimental infrastructure).
>>>
>>> Hence for both patches:
>>> Reviewed-by: Daniel Vetter 
>>
>> Yeah I'm with Daniel, I like this one, I can definitely build the drm
>> buffer sharing layer on top of this.
>>
>> How do we see this getting merged? I'm quite happy to push it to Linus
>> if we don't have an identified path, though it could go via a Linaro
>> tree as well.
>>
>> so feel free to add:
>> Reviewed-by: Dave Airlie 
> Thanks Daniel and Dave!
>
> I guess we can start with staging for 3.3, and see how it shapes up. I
> will post the latest patch version pretty soon.

not sure about staging, but could make sense to mark as experimental.

> Arnd, Dave: do you have any preference on the path it takes to get
> merged? In my mind, Linaro tree might make more sense, but I would
> leave it upto you gentlemen.

Looks like Dave is making some progress on drm usage of buffer sharing
between gpu's.. if that is ready to go in at the same time, it might
be a bit logistically simpler for him to put dmabuf in the same pull
req.  I don't have strong preference one way or another, so do what is
collectively simpler ;-)

BR,
-R

>>
>> Dave.
> Best regards,
> ~Sumit.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: workaround invalid AVI infoframe checksum issue

[Rafał Miłecki]

Cc: sta...@vger.kernel.org
Signed-off-by: Rafał Miłecki 
---
I'd like to propose taking this patch into older releases. It's really
trivial while it fixes important feature.

This change was verified to fix both issues with no video I've
investigated. I've also checked checksum calculation with fglrx on:
RV620, HD54xx, HD5450, HD6310, HD6320.
---
 drivers/gpu/drm/radeon/r600_hdmi.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5021372..3db76ac 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -196,6 +196,13 @@ static void r600_hdmi_videoinfoframe(
frame[0xD] = (right_bar >> 8);
 
r600_hdmi_infoframe_checksum(0x82, 0x02, 0x0D, frame);
+   /* Our header values (type, version, length) should be alright, Intel
+* is using the same. Checksum function also seems to be OK, it works
+* fine for audio infoframe. However calculated value is always lower
+* by 2 in comparison to fglrx. It breaks displaying anything in case
+* of TVs that strictly check the checksum. Hack it manually here to
+* workaround this issue. */
+   frame[0x0] += 2;
 
WREG32(offset+R600_HDMI_VIDEOINFOFRAME_0,
frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | 
(frame[0x3] << 24));
-- 
1.7.7

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

[PATCH V3] drm/radeon/kms: setup HDMI mode on Evergreen encoders

[Rafał Miłecki]

Signed-off-by: Rafał Miłecki 
---
V3: the earlier V2 wasn't applied, so I resend it with some changes.
I've switched HDMI block calculation to use register offsets known from
CRCT. This should match better the rest of Evergreen code.

Dave: this is on top of drm-radeon-testing containing few earlier
patches

Merry Christmas :)
---
 drivers/gpu/drm/radeon/evergreen_reg.h |5 
 drivers/gpu/drm/radeon/r600_hdmi.c |   36 ---
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h 
b/drivers/gpu/drm/radeon/evergreen_reg.h
index 01cff84..fd38ba4 100644
--- a/drivers/gpu/drm/radeon/evergreen_reg.h
+++ b/drivers/gpu/drm/radeon/evergreen_reg.h
@@ -199,4 +199,9 @@
 #define EVERGREEN_DC_GPIO_HPD_EN0x64b8
 #define EVERGREEN_DC_GPIO_HPD_Y 0x64bc
 
+/* HDMI blocks at 0x7030, 0x7c30, 0x10830, 0x11430, 0x12030, 0x12c30 */
+#define EVERGREEN_HDMI_BASE0x7030
+
+#define EVERGREEN_HDMI_CONFIG_OFFSET   0xf0
+
 #endif
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 3db76ac..2c70a85 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -320,7 +320,7 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
struct radeon_device *rdev = dev->dev_private;
uint32_t offset = to_radeon_encoder(encoder)->hdmi_offset;
 
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;
 
if (!offset)
@@ -462,6 +462,15 @@ static void r600_hdmi_assign_block(struct drm_encoder 
*encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
 
+   u16 eg_offsets[] = {
+   EVERGREEN_CRTC0_REGISTER_OFFSET,
+   EVERGREEN_CRTC1_REGISTER_OFFSET,
+   EVERGREEN_CRTC2_REGISTER_OFFSET,
+   EVERGREEN_CRTC3_REGISTER_OFFSET,
+   EVERGREEN_CRTC4_REGISTER_OFFSET,
+   EVERGREEN_CRTC5_REGISTER_OFFSET,
+   };
+
if (!dig) {
dev_err(rdev->dev, "Enabling HDMI on non-dig encoder\n");
return;
@@ -470,7 +479,14 @@ static void r600_hdmi_assign_block(struct drm_encoder 
*encoder)
if (ASIC_IS_DCE5(rdev)) {
/* TODO */
} else if (ASIC_IS_DCE4(rdev)) {
-   /* TODO */
+   if (dig->dig_encoder >= ARRAY_SIZE(eg_offsets)) {
+   dev_err(rdev->dev, "Enabling HDMI on unknown dig\n");
+   return;
+   }
+   radeon_encoder->hdmi_offset = EVERGREEN_HDMI_BASE +
+   eg_offsets[dig->dig_encoder];
+   radeon_encoder->hdmi_config_offset = radeon_encoder->hdmi_offset
+   + EVERGREEN_HDMI_CONFIG_OFFSET;
} else if (ASIC_IS_DCE3(rdev)) {
radeon_encoder->hdmi_offset = dig->dig_encoder ?
R600_HDMI_BLOCK3 : R600_HDMI_BLOCK1;
@@ -493,7 +509,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t offset;
 
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;
 
if (!radeon_encoder->hdmi_offset) {
@@ -509,7 +525,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
if (ASIC_IS_DCE5(rdev)) {
/* TODO */
} else if (ASIC_IS_DCE4(rdev)) {
-   /* TODO */
+   WREG32_P(radeon_encoder->hdmi_config_offset + 0xc, 0x1, ~0x1);
} else if (ASIC_IS_DCE32(rdev)) {
WREG32_P(radeon_encoder->hdmi_config_offset + 0x4, 0x1, ~0x1);
} else if (ASIC_IS_DCE3(rdev)) {
@@ -533,8 +549,8 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
if (rdev->irq.installed
&& rdev->family != CHIP_RS600
&& rdev->family != CHIP_RS690
-   && rdev->family != CHIP_RS740) {
-
+   && rdev->family != CHIP_RS740
+   && !ASIC_IS_DCE4(rdev)) {
/* if irq is available use it */
rdev->irq.hdmi[offset == R600_HDMI_BLOCK1 ? 0 : 1] = true;
radeon_irq_set(rdev);
@@ -559,7 +575,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t offset;
 
-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;
 
offset = radeon_encoder->hdmi_offset;
@@ -578,7 +594,11 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
/* disable polling */
r600_audio_disable_polling(encoder);
 
-   if (ASIC_IS_DCE32(rdev) && !ASIC_IS_DCE4(rdev)) {
+   if (ASIC_IS_DCE5(rdev)) {
+   /* TODO

Re: [PATCH] drm/radeon/kms: workaround invalid AVI infoframe checksum issue

[Rafał Miłecki]

W dniu 23 grudnia 2011 20:32 użytkownik Rafał Miłecki
 napisał:
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rafał Miłecki 
> ---
> I'd like to propose taking this patch into older releases. It's really
> trivial while it fixes important feature.
>
> This change was verified to fix both issues with no video I've
> investigated. I've also checked checksum calculation with fglrx on:
> RV620, HD54xx, HD5450, HD6310, HD6320.

My cases I've used to check fglrx behavior:


[Rafał Miłecki][RV620] fglrx:
0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77



[Rafał Miłecki][HD6320] fglrx:
0x7c84: 00 A8 5E FE R600_HDMI_VIDEOINFOFRAME_0
0x7c88: 00 1C 00 04 R600_HDMI_VIDEOINFOFRAME_1
0x7c8c: 00 32 02 D2 R600_HDMI_VIDEOINFOFRAME_2
0x7c90: 02 00 06 3F R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x273 = 0x304
-0x304 = 0xFC



[Nirbheek C.][HD5450] fglrx:
0x10884 00 a8 5e 4f R600_HDMI_VIDEOINFOFRAME_0
0x10888 00 2b 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x1088c 00 4c 04 3b R600_HDMI_VIDEOINFOFRAME_2
0x10890 02 00 08 4c R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x222 = 0x2B3
-0x2B3 = 0x4D



[Radu A.][HD5400] fglrx:
0x10884 00 08 1e 22 R600_HDMI_VIDEOINFOFRAME_0
0x10888 00 00 00 00 R600_HDMI_VIDEOINFOFRAME_1
0x1088c 00 00 03 1c R600_HDMI_VIDEOINFOFRAME_2
0x10890 02 00 07 01 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x4F = 0xE0
-0xE0 = 0x20



[Zveroy][HD6310] fglrx:
0x7c84 00 08 1e 30  R600_HDMI_VIDEOINFOFRAME_0
0x7c88 00 00 00 00  R600_HDMI_VIDEOINFOFRAME_1
0x7c8c 00 00 03 1f  R600_HDMI_VIDEOINFOFRAME_2
0x7c90 02 00 06 f1  R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x141= 0x1D2
-0x1D2 = 0x2E


As you can see, the checksum we calculate is always too low by 0x2 in
comparison to fglrx.

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

Re: [PULL] remove drm_sman and some i815 fixes

[Daniel Vetter]

On Fri, Dec 23, 2011 at 03:36:25PM +, James Simmons wrote:
> 
> > > > > Last attempt at your branch still had problem. Start I didn't have 
> > > > > time 
> > > > > track down the exact issue. I'm cloning the below branch and will 
> > > > > test it.
> > > > > Thanks for cleanup.
> > > > 
> > > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock 
> > > > you've
> > > > reported and noticed that the X server fails to start up (and that the
> > > > kernel hangs). Is that the same you're seeing?
> > > 
> > > What was just merged to drm-next works fine. Its the reclaim buffer 
> > > patches that cause the problem. In my case the X server starts but I get  
> > > a blank screen. I have full debug on so this is what happens.
> > 
> > Thanks for testing and gathering the logs.
> > 
> > Judging from the dmesg you've attached the via driver opens and closes the
> > via drm node at least twice while starting X. Which explains why things
> > blow up for you and Jakob already at startup. But ...
> 
> > Can you please retest with that and again grab the dmesg with full
> > logging? Jakob reported that this still blows up, so there's a problem
> > left somewhere. But I've rechecked the patches and couldn't see it.
> 
> Done. Using your latest branch.

Ok, I've noticed another problem that might or might not be the issue
here. Updated my kill-with-fire branch. Direct link to the new patch:

http://cgit.freedesktop.org/~danvet/drm/patch/?id=b22d66d226aeb22371175b7f7d69b408bc4c1ef7

Thanks a lot for testing all this crap.

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

Re: GPU hung with Linux-3.2-rc6

[Keith Packard]

On Fri, 23 Dec 2011 09:55:34 -0200, Eugeni Dodonov  wrote:

> Could we revert it for SNB, and leave it enabled for IVB?

Yes, that's my plan. I don't want to ever disable it for IVB.

-- 
keith.pack...@intel.com


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

Re: GPU hung with Linux-3.2-rc6

[Keith Packard]

It would also be nice to know if disabling VT-d in the BIOS resolves
this issue, or if building the kernel with IOMMU support and then
forcibly disabling it with 'intel_iommu=off' fixes the problem. Given
that you can easily reproduce this, it would be good to know how your
machine differs from dozens of others which work fine with semaphores
turned on...

Oh, and the output of 'lspci -nn -vv' would be nice to see in case
you've got older (or newer) chips...

-- 
keith.pack...@intel.com


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

[PATCH] drm/i915: Disable semaphores by default on SNB

[Keith Packard]

Semaphores still cause problems on some machines:

> From Udo Steinberg:
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
>
>  I can reproduce it fairly easily with something
>  as simple as:
>
> while true; do dmesg; done

This patch turns them off on SNB while leaving them on for IVB.

Reported-by: Udo Steinberg 
Cc: Daniel Vetter 
Cc: Eugeni Dodonov 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c681dc1..0d4d308 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -758,7 +758,7 @@ intel_enable_semaphores(struct drm_device *dev)
 
/* Enable semaphores on SNB when IO remapping is off */
if (INTEL_INFO(dev)->gen == 6)
-   return !intel_iommu_enabled;
+   return 0;
 
return 1;
 }
-- 
1.7.7.3

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

Re: [PATCH] drm/i915: Disable semaphores by default on SNB

[Keith Packard]

On Fri, 23 Dec 2011 13:33:07 -0800, Keith Packard  wrote:

>   /* Enable semaphores on SNB when IO remapping is off */

Yeah, the comment is wrong now. I've updated this too:

-   /* Enable semaphores on SNB when IO remapping is off */
+   /* Enable semaphores on SNB */

-- 
keith.pack...@intel.com


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

[ANNOUNCE] intel-gpu-tools 1.1

[Daniel Vetter]

A bit early for a Xmas gift but way too late for a release, I've finally
managed to shove out a new intel-gpu-tools version. Too much stuff to list
here, and mostly only interesting for developers (who use the latest git
version anyway).

One thing though I'd like to highlight which is also useful for the wider
community of users and testers, is the improved test-suite for the kernel
drm: It's just a beginning but after compiling everything you can run (as
root, no X running)

 # make test

and watch your kernel die a pityful death. For a less quick death, my next
branch at

http://cgit.freedesktop.org/~danvet/drm/log/?h=my-next

contains fixes for all known issues this hits. Reports for any issues not yet
fixed there highly welcome.

Enjoy!
-Daniel

Adam Jackson (6):
  intel_reg_dumper: Add support for reading register dumps from files
  bios reader: Decode device type from child device table
  fix reg_dumper on systems without intel gpus
  Use longer string padding in intel_reg_dumper on ironlake
  bios_reader: Fix to work on non-Intel machines
  bios_reader: Allow forcing the device ID with DEVICE=0x

Ben Widawsky (13):
  Add MI_SUSPEND_FLUSH instruction decode
  Add C99 requirement to autoconf.
  forcewake: Add mmio code to do proper forcewake stuff for gen6
  intel-gpu-tools/range handling: register range handling
  intel-gpu-tools/forcewaked: sample forcewake app
  intel-gpu-tools/debugging: add important debug regs
  intel-gpu-tools/debugging: shader debugger
  tools/range handing: forgot the register map file :(
  tools: readme addition for shader debugging
  intel: we don't do distcheck for the debugger
  i-g-t/debugger: Only allow the shader debugger if the user has specified 
a gen4asm
  i-g-t/debugger - make the debugger work with distcheck
  intel-decode: fix flush dword post sync parse

Chris Wilson (112):
  Add: tools/intel_gpu_time
  decode: Split decoder and reuse outside of intel_gpu_dump
  decode/i965: Show byte lengths for buffers.
  reg: Include INSTPM in dump.
  gpu_dump: Parse INSTDONE if seen inside a file.
  intel_gpu_dump: Parse ringbuffer info from i915_error_state
  Add intel_error_decode.
  decode: Parse MI_BATCH_BUFFER for i8xx
  man: Add manpage for intel_error_decode
  decode: Fix length mask for LOAD_REGISTER_IMM.
  intel_error_decode: Pretty print i830 PGTBL_ER
  decode: Parse i915 MAP_STATE texture sizes and tiling
  decode: There are 4 unpreserved registers on i915, not 3.
  Enable compilation on non-Intel, non-DRM systems.
  gitignore: Add missing intel_reg_snapshot
  decode: CLEAR_PARAMETERS has a fixed length bias of 5.
  decode: CLEAR_RECT uses a fixed VERTEX_XY format.
  decode: There are 4 unpreserved registers on i915, not 3.
  decode: Use a valid S4 mask [VERTEX_XY] for 3DPRIM_CLEAR_RECT
  decode: Also override S2 for 3DPRIM_CLEAR_RECT
  decode; Parse 3DSTATE_BUFFER_INFO
  intel_reg_dump: Off-by-one in calculation of i965 fence pitch
  error: Decode i915 PGTBL errors
  dump decode: Add a non-installed program for decoding binary batchbuffer 
dumps.
  reg dumper: Add panel backlight detailed information
  decode: Handle errors during parsing.
  tests: Fix fallout from s/EBADF/ENOENT/ in 2.6.36
  reg dumper: Fix ilk panel fitter filter shift
  reg dumper: Dump ILK panel fitting control debug registers
  intel_gpu_top: Sample BSD rings as well as render
  Decode PGTBL_ER for i965
  Prepare for split BLT ring on Sandybridge.
  decode: Improve parsing of i915 fixed-length indexed primitives
  error-decode: Operate as a pipe and accept input from stdin
  dump-decode: allow specification of devid, i.e. gen
  decode: Add some missing protection against short buffers for gen6 instr
  gpu-dump: Include BLT and BSD ringbuffers
  decode: Add a couple of BLT MI.
  error-decode: stdin is 0 not 1
  Add a GTT timing test
  error decode: print out class of chipset in the error report
  intel_gpu_top: Wake the GT power well to read gen6 ring registers
  intel_gpu_top: Include BLT ring
  error: Parse ring name before gtt_offset
  gpu-top: Correct computation of ring size
  bios: Parse SDVO panel DTDs
  Add a GTT timing test
  Add a simple test to execute n nop batches
  Time blt vs pwrite
  Exercise the whole aperture with tiled blits
  tests/gem_tiled_fence_blits: Ensure the bo count is odd
  Search for the first Intel dri device.
  error decode: Search for first i915_error_state
  Simple test to ensure that working sets larger than memory, just work.
  Simplify gem_linear_blits
  gem_linear_blits: Minor enhancements
  gem_tiled_blits: Minor enhancements
  Fix typo excluding Ironlake from IS_INTEL
  Fix basic blt test for SNB
  gem_linear_blits,gem_tiled_blits: Add o

Re: TTM and AGP conflicts

[Jerome Glisse]

On Thu, Dec 22, 2011 at 8:19 PM, James Simmons  wrote:
>
>> > Hi!
>> >
>> >        I updated the openchrome tree and while testing on the AGP system
>> > discovered some interesting problems with the new TTM changes. The
>> > problems center around the ttm_tt_[un]populate which I modeled after the
>> > radeon and nouveau driver.
>> >        First problem I noticed was on a AGP system that my ttm_tt_populate
>> > function would oops. Tracking it down I found the problem was the
>> > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my
>> > ttm_tt_populate function would attempt to touch the dma_address it would
>> > oops. The second issue is the assumption of the cast for struct ttm_tt in
>> > both the populate and unpopulate function. For the AGP case the proper
>> > case would be to ttm_agp_backend.
>> >        At this point my assumption is the ttm_bo_move function has to be
>> > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
>> > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
>> > drivers I don't see that testing happening. Am I just missing something?
>>
>> Happens on AGP radeons as well:
>> https://bugs.freedesktop.org/show_bug.cgi?id=43719
>
>        So I'm not crazy, so this needs to be fixed. Here is what my
> understanding of the TTM layer is. My impression is that struct ttm_bo_driver
> handles multiple domains, AGP, pcie etc and in each method you have to
> handle each specific domain you support. Also *move gives the impression of
> moving between these different domains.
>        Where as for struct ttm_backend_func was more for allocating from
> a specific domain. Also I never saw a clear way to handle multiple backends.
> For example my AGP systems can also do pci dma as well.

Yes this need to be fixed, i am likely guilty, i tested agp along the
way but i must have miss something. If no one beat me to it i will get
back to this on january.

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

[Bug 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)

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

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

lsching17 at gmail.com changed:

   What|Removed |Added

  Attachment #54616|0   |1
is obsolete||

--- Comment #2 from lsching17 at gmail.com 2011-12-22 16:17:51 PST ---
Created attachment 54733
  --> https://bugs.freedesktop.org/attachment.cgi?id=54733
updated glxinfo

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

[Bug 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)

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

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

--- Comment #3 from lsching17 at gmail.com 2011-12-22 16:19:24 PST ---
Created attachment 54734
  --> https://bugs.freedesktop.org/attachment.cgi?id=54734
backtrace

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

[Bug 43993] 3d game in vmware workstation cause X hang up (ati Gallium r600)

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

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

--- Comment #4 from lsching17 at gmail.com 2011-12-22 16:21:35 PST ---
(In reply to comment #1)
> > I install ppa:oibaf/graphics-drivers on Ubuntu Oneiric x64
> 
> Does the problem also occur without the PPA?
> 
> 

Ubuntu Oneiric x64 do not come with s3tc, and the game do not run. in my point
of view, its mesa is "outdated"

> > When i run a old 3d game in vmware workstation 8.0.1, X hang up and i am 
> > forced
> > to hard-reboot.
> 
> I suspect the hang may be due to Workstation failing to release an X server
> grab.
> 
> 
> > 2011-12-21T08:16:58+08:00[+36.736]| mks| W110: VMGL Panic: *** Caught 
> > signal 11
> > in glXMakeContextCurrent() ***
> > 2011-12-21T08:16:58+08:00[+36.736]| mks| W110: VMGL Panic: Fault occurred at
> > 7FBBFAF7122B ((null) + -84471253, in 
> > /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
> 
> In order to get more information about this crash, can you try:
> 
> * Power on the VM.
> * Log in remotely via ssh, and attach gdb to the VM's vmware-vmx process. You
> may
>   need to enter 'handle SIGPIPE nostop noprint' at the gdb prompt to prevent
> gdb
>   from constantly interrupting the VM from executing.
> * Enter 'continue' at the gdb prompt, and start the game in the VM.
> * After the crash, enter 'bt full' at the gdb prompt, and attach the resulting
> output.
> 
> Make sure debugging symbols are available for
> /usr/lib/x86_64-linux-gnu/dri/r600_dri.so, e.g. by installing the
> libgl1-mesa-dri-dbg package.

sorry, that i accidentially update my ubuntu lsat night and the glxinfo is
updated.

backtrace is dumped and attached

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

TTM and AGP conflicts

[James Simmons]

> > Hi!
> >
> > ? ? ? ?I updated the openchrome tree and while testing on the AGP system
> > discovered some interesting problems with the new TTM changes. The
> > problems center around the ttm_tt_[un]populate which I modeled after the
> > radeon and nouveau driver.
> > ? ? ? ?First problem I noticed was on a AGP system that my ttm_tt_populate
> > function would oops. Tracking it down I found the problem was the
> > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my
> > ttm_tt_populate function would attempt to touch the dma_address it would
> > oops. The second issue is the assumption of the cast for struct ttm_tt in
> > both the populate and unpopulate function. For the AGP case the proper
> > case would be to ttm_agp_backend.
> > ? ? ? ?At this point my assumption is the ttm_bo_move function has to be
> > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
> > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
> > drivers I don't see that testing happening. Am I just missing something?
> 
> Happens on AGP radeons as well:
> https://bugs.freedesktop.org/show_bug.cgi?id=43719

So I'm not crazy, so this needs to be fixed. Here is what my 
understanding of the TTM layer is. My impression is that struct ttm_bo_driver
handles multiple domains, AGP, pcie etc and in each method you have to 
handle each specific domain you support. Also *move gives the impression of
moving between these different domains. 
Where as for struct ttm_backend_func was more for allocating from
a specific domain. Also I never saw a clear way to handle multiple backends. 
For example my AGP systems can also do pci dma as well. 

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

[Semwal, Sumit]

On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark  wrote:
> On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie  wrote:


>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases and start fleshing out the integration with
>>> various subsystem (like drm and v4l). All the things still under
>>> discussion like
>>> - userspace mmap support
>>> - more advanced (and more strictly specified) coherency models
>>> - and shared infrastructure for implementing exporters
>>> are imo much clearer once we have a few example drivers at hand and a
>>> better understanding of some of the insane corner cases we need to be able
>>> to handle.
>>>
>>> And I think any risk that the resulting clarifications will break a basic
>>> use-case is really minimal, so I think it'd be great if this could go into
>>> 3.3 (maybe as some kind of staging/experimental infrastructure).
>>>
>>> Hence for both patches:
>>> Reviewed-by: Daniel Vetter 
>>
>> Yeah I'm with Daniel, I like this one, I can definitely build the drm
>> buffer sharing layer on top of this.
>>
>> How do we see this getting merged? I'm quite happy to push it to Linus
>> if we don't have an identified path, though it could go via a Linaro
>> tree as well.
>>
>> so feel free to add:
>> Reviewed-by: Dave Airlie 
>
> fwiw, patches to share buffers between drm and v4l2 are here:
>
> https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
>
> (need a bit of cleanup before the vb2 patches are submitted.. but that
> is unrelated to the dmabuf patches)
>
> so,
>
> Reviewed-and-Tested-by: Rob Clark 
Thanks Daniel, Dave, and Rob!
BR,
Sumit.
>
>> Dave.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

please add datasheet URL to dri.freedesktop.org/wiki/SMedia

[Paul Wise]

Hi all,

Sean from OpenMoko recently released the SMedia Glamo datasheets[1].
Could someone with permission add them to the wiki page[2]?

My account (PaulWise) does not appear to be able to edit the page.

 1. http://people.openmoko.org/sean/datasheets/glamo3362/
 2. http://dri.freedesktop.org/wiki/SMedia

-- 
bye,
pabs

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

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Semwal, Sumit]

Hi Konrad,

On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
 wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> sharing of this buffer object across devices.
>>
>> The framework allows:
>> - different devices to 'attach' themselves to this buffer, to facilitate
>> ? backing storage negotiation, using dma_buf_attach() API.
>
> Any thoughts of adding facility to track them? So you can see who is using 
> what?
Not for version 1, but it would be a useful addition once we start
using this mechanism.

>
>> - association of a file pointer with each user-buffer and associated
>> ? ?allocator-defined operations on that buffer. This operation is called the
>> ? ?'export' operation.
>
> ?'create'? or 'alloc' ?
>
> export implies an import somwhere and I don't think that is the case here.
I will rephrase it as suggested by Rob as well.

>
>> - this exported buffer-object to be shared with the other entity by asking 
>> for
>> ? ?its 'file-descriptor (fd)', and sharing the fd across.
>> - a received fd to get the buffer object back, where it can be accessed using
>> ? ?the associated exporter-defined operations.
>> - the exporter and user to share the scatterlist using map_dma_buf and
>> ? ?unmap_dma_buf operations.
>>
>> Atleast one 'attach()' call is required to be made prior to calling the
>> map_dma_buf() operation.
>
> for the whole memory region or just for the device itself?
Rob has very eloquently and kindly explained it in his reply.

>
>>

>> +/*
>> + * is_dma_buf_file - Check if struct file* is associated with dma_buf
>> + */
>> +static inline int is_dma_buf_file(struct file *file)
>> +{
>> + ? ? return file->f_op == &dma_buf_fops;
>> +}
>> +
>> +/**
>
> Wrong kerneldoc.
I looked into scripts/kernel-doc, and
Documentation/kernel-doc-na-HOWTO.txt => both these places mention
that the kernel-doc comments have to start with /**, and I couldn't
spot an error in what's wrong with my usage - would you please
elaborate on what you think is not right?
>

>> +/**
>> + * struct dma_buf_attachment - holds device-buffer attachment data
>
> OK, but what is the purpose of it?
I will add that in the comments.
>
>> + * @dmabuf: buffer for this attachment.
>> + * @dev: device attached to the buffer.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this
>> + * @node: list_head to allow manipulation of list of dma_buf_attachment.
>
> Just say: "list of dma_buf_attachment"'
ok.
>
>> + * @priv: exporter-specific attachment data.
>
> That "exporter-specific.." brings to my mind custom decleration forms. But 
> maybe that is me.
:) well, in context of dma-buf 'exporter', it makes sense.

>
>> + */
>> +struct dma_buf_attachment {
>> + ? ? struct dma_buf *dmabuf;
>> + ? ? struct device *dev;
>> + ? ? struct list_head node;
>> + ? ? void *priv;
>> +};
>
> Why don't you move the decleration of this below 'struct dma_buf'?
> It would easier than to read this structure..
I could do that, but then anyways I will have to do a
forward-declaration of dma_buf_attachment, since I have to use it in
dma_buf_ops. If it improves readability, I am happy to move it below
struct dma_buf.

>
>> +
>> +/**
>> + * struct dma_buf_ops - operations possible on struct dma_buf
>> + * @attach: allows different devices to 'attach' themselves to the given
>
> register?
>> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage
>> + * ? ? ? is already allocated and incompatible with the requirements
>
> Wait.. allocated or attached?
This and above comment on 'register' are already answered by Rob in
his explanation of the sequence in earlier reply. [the Documentation
patch [2/2] also tries to explain it]

>
>> + * ? ? ? of requesting device. [optional]
>
> What is optional? The return value? Or the 'attach' call? If the later , say
> that in the first paragraph.
>
ok, sure. it is meant for the attach op.
>
>> + * @detach: detach a given device from this buffer. [optional]
>> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount
>> + * ? ? ? ? ? ?of the buffer. Requires atleast one attach to be called
>> + * ? ? ? ? ? ?before. Returned sg list should already be mapped into
>> + * ? ? ? ? ? ?_device_ address space. This call may sleep. May also return
>
> Ok, there is some __might_sleep macro you should put on the function.
>
That's a nice suggestion; I will add it to the wrapper function for
map_dma_buf().

>> + * ? ? ? ? ? ?-EINTR.
>
> Ok. What is the return code if attach has _not_ been called?
Will document it to return -EINVAL if atleast on attach() hasn't been called.

>
>> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter
>> + * ? ? ? ? ? ? ?pages.
>> + * @release: release this buffer; to be called after the last dma_buf_put.
>> + * @sync_sg_for_cpu: sync the sg list for cpu.
>> + * @sync_sg_for_device: synch the sg list for

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Semwal, Sumit]

On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann  wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by 
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to buffer..

Thanks Rob - and the exporter can do the mmap outside of dma-buf
usage, right? I mean, we don't need to provide an mmap to dma_buf()
and restrict it to exporter, when the exporter has more 'control' of
the buffer anyways.
>
BR,
~Sumit.

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

[Semwal, Sumit]

On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie  wrote:

>>
>> I think this is a really good v1 version of dma_buf. It contains all the
>> required bits (with well-specified semantics in the doc patch) to
>> implement some basic use-cases and start fleshing out the integration with
>> various subsystem (like drm and v4l). All the things still under
>> discussion like
>> - userspace mmap support
>> - more advanced (and more strictly specified) coherency models
>> - and shared infrastructure for implementing exporters
>> are imo much clearer once we have a few example drivers at hand and a
>> better understanding of some of the insane corner cases we need to be able
>> to handle.
>>
>> And I think any risk that the resulting clarifications will break a basic
>> use-case is really minimal, so I think it'd be great if this could go into
>> 3.3 (maybe as some kind of staging/experimental infrastructure).
>>
>> Hence for both patches:
>> Reviewed-by: Daniel Vetter 
>
> Yeah I'm with Daniel, I like this one, I can definitely build the drm
> buffer sharing layer on top of this.
>
> How do we see this getting merged? I'm quite happy to push it to Linus
> if we don't have an identified path, though it could go via a Linaro
> tree as well.
>
> so feel free to add:
> Reviewed-by: Dave Airlie 
Thanks Daniel and Dave!

I guess we can start with staging for 3.3, and see how it shapes up. I
will post the latest patch version pretty soon.

Arnd, Dave: do you have any preference on the path it takes to get
merged? In my mind, Linaro tree might make more sense, but I would
leave it upto you gentlemen.
>
> Dave.
Best regards,
~Sumit.

GPU hung with Linux-3.2-rc6

[Eugeni Dodonov]

On Thu, Dec 22, 2011 at 15:00, Keith Packard  wrote:

> On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg 
> wrote:
>
> > I quick google search suggests that at least some of them are too old to
> > support SNA.
>
> Sounds good. If you can capture the error as Daniel suggests, that would
> be great. In any case, I'll post a revert of the semaphore enable patch
> as it looks like that's still not working right...
>

Could we revert it for SNB, and leave it enabled for IVB?

It would be just the chunk which checks for intel_iommu status in the patch.

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111223/a9701825/attachment.htm>

[PULL] remove drm_sman and some i815 fixes

[Daniel Vetter]

On Thu, Dec 22, 2011 at 11:22:00PM +, James Simmons wrote:
> 
> > > > Hi Dave,
> > > > 
> > > > I've failed to correctly fix the via hang in the reclaim buffers rework
> > > > till now, so I'm only submitting the drm_sman removal of my drm cruft
> > > > removal series.
> > > 
> > > Last attempt at your branch still had problem. Start I didn't have time 
> > > track down the exact issue. I'm cloning the below branch and will test it.
> > > Thanks for cleanup.
> > 
> > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > reported and noticed that the X server fails to start up (and that the
> > kernel hangs). Is that the same you're seeing?
> 
> What was just merged to drm-next works fine. Its the reclaim buffer 
> patches that cause the problem. In my case the X server starts but I get  
> a blank screen. I have full debug on so this is what happens.

Thanks for testing and gathering the logs.

Judging from the dmesg you've attached the via driver opens and closes the
via drm node at least twice while starting X. Which explains why things
blow up for you and Jakob already at startup. But ...

[snip]

> diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
> index bedb23d..f29d0c5 100644
> --- a/drivers/gpu/drm/via/via_mm.c
> +++ b/drivers/gpu/drm/via/via_mm.c
> @@ -215,6 +215,10 @@ void via_reclaim_buffers_locked(struct drm_device *dev,
>  {
>   struct via_file_private *file_priv = file->driver_priv;
>   struct via_memblock *entry, *next;
> + int release_idlelock = 0;
> +
> + if (file->master && file->master->lock.hw_lock)
> + drm_idlelock_take(&file->master->lock);

This is still the old version of the patch, which doesn't set
release_idlelock properly. I've made double-sure that my branch a

http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire

contains the right patches (now rebased onto drm-next). Alternatively you
can just apply the via reclaim_buffers patch on top of drm-next:

http://cgit.freedesktop.org/~danvet/drm/commit/?h=kill-with-fire&id=a00a2f313d6e99f6c35d2abed094aa4ec94431e2

Can you please retest with that and again grab the dmesg with full
logging? Jakob reported that this still blows up, so there's a problem
left somewhere. But I've rechecked the patches and couldn't see it.

I'll be offline next week.

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

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

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

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

--- Comment #5 from Stefano Teso  2011-12-23 
07:29:54 PST ---
> But I'm no Mesa/Piglit expert, so my assumption might be wrong.

I have the very same issue here on evergreen, 32-bit userland on i7; debian
unstable.

mesa: git 2eafd07323891944b9c012a17359cd5f07a87890 (cloned as of today)
libdrm: 2.4.29-1
kernel: 3.2-rc6
xorg: 1.11.2.902-1

(BTW, when using gnome-shell, the corruption is fixed automatically after half
a second or so; using fluxbox, the screen stays corrupted.)

HTH,

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

[PULL] remove drm_sman and some i815 fixes

[James Simmons]

> > > > Last attempt at your branch still had problem. Start I didn't have time 
> > > > track down the exact issue. I'm cloning the below branch and will test 
> > > > it.
> > > > Thanks for cleanup.
> > > 
> > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock you've
> > > reported and noticed that the X server fails to start up (and that the
> > > kernel hangs). Is that the same you're seeing?
> > 
> > What was just merged to drm-next works fine. Its the reclaim buffer 
> > patches that cause the problem. In my case the X server starts but I get  
> > a blank screen. I have full debug on so this is what happens.
> 
> Thanks for testing and gathering the logs.
> 
> Judging from the dmesg you've attached the via driver opens and closes the
> via drm node at least twice while starting X. Which explains why things
> blow up for you and Jakob already at startup. But ...

> Can you please retest with that and again grab the dmesg with full
> logging? Jakob reported that this still blows up, so there's a problem
> left somewhere. But I've rechecked the patches and couldn't see it.

Done. Using your latest branch.

Initializing cgroup subsys cpu
Linux version 3.2.0-rc6-openchrome+ (jsimmons at debian) (gcc version 4.6.2 
(Debian 4.6.2-7) ) #42 SMP Fri Dec 23 10:16:38 EST 2011
Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=2539cb3b-47b9-47fc-81c1-97dabc51b2b2 ro drm.debug=255
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f400 (usable)
 BIOS-e820: 0009f400 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7bef (usable)
 BIOS-e820: 7bef - 7bef3000 (ACPI NVS)
 BIOS-e820: 7bef3000 - 7bf0 (ACPI data)
 BIOS-e820: fec0 - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
DMI: MICRO-STAR INTERNATIONAL CO., LTD MS-7312/MS-7312, BIOS V1.2 01/25/2007
e820 update range:  - 0001 (usable) ==> (reserved)
e820 remove range: 000a - 0010 (usable)
AGP bridge at 00:00:00
Aperture from AGP @ e800 old size 32 MB
Aperture from AGP @ e800 size 128 MB (APSIZE f20)
last_pfn = 0x7bef0 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
  0-9 write-back
  A-B uncachable
  C-C7FFF write-protect
  C8000-CBFFF uncachable
  CC000-D3FFF write-back
  D4000-F uncachable
MTRR variable ranges enabled:
  0 base 00 mask FFC000 write-back
  1 base 004000 mask FFE000 write-back
  2 base 006000 mask FFF000 write-back
  3 base 007000 mask FFF800 write-back
  4 base 007800 mask FFFC00 write-back
  5 base 007BF0 mask F0 uncachable
  6 base 00E800 mask FFF800 write-combining
  7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
initial memory mapped : 0 - 2000
Base memory trampoline at [8809d000] 9d000 size 8192
init_memory_mapping: -7bef
 00 - 007be0 page 2M
 007be0 - 007bef page 4k
kernel direct mapping tables up to 7bef @ 1fffc000-2000
RAMDISK: 37aba000 - 37d55000
ACPI: RSDP 000f78c0 00014 (v00 VIAK8M)
ACPI: RSDT 7bef3040 0002C (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: FACP 7bef30c0 00074 (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: DSDT 7bef3180 05396 (v01 VIAK8M AWRDACPI 1000 MSFT 010E)
ACPI: FACS 7bef 00040
ACPI: APIC 7bef8580 00068 (v01 VIAK8M AWRDACPI 42302E31 AWRD )
ACPI: Local APIC address 0xfee0
 [ea00-ea0001bf] PMD -> [88007960-88007b1f] 
on node 0
Zone PFN ranges:
  DMA  0x0010 -> 0x1000
  DMA320x1000 -> 0x0010
  Normal   empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x0010 -> 0x009f
0: 0x0100 -> 0x0007bef0
On node 0 totalpages: 507519
  DMA zone: 56 pages used for memmap
  DMA zone: 2 pages reserved
  DMA zone: 3925 pages, LIFO batch:0
  DMA32 zone: 6885 pages used for memmap
  DMA32 zone: 496651 pages, LIFO batch:31
Detected use of extended apic ids on hypertransport bus
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 2 CPUs, 0 hotplug CPUs
nr_irqs_

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Rob Clark]

On Fri, Dec 23, 2011 at 4:00 AM, Semwal, Sumit  wrote:
> On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann  wrote:
>> On Tuesday 20 December 2011, Daniel Vetter wrote:
>>> > I'm thinking for a first version, we can get enough mileage out of it by 
>>> > saying:
>>> > 1) only exporter can mmap to userspace
>>> > 2) only importers that do not need CPU access to buffer..
>
> Thanks Rob - and the exporter can do the mmap outside of dma-buf
> usage, right?

Yes

> I mean, we don't need to provide an mmap to dma_buf()
> and restrict it to exporter, when the exporter has more 'control' of
> the buffer anyways.

No, if it is only for the exporter, it really doesn't need to be in
dmabuf (ie. the exporter already knows how he is)

BR,
-R

>>
> BR,
> ~Sumit.

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

[Rob Clark]

On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit  wrote:
> On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie  wrote:
> 
>>>
>>> I think this is a really good v1 version of dma_buf. It contains all the
>>> required bits (with well-specified semantics in the doc patch) to
>>> implement some basic use-cases and start fleshing out the integration with
>>> various subsystem (like drm and v4l). All the things still under
>>> discussion like
>>> - userspace mmap support
>>> - more advanced (and more strictly specified) coherency models
>>> - and shared infrastructure for implementing exporters
>>> are imo much clearer once we have a few example drivers at hand and a
>>> better understanding of some of the insane corner cases we need to be able
>>> to handle.
>>>
>>> And I think any risk that the resulting clarifications will break a basic
>>> use-case is really minimal, so I think it'd be great if this could go into
>>> 3.3 (maybe as some kind of staging/experimental infrastructure).
>>>
>>> Hence for both patches:
>>> Reviewed-by: Daniel Vetter 
>>
>> Yeah I'm with Daniel, I like this one, I can definitely build the drm
>> buffer sharing layer on top of this.
>>
>> How do we see this getting merged? I'm quite happy to push it to Linus
>> if we don't have an identified path, though it could go via a Linaro
>> tree as well.
>>
>> so feel free to add:
>> Reviewed-by: Dave Airlie 
> Thanks Daniel and Dave!
>
> I guess we can start with staging for 3.3, and see how it shapes up. I
> will post the latest patch version pretty soon.

not sure about staging, but could make sense to mark as experimental.

> Arnd, Dave: do you have any preference on the path it takes to get
> merged? In my mind, Linaro tree might make more sense, but I would
> leave it upto you gentlemen.

Looks like Dave is making some progress on drm usage of buffer sharing
between gpu's.. if that is ready to go in at the same time, it might
be a bit logistically simpler for him to put dmabuf in the same pull
req.  I don't have strong preference one way or another, so do what is
collectively simpler ;-)

BR,
-R

>>
>> Dave.
> Best regards,
> ~Sumit.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

[PATCH] drm/radeon/kms: workaround invalid AVI infoframe checksum issue

[Rafał Miłecki]

Cc: stable at vger.kernel.org
Signed-off-by: Rafa? Mi?ecki 
---
I'd like to propose taking this patch into older releases. It's really
trivial while it fixes important feature.

This change was verified to fix both issues with no video I've
investigated. I've also checked checksum calculation with fglrx on:
RV620, HD54xx, HD5450, HD6310, HD6320.
---
 drivers/gpu/drm/radeon/r600_hdmi.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5021372..3db76ac 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -196,6 +196,13 @@ static void r600_hdmi_videoinfoframe(
frame[0xD] = (right_bar >> 8);

r600_hdmi_infoframe_checksum(0x82, 0x02, 0x0D, frame);
+   /* Our header values (type, version, length) should be alright, Intel
+* is using the same. Checksum function also seems to be OK, it works
+* fine for audio infoframe. However calculated value is always lower
+* by 2 in comparison to fglrx. It breaks displaying anything in case
+* of TVs that strictly check the checksum. Hack it manually here to
+* workaround this issue. */
+   frame[0x0] += 2;

WREG32(offset+R600_HDMI_VIDEOINFOFRAME_0,
frame[0x0] | (frame[0x1] << 8) | (frame[0x2] << 16) | 
(frame[0x3] << 24));
-- 
1.7.7

[PATCH V3] drm/radeon/kms: setup HDMI mode on Evergreen encoders

[Rafał Miłecki]

Signed-off-by: Rafa? Mi?ecki 
---
V3: the earlier V2 wasn't applied, so I resend it with some changes.
I've switched HDMI block calculation to use register offsets known from
CRCT. This should match better the rest of Evergreen code.

Dave: this is on top of drm-radeon-testing containing few earlier
patches

Merry Christmas :)
---
 drivers/gpu/drm/radeon/evergreen_reg.h |5 
 drivers/gpu/drm/radeon/r600_hdmi.c |   36 ---
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h 
b/drivers/gpu/drm/radeon/evergreen_reg.h
index 01cff84..fd38ba4 100644
--- a/drivers/gpu/drm/radeon/evergreen_reg.h
+++ b/drivers/gpu/drm/radeon/evergreen_reg.h
@@ -199,4 +199,9 @@
 #define EVERGREEN_DC_GPIO_HPD_EN0x64b8
 #define EVERGREEN_DC_GPIO_HPD_Y 0x64bc

+/* HDMI blocks at 0x7030, 0x7c30, 0x10830, 0x11430, 0x12030, 0x12c30 */
+#define EVERGREEN_HDMI_BASE0x7030
+
+#define EVERGREEN_HDMI_CONFIG_OFFSET   0xf0
+
 #endif
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 3db76ac..2c70a85 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -320,7 +320,7 @@ void r600_hdmi_setmode(struct drm_encoder *encoder, struct 
drm_display_mode *mod
struct radeon_device *rdev = dev->dev_private;
uint32_t offset = to_radeon_encoder(encoder)->hdmi_offset;

-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;

if (!offset)
@@ -462,6 +462,15 @@ static void r600_hdmi_assign_block(struct drm_encoder 
*encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;

+   u16 eg_offsets[] = {
+   EVERGREEN_CRTC0_REGISTER_OFFSET,
+   EVERGREEN_CRTC1_REGISTER_OFFSET,
+   EVERGREEN_CRTC2_REGISTER_OFFSET,
+   EVERGREEN_CRTC3_REGISTER_OFFSET,
+   EVERGREEN_CRTC4_REGISTER_OFFSET,
+   EVERGREEN_CRTC5_REGISTER_OFFSET,
+   };
+
if (!dig) {
dev_err(rdev->dev, "Enabling HDMI on non-dig encoder\n");
return;
@@ -470,7 +479,14 @@ static void r600_hdmi_assign_block(struct drm_encoder 
*encoder)
if (ASIC_IS_DCE5(rdev)) {
/* TODO */
} else if (ASIC_IS_DCE4(rdev)) {
-   /* TODO */
+   if (dig->dig_encoder >= ARRAY_SIZE(eg_offsets)) {
+   dev_err(rdev->dev, "Enabling HDMI on unknown dig\n");
+   return;
+   }
+   radeon_encoder->hdmi_offset = EVERGREEN_HDMI_BASE +
+   eg_offsets[dig->dig_encoder];
+   radeon_encoder->hdmi_config_offset = radeon_encoder->hdmi_offset
+   + EVERGREEN_HDMI_CONFIG_OFFSET;
} else if (ASIC_IS_DCE3(rdev)) {
radeon_encoder->hdmi_offset = dig->dig_encoder ?
R600_HDMI_BLOCK3 : R600_HDMI_BLOCK1;
@@ -493,7 +509,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t offset;

-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;

if (!radeon_encoder->hdmi_offset) {
@@ -509,7 +525,7 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
if (ASIC_IS_DCE5(rdev)) {
/* TODO */
} else if (ASIC_IS_DCE4(rdev)) {
-   /* TODO */
+   WREG32_P(radeon_encoder->hdmi_config_offset + 0xc, 0x1, ~0x1);
} else if (ASIC_IS_DCE32(rdev)) {
WREG32_P(radeon_encoder->hdmi_config_offset + 0x4, 0x1, ~0x1);
} else if (ASIC_IS_DCE3(rdev)) {
@@ -533,8 +549,8 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
if (rdev->irq.installed
&& rdev->family != CHIP_RS600
&& rdev->family != CHIP_RS690
-   && rdev->family != CHIP_RS740) {
-
+   && rdev->family != CHIP_RS740
+   && !ASIC_IS_DCE4(rdev)) {
/* if irq is available use it */
rdev->irq.hdmi[offset == R600_HDMI_BLOCK1 ? 0 : 1] = true;
radeon_irq_set(rdev);
@@ -559,7 +575,7 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t offset;

-   if (ASIC_IS_DCE4(rdev))
+   if (ASIC_IS_DCE5(rdev))
return;

offset = radeon_encoder->hdmi_offset;
@@ -578,7 +594,11 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
/* disable polling */
r600_audio_disable_polling(encoder);

-   if (ASIC_IS_DCE32(rdev) && !ASIC_IS_DCE4(rdev)) {
+   if (ASIC_IS_DCE5(rdev)) {
+   /* TODO */
+

[PATCH] drm/radeon/kms: workaround invalid AVI infoframe checksum issue

[Rafał Miłecki]

W dniu 23 grudnia 2011 20:32 u?ytkownik Rafa? Mi?ecki
 napisa?:
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Rafa? Mi?ecki 
> ---
> I'd like to propose taking this patch into older releases. It's really
> trivial while it fixes important feature.
>
> This change was verified to fix both issues with no video I've
> investigated. I've also checked checksum calculation with fglrx on:
> RV620, HD54xx, HD5450, HD6310, HD6320.

My cases I've used to check fglrx behavior:


[Rafa? Mi?ecki][RV620] fglrx:
0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77



[Rafa? Mi?ecki][HD6320] fglrx:
0x7c84: 00 A8 5E FE R600_HDMI_VIDEOINFOFRAME_0
0x7c88: 00 1C 00 04 R600_HDMI_VIDEOINFOFRAME_1
0x7c8c: 00 32 02 D2 R600_HDMI_VIDEOINFOFRAME_2
0x7c90: 02 00 06 3F R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x273 = 0x304
-0x304 = 0xFC



[Nirbheek C.][HD5450] fglrx:
0x10884 00 a8 5e 4f R600_HDMI_VIDEOINFOFRAME_0
0x10888 00 2b 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x1088c 00 4c 04 3b R600_HDMI_VIDEOINFOFRAME_2
0x10890 02 00 08 4c R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x222 = 0x2B3
-0x2B3 = 0x4D



[Radu A.][HD5400] fglrx:
0x10884 00 08 1e 22 R600_HDMI_VIDEOINFOFRAME_0
0x10888 00 00 00 00 R600_HDMI_VIDEOINFOFRAME_1
0x1088c 00 00 03 1c R600_HDMI_VIDEOINFOFRAME_2
0x10890 02 00 07 01 R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x4F = 0xE0
-0xE0 = 0x20



[Zveroy][HD6310] fglrx:
0x7c84 00 08 1e 30  R600_HDMI_VIDEOINFOFRAME_0
0x7c88 00 00 00 00  R600_HDMI_VIDEOINFOFRAME_1
0x7c8c 00 00 03 1f  R600_HDMI_VIDEOINFOFRAME_2
0x7c90 02 00 06 f1  R600_HDMI_VIDEOINFOFRAME_3
===
(0x82 + 0x2 + 0xD) + 0x141= 0x1D2
-0x1D2 = 0x2E


As you can see, the checksum we calculate is always too low by 0x2 in
comparison to fglrx.

-- 
Rafa?

[PULL] remove drm_sman and some i815 fixes

[Daniel Vetter]

On Fri, Dec 23, 2011 at 03:36:25PM +, James Simmons wrote:
> 
> > > > > Last attempt at your branch still had problem. Start I didn't have 
> > > > > time 
> > > > > track down the exact issue. I'm cloning the below branch and will 
> > > > > test it.
> > > > > Thanks for cleanup.
> > > > 
> > > > Jakob Bornecrantz quickly tested my attempt at fixing the deadlock 
> > > > you've
> > > > reported and noticed that the X server fails to start up (and that the
> > > > kernel hangs). Is that the same you're seeing?
> > > 
> > > What was just merged to drm-next works fine. Its the reclaim buffer 
> > > patches that cause the problem. In my case the X server starts but I get  
> > > a blank screen. I have full debug on so this is what happens.
> > 
> > Thanks for testing and gathering the logs.
> > 
> > Judging from the dmesg you've attached the via driver opens and closes the
> > via drm node at least twice while starting X. Which explains why things
> > blow up for you and Jakob already at startup. But ...
> 
> > Can you please retest with that and again grab the dmesg with full
> > logging? Jakob reported that this still blows up, so there's a problem
> > left somewhere. But I've rechecked the patches and couldn't see it.
> 
> Done. Using your latest branch.

Ok, I've noticed another problem that might or might not be the issue
here. Updated my kill-with-fire branch. Direct link to the new patch:

http://cgit.freedesktop.org/~danvet/drm/patch/?id=b22d66d226aeb22371175b7f7d69b408bc4c1ef7

Thanks a lot for testing all this crap.

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

GPU hung with Linux-3.2-rc6

[Keith Packard]

On Fri, 23 Dec 2011 09:55:34 -0200, Eugeni Dodonov  
wrote:

> Could we revert it for SNB, and leave it enabled for IVB?

Yes, that's my plan. I don't want to ever disable it for IVB.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111223/5ed7ace9/attachment.pgp>

GPU hung with Linux-3.2-rc6

[Keith Packard]

It would also be nice to know if disabling VT-d in the BIOS resolves
this issue, or if building the kernel with IOMMU support and then
forcibly disabling it with 'intel_iommu=off' fixes the problem. Given
that you can easily reproduce this, it would be good to know how your
machine differs from dozens of others which work fine with semaphores
turned on...

Oh, and the output of 'lspci -nn -vv' would be nice to see in case
you've got older (or newer) chips...

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111223/20dde04d/attachment.pgp>

[PATCH] drm/i915: Disable semaphores by default on SNB

[Keith Packard]

Semaphores still cause problems on some machines:

> From Udo Steinberg:
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
>
>  I can reproduce it fairly easily with something
>  as simple as:
>
> while true; do dmesg; done

This patch turns them off on SNB while leaving them on for IVB.

Reported-by: Udo Steinberg 
Cc: Daniel Vetter 
Cc: Eugeni Dodonov 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c681dc1..0d4d308 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -758,7 +758,7 @@ intel_enable_semaphores(struct drm_device *dev)

/* Enable semaphores on SNB when IO remapping is off */
if (INTEL_INFO(dev)->gen == 6)
-   return !intel_iommu_enabled;
+   return 0;

return 1;
 }
-- 
1.7.7.3

[PATCH] drm/i915: Disable semaphores by default on SNB

[Keith Packard]

On Fri, 23 Dec 2011 13:33:07 -0800, Keith Packard  wrote:

>   /* Enable semaphores on SNB when IO remapping is off */

Yeah, the comment is wrong now. I've updated this too:

-   /* Enable semaphores on SNB when IO remapping is off */
+   /* Enable semaphores on SNB */

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111223/17b778ab/attachment.pgp>

TTM and AGP conflicts

[Jerome Glisse]

On Thu, Dec 22, 2011 at 8:19 PM, James Simmons  
wrote:
>
>> > Hi!
>> >
>> > ? ? ? ?I updated the openchrome tree and while testing on the AGP system
>> > discovered some interesting problems with the new TTM changes. The
>> > problems center around the ttm_tt_[un]populate which I modeled after the
>> > radeon and nouveau driver.
>> > ? ? ? ?First problem I noticed was on a AGP system that my ttm_tt_populate
>> > function would oops. Tracking it down I found the problem was the
>> > ttm_agp_tt_create calls ttm_tt_init instead of ttm_dma_tt_init so once my
>> > ttm_tt_populate function would attempt to touch the dma_address it would
>> > oops. The second issue is the assumption of the cast for struct ttm_tt in
>> > both the populate and unpopulate function. For the AGP case the proper
>> > case would be to ttm_agp_backend.
>> > ? ? ? ?At this point my assumption is the ttm_bo_move function has to be
>> > rewritten to handle the AGP case to avoid calling ttm_tt_bind and in all
>> > cases ttm_tt_bind needs to be avoided. Looking at the radeon and nouveau
>> > drivers I don't see that testing happening. Am I just missing something?
>>
>> Happens on AGP radeons as well:
>> https://bugs.freedesktop.org/show_bug.cgi?id=43719
>
> ? ? ? ?So I'm not crazy, so this needs to be fixed. Here is what my
> understanding of the TTM layer is. My impression is that struct ttm_bo_driver
> handles multiple domains, AGP, pcie etc and in each method you have to
> handle each specific domain you support. Also *move gives the impression of
> moving between these different domains.
> ? ? ? ?Where as for struct ttm_backend_func was more for allocating from
> a specific domain. Also I never saw a clear way to handle multiple backends.
> For example my AGP systems can also do pci dma as well.

Yes this need to be fixed, i am likely guilty, i tested agp along the
way but i must have miss something. If no one beat me to it i will get
back to this on january.

Cheers,
Jerome