Re: [git pull] drm fixes
On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > in vblank. [...] > Ilija Hadzic (1): > drm/kernel: vblank wait on crtc > 1 This patch was still being debated yesterday, are you deliberately pushing it regardless? Once it hits mainline, it'll be pretty much set in stone. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix hardcoded EDID handling
On some servers there is a hardcoded EDID provided
in the vbios so that the driver will always see a
display connected even if something like a KVM
prevents traditional means like DDC or load
detection from working properly. Also most
server boards with DVI are not actually DVI, but
DVO connected to a virtual KVM service processor.
If we fail to detect a monitor via DDC or load
detection and a hardcoded EDID is available, use
it.
Additionally, when using the hardcoded EDID, use
a copy of it rather than the actual one stored
in the driver as the detect() and get_modes()
functions may free it if DDC is successful.
This fixes the virtual KVM on several internal
servers.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c| 21 ++
drivers/gpu/drm/radeon/radeon_connectors.c | 30 ++-
drivers/gpu/drm/radeon/radeon_mode.h |1 +
3 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6467b0a..8caf546 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -448,7 +448,7 @@ static uint16_t combios_get_table_offset(struct drm_device
*dev,
bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev)
{
- int edid_info;
+ int edid_info, size;
struct edid *edid;
unsigned char *raw;
edid_info = combios_get_table_offset(rdev->ddev,
COMBIOS_HARDCODED_EDID_TABLE);
@@ -456,11 +456,12 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
return false;
raw = rdev->bios + edid_info;
- edid = kmalloc(EDID_LENGTH * (raw[0x7e] + 1), GFP_KERNEL);
+ size = EDID_LENGTH * (raw[0x7e] + 1);
+ edid = kmalloc(size, GFP_KERNEL);
if (edid == NULL)
return false;
- memcpy((unsigned char *)edid, raw, EDID_LENGTH * (raw[0x7e] + 1));
+ memcpy((unsigned char *)edid, raw, size);
if (!drm_edid_is_valid(edid)) {
kfree(edid);
@@ -468,6 +469,7 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
}
rdev->mode_info.bios_hardcoded_edid = edid;
+ rdev->mode_info.bios_hardcoded_edid_size = size;
return true;
}
@@ -475,8 +477,17 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
struct edid *
radeon_bios_get_hardcoded_edid(struct radeon_device *rdev)
{
- if (rdev->mode_info.bios_hardcoded_edid)
- return rdev->mode_info.bios_hardcoded_edid;
+ struct edid *edid;
+
+ if (rdev->mode_info.bios_hardcoded_edid) {
+ edid = kmalloc(rdev->mode_info.bios_hardcoded_edid_size,
GFP_KERNEL);
+ if (edid) {
+ memcpy((unsigned char *)edid,
+ (unsigned char
*)rdev->mode_info.bios_hardcoded_edid,
+ rdev->mode_info.bios_hardcoded_edid_size);
+ return edid;
+ }
+ }
return NULL;
}
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 3f3c9aa..a186673 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -629,6 +629,8 @@ static int radeon_vga_mode_valid(struct drm_connector
*connector,
static enum drm_connector_status
radeon_vga_detect(struct drm_connector *connector, bool force)
{
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder;
struct drm_encoder_helper_funcs *encoder_funcs;
@@ -679,6 +681,17 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
if (ret == connector_status_connected)
ret = radeon_connector_analog_encoder_conflict_solve(connector,
encoder, ret, true);
+
+ /* RN50 and some RV100 asics in servers often have a hardcoded EDID in
the
+* vbios to deal with KVMs. If we have one and are not able to detect a
monitor
+* by other means, assume the CRT is connected and use that EDID.
+*/
+ if ((!rdev->is_atom_bios) &&
+ (ret == connector_status_disconnected) &&
+ rdev->mode_info.bios_hardcoded_edid_size) {
+ ret = connector_status_connected;
+ }
+
radeon_connector_update_scratch_regs(connector, ret);
return ret;
}
@@ -790,6 +803,8 @@ static int radeon_dvi_get_modes(struct drm_connector
*connector)
static enum drm_connector_status
radeon_dvi_detect(struct drm_connector *connector, bool force)
{
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_conn
Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On 03/22/2011 03:31 PM, Konrad Rzeszutek Wilk wrote: On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote: Hi, Konrad, Is passing a struct device to the DMA api really *strictly* necessary? Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require this. I'd like to avoid that at all cost, since we don't want pages that are backing buffer objects (coherent pages) to be associated with a specific device. The reason for this is that we probably soon will want to move ttm buffer objects between devices, and that should ideally be a simple operation: If the memory type the buffer object currently resides in is not shared between two devices, then move it out to system memory and change its struct bo_device pointer. I was thinking about this a bit after I found that the PowerPC requires the 'struct dev'. But I got a question first, what do you with pages that were allocated to a device that can do 64-bit DMA and then move it to a device than can 32-bit DMA? Obviously the 32-bit card would set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the process then? Allocate a new page from the 32-bit device and then copy over the page from the 64-bit TTM and put the 64-bit TTM page? Yes, in certain situations we need to copy, and if it's necessary in some cases to use coherent memory with a struct device assoicated with it, I agree it may be reasonable to do a copy in that case as well. I'm against, however, to make that the default case when running on bare metal. However, I've looked a bit deeper into all this, and it looks like we already have other problems that need to be addressed, and that exists with the code already in git: Consider a situation where you allocate a cached DMA32 page from the ttm page allocator. You'll end up with a coherent page. Then you make it uncached and finally you return it to the ttm page allocator. Since it's uncached, it will not be freed by the dma api, but kept in the uncached pool, and later the incorrect page free function will be called. I think we might need to take a few steps back and rethink this whole idea: 1) How does this work in the AGP case? Let's say you allocate write-combined DMA32 pages from the ttm page pool (in this case you won't get coherent memory) and then use them in an AGP gart? Why is it that we don't need coherent pages then in the Xen case? 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33 makes me scared. We should identify what platforms may have problems with this. 3) When hacking on the unichrome DMA engine it wasn't that hard to use the synchronization functions of the DMA api correctly: When binding a TTM, the backend calls dma_map_page() on pages, When unbinding, the backend calls dma_unmap_page(), If we need cpu access when bound, we need to call dma_sync_single_for_[cpu|device]. If this is done, it will be harder to implement user-space sub-allocation, but possible. There will be a performance loss on some platforms, though. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
2011/3/23 Michel Dänzer : > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs >> in vblank. > > [...] > >> Ilija Hadzic (1): >> drm/kernel: vblank wait on crtc > 1 > > This patch was still being debated yesterday, are you deliberately > pushing it regardless? Once it hits mainline, it'll be pretty much set > in stone. >From what I can see it was the userspace patches being debated, this one seemed fine and the interface looked okay to me. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > 2011/3/23 Michel Dänzer : > > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > >> > >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > >> in vblank. > > > > [...] > > > >> Ilija Hadzic (1): > >> drm/kernel: vblank wait on crtc > 1 > > > > This patch was still being debated yesterday, are you deliberately > > pushing it regardless? Once it hits mainline, it'll be pretty much set > > in stone. > > From what I can see it was the userspace patches being debated, this > one seemed fine and the interface looked okay to me. The author ignored my suggestions to make the patch smaller and simpler, more maintainable and more future-proof all at once. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #1 from Michel Dänzer 2011-03-23 01:47:44 PDT --- (In reply to comment #1) > actually i have updated Mesa from git, Which commit from which branch are you using? > 0x7f67e863854e in r600_bo (radeon=0x7f67e9c95d60, size=208, > alignment=4096, binding=32, usage=0) at r600_bo.c:43 Would be interesting if you could provide the output from running p *radeon at the gdb prompt here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] (revised) xf86-video-ati: add support for vblank on crtc > 1
On Die, 2011-03-22 at 22:15 -0400, Ilija Hadzic wrote: > > Enclosed is a revised version of the patch sent on Mar 18, against > the master branch of the xf86-video-ati. Details summarized in this thread: > http://lists.freedesktop.org/archives/dri-devel/2011-March/009463.html > > This patch reflects several comments posted to the list after the original > patch had been submitted. It *supersedes* the previous patch (i.e. apply > it to the master branch as it exists at the time of this writing, not > as an incremental patch to the one sent previously). > > No new functionality has been introduced. Apart from the sticking point about what to do when the ioctl doesn't work for the given CRTC, this looks good. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
2011/3/23 Michel Dänzer : > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: >> 2011/3/23 Michel Dänzer : >> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: >> >> >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs >> >> in vblank. >> > >> > [...] >> > >> >> Ilija Hadzic (1): >> >> drm/kernel: vblank wait on crtc > 1 >> > >> > This patch was still being debated yesterday, are you deliberately >> > pushing it regardless? Once it hits mainline, it'll be pretty much set >> > in stone. >> >> From what I can see it was the userspace patches being debated, this >> one seemed fine and the interface looked okay to me. > > The author ignored my suggestions to make the patch smaller and simpler, > more maintainable and more future-proof all at once. It was already small and I'm not sure merging the flags made it more maintainable. Its always being a slightly painful ioctl, and hopefully any future changes add a new ioctl esp if we want 64-bit values. The only comment I really thought was necessary was changing the CAP name, but since that isn't part of the ABI (just the number) we can quickly fix it with a follow-up. Dave. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Mit, 2011-03-23 at 19:06 +1000, Dave Airlie wrote: > 2011/3/23 Michel Dänzer : > > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > >> 2011/3/23 Michel Dänzer : > >> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > >> >> > >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > >> >> in vblank. > >> > > >> > [...] > >> > > >> >> Ilija Hadzic (1): > >> >> drm/kernel: vblank wait on crtc > 1 > >> > > >> > This patch was still being debated yesterday, are you deliberately > >> > pushing it regardless? Once it hits mainline, it'll be pretty much set > >> > in stone. > >> > >> From what I can see it was the userspace patches being debated, this > >> one seemed fine and the interface looked okay to me. > > > > The author ignored my suggestions to make the patch smaller and simpler, > > more maintainable and more future-proof all at once. > > It was already small and I'm not sure merging the flags made it more > maintainable. Having two holes between _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK can unnecessarily complicate future extensions. > Its always being a slightly painful ioctl, and hopefully any future > changes add a new ioctl esp if we want 64-bit values. Is there really a problem with assuming that if the 32-bit value went backwards, the upper 32 bits have incremented by 1? 1 << 32 refreshes is about 2 years, so I can't really see any ambiguity there. For hardware that doesn't have 64 bit frame counters (does any have that yet?), something like that needs to be done at some level anyway. Anyway, that's another discussion... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #2 from Henri Verbeet 2011-03-23 03:25:37 PDT --- I don't think that's from the driver you built yourself, the line numbers don't match current git. By default the drivers will be installed in /usr/local/, so you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and LD_LIBRARY_PATH="/usr/local/lib/". -- 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: [git pull] drm fixes
On Wed, 23 Mar 2011, Dave Airlie wrote: 2011/3/23 Michel Dänzer : On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: 2011/3/23 Michel Dänzer : On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs in vblank. [...] Ilija Hadzic (1): drm/kernel: vblank wait on crtc > 1 This patch was still being debated yesterday, are you deliberately pushing it regardless? Once it hits mainline, it'll be pretty much set in stone. From what I can see it was the userspace patches being debated, this one seemed fine and the interface looked okay to me. The author ignored my suggestions to make the patch smaller and simpler, more maintainable and more future-proof all at once. It was already small and I'm not sure merging the flags made it more maintainable. Its always being a slightly painful ioctl, and hopefully any future changes add a new ioctl esp if we want 64-bit values. The only comment I really thought was necessary was changing the CAP name, but since that isn't part of the ABI (just the number) we can quickly fix it with a follow-up. Dave. All of the issues debated yesterday, except one, boil down to renaming a handful on #defines without changing the values nor interface nor behavior of the kernel. For those that I agreed, I'll follow up with a small patch shortly. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #3 from Nicolas Peninguy 2011-03-23 04:45:43 PDT --- Mozilla only provides 32bits builds of Firefox I think, so you might need to build a i386 version of Mesa. -- 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: [git pull] drm fixes
On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote: > On Wed, 23 Mar 2011, Dave Airlie wrote: > > > 2011/3/23 Michel Dänzer : > >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > >>> 2011/3/23 Michel Dänzer : > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > > > > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > > in vblank. > > [...] > > > Ilija Hadzic (1): > > drm/kernel: vblank wait on crtc > 1 > > This patch was still being debated yesterday, are you deliberately > pushing it regardless? Once it hits mainline, it'll be pretty much set > in stone. > >>> > >>> From what I can see it was the userspace patches being debated, this > >>> one seemed fine and the interface looked okay to me. > >> > >> The author ignored my suggestions to make the patch smaller and simpler, > >> more maintainable and more future-proof all at once. > > > > It was already small and I'm not sure merging the flags made it more > > maintainable. Its always > > being a slightly painful ioctl, and hopefully any future changes add a > > new ioctl esp if we want 64-bit values. > > > > The only comment I really thought was necessary was changing the CAP > > name, but since that isn't > > part of the ABI (just the number) we can quickly fix it with a follow-up. > > > > Dave. > > All of the issues debated yesterday, except one, boil down to renaming a > handful on #defines without changing the values nor interface nor behavior > of the kernel. No, one central point is not to leave two holes between _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #4 from Henri Verbeet 2011-03-23 04:49:05 PDT --- (In reply to comment #3) > Mozilla only provides 32bits builds of Firefox I think, The backtrace looks very much like a 64-bit build. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
> >process then? Allocate a new page from the 32-bit device and then copy over
> >the
> >page from the 64-bit TTM and put the 64-bit TTM page?
>
> Yes, in certain situations we need to copy, and if it's necessary in
> some cases to use coherent memory with a struct device assoicated
> with it, I agree it may be reasonable to do a copy in that case as
> well. I'm against, however, to make that the default case when
> running on bare metal.
This situation could occur on native/baremetal. When you say 'default
case' you mean for every type of page without consulting whether it
had the TTM_PAGE_FLAG_DMA32?
>
> However, I've looked a bit deeper into all this, and it looks like
> we already have other problems that need to be addressed, and that
> exists with the code already in git:
>
> Consider a situation where you allocate a cached DMA32 page from the
> ttm page allocator. You'll end up with a coherent page. Then you
> make it uncached and finally you return it to the ttm page
> allocator. Since it's uncached, it will not be freed by the dma api,
> but kept in the uncached pool, and later the incorrect page free
> function will be called.
Let me look in details in the code, but I thought it would check the
TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
We could piggyback on the idea of the struct I had and have these
values:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *ttm_pool*origin;
}
And the origin would point to the correct pool so that on de-allocate
it would divert it to the original one. Naturally there would
be some thinking to be done on the de-alloc path so that
the *origin isn't pointing to something htat has already been free-d.
>
> I think we might need to take a few steps back and rethink this whole idea:
>
> 1) How does this work in the AGP case? Let's say you allocate
> write-combined DMA32 pages from the ttm page pool (in this case you
> won't get coherent memory) and then use them in an AGP gart? Why is
> it that we don't need coherent pages then in the Xen case?
Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
the AGP API and then to its backends to program that. And also the frontends
(so DRM, TTM) Here is the
patchset I posted some time ago:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
and the discussion:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
Dave recommended I skip AGP and just concentrate on PCIe since not to many
folks use AGP anymore. Thought I realized that server boards use PCI
cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
and I have a set of patches for this that I was in process of rebasing
on 2.6.39-rcX.
>
> 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
> makes me scared.
> We should identify what platforms may have problems with this.
Right.. I think nobody much thought about this in context of TTM since
that was only used on X86. I can take a look at the DMA API's of the
other two major platforms: IA64 and PPC and see what lurks there.
>
> 3) When hacking on the unichrome DMA engine it wasn't that hard to
> use the synchronization functions of the DMA api correctly:
>
> When binding a TTM, the backend calls dma_map_page() on pages, When
> unbinding, the backend calls dma_unmap_page(), If we need cpu access
> when bound, we need to call dma_sync_single_for_[cpu|device]. If
> this is done, it will be harder to implement user-space
> sub-allocation, but possible. There will be a performance loss on
> some platforms, though.
Yup. That was my other suggestion about this. But I had no idea
where to sprinkle those 'dma_sync_single_[*]' calls, as they would
have been done in the drivers. Probably on its DMA paths, right before
telling the GPU to process the CP, and when receiving an interrupt
when the CP has been completed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
I was thinking about this a bit after I found that the PowerPC requires
the 'struct dev'. But I got a question first, what do you with pages
that were allocated to a device that can do 64-bit DMA and then
move it to a device than can 32-bit DMA? Obviously the 32-bit card would
set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
process then? Allocate a new page from the 32-bit device and then copy over the
page from the 64-bit TTM and put the 64-bit TTM page?
Yes, in certain situations we need to copy, and if it's necessary in
some cases to use coherent memory with a struct device assoicated
with it, I agree it may be reasonable to do a copy in that case as
well. I'm against, however, to make that the default case when
running on bare metal.
This situation could occur on native/baremetal. When you say 'default
case' you mean for every type of page without consulting whether it
had the TTM_PAGE_FLAG_DMA32?
No, Basically I mean a device that runs perfectly fine with
alloc_pages(DMA32) on bare metal shouldn't need to be using
dma_alloc_coherent() on bare metal, because that would mean we'd need
to take the copy path above.
However, I've looked a bit deeper into all this, and it looks like
we already have other problems that need to be addressed, and that
exists with the code already in git:
Consider a situation where you allocate a cached DMA32 page from the
ttm page allocator. You'll end up with a coherent page. Then you
make it uncached and finally you return it to the ttm page
allocator. Since it's uncached, it will not be freed by the dma api,
but kept in the uncached pool, and later the incorrect page free
function will be called.
Let me look in details in the code, but I thought it would check the
TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
We could piggyback on the idea of the struct I had and have these
values:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *ttm_pool*origin;
}
And the origin would point to the correct pool so that on de-allocate
it would divert it to the original one. Naturally there would
be some thinking to be done on the de-alloc path so that
the *origin isn't pointing to something htat has already been free-d.
The idea with these pools is to keep a cache of write-combined pages, so
the pool
is determined by the caching status of the page when it is returned to
the page
allocator.
If we were to associate a page with a device, we'd basically need one
such pool per
device.
I think we might need to take a few steps back and rethink this whole idea:
1) How does this work in the AGP case? Let's say you allocate
write-combined DMA32 pages from the ttm page pool (in this case you
won't get coherent memory) and then use them in an AGP gart? Why is
it that we don't need coherent pages then in the Xen case?
Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
the AGP API and then to its backends to program that. And also the frontends
(so DRM, TTM) Here is the
patchset I posted some time ago:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
and the discussion:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
Dave recommended I skip AGP and just concentrate on PCIe since not to many
folks use AGP anymore. Thought I realized that server boards use PCI
cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
and I have a set of patches for this that I was in process of rebasing
on 2.6.39-rcX.
I see. Well, both in the AGP case and sometimes in the PCIe case,
(some devices can use a non-cache-coherent PCIe mode for speed)
it's a not too uncommon use case of TTM to alloc cached pages and
transition them to write-combined (see impact below).
2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
makes me scared.
We should identify what platforms may have problems with this.
Right.. I think nobody much thought about this in context of TTM since
that was only used on X86. I can take a look at the DMA API's of the
other two major platforms: IA64 and PPC and see what lurks there.
3) When hacking on the unichrome DMA engine it wasn't that hard to
use the synchronization functions of the DMA api correctly:
When binding a TTM, the backend calls dma_map_page() on pages, When
unbinding, the backend calls dma_unmap_page(), If we need cpu access
when bound, we need to call dma_sync_single_for_[cpu|device]. If
this is done, it will be harder to implement user-space
sub-allocation, but possible. There will be a performance loss on
some platforms, though.
Yup. That was my other suggestion about this. But I had no idea
where to sprinkle those 'dma_sync_single_[*]' calls, as they would
have been done in the drivers. Probably on its DMA paths, right before
telling the GPU to pr
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #35 from Ortwin Glück 2011-03-23 06:34:13 PDT --- Just out of curiosity, why is link training implemented on driver level and not on drm level? I see that nouvau and radeon each have their own implementation. The algorithm does not depend on the card, right? Only the way voltage, patterns etc are set does. Maybe by merging them the problem can be found. -- 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: Future desktop on dumb frame buffers?
On 21 March 2011 21:08, Alex Deucher wrote: > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > wrote: >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote: >>> On Mon, 21 Mar 2011 19:19:43 + >>> timofonic timofonic wrote: So if KMS is so cool and provides many advantages over fbdev and such... Why isn't more widely used intead of still relying on fbdev? Why still using fbdev emulation (that is partial and somewhat broken, it seems) instead using KMS directly? >>> >>> Used by what? All three major GPU device classes have KMS support >>> (Intel, ATI, and nVidia). If you want it for a particular device, you >>> can always port it over. >> >> The three major GPU device classes on PC... > > Sadly it gets worse. A lot of the SoC vendors are adding an fbdev > emulation layer on top of v4l rather than using fbdev directly or > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > I agree, it is sad that as a SoC vendor there are different kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say a Display controller driver. One must also remember that there are big differences between a desktop/PC multimedia/graphics system and the ones present on an embedded SoC. It is two very different cultures and HW designs now trying to merge into one Linux Kernel. Of course there will be some overlaps but I believe it can be sorted out as soon as we understand each others different possibilities/limitations. Doing duplicate work like HDMI will not benefit any party. Just to list some of the differences. - Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems. - Embedded devices usually have several different hw IP's managing displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, 2D blitters, Open GL ES hw, all of which have a separate device/driver in the kernel, while on a desktop nowadays all this functionality usually resides on ONE graphics card, hence one DRM device for all. - DRM is closely developed in conjunction with desktop/Xorg, while X11 on an embedded device is not very 2011...wayland on the other hand is :-), but do wayland really need the full potential of DRM/DRI or just parts of it. - Copying buffers is really bad for embedded devices due to lower memory bandwidth and power consumption while on a Desktop memory bandwidth is from an other galaxy (copying still bad but accepted it seems), AND embedded devices of today records and plays/displays 1080p content as well. - Not all embedded devices have MMU's for each IP requiring physical contiguous memory, while on a desktop MMU's have been present for ages. - Embedded devices are usually ARM based SoCs while x86 dominates the Desktop/Laptop market, and functionality provided is soon the very same. - yada yadaThe list can grow very longThere are also similarities of course. The outcome is that SoC vendors likes the embedded friendliness of v4l2 and fbdev while "we" also glance at the DRM part due to its de-facto standard on desktop environments. But from an embedded point of view DRM lacks the support for interconnecting multiple devices/drivers mentioned above, GEM/TTM is valid within a DRM device, the execution/context management is not needed,, no overlays(or similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but the rest of DRM will likely not be heavily used on SoCs unless running X11 as well. Most likely this worked on as well within the DRI community. I can see good features all over the place(sometimes duplicated) but not find one single guideline/API that solves all the embedded SoC problems (which involves use-cases optimized for no-copy cross media/drivers). Last but not least... On Linaro there is already discussions ongoing to solve one of the biggest issues from a SoC point of view and that is a "System Wide Memory manager" which manages buffer sharing and resolves no-copy use cases between devices/drivers. Read more on the following thread: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. BR /Robert Fekete st-ericsson ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next tree
On Wed, Mar 23, 2011 at 8:21 AM, Stephen Clark wrote: > On 03/22/2011 10:19 PM, Linus Torvalds wrote: >> >> So I had hoped - yes, very naïve of me, I know - that this merge >> window would be different. >> >> But it's not. >> >> On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: >> >>> >>> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. >>> >> >> .. and apparently a lot of breakage too. My crappy laptop that I abuse >> for travel is - once more - broken by the updates. I cannot suspend >> and resume, because every resume seems to fail. >> >> One of the more useful failures was: >> >> [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer >> elapsed... GPU hung >> [ 61.656079] [drm] capturing error event; look for more information >> in /debug/dri/0/i915_error_state >> [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request >> returns -11 (awaiting 2 at 0, next 3) >> >> and I'm attaching the error_state file from that particular case here. >> In other cases it seems to just hang entirely. >> >> Keith/Jesse/Chris - I don't know that it's i915, and it will take >> forever to bisect (I'll try). But it does seem pretty likely. >> >> Linus >> > > Why can't the gpu be reset/restarted when this happens? When a nic card gets > hung it is reinitialized > and restarted why not the gpu? > > -- GPU are so complex, i know case where reseting a GPU would lead to bring down the PCI and the CPU with it (basicly the reset clear some of the GPU memory controller bit but not the GPU PCI request queue, so after/while reseting the GPU trigger a several request to bogus address on the bus, then trigger a double fault and eventually a CPU shutdown) . Of course here we can blame the hw designer for not having a proper reset. All this vary from one GPU to another, it seems that reset have become more reliable on newer hw. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do you with pages
> >>>that were allocated to a device that can do 64-bit DMA and then
> >>>move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >>>set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
> >>>process then? Allocate a new page from the 32-bit device and then copy
> >>>over the
> >>>page from the 64-bit TTM and put the 64-bit TTM page?
> >>Yes, in certain situations we need to copy, and if it's necessary in
> >>some cases to use coherent memory with a struct device assoicated
> >>with it, I agree it may be reasonable to do a copy in that case as
> >>well. I'm against, however, to make that the default case when
> >>running on bare metal.
> >This situation could occur on native/baremetal. When you say 'default
> >case' you mean for every type of page without consulting whether it
> >had the TTM_PAGE_FLAG_DMA32?
>
> No, Basically I mean a device that runs perfectly fine with
> alloc_pages(DMA32) on bare metal shouldn't need to be using
> dma_alloc_coherent() on bare metal, because that would mean we'd need
> to take the copy path above.
I think we got the scenarios confused (or I did at least).
The scenario I used ("I was thinking.."), the 64-bit device would do
alloc_page(GFP_HIGHUSER) and if you were to move it to a 32-bit device
it would have to make a copy of the page as it could not reach the page
from GFP_HIGUSER.
The other scenario, which I think is what you are using, is that
we have a 32-bit device allocating a page, so TTM_PAGE_FLAG_DMA32 is set
and then we if we were to move it a 64-bit device it would need to
copied. But I don't think that is the case - the page would be
reachable by the 64-bit device. Help me out please if I am misunderstanding
this.
>
> >>However, I've looked a bit deeper into all this, and it looks like
> >>we already have other problems that need to be addressed, and that
> >>exists with the code already in git:
> >>
> >>Consider a situation where you allocate a cached DMA32 page from the
> >>ttm page allocator. You'll end up with a coherent page. Then you
> >>make it uncached and finally you return it to the ttm page
> >>allocator. Since it's uncached, it will not be freed by the dma api,
> >>but kept in the uncached pool, and later the incorrect page free
> >>function will be called.
> >Let me look in details in the code, but I thought it would check the
> >TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
> >
> >We could piggyback on the idea of the struct I had and have these
> >values:
> >
> >struct ttm_page {
> > struct page *page;
> > dma_addr_t *bus_addr;
> > struct *ttm_pool*origin;
> >}
> >
> >And the origin would point to the correct pool so that on de-allocate
> >it would divert it to the original one. Naturally there would
> >be some thinking to be done on the de-alloc path so that
> >the *origin isn't pointing to something htat has already been free-d.
>
> The idea with these pools is to keep a cache of write-combined
> pages, so the pool
> is determined by the caching status of the page when it is returned
> to the page
> allocator.
> If we were to associate a page with a device, we'd basically need
> one such pool per
> device.
OK, I think I get it. The issue here is that with the struct I mentioned
above is that a page that was initially allocated as coherent, and then
you make it uncached, and if you were to free it - it would go back
to the pool that only deals with 'coherent' - which is wrong.
I had an earlier suggestion which was:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *dev *dev;
}
this way even if it was to become uncached, you could still have it
associated with the right device. Granted at point the page is not
coherent anymore, it is uncached.
The problem is that on free-ing it is using the 'dma_free_coherent'
on a non-coherent page which it should not do. Would it be possible
then to make it coherent when we free it? Say as part of freeing
everything it would check what the original pool it belonged to
(so back to the struct with 'struct *ttm_pool *origin) and
convert it back to coherent as part of "moving" it to the original
pool?
> >}
>
>
> >>I think we might need to take a few steps back and rethink this whole idea:
> >>
> >>1) How does this work in the AGP case? Let's say you allocate
> >>write-combined DMA32 pages from the ttm page pool (in this case you
> >>won't get coherent memory) and then use them in an AGP gart? Why is
> >>it that we don't need coherent pages then in the Xen case?
> >Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
> >the AGP API and then to its backends to program that. And also the fronte
Re: [git pull] drm next tree
On 03/22/2011 10:19 PM, Linus Torvalds wrote: So I had hoped - yes, very naïve of me, I know - that this merge window would be different. But it's not. On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. .. and apparently a lot of breakage too. My crappy laptop that I abuse for travel is - once more - broken by the updates. I cannot suspend and resume, because every resume seems to fail. One of the more useful failures was: [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 61.656079] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 2 at 0, next 3) and I'm attaching the error_state file from that particular case here. In other cases it seems to just hang entirely. Keith/Jesse/Chris - I don't know that it's i915, and it will take forever to bisect (I'll try). But it does seem pretty likely. Linus Why can't the gpu be reset/restarted when this happens? When a nic card gets hung it is reinitialized and restarted why not the gpu? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
Hi Dave, On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: >> Adding support for common EDID parsing in kernel. >> >> EDID - Extended display identification data is a data structure provided by >> a digital display to describe its capabilities to a video source, This a >> standard supported by CEA and VESA. >> >> There are several custom implementations for parsing EDID in kernel, some >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally >> parsing of EDID should be done in a library, which is agnostic of the >> framework (V4l2, DRM, FB) which is using the functionality, just based on >> the raw EDID pointer with size/segment information. >> >> With other RFC's such as the one below, which tries to standardize HDMI API's >> It would be better to have a common EDID code in one place.It also helps to >> provide better interoperability with variety of TV/Monitor may be even by >> listing out quirks which might get missed with several custom implementation >> of EDID. >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 >> >> This patch tries to add functions to parse some portion EDID (detailed >> timing, >> monitor limits, AV delay information, deep color mode support, Audio and >> VSDB) >> If we can align on this library approach i can enhance this library to parse >> other blocks and probably we could also add quirks from other implementation >> as well. >> > > If you want to take this approach, you need to start from the DRM EDID parser, > its the most well tested and I can guarantee its been plugged into more > monitors > than any of the others. There is just no way we would move the DRM parser to a > library one that isn't derived from it + enhancements, as we'd throw away the > years of testing and the regression count would be way too high. > I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM. > Dave. > Thanks and regards, Mythri. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next tree
On Wed, Mar 23, 2011 at 3:19 AM, Linus Torvalds wrote: > So I had hoped - yes, very naïve of me, I know - that this merge > window would be different. > > But it's not. > > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: >> >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. > > .. and apparently a lot of breakage too. My crappy laptop that I abuse > for travel is - once more - broken by the updates. I cannot suspend > and resume, because every resume seems to fail. > > One of the more useful failures was: > > [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > elapsed... GPU hung > [ 61.656079] [drm] capturing error event; look for more information > in /debug/dri/0/i915_error_state > [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request > returns -11 (awaiting 2 at 0, next 3) > > and I'm attaching the error_state file from that particular case here. > In other cases it seems to just hang entirely. > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. Just in case - is it possible to have that commit in diff format ? Asking as 2.6.38-git2 is the latest kernel where my Latitude E6400 is displaying X at 1440x900, -git3 through -git6 do not compile and -git7 and onwards (up at least to -git11) display 1024x768 instead. If I run xrandr --fb 1440x900 --output LVDS1 --mode 1440x900 once in X, then I get 1440x900 display, but then: - the wallpaper's original 1024x768 image stays (the rest of the display area is filled with the part of image that should be there correctly at 1440x900) - if I run mplayer and ask it to go fullscreen, it does 1024x768 lspci (from 2.6.38-git2) says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0233 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at f6c0 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at ef98 [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 07) Subsystem: Dell Device 0233 Flags: bus master, fast devsel, latency 0 Memory at f6b0 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3 thanks, --alessandro "There's always a siren singing you to shipwreck" (Radiohead, "There There") ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm radeon: Return -EINVAL on wrong pm sysfs access
drm radeon: Return -EINVAL on wrong pm sysfs access
Throw an error if someone tries to fill this with
wrong data, instead of simply ignoring the input.
Now you get:
echo hello >/sys/../power_method
-bash: echo: write error: Invalid argument
Signed-off-by: Thomas Renninger
CC: alexander.deuc...@amd.com
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_pm.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 2aed03b..08de669 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -365,12 +365,14 @@ static ssize_t radeon_set_pm_profile(struct device *dev,
else if (strncmp("high", buf, strlen("high")) == 0)
rdev->pm.profile = PM_PROFILE_HIGH;
else {
- DRM_ERROR("invalid power profile!\n");
+ count = -EINVAL;
goto fail;
}
radeon_pm_update_profile(rdev);
radeon_pm_set_clocks(rdev);
- }
+ } else
+ count = -EINVAL;
+
fail:
mutex_unlock(&rdev->pm.mutex);
@@ -413,7 +415,7 @@ static ssize_t radeon_set_pm_method(struct device *dev,
mutex_unlock(&rdev->pm.mutex);
cancel_delayed_work_sync(&rdev->pm.dynpm_idle_work);
} else {
- DRM_ERROR("invalid power method!\n");
+ count = -EINVAL;
goto fail;
}
radeon_pm_compute_clocks(rdev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" wrote: > Hi Dave, > > On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: > >> Adding support for common EDID parsing in kernel. > >> > >> EDID - Extended display identification data is a data structure provided by > >> a digital display to describe its capabilities to a video source, This a > >> standard supported by CEA and VESA. > >> > >> There are several custom implementations for parsing EDID in kernel, some > >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > >> parsing of EDID should be done in a library, which is agnostic of the > >> framework (V4l2, DRM, FB) which is using the functionality, just based on > >> the raw EDID pointer with size/segment information. > >> > >> With other RFC's such as the one below, which tries to standardize HDMI > >> API's > >> It would be better to have a common EDID code in one place.It also helps to > >> provide better interoperability with variety of TV/Monitor may be even by > >> listing out quirks which might get missed with several custom > >> implementation > >> of EDID. > >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > >> > >> This patch tries to add functions to parse some portion EDID (detailed > >> timing, > >> monitor limits, AV delay information, deep color mode support, Audio and > >> VSDB) > >> If we can align on this library approach i can enhance this library to > >> parse > >> other blocks and probably we could also add quirks from other > >> implementation > >> as well. > >> > > > > If you want to take this approach, you need to start from the DRM EDID > > parser, > > its the most well tested and I can guarantee its been plugged into more > > monitors > > than any of the others. There is just no way we would move the DRM parser > > to a > > library one that isn't derived from it + enhancements, as we'd throw away > > the > > years of testing and the regression count would be way too high. > > > I had a look at the DRM EDID code, but for quirks it looks pretty much the > same. > yes i could take quirks and other DRM tested code and enhance, but > still the code has to do away with struct drm_display_mode > which is very much custom to DRM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Do you really think the differences between your code and the existing DRM code are irreconcilable? -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next tree
On Wed, 23 Mar 2011 08:21:53 -0400 Stephen Clark wrote: > On 03/22/2011 10:19 PM, Linus Torvalds wrote: > > So I had hoped - yes, very naïve of me, I know - that this merge > > window would be different. > > > > But it's not. > > > > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: > > > >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. > >> > > .. and apparently a lot of breakage too. My crappy laptop that I abuse > > for travel is - once more - broken by the updates. I cannot suspend > > and resume, because every resume seems to fail. > > > > One of the more useful failures was: > > > > [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 61.656079] [drm] capturing error event; look for more information > > in /debug/dri/0/i915_error_state > > [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request > > returns -11 (awaiting 2 at 0, next 3) > > > > and I'm attaching the error_state file from that particular case here. > > In other cases it seems to just hang entirely. > > > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > > forever to bisect (I'll try). But it does seem pretty likely. > > > > Linus > > > Why can't the gpu be reset/restarted when this happens? When a nic card > gets hung it is reinitialized > and restarted why not the gpu? Yeah, we try to restart in this case, but often just end up back in the same situation when the app runs again. We could be meaner about things and SIGILL the app, but often it's an innocent bystander, and the real problem is kernel object synchronization and/or the DRI driver generating bad commands. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next tree
On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds wrote: > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. Ok, so I'm still bisecting, but it's definitely the DRM pull. Current bisection log attached (the result does contain the fbdev pull from Paul Mundt, but that doesn't touch any files I compile afaik). Linus BISECT_LOG Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next tree
On Wed, 23 Mar 2011 08:29:35 -0700 Linus Torvalds wrote: > On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds > wrote: > > > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > > forever to bisect (I'll try). But it does seem pretty likely. > > Ok, so I'm still bisecting, but it's definitely the DRM pull. Current > bisection log attached (the result does contain the fbdev pull from > Paul Mundt, but that doesn't touch any files I compile afaik). Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this issue though, but it does seem a likely candidate. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #5 from Maximiliano Castañón 2011-03-23 08:48:13 PDT --- (In reply to comment #2) > I don't think that's from the driver you built yourself, the line numbers > don't > match current git. By default the drivers will be installed in /usr/local/, so > you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and > LD_LIBRARY_PATH="/usr/local/lib/". i will try it when i go to my house. What means that of "p *radeon" ? i need to run it in the gdb? And yes,i´m using the 64 bits version, it´s called x86_64 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Thank! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On Wed, Mar 23, 2011 at 8:51 AM, Konrad Rzeszutek Wilk
wrote:
>> >I was thinking about this a bit after I found that the PowerPC requires
>> >the 'struct dev'. But I got a question first, what do you with pages
>> >that were allocated to a device that can do 64-bit DMA and then
>> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
>> >set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
>> >process then? Allocate a new page from the 32-bit device and then copy over
>> >the
>> >page from the 64-bit TTM and put the 64-bit TTM page?
>>
>> Yes, in certain situations we need to copy, and if it's necessary in
>> some cases to use coherent memory with a struct device assoicated
>> with it, I agree it may be reasonable to do a copy in that case as
>> well. I'm against, however, to make that the default case when
>> running on bare metal.
>
> This situation could occur on native/baremetal. When you say 'default
> case' you mean for every type of page without consulting whether it
> had the TTM_PAGE_FLAG_DMA32?
>>
>> However, I've looked a bit deeper into all this, and it looks like
>> we already have other problems that need to be addressed, and that
>> exists with the code already in git:
>>
>> Consider a situation where you allocate a cached DMA32 page from the
>> ttm page allocator. You'll end up with a coherent page. Then you
>> make it uncached and finally you return it to the ttm page
>> allocator. Since it's uncached, it will not be freed by the dma api,
>> but kept in the uncached pool, and later the incorrect page free
>> function will be called.
>
> Let me look in details in the code, but I thought it would check the
> TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
>
> We could piggyback on the idea of the struct I had and have these
> values:
>
> struct ttm_page {
> struct page *page;
> dma_addr_t *bus_addr;
> struct *ttm_pool *origin;
> }
>
> And the origin would point to the correct pool so that on de-allocate
> it would divert it to the original one. Naturally there would
> be some thinking to be done on the de-alloc path so that
> the *origin isn't pointing to something htat has already been free-d.
>
>>
>> I think we might need to take a few steps back and rethink this whole idea:
>>
>> 1) How does this work in the AGP case? Let's say you allocate
>> write-combined DMA32 pages from the ttm page pool (in this case you
>> won't get coherent memory) and then use them in an AGP gart? Why is
>> it that we don't need coherent pages then in the Xen case?
>
> Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
> the AGP API and then to its backends to program that. And also the frontends
> (so DRM, TTM) Here is the
> patchset I posted some time ago:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
> and the discussion:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
>
> Dave recommended I skip AGP and just concentrate on PCIe since not to many
> folks use AGP anymore. Thought I realized that server boards use PCI
> cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
> and I have a set of patches for this that I was in process of rebasing
> on 2.6.39-rcX.
Actually the PCI gart mechanism uses cached pages rather than uncached
on the pre-pcie asics. On pcie asics, the on-board gart can use both
cached and uncached pages. There is a flag in the gpu's page table to
specify whether the pages need a snooped cycle or not. At the moment
we only use cached pages for the onboard gart, but there are
performance advantages for using uncached pages for certain types of
buffers (pretty much everything that doesn't require CPU reads). That
may be something we want to take advantage of in the future. FWIW,
all AGP radeons can use the onboard gart instead of or in addition to
AGP.
Alex
>
>>
>> 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
>> makes me scared.
>> We should identify what platforms may have problems with this.
>
> Right.. I think nobody much thought about this in context of TTM since
> that was only used on X86. I can take a look at the DMA API's of the
> other two major platforms: IA64 and PPC and see what lurks there.
>
>>
>> 3) When hacking on the unichrome DMA engine it wasn't that hard to
>> use the synchronization functions of the DMA api correctly:
>>
>> When binding a TTM, the backend calls dma_map_page() on pages, When
>> unbinding, the backend calls dma_unmap_page(), If we need cpu access
>> when bound, we need to call dma_sync_single_for_[cpu|device]. If
>> this is done, it will be harder to implement user-space
>> sub-allocation, but possible. There will be a performance loss on
>> some platforms, though.
>
> Yup. That was my other suggestion about this. But I had no idea
> where to sprinkle those 'dma_sync_single_[*]' calls, as they would
> have been done in the drivers. Probably on
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #36 from Alex Deucher 2011-03-23 09:46:22 PDT --- (In reply to comment #35) > Just out of curiosity, why is link training implemented on driver level and > not > on drm level? I see that nouvau and radeon each have their own implementation. > The algorithm does not depend on the card, right? Only the way voltage, > patterns etc are set does. Maybe by merging them the problem can be found. The link training algo is the same across all chips in theory (it's defined in a VESA spec). However, there are often a lot of asic specific things that need to be handled. It would probably be doable if you could figure out the right set of callbacks and driver adjustable fields to make all the drivers happy. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm radeon: Return -EINVAL on wrong pm sysfs access
On Wed, Mar 23, 2011 at 11:14 AM, Thomas Renninger wrote:
> drm radeon: Return -EINVAL on wrong pm sysfs access
>
> Throw an error if someone tries to fill this with
> wrong data, instead of simply ignoring the input.
> Now you get:
>
> echo hello >/sys/../power_method
> -bash: echo: write error: Invalid argument
>
> Signed-off-by: Thomas Renninger
> CC: alexander.deuc...@amd.com
> CC: dri-devel@lists.freedesktop.org
Looks good to me.
Reviewed-by: Alex Deucher
>
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 2aed03b..08de669 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -365,12 +365,14 @@ static ssize_t radeon_set_pm_profile(struct device *dev,
> else if (strncmp("high", buf, strlen("high")) == 0)
> rdev->pm.profile = PM_PROFILE_HIGH;
> else {
> - DRM_ERROR("invalid power profile!\n");
> + count = -EINVAL;
> goto fail;
> }
> radeon_pm_update_profile(rdev);
> radeon_pm_set_clocks(rdev);
> - }
> + } else
> + count = -EINVAL;
> +
> fail:
> mutex_unlock(&rdev->pm.mutex);
>
> @@ -413,7 +415,7 @@ static ssize_t radeon_set_pm_method(struct device *dev,
> mutex_unlock(&rdev->pm.mutex);
> cancel_delayed_work_sync(&rdev->pm.dynpm_idle_work);
> } else {
> - DRM_ERROR("invalid power method!\n");
> + count = -EINVAL;
> goto fail;
> }
> radeon_pm_compute_clocks(rdev);
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #6 from Maximiliano Castañón 2011-03-23 14:39:00 PDT --- well, i ran FF with: LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" LD_LIBRARY_PATH="/usr/local/lib/" MOZ_GLX_IGNORE_BLACKLIST=1 ./firefox it show various messages of: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable But it seems to work fine... the test of FPS with Mozilla gives me 4 FPS, but seems to work. I'm running mesa e4b040c2b -- 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: [git pull] drm next tree
On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes wrote: > > Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this > issue though, but it does seem a likely candidate. Yup, that revert fixes it for me. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #7 from Maximiliano Castañón 2011-03-23 21:39:07 PDT --- Ok, got another crash: Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7fde18eff700 (LWP 16893)] 0x7fde2b1ad57c in __libc_send (fd=72, buf=, n=, flags=) at ../sysdeps/unix/sysv/linux/x86_64/send.c:32 32../sysdeps/unix/sysv/linux/x86_64/send.c: No existe el fichero o el directorio. in ../sysdeps/unix/sysv/linux/x86_64/send.c (gdb) traceback Undefined command: "traceback". Try "help". (gdb) backtrace #0 0x7fde2b1ad57c in __libc_send (fd=72, buf=, n=, flags=) at ../sysdeps/unix/sysv/linux/x86_64/send.c:32 #1 0x7fde288d199d in ?? () #2 0x7fdd5ed6f005 in ?? () #3 0x7fde0a2ce6ba in ?? () #4 0x7fddd5b01068 in ?? () #5 0x7fddd5baf000 in ?? () #6 0x7fde2b49c040 in ?? () #7 0x7fddc1b3e6a0 in ?? () #8 0x0012 in ?? () #9 0x7fdda54040f0 in ?? () #10 0x in ?? () -- 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 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #8 from Maximiliano Castañón 2011-03-23 21:41:35 PDT --- Created an attachment (id=44773) --> (https://bugs.freedesktop.org/attachment.cgi?id=44773) traceback when i try to login it crashed. -- 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] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote: > Is passing a struct device to the DMA api really *strictly* necessary? > Yes. > I'd like to avoid that at all cost, since we don't want pages that are > backing buffer objects > (coherent pages) to be associated with a specific device. > And what do you do when coherent memory for a given device can only be obtained from that bus or that device alone? This API permits for cases where system memory is non-coherent or you are handling transactions across busses lacking coherency protocols between each other and so on. There are plenty of cases where coherent DMA buffers for PCI devices need to be allocated within the context of the PCI bus and no other coherent memory is possible. More complex examples exist as well. There are MFDs where DMA transactions are only coherent with regards to local SRAM that in turn is mapped in and out of an 8051 microcontroller's address space, and so on. The kernel deals with all of these sorts of cases by way of that dev pointer in the DMA API, and any attempt to move beyond that scope makes non-portable assumptions about the nature of coherent memory pools. > The reason for this is that we probably soon will want to move ttm > buffer objects between devices, and that should ideally be a simple > operation: If the memory type the buffer object currently resides in is > not shared between two devices, then move it out to system memory and > change its struct bo_device pointer. > > If pages are associated with a specific device, this will become much > harder. Basically we need to change backing pages and copy all the data. > That won't work if a device has consistent buffers locally but system memory is non-coherent. A not too uncommon situation for embedded platforms with a PCI bus hanging off of the CPU local bus.
[RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: > Adding support for common EDID parsing in kernel. > > EDID - Extended display identification data is a data structure provided by > a digital display to describe its capabilities to a video source, This a > standard supported by CEA and VESA. > > There are several custom implementations for parsing EDID in kernel, some > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > parsing of EDID should be done in a library, which is agnostic of the > framework (V4l2, DRM, FB) ?which is using the functionality, just based on > the raw EDID pointer with size/segment information. > > With other RFC's such as the one below, which tries to standardize HDMI API's > It would be better to have a common EDID code in one place.It also helps to > provide better interoperability with variety of TV/Monitor may be even by > listing out quirks which might get missed with several custom implementation > of EDID. > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > > This patch tries to add functions to parse some portion EDID (detailed timing, > monitor limits, AV delay information, deep color mode support, Audio and VSDB) > If we can align on this library approach i can enhance this library to parse > other blocks and probably we could also add quirks from other implementation > as well. > If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high. Dave.
[Bug 31712] New: GPU lockup CP stall after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=31712 Summary: GPU lockup CP stall after resume from hibernation Product: Drivers Version: 2.5 Kernel Version: 2.6.38 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: psusi at cfl.rr.com Regression: No When resuming from hibernation on my Asus P8P67 Pro Core-i5 2500K system with a Radeon 4850, I get a GPU lockup CP stall error, which leaves the display in a corrupt state. The kernel attempts to reset the display to no avail, landing back in the lockup again and again. A sysrq-K to kill X.org resolves the issue. The issue seems to be tied to plymouth. If I boot without the quiet and splash options when resuming, it resumes just fine. Suspend also works fine. This occurs with the stock Ubuntu Maverick 2.6.35 based kernel, the Natty 2.6.38 based kernel, and the Linus 2.6.38 kernel ( last two built from source ). The kernel log shows: Mar 22 22:34:34 faldara kernel: [ 808.672904] [ cut here ] Mar 22 22:34:34 faldara kernel: [ 808.672926] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:248 radeon_fence_wait+0x40f/0x470 [radeon]() Mar 22 22:34:34 faldara kernel: [ 808.672929] Hardware name: System Product Name Mar 22 22:34:34 faldara kernel: [ 808.672931] GPU lockup (waiting for 0x3DCC last fence id 0x3DC8) Mar 22 22:34:34 faldara kernel: [ 808.672933] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat binfmt_misc kvm_intel kvm parport_pc ppdev dm_crypt dm_zero snd_hda_codec_hdmi snd_hda_codec_realtek snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_hda_intel snd_hda_codec snd_hwdep ath3k btusb snd_pcm bluetooth pkgtemp snd_timer eeepc_wmi snd_seq_device sparse_keymap snd joydev psmouse soundcore snd_page_alloc serio_raw lp parport raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx raid1 raid0 multipath linear btrfs zlib_deflate crc32c libcrc32c hid_microsoft usbhid hid usb_storage radeon ttm firewire_ohci firewire_core drm_kms_helper crc_itu_t drm i2c_algo_bit ahci e1000e libahci intel_agp intel_gtt [last unloaded: xhci_hcd] Mar 22 22:34:34 faldara kernel: [ 808.672984] Pid: 8039, comm: Xorg Tainted: G W 2.6.38 #13 Mar 22 22:34:34 faldara kernel: [ 808.672986] Call Trace: Mar 22 22:34:34 faldara kernel: [ 808.672994] [] ? warn_slowpath_common+0x7f/0xc0 Mar 22 22:34:34 faldara kernel: [ 808.672998] [] ? warn_slowpath_fmt+0x46/0x50 Mar 22 22:34:34 faldara kernel: [ 808.673011] [] ? radeon_fence_wait+0x40f/0x470 [radeon] Mar 22 22:34:34 faldara kernel: [ 808.673015] [] ? autoremove_wake_function+0x0/0x40 Mar 22 22:34:34 faldara kernel: [ 808.673027] [] ? radeon_sync_obj_wait+0x11/0x20 [radeon] Mar 22 22:34:34 faldara kernel: [ 808.673034] [] ? ttm_bo_wait+0x103/0x1c0 [ttm] Mar 22 22:34:34 faldara kernel: [ 808.673040] [] ? ttm_bo_list_ref_sub+0x28/0x30 [ttm] Mar 22 22:34:34 faldara kernel: [ 808.673055] [] ? radeon_gem_wait_idle_ioctl+0x93/0x110 [radeon] Mar 22 22:34:34 faldara kernel: [ 808.673063] [] ? drm_ioctl+0x42b/0x4e0 [drm] Mar 22 22:34:34 faldara kernel: [ 808.673076] [] ? radeon_gem_wait_idle_ioctl+0x0/0x110 [radeon] Mar 22 22:34:34 faldara kernel: [ 808.673080] [] ? save_i387_xstate+0x165/0x230 Mar 22 22:34:34 faldara kernel: [ 808.673085] [] ? _raw_spin_lock_irq+0x15/0x20 Mar 22 22:34:34 faldara kernel: [ 808.673089] [] ? do_signal+0x182/0x7d0 Mar 22 22:34:34 faldara kernel: [ 808.673093] [] ? do_vfs_ioctl+0xa5/0x5a0 Mar 22 22:34:34 faldara kernel: [ 808.673096] [] ? sys_ioctl+0xa1/0xb0 Mar 22 22:34:34 faldara kernel: [ 808.673100] [] ? system_call_fastpath+0x16/0x1b Mar 22 22:34:34 faldara kernel: [ 808.673103] ---[ end trace 746c9b8991f7ff2a ]--- Mar 22 22:34:34 faldara kernel: [ 808.673111] [drm] Disabling audio support Mar 22 22:34:34 faldara kernel: [ 808.689259] radeon :01:00.0: GPU softreset Mar 22 22:34:34 faldara kernel: [ 808.689261] radeon :01:00.0: R_008010_GRBM_STATUS=0xA27034A4 Mar 22 22:34:34 faldara kernel: [ 808.689262] radeon :01:00.0: R_008014_GRBM_STATUS2=0x0102 Mar 22 22:34:34 faldara kernel: [ 808.689263] radeon :01:00.0: R_000E50_SRBM_STATUS=0x20C0 Mar 22 22:34:34 faldara kernel: [ 808.689269] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE Mar 22 22:34:34 faldara kernel: [ 808.704257] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x0001 Mar 22 22:34:34 faldara kernel: [ 808.720245] radeon :01:00.0: R_008010_GRBM_STATUS=0x3028 Mar 22 22:34:34 faldara kernel: [ 808.720246] radeon :01:00.0: R_008014_GRBM_STATUS2=0x0002 Mar 22 22:34:34 faldara kernel: [ 808.720248] radeon :01:00.0: R_000E50_SRBM_STATUS=0x20C0 Mar 22 22:34:34 faldara kernel: [ 808.721248] radeon :01:00.0: GPU reset succeed Mar 22 22:34:34 faldara kernel: [ 808.
[git pull] drm fixes
Hi Linus, One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs in vblank. hopefully the Intel guys can give me some updates on the s/r issue tomorrow. Dave. The following changes since commit c87a8d8dcd2587c203f3dd8a3c5c15d1e128ec0d: drm/radeon: fixup refcounts in radeon dumb create ioctl. (2011-03-17 13:58:34 +1000) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (1): drm/radeon/kms: prefer legacy pll algo for tv-out Chris Wilson (1): drm: Fix use-after-free in drm_gem_vm_close() Dave Airlie (1): drm: check for modesetting on modeset ioctls Ilija Hadzic (1): drm/kernel: vblank wait on crtc > 1 drivers/gpu/drm/drm_crtc.c | 51 drivers/gpu/drm/drm_gem.c |5 ++- drivers/gpu/drm/drm_ioctl.c|3 ++ drivers/gpu/drm/drm_irq.c | 15 ++--- drivers/gpu/drm/radeon/atombios_crtc.c |6 +++- include/drm/drm.h |3 ++ 6 files changed, 75 insertions(+), 8 deletions(-)
[git pull] drm fixes
On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > in vblank. [...] > Ilija Hadzic (1): > drm/kernel: vblank wait on crtc > 1 This patch was still being debated yesterday, are you deliberately pushing it regardless? Once it hits mainline, it'll be pretty much set in stone. -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[PATCH] drm/radeon/kms: fix hardcoded EDID handling
On some servers there is a hardcoded EDID provided
in the vbios so that the driver will always see a
display connected even if something like a KVM
prevents traditional means like DDC or load
detection from working properly. Also most
server boards with DVI are not actually DVI, but
DVO connected to a virtual KVM service processor.
If we fail to detect a monitor via DDC or load
detection and a hardcoded EDID is available, use
it.
Additionally, when using the hardcoded EDID, use
a copy of it rather than the actual one stored
in the driver as the detect() and get_modes()
functions may free it if DDC is successful.
This fixes the virtual KVM on several internal
servers.
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c| 21 ++
drivers/gpu/drm/radeon/radeon_connectors.c | 30 ++-
drivers/gpu/drm/radeon/radeon_mode.h |1 +
3 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 6467b0a..8caf546 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -448,7 +448,7 @@ static uint16_t combios_get_table_offset(struct drm_device
*dev,
bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev)
{
- int edid_info;
+ int edid_info, size;
struct edid *edid;
unsigned char *raw;
edid_info = combios_get_table_offset(rdev->ddev,
COMBIOS_HARDCODED_EDID_TABLE);
@@ -456,11 +456,12 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
return false;
raw = rdev->bios + edid_info;
- edid = kmalloc(EDID_LENGTH * (raw[0x7e] + 1), GFP_KERNEL);
+ size = EDID_LENGTH * (raw[0x7e] + 1);
+ edid = kmalloc(size, GFP_KERNEL);
if (edid == NULL)
return false;
- memcpy((unsigned char *)edid, raw, EDID_LENGTH * (raw[0x7e] + 1));
+ memcpy((unsigned char *)edid, raw, size);
if (!drm_edid_is_valid(edid)) {
kfree(edid);
@@ -468,6 +469,7 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
}
rdev->mode_info.bios_hardcoded_edid = edid;
+ rdev->mode_info.bios_hardcoded_edid_size = size;
return true;
}
@@ -475,8 +477,17 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
struct edid *
radeon_bios_get_hardcoded_edid(struct radeon_device *rdev)
{
- if (rdev->mode_info.bios_hardcoded_edid)
- return rdev->mode_info.bios_hardcoded_edid;
+ struct edid *edid;
+
+ if (rdev->mode_info.bios_hardcoded_edid) {
+ edid = kmalloc(rdev->mode_info.bios_hardcoded_edid_size,
GFP_KERNEL);
+ if (edid) {
+ memcpy((unsigned char *)edid,
+ (unsigned char
*)rdev->mode_info.bios_hardcoded_edid,
+ rdev->mode_info.bios_hardcoded_edid_size);
+ return edid;
+ }
+ }
return NULL;
}
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 3f3c9aa..a186673 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -629,6 +629,8 @@ static int radeon_vga_mode_valid(struct drm_connector
*connector,
static enum drm_connector_status
radeon_vga_detect(struct drm_connector *connector, bool force)
{
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder;
struct drm_encoder_helper_funcs *encoder_funcs;
@@ -679,6 +681,17 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
if (ret == connector_status_connected)
ret = radeon_connector_analog_encoder_conflict_solve(connector,
encoder, ret, true);
+
+ /* RN50 and some RV100 asics in servers often have a hardcoded EDID in
the
+* vbios to deal with KVMs. If we have one and are not able to detect a
monitor
+* by other means, assume the CRT is connected and use that EDID.
+*/
+ if ((!rdev->is_atom_bios) &&
+ (ret == connector_status_disconnected) &&
+ rdev->mode_info.bios_hardcoded_edid_size) {
+ ret = connector_status_connected;
+ }
+
radeon_connector_update_scratch_regs(connector, ret);
return ret;
}
@@ -790,6 +803,8 @@ static int radeon_dvi_get_modes(struct drm_connector
*connector)
static enum drm_connector_status
radeon_dvi_detect(struct drm_connector *connector, bool force)
{
+ struct drm_device *dev = connector->dev;
+ struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector
[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On 03/22/2011 03:31 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote: > >> Hi, Konrad, >> >> Is passing a struct device to the DMA api really *strictly* necessary? >> > Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require > this. > >> I'd like to avoid that at all cost, since we don't want pages that >> are backing buffer objects >> (coherent pages) to be associated with a specific device. >> >> The reason for this is that we probably soon will want to move ttm >> buffer objects between devices, and that should ideally be a simple >> operation: If the memory type the buffer object currently resides in >> is not shared between two devices, then move it out to system memory >> and change its struct bo_device pointer. >> > I was thinking about this a bit after I found that the PowerPC requires > the 'struct dev'. But I got a question first, what do you with pages > that were allocated to a device that can do 64-bit DMA and then > move it to a device than can 32-bit DMA? Obviously the 32-bit card would > set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the > process then? Allocate a new page from the 32-bit device and then copy over > the > page from the 64-bit TTM and put the 64-bit TTM page? > Yes, in certain situations we need to copy, and if it's necessary in some cases to use coherent memory with a struct device assoicated with it, I agree it may be reasonable to do a copy in that case as well. I'm against, however, to make that the default case when running on bare metal. However, I've looked a bit deeper into all this, and it looks like we already have other problems that need to be addressed, and that exists with the code already in git: Consider a situation where you allocate a cached DMA32 page from the ttm page allocator. You'll end up with a coherent page. Then you make it uncached and finally you return it to the ttm page allocator. Since it's uncached, it will not be freed by the dma api, but kept in the uncached pool, and later the incorrect page free function will be called. I think we might need to take a few steps back and rethink this whole idea: 1) How does this work in the AGP case? Let's say you allocate write-combined DMA32 pages from the ttm page pool (in this case you won't get coherent memory) and then use them in an AGP gart? Why is it that we don't need coherent pages then in the Xen case? 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33 makes me scared. We should identify what platforms may have problems with this. 3) When hacking on the unichrome DMA engine it wasn't that hard to use the synchronization functions of the DMA api correctly: When binding a TTM, the backend calls dma_map_page() on pages, When unbinding, the backend calls dma_unmap_page(), If we need cpu access when bound, we need to call dma_sync_single_for_[cpu|device]. If this is done, it will be harder to implement user-space sub-allocation, but possible. There will be a performance loss on some platforms, though. /Thomas
[git pull] drm fixes
2011/3/23 Michel D?nzer : > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs >> in vblank. > > [...] > >> Ilija Hadzic (1): >> ? ? ? drm/kernel: vblank wait on crtc > 1 > > This patch was still being debated yesterday, are you deliberately > pushing it regardless? Once it hits mainline, it'll be pretty much set > in stone.
No subject
one seemed fine and the interface looked okay to me. Dave.
[git pull] drm fixes
On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > 2011/3/23 Michel D?nzer : > > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > >> > >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > >> in vblank. > > > > [...] > > > >> Ilija Hadzic (1): > >> drm/kernel: vblank wait on crtc > 1 > > > > This patch was still being debated yesterday, are you deliberately > > pushing it regardless? Once it hits mainline, it'll be pretty much set > > in stone. > > From what I can see it was the userspace patches being debated, this > one seemed fine and the interface looked okay to me. The author ignored my suggestions to make the patch smaller and simpler, more maintainable and more future-proof all at once. -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #1 from Michel D?nzer 2011-03-23 01:47:44 PDT --- (In reply to comment #1) > actually i have updated Mesa from git, Which commit from which branch are you using? > 0x7f67e863854e in r600_bo (radeon=0x7f67e9c95d60, size=208, > alignment=4096, binding=32, usage=0) at r600_bo.c:43 Would be interesting if you could provide the output from running p *radeon at the gdb prompt here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] (revised) xf86-video-ati: add support for vblank on crtc > 1
On Die, 2011-03-22 at 22:15 -0400, Ilija Hadzic wrote: > > Enclosed is a revised version of the patch sent on Mar 18, against > the master branch of the xf86-video-ati. Details summarized in this thread: > http://lists.freedesktop.org/archives/dri-devel/2011-March/009463.html > > This patch reflects several comments posted to the list after the original > patch had been submitted. It *supersedes* the previous patch (i.e. apply > it to the master branch as it exists at the time of this writing, not > as an incremental patch to the one sent previously). > > No new functionality has been introduced. Apart from the sticking point about what to do when the ioctl doesn't work for the given CRTC, this looks good. -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[git pull] drm fixes
2011/3/23 Michel D?nzer : > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: >> 2011/3/23 Michel D?nzer : >> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: >> >> >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs >> >> in vblank. >> > >> > [...] >> > >> >> Ilija Hadzic (1): >> >> ? ? ? drm/kernel: vblank wait on crtc > 1 >> > >> > This patch was still being debated yesterday, are you deliberately >> > pushing it regardless? Once it hits mainline, it'll be pretty much set >> > in stone. >> >> From what I can see it was the userspace patches being debated, this >> one seemed fine and the interface looked okay to me. > > The author ignored my suggestions to make the patch smaller and simpler, > more maintainable and more future-proof all at once. It was already small and I'm not sure merging the flags made it more maintainable. Its always being a slightly painful ioctl, and hopefully any future changes add a new ioctl esp if we want 64-bit values. The only comment I really thought was necessary was changing the CAP name, but since that isn't part of the ABI (just the number) we can quickly fix it with a follow-up. Dave. Dave.
[git pull] drm fixes
On Mit, 2011-03-23 at 19:06 +1000, Dave Airlie wrote: > 2011/3/23 Michel D?nzer : > > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > >> 2011/3/23 Michel D?nzer : > >> > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > >> >> > >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > >> >> in vblank. > >> > > >> > [...] > >> > > >> >> Ilija Hadzic (1): > >> >> drm/kernel: vblank wait on crtc > 1 > >> > > >> > This patch was still being debated yesterday, are you deliberately > >> > pushing it regardless? Once it hits mainline, it'll be pretty much set > >> > in stone. > >> > >> From what I can see it was the userspace patches being debated, this > >> one seemed fine and the interface looked okay to me. > > > > The author ignored my suggestions to make the patch smaller and simpler, > > more maintainable and more future-proof all at once. > > It was already small and I'm not sure merging the flags made it more > maintainable. Having two holes between _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK can unnecessarily complicate future extensions. > Its always being a slightly painful ioctl, and hopefully any future > changes add a new ioctl esp if we want 64-bit values. Is there really a problem with assuming that if the 32-bit value went backwards, the upper 32 bits have incremented by 1? 1 << 32 refreshes is about 2 years, so I can't really see any ambiguity there. For hardware that doesn't have 64 bit frame counters (does any have that yet?), something like that needs to be done at some level anyway. Anyway, that's another discussion... -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #2 from Henri Verbeet 2011-03-23 03:25:37 PDT --- I don't think that's from the driver you built yourself, the line numbers don't match current git. By default the drivers will be installed in /usr/local/, so you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and LD_LIBRARY_PATH="/usr/local/lib/". -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes
On Wed, 23 Mar 2011, Dave Airlie wrote: > 2011/3/23 Michel D?nzer : >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: >>> 2011/3/23 Michel D?nzer : On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > in vblank. [...] > Ilija Hadzic (1): > ? ? ? drm/kernel: vblank wait on crtc > 1 This patch was still being debated yesterday, are you deliberately pushing it regardless? Once it hits mainline, it'll be pretty much set in stone. >>> >>> From what I can see it was the userspace patches being debated, this >>> one seemed fine and the interface looked okay to me. >> >> The author ignored my suggestions to make the patch smaller and simpler, >> more maintainable and more future-proof all at once. > > It was already small and I'm not sure merging the flags made it more > maintainable. Its always > being a slightly painful ioctl, and hopefully any future changes add a > new ioctl esp if we want 64-bit values. > > The only comment I really thought was necessary was changing the CAP > name, but since that isn't > part of the ABI (just the number) we can quickly fix it with a follow-up. > > Dave. All of the issues debated yesterday, except one, boil down to renaming a handful on #defines without changing the values nor interface nor behavior of the kernel. For those that I agreed, I'll follow up with a small patch shortly. -- Ilija
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #3 from Nicolas Peninguy 2011-03-23 04:45:43 PDT --- Mozilla only provides 32bits builds of Firefox I think, so you might need to build a i386 version of Mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes
On Mit, 2011-03-23 at 06:40 -0500, Ilija Hadzic wrote: > On Wed, 23 Mar 2011, Dave Airlie wrote: > > > 2011/3/23 Michel D?nzer : > >> On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote: > >>> 2011/3/23 Michel D?nzer : > On Mit, 2011-03-23 at 04:18 +, Dave Airlie wrote: > > > > One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs > > in vblank. > > [...] > > > Ilija Hadzic (1): > > drm/kernel: vblank wait on crtc > 1 > > This patch was still being debated yesterday, are you deliberately > pushing it regardless? Once it hits mainline, it'll be pretty much set > in stone. > >>> > >>> From what I can see it was the userspace patches being debated, this > >>> one seemed fine and the interface looked okay to me. > >> > >> The author ignored my suggestions to make the patch smaller and simpler, > >> more maintainable and more future-proof all at once. > > > > It was already small and I'm not sure merging the flags made it more > > maintainable. Its always > > being a slightly painful ioctl, and hopefully any future changes add a > > new ioctl esp if we want 64-bit values. > > > > The only comment I really thought was necessary was changing the CAP > > name, but since that isn't > > part of the ABI (just the number) we can quickly fix it with a follow-up. > > > > Dave. > > All of the issues debated yesterday, except one, boil down to renaming a > handful on #defines without changing the values nor interface nor behavior > of the kernel. No, one central point is not to leave two holes between _DRM_VBLANK_FLAGS_MASK, _DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK . -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #4 from Henri Verbeet 2011-03-23 04:49:05 PDT --- (In reply to comment #3) > Mozilla only provides 32bits builds of Firefox I think, The backtrace looks very much like a 64-bit build. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
> >I was thinking about this a bit after I found that the PowerPC requires
> >the 'struct dev'. But I got a question first, what do you with pages
> >that were allocated to a device that can do 64-bit DMA and then
> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
> >process then? Allocate a new page from the 32-bit device and then copy over
> >the
> >page from the 64-bit TTM and put the 64-bit TTM page?
>
> Yes, in certain situations we need to copy, and if it's necessary in
> some cases to use coherent memory with a struct device assoicated
> with it, I agree it may be reasonable to do a copy in that case as
> well. I'm against, however, to make that the default case when
> running on bare metal.
This situation could occur on native/baremetal. When you say 'default
case' you mean for every type of page without consulting whether it
had the TTM_PAGE_FLAG_DMA32?
>
> However, I've looked a bit deeper into all this, and it looks like
> we already have other problems that need to be addressed, and that
> exists with the code already in git:
>
> Consider a situation where you allocate a cached DMA32 page from the
> ttm page allocator. You'll end up with a coherent page. Then you
> make it uncached and finally you return it to the ttm page
> allocator. Since it's uncached, it will not be freed by the dma api,
> but kept in the uncached pool, and later the incorrect page free
> function will be called.
Let me look in details in the code, but I thought it would check the
TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
We could piggyback on the idea of the struct I had and have these
values:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *ttm_pool*origin;
}
And the origin would point to the correct pool so that on de-allocate
it would divert it to the original one. Naturally there would
be some thinking to be done on the de-alloc path so that
the *origin isn't pointing to something htat has already been free-d.
>
> I think we might need to take a few steps back and rethink this whole idea:
>
> 1) How does this work in the AGP case? Let's say you allocate
> write-combined DMA32 pages from the ttm page pool (in this case you
> won't get coherent memory) and then use them in an AGP gart? Why is
> it that we don't need coherent pages then in the Xen case?
Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
the AGP API and then to its backends to program that. And also the frontends
(so DRM, TTM) Here is the
patchset I posted some time ago:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
and the discussion:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
Dave recommended I skip AGP and just concentrate on PCIe since not to many
folks use AGP anymore. Thought I realized that server boards use PCI
cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
and I have a set of patches for this that I was in process of rebasing
on 2.6.39-rcX.
>
> 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
> makes me scared.
> We should identify what platforms may have problems with this.
Right.. I think nobody much thought about this in context of TTM since
that was only used on X86. I can take a look at the DMA API's of the
other two major platforms: IA64 and PPC and see what lurks there.
>
> 3) When hacking on the unichrome DMA engine it wasn't that hard to
> use the synchronization functions of the DMA api correctly:
>
> When binding a TTM, the backend calls dma_map_page() on pages, When
> unbinding, the backend calls dma_unmap_page(), If we need cpu access
> when bound, we need to call dma_sync_single_for_[cpu|device]. If
> this is done, it will be harder to implement user-space
> sub-allocation, but possible. There will be a performance loss on
> some platforms, though.
Yup. That was my other suggestion about this. But I had no idea
where to sprinkle those 'dma_sync_single_[*]' calls, as they would
have been done in the drivers. Probably on its DMA paths, right before
telling the GPU to process the CP, and when receiving an interrupt
when the CP has been completed.
[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
>>> I was thinking about this a bit after I found that the PowerPC requires
>>> the 'struct dev'. But I got a question first, what do you with pages
>>> that were allocated to a device that can do 64-bit DMA and then
>>> move it to a device than can 32-bit DMA? Obviously the 32-bit card would
>>> set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
>>> process then? Allocate a new page from the 32-bit device and then copy over
>>> the
>>> page from the 64-bit TTM and put the 64-bit TTM page?
>>>
>> Yes, in certain situations we need to copy, and if it's necessary in
>> some cases to use coherent memory with a struct device assoicated
>> with it, I agree it may be reasonable to do a copy in that case as
>> well. I'm against, however, to make that the default case when
>> running on bare metal.
>>
> This situation could occur on native/baremetal. When you say 'default
> case' you mean for every type of page without consulting whether it
> had the TTM_PAGE_FLAG_DMA32?
>
No, Basically I mean a device that runs perfectly fine with
alloc_pages(DMA32) on bare metal shouldn't need to be using
dma_alloc_coherent() on bare metal, because that would mean we'd need
to take the copy path above.
>> However, I've looked a bit deeper into all this, and it looks like
>> we already have other problems that need to be addressed, and that
>> exists with the code already in git:
>>
>> Consider a situation where you allocate a cached DMA32 page from the
>> ttm page allocator. You'll end up with a coherent page. Then you
>> make it uncached and finally you return it to the ttm page
>> allocator. Since it's uncached, it will not be freed by the dma api,
>> but kept in the uncached pool, and later the incorrect page free
>> function will be called.
>>
> Let me look in details in the code, but I thought it would check the
> TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
>
> We could piggyback on the idea of the struct I had and have these
> values:
>
> struct ttm_page {
> struct page *page;
> dma_addr_t *bus_addr;
> struct *ttm_pool*origin;
> }
>
> And the origin would point to the correct pool so that on de-allocate
> it would divert it to the original one. Naturally there would
> be some thinking to be done on the de-alloc path so that
> the *origin isn't pointing to something htat has already been free-d.
>
The idea with these pools is to keep a cache of write-combined pages, so
the pool
is determined by the caching status of the page when it is returned to
the page
allocator.
If we were to associate a page with a device, we'd basically need one
such pool per
device.
>
>> I think we might need to take a few steps back and rethink this whole idea:
>>
>> 1) How does this work in the AGP case? Let's say you allocate
>> write-combined DMA32 pages from the ttm page pool (in this case you
>> won't get coherent memory) and then use them in an AGP gart? Why is
>> it that we don't need coherent pages then in the Xen case?
>>
> Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
> the AGP API and then to its backends to program that. And also the frontends
> (so DRM, TTM) Here is the
> patchset I posted some time ago:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
> and the discussion:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
>
> Dave recommended I skip AGP and just concentrate on PCIe since not to many
> folks use AGP anymore. Thought I realized that server boards use PCI
> cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
> and I have a set of patches for this that I was in process of rebasing
> on 2.6.39-rcX.
>
I see. Well, both in the AGP case and sometimes in the PCIe case,
(some devices can use a non-cache-coherent PCIe mode for speed)
it's a not too uncommon use case of TTM to alloc cached pages and
transition them to write-combined (see impact below).
>
>> 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
>> makes me scared.
>> We should identify what platforms may have problems with this.
>>
> Right.. I think nobody much thought about this in context of TTM since
> that was only used on X86. I can take a look at the DMA API's of the
> other two major platforms: IA64 and PPC and see what lurks there.
>
>
>> 3) When hacking on the unichrome DMA engine it wasn't that hard to
>> use the synchronization functions of the DMA api correctly:
>>
>> When binding a TTM, the backend calls dma_map_page() on pages, When
>> unbinding, the backend calls dma_unmap_page(), If we need cpu access
>> when bound, we need to call dma_sync_single_for_[cpu|device]. If
>> this is done, it will be harder to implement user-space
>> sub-allocation, but possible. There will be a performance loss on
>> some platforms, though.
>>
> Yup. That was m
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #35 from Ortwin Gl?ck 2011-03-23 06:34:13 PDT --- Just out of curiosity, why is link training implemented on driver level and not on drm level? I see that nouvau and radeon each have their own implementation. The algorithm does not depend on the card, right? Only the way voltage, patterns etc are set does. Maybe by merging them the problem can be found. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Future desktop on dumb frame buffers?
On 21 March 2011 21:08, Alex Deucher wrote: > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > wrote: >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes >> wrote: >>> On Mon, 21 Mar 2011 19:19:43 + >>> timofonic timofonic wrote: So if KMS is so cool and provides many advantages over fbdev and such... Why isn't more widely used intead of still relying on fbdev? Why still using fbdev emulation (that is partial and somewhat broken, it seems) instead using KMS directly? >>> >>> Used by what? ?All three major GPU device classes have KMS support >>> (Intel, ATI, and nVidia). ?If you want it for a particular device, you >>> can always port it over. >> >> The three major GPU device classes on PC... > > Sadly it gets worse. ?A lot of the SoC vendors are adding an fbdev > emulation layer on top of v4l rather than using fbdev directly or > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > I agree, it is sad that as a SoC vendor there are different kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say a Display controller driver. One must also remember that there are big differences between a desktop/PC multimedia/graphics system and the ones present on an embedded SoC. It is two very different cultures and HW designs now trying to merge into one Linux Kernel. Of course there will be some overlaps but I believe it can be sorted out as soon as we understand each others different possibilities/limitations. Doing duplicate work like HDMI will not benefit any party. Just to list some of the differences. - Developments within V4L2 has mainly been driven by embedded devices while DRM is a result of desktop Graphics cards. And for some extent also solving different problems. - Embedded devices usually have several different hw IP's managing displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, 2D blitters, Open GL ES hw, all of which have a separate device/driver in the kernel, while on a desktop nowadays all this functionality usually resides on ONE graphics card, hence one DRM device for all. - DRM is closely developed in conjunction with desktop/Xorg, while X11 on an embedded device is not very 2011...wayland on the other hand is :-), but do wayland really need the full potential of DRM/DRI or just parts of it. - Copying buffers is really bad for embedded devices due to lower memory bandwidth and power consumption while on a Desktop memory bandwidth is from an other galaxy (copying still bad but accepted it seems), AND embedded devices of today records and plays/displays 1080p content as well. - Not all embedded devices have MMU's for each IP requiring physical contiguous memory, while on a desktop MMU's have been present for ages. - Embedded devices are usually ARM based SoCs while x86 dominates the Desktop/Laptop market, and functionality provided is soon the very same. - yada yadaThe list can grow very longThere are also similarities of course. The outcome is that SoC vendors likes the embedded friendliness of v4l2 and fbdev while "we" also glance at the DRM part due to its de-facto standard on desktop environments. But from an embedded point of view DRM lacks the support for interconnecting multiple devices/drivers mentioned above, GEM/TTM is valid within a DRM device, the execution/context management is not needed,, no overlays(or similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but the rest of DRM will likely not be heavily used on SoCs unless running X11 as well. Most likely this worked on as well within the DRI community. I can see good features all over the place(sometimes duplicated) but not find one single guideline/API that solves all the embedded SoC problems (which involves use-cases optimized for no-copy cross media/drivers). Last but not least... On Linaro there is already discussions ongoing to solve one of the biggest issues from a SoC point of view and that is a "System Wide Memory manager" which manages buffer sharing and resolves no-copy use cases between devices/drivers. Read more on the following thread: http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. BR /Robert Fekete st-ericsson
[git pull] drm next tree
On Wed, Mar 23, 2011 at 8:21 AM, Stephen Clark wrote: > On 03/22/2011 10:19 PM, Linus Torvalds wrote: >> >> So I had ?hoped - yes, very na?ve of me, I know - that this merge >> window would be different. >> >> But it's not. >> >> On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie ?wrote: >> >>> >>> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. >>> >> >> .. and apparently a lot of breakage too. My crappy laptop that I abuse >> for travel is - once more - broken by the updates. I cannot suspend >> and resume, because every resume seems to fail. >> >> One of the more useful failures was: >> >> [ ? 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer >> elapsed... GPU hung >> [ ? 61.656079] [drm] capturing error event; look for more information >> in /debug/dri/0/i915_error_state >> [ ? 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request >> returns -11 (awaiting 2 at 0, next 3) >> >> and I'm attaching the error_state file from that particular case here. >> In other cases it seems to just hang entirely. >> >> Keith/Jesse/Chris - I don't know that it's i915, and it will take >> forever to bisect (I'll try). But it does seem pretty likely. >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Linus >> > > Why can't the gpu be reset/restarted when this happens? When a nic card gets > hung it is reinitialized > and restarted why not the gpu? > > -- GPU are so complex, i know case where reseting a GPU would lead to bring down the PCI and the CPU with it (basicly the reset clear some of the GPU memory controller bit but not the GPU PCI request queue, so after/while reseting the GPU trigger a several request to bogus address on the bus, then trigger a double fault and eventually a CPU shutdown) . Of course here we can blame the hw designer for not having a proper reset. All this vary from one GPU to another, it seems that reset have become more reliable on newer hw. Cheers, Jerome
[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On Wed, Mar 23, 2011 at 02:17:18PM +0100, Thomas Hellstrom wrote:
> On 03/23/2011 01:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>I was thinking about this a bit after I found that the PowerPC requires
> >>>the 'struct dev'. But I got a question first, what do you with pages
> >>>that were allocated to a device that can do 64-bit DMA and then
> >>>move it to a device than can 32-bit DMA? Obviously the 32-bit card would
> >>>set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
> >>>process then? Allocate a new page from the 32-bit device and then copy
> >>>over the
> >>>page from the 64-bit TTM and put the 64-bit TTM page?
> >>Yes, in certain situations we need to copy, and if it's necessary in
> >>some cases to use coherent memory with a struct device assoicated
> >>with it, I agree it may be reasonable to do a copy in that case as
> >>well. I'm against, however, to make that the default case when
> >>running on bare metal.
> >This situation could occur on native/baremetal. When you say 'default
> >case' you mean for every type of page without consulting whether it
> >had the TTM_PAGE_FLAG_DMA32?
>
> No, Basically I mean a device that runs perfectly fine with
> alloc_pages(DMA32) on bare metal shouldn't need to be using
> dma_alloc_coherent() on bare metal, because that would mean we'd need
> to take the copy path above.
I think we got the scenarios confused (or I did at least).
The scenario I used ("I was thinking.."), the 64-bit device would do
alloc_page(GFP_HIGHUSER) and if you were to move it to a 32-bit device
it would have to make a copy of the page as it could not reach the page
from GFP_HIGUSER.
The other scenario, which I think is what you are using, is that
we have a 32-bit device allocating a page, so TTM_PAGE_FLAG_DMA32 is set
and then we if we were to move it a 64-bit device it would need to
copied. But I don't think that is the case - the page would be
reachable by the 64-bit device. Help me out please if I am misunderstanding
this.
>
> >>However, I've looked a bit deeper into all this, and it looks like
> >>we already have other problems that need to be addressed, and that
> >>exists with the code already in git:
> >>
> >>Consider a situation where you allocate a cached DMA32 page from the
> >>ttm page allocator. You'll end up with a coherent page. Then you
> >>make it uncached and finally you return it to the ttm page
> >>allocator. Since it's uncached, it will not be freed by the dma api,
> >>but kept in the uncached pool, and later the incorrect page free
> >>function will be called.
> >Let me look in details in the code, but I thought it would check the
> >TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
> >
> >We could piggyback on the idea of the struct I had and have these
> >values:
> >
> >struct ttm_page {
> > struct page *page;
> > dma_addr_t *bus_addr;
> > struct *ttm_pool*origin;
> >}
> >
> >And the origin would point to the correct pool so that on de-allocate
> >it would divert it to the original one. Naturally there would
> >be some thinking to be done on the de-alloc path so that
> >the *origin isn't pointing to something htat has already been free-d.
>
> The idea with these pools is to keep a cache of write-combined
> pages, so the pool
> is determined by the caching status of the page when it is returned
> to the page
> allocator.
> If we were to associate a page with a device, we'd basically need
> one such pool per
> device.
OK, I think I get it. The issue here is that with the struct I mentioned
above is that a page that was initially allocated as coherent, and then
you make it uncached, and if you were to free it - it would go back
to the pool that only deals with 'coherent' - which is wrong.
I had an earlier suggestion which was:
struct ttm_page {
struct page *page;
dma_addr_t *bus_addr;
struct *dev *dev;
}
this way even if it was to become uncached, you could still have it
associated with the right device. Granted at point the page is not
coherent anymore, it is uncached.
The problem is that on free-ing it is using the 'dma_free_coherent'
on a non-coherent page which it should not do. Would it be possible
then to make it coherent when we free it? Say as part of freeing
everything it would check what the original pool it belonged to
(so back to the struct with 'struct *ttm_pool *origin) and
convert it back to coherent as part of "moving" it to the original
pool?
> >}
>
>
> >>I think we might need to take a few steps back and rethink this whole idea:
> >>
> >>1) How does this work in the AGP case? Let's say you allocate
> >>write-combined DMA32 pages from the ttm page pool (in this case you
> >>won't get coherent memory) and then use them in an AGP gart? Why is
> >>it that we don't need coherent pages then in the Xen case?
> >Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
> >the AGP API and then to its backends to program that. And also the fronte
[git pull] drm next tree
On 03/22/2011 10:19 PM, Linus Torvalds wrote: > So I had hoped - yes, very na?ve of me, I know - that this merge > window would be different. > > But it's not. > > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: > >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. >> > .. and apparently a lot of breakage too. My crappy laptop that I abuse > for travel is - once more - broken by the updates. I cannot suspend > and resume, because every resume seems to fail. > > One of the more useful failures was: > > [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > elapsed... GPU hung > [ 61.656079] [drm] capturing error event; look for more information > in /debug/dri/0/i915_error_state > [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request > returns -11 (awaiting 2 at 0, next 3) > > and I'm attaching the error_state file from that particular case here. > In other cases it seems to just hang entirely. > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. > > Linus > Why can't the gpu be reset/restarted when this happens? When a nic card gets hung it is reinitialized and restarted why not the gpu? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)
[RFC PATCH] HDMI:Support for EDID parsing in kernel.
Hi Dave, On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: >> Adding support for common EDID parsing in kernel. >> >> EDID - Extended display identification data is a data structure provided by >> a digital display to describe its capabilities to a video source, This a >> standard supported by CEA and VESA. >> >> There are several custom implementations for parsing EDID in kernel, some >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally >> parsing of EDID should be done in a library, which is agnostic of the >> framework (V4l2, DRM, FB) ?which is using the functionality, just based on >> the raw EDID pointer with size/segment information. >> >> With other RFC's such as the one below, which tries to standardize HDMI API's >> It would be better to have a common EDID code in one place.It also helps to >> provide better interoperability with variety of TV/Monitor may be even by >> listing out quirks which might get missed with several custom implementation >> of EDID. >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 >> >> This patch tries to add functions to parse some portion EDID (detailed >> timing, >> monitor limits, AV delay information, deep color mode support, Audio and >> VSDB) >> If we can align on this library approach i can enhance this library to parse >> other blocks and probably we could also add quirks from other implementation >> as well. >> > > If you want to take this approach, you need to start from the DRM EDID parser, > its the most well tested and I can guarantee its been plugged into more > monitors > than any of the others. There is just no way we would move the DRM parser to a > library one that isn't derived from it + enhancements, as we'd throw away the > years of testing and the regression count would be way too high. > I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM. > Dave. > Thanks and regards, Mythri.
[git pull] drm next tree
On Wed, Mar 23, 2011 at 3:19 AM, Linus Torvalds wrote: > So I had ?hoped - yes, very na?ve of me, I know - that this merge > window would be different. > > But it's not. > > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: >> >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. > > .. and apparently a lot of breakage too. My crappy laptop that I abuse > for travel is - once more - broken by the updates. I cannot suspend > and resume, because every resume seems to fail. > > One of the more useful failures was: > > [ ? 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > elapsed... GPU hung > [ ? 61.656079] [drm] capturing error event; look for more information > in /debug/dri/0/i915_error_state > [ ? 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request > returns -11 (awaiting 2 at 0, next 3) > > and I'm attaching the error_state file from that particular case here. > In other cases it seems to just hang entirely. > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. Just in case - is it possible to have that commit in diff format ? Asking as 2.6.38-git2 is the latest kernel where my Latitude E6400 is displaying X at 1440x900, -git3 through -git6 do not compile and -git7 and onwards (up at least to -git11) display 1024x768 instead. If I run xrandr --fb 1440x900 --output LVDS1 --mode 1440x900 once in X, then I get 1440x900 display, but then: - the wallpaper's original 1024x768 image stays (the rest of the display area is filled with the part of image that should be there correctly at 1440x900) - if I run mplayer and ask it to go fullscreen, it does 1024x768 lspci (from 2.6.38-git2) says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0233 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at f6c0 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at ef98 [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 07) Subsystem: Dell Device 0233 Flags: bus master, fast devsel, latency 0 Memory at f6b0 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3 thanks, --alessandro ?"There's always a siren singing you to shipwreck" ?? (Radiohead, "There There")
[PATCH] drm radeon: Return -EINVAL on wrong pm sysfs access
drm radeon: Return -EINVAL on wrong pm sysfs access
Throw an error if someone tries to fill this with
wrong data, instead of simply ignoring the input.
Now you get:
echo hello >/sys/../power_method
-bash: echo: write error: Invalid argument
Signed-off-by: Thomas Renninger
CC: Alexander.Deucher at amd.com
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_pm.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 2aed03b..08de669 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -365,12 +365,14 @@ static ssize_t radeon_set_pm_profile(struct device *dev,
else if (strncmp("high", buf, strlen("high")) == 0)
rdev->pm.profile = PM_PROFILE_HIGH;
else {
- DRM_ERROR("invalid power profile!\n");
+ count = -EINVAL;
goto fail;
}
radeon_pm_update_profile(rdev);
radeon_pm_set_clocks(rdev);
- }
+ } else
+ count = -EINVAL;
+
fail:
mutex_unlock(&rdev->pm.mutex);
@@ -413,7 +415,7 @@ static ssize_t radeon_set_pm_method(struct device *dev,
mutex_unlock(&rdev->pm.mutex);
cancel_delayed_work_sync(&rdev->pm.dynpm_idle_work);
} else {
- DRM_ERROR("invalid power method!\n");
+ count = -EINVAL;
goto fail;
}
radeon_pm_compute_clocks(rdev);
[RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Wed, 23 Mar 2011 18:58:27 +0530 "K, Mythri P" wrote: > Hi Dave, > > On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie wrote: > > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K wrote: > >> Adding support for common EDID parsing in kernel. > >> > >> EDID - Extended display identification data is a data structure provided by > >> a digital display to describe its capabilities to a video source, This a > >> standard supported by CEA and VESA. > >> > >> There are several custom implementations for parsing EDID in kernel, some > >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally > >> parsing of EDID should be done in a library, which is agnostic of the > >> framework (V4l2, DRM, FB) ?which is using the functionality, just based on > >> the raw EDID pointer with size/segment information. > >> > >> With other RFC's such as the one below, which tries to standardize HDMI > >> API's > >> It would be better to have a common EDID code in one place.It also helps to > >> provide better interoperability with variety of TV/Monitor may be even by > >> listing out quirks which might get missed with several custom > >> implementation > >> of EDID. > >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 > >> > >> This patch tries to add functions to parse some portion EDID (detailed > >> timing, > >> monitor limits, AV delay information, deep color mode support, Audio and > >> VSDB) > >> If we can align on this library approach i can enhance this library to > >> parse > >> other blocks and probably we could also add quirks from other > >> implementation > >> as well. > >> > > > > If you want to take this approach, you need to start from the DRM EDID > > parser, > > its the most well tested and I can guarantee its been plugged into more > > monitors > > than any of the others. There is just no way we would move the DRM parser > > to a > > library one that isn't derived from it + enhancements, as we'd throw away > > the > > years of testing and the regression count would be way too high. > > > I had a look at the DRM EDID code, but for quirks it looks pretty much the > same. > yes i could take quirks and other DRM tested code and enhance, but > still the code has to do away with struct drm_display_mode > which is very much custom to DRM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Do you really think the differences between your code and the existing DRM code are irreconcilable? -- Jesse Barnes, Intel Open Source Technology Center
[git pull] drm next tree
On Wed, 23 Mar 2011 08:21:53 -0400 Stephen Clark wrote: > On 03/22/2011 10:19 PM, Linus Torvalds wrote: > > So I had hoped - yes, very na?ve of me, I know - that this merge > > window would be different. > > > > But it's not. > > > > On Wed, Mar 16, 2011 at 9:09 PM, Dave Airlie wrote: > > > >> i915: big 855 fix, lots of output setup refactoring, lots of misc fixes. > >> > > .. and apparently a lot of breakage too. My crappy laptop that I abuse > > for travel is - once more - broken by the updates. I cannot suspend > > and resume, because every resume seems to fail. > > > > One of the more useful failures was: > > > > [ 61.656055] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 61.656079] [drm] capturing error event; look for more information > > in /debug/dri/0/i915_error_state > > [ 61.664387] [drm:i915_wait_request] *ERROR* i915_wait_request > > returns -11 (awaiting 2 at 0, next 3) > > > > and I'm attaching the error_state file from that particular case here. > > In other cases it seems to just hang entirely. > > > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > > forever to bisect (I'll try). But it does seem pretty likely. > > > > Linus > > > Why can't the gpu be reset/restarted when this happens? When a nic card > gets hung it is reinitialized > and restarted why not the gpu? Yeah, we try to restart in this case, but often just end up back in the same situation when the app runs again. We could be meaner about things and SIGILL the app, but often it's an innocent bystander, and the real problem is kernel object synchronization and/or the DRI driver generating bad commands. -- Jesse Barnes, Intel Open Source Technology Center
[git pull] drm next tree
On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds wrote: > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > forever to bisect (I'll try). But it does seem pretty likely. Ok, so I'm still bisecting, but it's definitely the DRM pull. Current bisection log attached (the result does contain the fbdev pull from Paul Mundt, but that doesn't touch any files I compile afaik). Linus -- next part -- A non-text attachment was scrubbed... Name: BISECT_LOG Type: application/octet-stream Size: 1404 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110323/9cfb4617/attachment.obj>
[git pull] drm next tree
On Wed, 23 Mar 2011 08:29:35 -0700 Linus Torvalds wrote: > On Tue, Mar 22, 2011 at 7:19 PM, Linus Torvalds > wrote: > > > > Keith/Jesse/Chris - I don't know that it's i915, and it will take > > forever to bisect (I'll try). But it does seem pretty likely. > > Ok, so I'm still bisecting, but it's definitely the DRM pull. Current > bisection log attached (the result does contain the fbdev pull from > Paul Mundt, but that doesn't touch any files I compile afaik). Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this issue though, but it does seem a likely candidate. -- Jesse Barnes, Intel Open Source Technology Center
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #5 from Maximiliano Casta??n 2011-03-23 08:48:13 PDT --- (In reply to comment #2) > I don't think that's from the driver you built yourself, the line numbers > don't > match current git. By default the drivers will be installed in /usr/local/, so > you would have to set LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" and > LD_LIBRARY_PATH="/usr/local/lib/". i will try it when i go to my house. What means that of "p *radeon" ? i need to run it in the gdb? And yes,i?m using the 64 bits version, it?s called x86_64 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Thank! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
On Wed, Mar 23, 2011 at 8:51 AM, Konrad Rzeszutek Wilk
wrote:
>> >I was thinking about this a bit after I found that the PowerPC requires
>> >the 'struct dev'. But I got a question first, what do you with pages
>> >that were allocated to a device that can do 64-bit DMA and then
>> >move it to a device than can 32-bit DMA? Obviously the 32-bit card would
>> >set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
>> >process then? Allocate a new page from the 32-bit device and then copy over
>> >the
>> >page from the 64-bit TTM and put the 64-bit TTM page?
>>
>> Yes, in certain situations we need to copy, and if it's necessary in
>> some cases to use coherent memory with a struct device assoicated
>> with it, I agree it may be reasonable to do a copy in that case as
>> well. I'm against, however, to make that the default case when
>> running on bare metal.
>
> This situation could occur on native/baremetal. When you say 'default
> case' you mean for every type of page without consulting whether it
> had the TTM_PAGE_FLAG_DMA32?
>>
>> However, I've looked a bit deeper into all this, and it looks like
>> we already have other problems that need to be addressed, and that
>> exists with the code already in git:
>>
>> Consider a situation where you allocate a cached DMA32 page from the
>> ttm page allocator. You'll end up with a coherent page. Then you
>> make it uncached and finally you return it to the ttm page
>> allocator. Since it's uncached, it will not be freed by the dma api,
>> but kept in the uncached pool, and later the incorrect page free
>> function will be called.
>
> Let me look in details in the code, but I thought it would check the
> TTM_PAGE_FLAG_DMA32 and direct the page to the correct pool?
>
> We could piggyback on the idea of the struct I had and have these
> values:
>
> struct ttm_page {
> ? ? ? ?struct page *page;
> ? ? ? ?dma_addr_t ? ? ?*bus_addr;
> ? ? ? ?struct *ttm_pool ? ? ? ?*origin;
> }
>
> And the origin would point to the correct pool so that on de-allocate
> it would divert it to the original one. Naturally there would
> be some thinking to be done on the de-alloc path so that
> the *origin isn't pointing to something htat has already been free-d.
>
>>
>> I think we might need to take a few steps back and rethink this whole idea:
>>
>> 1) How does this work in the AGP case? Let's say you allocate
>> write-combined DMA32 pages from the ttm page pool (in this case you
>> won't get coherent memory) and then use them in an AGP gart? Why is
>> it that we don't need coherent pages then in the Xen case?
>
> Hehe.. So I had posted a set of patches to carry the 'dma_addr_t' through
> the AGP API and then to its backends to program that. And also the frontends
> (so DRM, TTM) Here is the
> patchset I posted some time ago:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02382.html
> and the discussion:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-12/msg02411.html
>
> Dave recommended I skip AGP and just concentrate on PCIe since not to many
> folks use AGP anymore. Thought I realized that server boards use PCI
> cards (ATI ES1000), which do utilize the AGP API. So there is breakage there
> and I have a set of patches for this that I was in process of rebasing
> on 2.6.39-rcX.
Actually the PCI gart mechanism uses cached pages rather than uncached
on the pre-pcie asics. On pcie asics, the on-board gart can use both
cached and uncached pages. There is a flag in the gpu's page table to
specify whether the pages need a snooped cycle or not. At the moment
we only use cached pages for the onboard gart, but there are
performance advantages for using uncached pages for certain types of
buffers (pretty much everything that doesn't require CPU reads). That
may be something we want to take advantage of in the future. FWIW,
all AGP radeons can use the onboard gart instead of or in addition to
AGP.
Alex
>
>>
>> 2) http://www.mjmwired.net/kernel/Documentation/DMA-API.txt, line 33
>> makes me scared.
>> We should identify what platforms may have problems with this.
>
> Right.. I think nobody much thought about this in context of TTM since
> that was only used on X86. I can take a look at the DMA API's of the
> other two major platforms: IA64 and PPC and see what lurks there.
>
>>
>> 3) When hacking on the unichrome DMA engine it wasn't that hard to
>> use the synchronization functions of the DMA api correctly:
>>
>> ?When binding a TTM, the backend calls dma_map_page() on pages, When
>> unbinding, the backend calls dma_unmap_page(), If we need cpu access
>> when bound, we need to call dma_sync_single_for_[cpu|device]. If
>> this is done, it will be harder to implement user-space
>> sub-allocation, but possible. There will be a performance loss on
>> some platforms, though.
>
> Yup. That was my other suggestion about this. But I had no idea
> where to sprinkle those 'dma_sync_single_[*]' calls, as they would
> have been done in the drivers. Probably on
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #36 from Alex Deucher 2011-03-23 09:46:22 PDT --- (In reply to comment #35) > Just out of curiosity, why is link training implemented on driver level and > not > on drm level? I see that nouvau and radeon each have their own implementation. > The algorithm does not depend on the card, right? Only the way voltage, > patterns etc are set does. Maybe by merging them the problem can be found. The link training algo is the same across all chips in theory (it's defined in a VESA spec). However, there are often a lot of asic specific things that need to be handled. It would probably be doable if you could figure out the right set of callbacks and driver adjustable fields to make all the drivers happy. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm radeon: Return -EINVAL on wrong pm sysfs access
On Wed, Mar 23, 2011 at 11:14 AM, Thomas Renninger wrote:
> drm radeon: Return -EINVAL on wrong pm sysfs access
>
> Throw an error if someone tries to fill this with
> wrong data, instead of simply ignoring the input.
> Now you get:
>
> echo hello >/sys/../power_method
> -bash: echo: write error: Invalid argument
>
> Signed-off-by: Thomas Renninger
> CC: Alexander.Deucher at amd.com
> CC: dri-devel at lists.freedesktop.org
Looks good to me.
Reviewed-by: Alex Deucher
>
> ---
> ?drivers/gpu/drm/radeon/radeon_pm.c | ? ?8 +---
> ?1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 2aed03b..08de669 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -365,12 +365,14 @@ static ssize_t radeon_set_pm_profile(struct device *dev,
> ? ? ? ? ? ? ? ?else if (strncmp("high", buf, strlen("high")) == 0)
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->pm.profile = PM_PROFILE_HIGH;
> ? ? ? ? ? ? ? ?else {
> - ? ? ? ? ? ? ? ? ? ? ? DRM_ERROR("invalid power profile!\n");
> + ? ? ? ? ? ? ? ? ? ? ? count = -EINVAL;
> ? ? ? ? ? ? ? ? ? ? ? ?goto fail;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?radeon_pm_update_profile(rdev);
> ? ? ? ? ? ? ? ?radeon_pm_set_clocks(rdev);
> - ? ? ? }
> + ? ? ? } else
> + ? ? ? ? ? ? ? count = -EINVAL;
> +
> ?fail:
> ? ? ? ?mutex_unlock(&rdev->pm.mutex);
>
> @@ -413,7 +415,7 @@ static ssize_t radeon_set_pm_method(struct device *dev,
> ? ? ? ? ? ? ? ?mutex_unlock(&rdev->pm.mutex);
> ? ? ? ? ? ? ? ?cancel_delayed_work_sync(&rdev->pm.dynpm_idle_work);
> ? ? ? ?} else {
> - ? ? ? ? ? ? ? DRM_ERROR("invalid power method!\n");
> + ? ? ? ? ? ? ? count = -EINVAL;
> ? ? ? ? ? ? ? ?goto fail;
> ? ? ? ?}
> ? ? ? ?radeon_pm_compute_clocks(rdev);
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #6 from Maximiliano Casta??n 2011-03-23 14:39:00 PDT --- well, i ran FF with: LIBGL_DRIVERS_PATH="/usr/local/lib/dri/" LD_LIBRARY_PATH="/usr/local/lib/" MOZ_GLX_IGNORE_BLACKLIST=1 ./firefox it show various messages of: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable But it seems to work fine... the test of FPS with Mozilla gives me 4 FPS, but seems to work. I'm running mesa e4b040c2b -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm next tree
On Wed, Mar 23, 2011 at 8:33 AM, Jesse Barnes wrote: > > Chris mentioned a7a75c8f7 on irc, not sure if it was regarding this > issue though, but it does seem a likely candidate. Yup, that revert fixes it for me. Linus
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #7 from Maximiliano Casta??n 2011-03-23 21:39:07 PDT --- Ok, got another crash: Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7fde18eff700 (LWP 16893)] 0x7fde2b1ad57c in __libc_send (fd=72, buf=, n=, flags=) at ../sysdeps/unix/sysv/linux/x86_64/send.c:32 32../sysdeps/unix/sysv/linux/x86_64/send.c: No existe el fichero o el directorio. in ../sysdeps/unix/sysv/linux/x86_64/send.c (gdb) traceback Undefined command: "traceback". Try "help". (gdb) backtrace #0 0x7fde2b1ad57c in __libc_send (fd=72, buf=, n=, flags=) at ../sysdeps/unix/sysv/linux/x86_64/send.c:32 #1 0x7fde288d199d in ?? () #2 0x7fdd5ed6f005 in ?? () #3 0x7fde0a2ce6ba in ?? () #4 0x7fddd5b01068 in ?? () #5 0x7fddd5baf000 in ?? () #6 0x7fde2b49c040 in ?? () #7 0x7fddc1b3e6a0 in ?? () #8 0x0012 in ?? () #9 0x7fdda54040f0 in ?? () #10 0x in ?? () -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35578] When WebGL(HWaccel) is activated, Firefox will Crash...
https://bugs.freedesktop.org/show_bug.cgi?id=35578 --- Comment #8 from Maximiliano Casta??n 2011-03-23 21:41:35 PDT --- Created an attachment (id=44773) --> (https://bugs.freedesktop.org/attachment.cgi?id=44773) traceback when i try to login it crashed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
