[PATCH resend] drm/savage: Do not add framebuffer and aperture maps
From: Tormod Volden
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Signed-off-by: Tormod Volden
---
The drm driver is not required to set up fb maps, right?
For instance radeon does, but its comment says "Create mappings
for registers and framebuffer so userland doesn't necessarily
have to find them."
Tormod
drivers/gpu/drm/savage/savage_bci.c | 13 +
drivers/gpu/drm/savage/savage_drv.h |2 --
2 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/savage/savage_bci.c
b/drivers/gpu/drm/savage/savage_bci.c
index bf5f83e..91fe7b4 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -639,18 +639,7 @@ int savage_driver_firstopen(struct drm_device *dev)
if (ret)
return ret;
- ret = drm_addmap(dev, fb_base, fb_size, _DRM_FRAME_BUFFER,
-_DRM_WRITE_COMBINING, &dev_priv->fb);
- if (ret)
- return ret;
-
- ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE,
-_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING,
-&dev_priv->aperture);
- if (ret)
- return ret;
-
- return ret;
+ return 0;
}
/*
diff --git a/drivers/gpu/drm/savage/savage_drv.h
b/drivers/gpu/drm/savage/savage_drv.h
index df2aac6..2b49b3e 100644
--- a/drivers/gpu/drm/savage/savage_drv.h
+++ b/drivers/gpu/drm/savage/savage_drv.h
@@ -153,8 +153,6 @@ typedef struct drm_savage_private {
/* memory regions in physical memory */
drm_local_map_t *sarea;
drm_local_map_t *mmio;
- drm_local_map_t *fb;
- drm_local_map_t *aperture;
drm_local_map_t *status;
drm_local_map_t *agp_textures;
drm_local_map_t *cmd_dma;
--
1.7.0.4
[BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
Hi Justin, I'm a spanish Mac user, who's screen suddenly starts to appear red wherever it should appear black or very dark colors. Everything dark or black appears in red instead of it's original color. I went today to a Mac shop and a technician connected my mac to an external display and the red stuff didn't appear. So he concluded it had something to do with my screen, not graphics card or whatever. So I googled my problem and found your post. I wonder whether my problem has anything to do with your post, so if you could help me... I also don't know how to apply the patch, so I would also need some help regarding the medicine. Thank you very much for your time, Jose Mora -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110527/a0fa3f53/attachment.htm>
Re: [PATCH resend] drm/savage: Do not add framebuffer and aperture maps
On Fri, May 27, 2011 at 10:48 PM, Dave Airlie wrote: > On Sat, May 28, 2011 at 4:19 AM, Tormod Volden wrote: >> From: Tormod Volden >> >> Since multiple framebuffer maps are not supported any longer (commit >> 41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken, >> and they are not used by the drm anyway. >> >> Leave it to userspace to create one working map instead. > > Sorry Tormod, I'm really failing to get this far down my todo list. > I'll try and get some > time next week. I think I preferred the patch to make things work with > current userspace. > and undo the regression. > > Dave. Thanks, I am glad to hear that. I would really prefer to not rewrite userspace, which seems rather painful. Cheers, Tormod ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #24 from Bob Ham 2011-05-27 16:01:34 PDT --- In the previously described bisect, I failed to mention that the tree had been restricted to drivers/gpu/drm/radeon. Using the log of that bisect as a starting point for a bisect of the whole tree, I arrived at the following, similar report: There are only 'skip'ped commits left to test. The first bad commit could be any of: b7ae5056c94a8191c1fd0b5697707377516c0c5d c9220b0f7cbd1d2272426aa81a72ae2f6582bb71 We cannot bisect more! The first is the same skipped (weird timing out kernel) commit as the restricted bisect but the second possibility is different and from TTM: Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ae5056c94a8191c1fd0b5697707377516c0c5d drm/ttm: add unlocked variant of new manager put node. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c9220b0f7cbd1d2272426aa81a72ae2f6582bb71 -- 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 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #24 from Bob Ham 2011-05-27 16:01:34 PDT --- In the previously described bisect, I failed to mention that the tree had been restricted to drivers/gpu/drm/radeon. Using the log of that bisect as a starting point for a bisect of the whole tree, I arrived at the following, similar report: There are only 'skip'ped commits left to test. The first bad commit could be any of: b7ae5056c94a8191c1fd0b5697707377516c0c5d c9220b0f7cbd1d2272426aa81a72ae2f6582bb71 We cannot bisect more! The first is the same skipped (weird timing out kernel) commit as the restricted bisect but the second possibility is different and from TTM: Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ae5056c94a8191c1fd0b5697707377516c0c5d drm/ttm: add unlocked variant of new manager put node. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c9220b0f7cbd1d2272426aa81a72ae2f6582bb71 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
On Fri, May 27, 2011 at 1:37 PM, Jose Maria Mora Castera wrote: > Hi Justin, > I'm a spanish Mac user, who's screen suddenly starts to appear red wherever > it should appear black or very dark colors. Everything dark or black appears > in red instead of it's original color. > I went today to a Mac shop and a technician connected my mac to an external > display and the red stuff didn't appear. So he concluded it had something to > do with my screen, not graphics card or whatever. > So I googled my problem and found your post.?I wonder whether my problem has > anything to do with your post, so if you could help me... > I also don't know how to apply the patch, so I would also need some help > regarding the medicine. > Thank you very much for your time, As I mentioned before, if you are not using the open source radeon driver, there's not much we can do for you. Alex
[Bug 27517] KMS breaks 3D on R200
https://bugs.freedesktop.org/show_bug.cgi?id=27517 --- Comment #9 from Keith 2011-05-27 14:45:48 PDT --- (In reply to comment #8) > Yes, some time around the introduction of KMS, acceleration stopped working. I > had it fine on Debian before squeeze and Ubuntu Maveric but recently upgraded > to Natty and it stopped working. Starting compiz gives the old > GLX_EXT_texture_pixmap not available error. It also complains about GL version > 1.4+ whereas glxinfo reports version 1.4 Latest updates on Debian squeeze have 3D acceleration bursting into life. Kernel: 2.6.32-5-686 X server 1.7.7 -- 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 27517] KMS breaks 3D on R200
https://bugs.freedesktop.org/show_bug.cgi?id=27517 --- Comment #9 from Keith 2011-05-27 14:45:48 PDT --- (In reply to comment #8) > Yes, some time around the introduction of KMS, acceleration stopped working. I > had it fine on Debian before squeeze and Ubuntu Maveric but recently upgraded > to Natty and it stopped working. Starting compiz gives the old > GLX_EXT_texture_pixmap not available error. It also complains about GL version > 1.4+ whereas glxinfo reports version 1.4 Latest updates on Debian squeeze have 3D acceleration bursting into life. Kernel: 2.6.32-5-686 X server 1.7.7 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Questions about libdrm_intel and way to share physical memory between CPU and GPU
Hello gurus, I have two question mostly regarding libdrm_intel 1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ? 2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API: char *ptr = malloc(sz); cl_mem buf = clCreateBuffer(ctx, CL_MEM_USE_HOST_PTR, sz, ptr, &err); Here, you create a buffer which directly uses the physical memory you are going to use for ptr. The idea, I guess, is to give GTT pages for this piece of memory. Today, I get a similar functionnality the other way using mostly: drm_intel_bo *bo = drm_intel_bo_alloc(..) char *ptr = drm_intel_bo_map(...) Thanks! Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Questions about libdrm_intel and way to share physical memory between CPU and GPU
Hello gurus, I have two question mostly regarding libdrm_intel 1/ What is the difference between drm_intel_bo_map and drm_intel_gem_bo_map_gtt ? 2/ Will it be possible (or is it already possible) to directly share a regularly allocated piece of physical memory? Typical use case is the following one using OpenCL API: char *ptr = malloc(sz); cl_mem buf = clCreateBuffer(ctx, CL_MEM_USE_HOST_PTR, sz, ptr, &err); Here, you create a buffer which directly uses the physical memory you are going to use for ptr. The idea, I guess, is to give GTT pages for this piece of memory. Today, I get a similar functionnality the other way using mostly: drm_intel_bo *bo = drm_intel_bo_alloc(..) char *ptr = drm_intel_bo_map(...) Thanks! Ben
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 --- Comment #5 from Alex Deucher 2011-05-27 14:23:25 --- Laptops don't generally use the onboard GPU fan controller and thermal sensor since they usually have a single fan for both the GPU and the CPU. The fan and thermal zones are generally exposed via ACPI or a vendor specific control. For more info on the power management options in the driver see the page I linked in comment #1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #18 from ZeRo 2011-05-27 13:52:00 PDT --- so any idea? -- 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 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #18 from ZeRo 2011-05-27 13:52:00 PDT --- so any idea? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH resend] drm/savage: Do not add framebuffer and aperture maps
On Sat, May 28, 2011 at 4:19 AM, Tormod Volden wrote:
> From: Tormod Volden
>
> Since multiple framebuffer maps are not supported any longer (commit
> 41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
> and they are not used by the drm anyway.
>
> Leave it to userspace to create one working map instead.
Sorry Tormod, I'm really failing to get this far down my todo list.
I'll try and get some
time next week. I think I preferred the patch to make things work with
current userspace.
and undo the regression.
Dave.
>
> Signed-off-by: Tormod Volden
> ---
>
> The drm driver is not required to set up fb maps, right?
> For instance radeon does, but its comment says "Create mappings
> for registers and framebuffer so userland doesn't necessarily
> have to find them."
>
> Tormod
>
> drivers/gpu/drm/savage/savage_bci.c | 13 +
> drivers/gpu/drm/savage/savage_drv.h | 2 --
> 2 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/savage/savage_bci.c
> b/drivers/gpu/drm/savage/savage_bci.c
> index bf5f83e..91fe7b4 100644
> --- a/drivers/gpu/drm/savage/savage_bci.c
> +++ b/drivers/gpu/drm/savage/savage_bci.c
> @@ -639,18 +639,7 @@ int savage_driver_firstopen(struct drm_device *dev)
> if (ret)
> return ret;
>
> - ret = drm_addmap(dev, fb_base, fb_size, _DRM_FRAME_BUFFER,
> - _DRM_WRITE_COMBINING, &dev_priv->fb);
> - if (ret)
> - return ret;
> -
> - ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE,
> - _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING,
> - &dev_priv->aperture);
> - if (ret)
> - return ret;
> -
> - return ret;
> + return 0;
> }
>
> /*
> diff --git a/drivers/gpu/drm/savage/savage_drv.h
> b/drivers/gpu/drm/savage/savage_drv.h
> index df2aac6..2b49b3e 100644
> --- a/drivers/gpu/drm/savage/savage_drv.h
> +++ b/drivers/gpu/drm/savage/savage_drv.h
> @@ -153,8 +153,6 @@ typedef struct drm_savage_private {
> /* memory regions in physical memory */
> drm_local_map_t *sarea;
> drm_local_map_t *mmio;
> - drm_local_map_t *fb;
> - drm_local_map_t *aperture;
> drm_local_map_t *status;
> drm_local_map_t *agp_textures;
> drm_local_map_t *cmd_dma;
> --
> 1.7.0.4
>
> ___
> 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
i915 "black screen of death" clearly still an issue
i just built a kernel for my ubuntu 10.10 system and forgot to include the following patch which is what i've needed to avoid the dreaded black screen of death: diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index d2c7104..a1a5d03 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp) struct opregion_asle *asle = dev_priv->opregion.asle; u32 max; +return ASLE_BACKLIGHT_FAILED; // rday + if (!(bclp & ASLE_BCLP_VALID)) return ASLE_BACKLIGHT_FAILED; and i once again got the black screen. is this still a known and unresolved issue? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 Marco Trevisan (Trevi?o) changed: What|Removed |Added CC||mail at 3v1n0.net --- Comment #14 from Marco Trevisan (Trevi?o) 2011-05-27 12:57:16 --- Could this related to Bug 15851 too? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
On Fri, May 27, 2011 at 1:37 PM, Jose Maria Mora Castera wrote: > Hi Justin, > I'm a spanish Mac user, who's screen suddenly starts to appear red wherever > it should appear black or very dark colors. Everything dark or black appears > in red instead of it's original color. > I went today to a Mac shop and a technician connected my mac to an external > display and the red stuff didn't appear. So he concluded it had something to > do with my screen, not graphics card or whatever. > So I googled my problem and found your post. I wonder whether my problem has > anything to do with your post, so if you could help me... > I also don't know how to apply the patch, so I would also need some help > regarding the medicine. > Thank you very much for your time, As I mentioned before, if you are not using the open source radeon driver, there's not much we can do for you. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 and boot freeze
On Wed, 25 May 2011 10:38:59 -0300, Yermandu Patapitafious wrote: > Hello Jean, > > Thanks for answer, i will take more atention in subjects, > > > What is the last kernel that works for you? > > > > Are you running self-built or distribution kernels? > > Can we please see the kernel configuration file? > > My Last kernel working from git repository was 2.6.38-rc8+, the stable > line .38.X work fines. OK, this is good, it means the bisection domain isn't too big. Can you remember if you made any kernel configuration change between 2.6.38 and 2.6.39? > I use the git version from kernel.org site pull and build manually be > me. The Latest Stable Kernel is from gentoo-sources, and i always > compile manually too. > I have attached .config kernel in mail. I see you have many debug options enabled. I suggest you try building a kernel without these and see if it makes a difference. > > It would be great > > if you were able to get us the kernel logs in a text form, using some > > form of serial console. > > Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues > happing I looking for some way to send panic log in text, but no > success yet. If you can't get a serial console to capture the complete error log, the other approach is to bisect between kernels 2.6.38 and 2.6.39, to find the faulty commit. If you're used to building your kernel yourself, it shouldn't be too difficult. Just clone Linus' kernel tree and follow the git bisect manual page: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Jean Delvare
Re: [BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
Hi Justin, I'm a spanish Mac user, who's screen suddenly starts to appear red wherever it should appear black or very dark colors. Everything dark or black appears in red instead of it's original color. I went today to a Mac shop and a technician connected my mac to an external display and the red stuff didn't appear. So he concluded it had something to do with my screen, not graphics card or whatever. So I googled my problem and found your post. I wonder whether my problem has anything to do with your post, so if you could help me... I also don't know how to apply the patch, so I would also need some help regarding the medicine. Thank you very much for your time, Jose Mora ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drivers: Use kzalloc instead of 'kmalloc+memset', where possible
A previous patch was sent to address this issue at,
https://lkml.org/lkml/2011/5/23/305. Joe Perches suggest that, its best to use
kcalloc for array allocation instead of kzalloc. This version addresses this
issue.
Changes since V0:
Use kcalloc instead of kzalloc for array allocation.
Signed-off-by: Rakib Mullick
---
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 1c4b3aa..168b78f 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1638,13 +1638,12 @@ static int sata_dwc_probe(struct platform_device *ofdev)
const struct ata_port_info *ppi[] = { &pi, NULL };
/* Allocate DWC SATA device */
- hsdev = kmalloc(sizeof(*hsdev), GFP_KERNEL);
+ hsdev = kzalloc(sizeof(*hsdev), GFP_KERNEL);
if (hsdev == NULL) {
dev_err(&ofdev->dev, "kmalloc failed for hsdev\n");
err = -ENOMEM;
goto error_out;
}
- memset(hsdev, 0, sizeof(*hsdev));
/* Ioremap SATA registers */
base = of_iomap(ofdev->dev.of_node, 0);
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index d15e09b..7525e03 100644
--- a/drivers/gpu/drm/drm_scatter.c
+++ b/drivers/gpu/drm/drm_scatter.c
@@ -83,30 +83,26 @@ int drm_sg_alloc(struct drm_device *dev, struct
drm_scatter_gather * request)
if (dev->sg)
return -EINVAL;
- entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
if (!entry)
return -ENOMEM;
- memset(entry, 0, sizeof(*entry));
pages = (request->size + PAGE_SIZE - 1) / PAGE_SIZE;
DRM_DEBUG("size=%ld pages=%ld\n", request->size, pages);
entry->pages = pages;
- entry->pagelist = kmalloc(pages * sizeof(*entry->pagelist), GFP_KERNEL);
+ entry->pagelist = kcalloc(pages, sizeof(*entry->pagelist), GFP_KERNEL);
if (!entry->pagelist) {
kfree(entry);
return -ENOMEM;
}
- memset(entry->pagelist, 0, pages * sizeof(*entry->pagelist));
-
- entry->busaddr = kmalloc(pages * sizeof(*entry->busaddr), GFP_KERNEL);
+ entry->busaddr = kcalloc(pages, sizeof(*entry->busaddr), GFP_KERNEL);
if (!entry->busaddr) {
kfree(entry->pagelist);
kfree(entry);
return -ENOMEM;
}
- memset((void *)entry->busaddr, 0, pages * sizeof(*entry->busaddr));
entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
if (!entry->virtual) {
diff --git a/drivers/gpu/drm/radeon/radeon_mem.c
b/drivers/gpu/drm/radeon/radeon_mem.c
index ed95155..988548e 100644
--- a/drivers/gpu/drm/radeon/radeon_mem.c
+++ b/drivers/gpu/drm/radeon/radeon_mem.c
@@ -139,7 +139,7 @@ static int init_heap(struct mem_block **heap, int start,
int size)
if (!blocks)
return -ENOMEM;
- *heap = kmalloc(sizeof(**heap), GFP_KERNEL);
+ *heap = kzalloc(sizeof(**heap), GFP_KERNEL);
if (!*heap) {
kfree(blocks);
return -ENOMEM;
@@ -150,7 +150,6 @@ static int init_heap(struct mem_block **heap, int start,
int size)
blocks->file_priv = NULL;
blocks->next = blocks->prev = *heap;
- memset(*heap, 0, sizeof(**heap));
(*heap)->file_priv = (struct drm_file *) - 1;
(*heap)->next = (*heap)->prev = blocks;
return 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index f1a52f9..07ce02d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -585,11 +585,10 @@ int vmw_overlay_init(struct vmw_private *dev_priv)
return -ENOSYS;
}
- overlay = kmalloc(sizeof(*overlay), GFP_KERNEL);
+ overlay = kzalloc(sizeof(*overlay), GFP_KERNEL);
if (!overlay)
return -ENOMEM;
- memset(overlay, 0, sizeof(*overlay));
mutex_init(&overlay->mutex);
for (i = 0; i < VMW_MAX_NUM_STREAMS; i++) {
overlay->stream[i].buf = NULL;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 5408b1b..bfe1bcc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -612,11 +612,9 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void
*data,
srf->sizes[0].height == 64 &&
srf->format == SVGA3D_A8R8G8B8) {
- srf->snooper.image = kmalloc(64 * 64 * 4, GFP_KERNEL);
- /* clear the image */
- if (srf->snooper.image) {
- memset(srf->snooper.image, 0x00, 64 * 64 * 4);
- } else {
+ /* allocate image area and clear it */
+ srf->snooper.image = kzalloc(64 * 64 * 4, GFP_KERNEL);
+ if (!srf->snooper.image) {
DRM_ERROR("Fai
[PATCH resend] drm/savage: Do not add framebuffer and aperture maps
From: Tormod Volden
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Signed-off-by: Tormod Volden
---
The drm driver is not required to set up fb maps, right?
For instance radeon does, but its comment says "Create mappings
for registers and framebuffer so userland doesn't necessarily
have to find them."
Tormod
drivers/gpu/drm/savage/savage_bci.c | 13 +
drivers/gpu/drm/savage/savage_drv.h |2 --
2 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/savage/savage_bci.c
b/drivers/gpu/drm/savage/savage_bci.c
index bf5f83e..91fe7b4 100644
--- a/drivers/gpu/drm/savage/savage_bci.c
+++ b/drivers/gpu/drm/savage/savage_bci.c
@@ -639,18 +639,7 @@ int savage_driver_firstopen(struct drm_device *dev)
if (ret)
return ret;
- ret = drm_addmap(dev, fb_base, fb_size, _DRM_FRAME_BUFFER,
-_DRM_WRITE_COMBINING, &dev_priv->fb);
- if (ret)
- return ret;
-
- ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE,
-_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING,
-&dev_priv->aperture);
- if (ret)
- return ret;
-
- return ret;
+ return 0;
}
/*
diff --git a/drivers/gpu/drm/savage/savage_drv.h
b/drivers/gpu/drm/savage/savage_drv.h
index df2aac6..2b49b3e 100644
--- a/drivers/gpu/drm/savage/savage_drv.h
+++ b/drivers/gpu/drm/savage/savage_drv.h
@@ -153,8 +153,6 @@ typedef struct drm_savage_private {
/* memory regions in physical memory */
drm_local_map_t *sarea;
drm_local_map_t *mmio;
- drm_local_map_t *fb;
- drm_local_map_t *aperture;
drm_local_map_t *status;
drm_local_map_t *agp_textures;
drm_local_map_t *cmd_dma;
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #15 from Anisse Astier 2011-05-27 10:48:09 --- Created an attachment (id=59672) --> (https://bugzilla.kernel.org/attachment.cgi?id=59672) xrandr output before and after first patch Here you can see the output of xrandr before and after applying patch in comment 11 . Adding patch in comment 12 didn't change anything. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #14 from Anisse Astier 2011-05-27 10:45:53 --- Created an attachment (id=59662) --> (https://bugzilla.kernel.org/attachment.cgi?id=59662) Dmesg with 1st patch applied As you asked, I tried with first patch, then second patch on top of it. No change on display (still blank, no backlight) in any case. But we can see here a difference in modesets shown kernel log, before and after first patch. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #13 from Anisse Astier 2011-05-27 10:34:38 --- Created an attachment (id=59652) --> (https://bugzilla.kernel.org/attachment.cgi?id=59652) Xorg log with drm-radeon-testing as of 05/26 (no patch applied) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: viewport height has to be even
Otherwise, no vblank interrupts. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37522 Signed-off-by: Alex Deucher Cc: stable at kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index ec84878..84a69e7 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1045,7 +1045,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc, uint64_t fb_location; uint32_t fb_format, fb_pitch_pixels, tiling_flags; u32 fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_NONE); - u32 tmp; + u32 tmp, viewport_w, viewport_h; int r; /* no fb bound */ @@ -1171,8 +1171,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc, y &= ~1; WREG32(EVERGREEN_VIEWPORT_START + radeon_crtc->crtc_offset, (x << 16) | y); + viewport_w = crtc->mode.hdisplay; + viewport_h = (crtc->mode.vdisplay + 1) & ~1; WREG32(EVERGREEN_VIEWPORT_SIZE + radeon_crtc->crtc_offset, - (crtc->mode.hdisplay << 16) | crtc->mode.vdisplay); + (viewport_w << 16) | viewport_h); /* pageflip setup */ /* make sure flip is at vb rather than hb */ @@ -1213,7 +1215,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, uint64_t fb_location; uint32_t fb_format, fb_pitch_pixels, tiling_flags; u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE; - u32 tmp; + u32 tmp, viewport_w, viewport_h; int r; /* no fb bound */ @@ -1338,8 +1340,10 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, y &= ~1; WREG32(AVIVO_D1MODE_VIEWPORT_START + radeon_crtc->crtc_offset, (x << 16) | y); + viewport_w = crtc->mode.hdisplay; + viewport_h = (crtc->mode.vdisplay + 1) & ~1; WREG32(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset, - (crtc->mode.hdisplay << 16) | crtc->mode.vdisplay); + (viewport_w << 16) | viewport_h); /* pageflip setup */ /* make sure flip is at vb rather than hb */ -- 1.7.1.1
connector - encoder relationship
On Wed, May 25, 2011 at 12:07:33PM -0400, Alex Deucher wrote: > On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer > wrote: > > Hi All, > > > > I'm currently looking into implementing a SoC graphics core with KMS. > > > > What I wonder about is the relationship between connectors and encoders. > > On my board I have a sii9022 HDMI encoder connected via i2c. This chip > > supports reading edid data, tracks the connection status of the display > > and needs to be configured when the resolution changes. So my first > > guess is that I have to implement an encoder. looking at struct > > drm_encoder_funcs there are no callbacks suitable for this. struct > > drm_connector_funcs on the other hand has all the callbacks I need. > > Now I look at drivers/gpu/drm/i2c. The drivers there implement a > > drm_encoder_slave which also has all the callbacks I need. So from > > one point of view the functions should be implemented in the connector, > > while in the i2c case it's implemented in the (slave-) encoder. > > Generally I have the feeling that my sii9022 should be both an encoder > > and a connector, but this doesn't fit into the current scheme. > > > > I'm confused. Could someone clarify this a bit? > > The general idea is this: > framebuffer -> crtc -> encoder -> connector -> monitor > > - The framebuffer is just a buffer vram that has an image encoded in > it as an array of pixels. > - The crtc reads the data out of the framebuffer and generates the > video mode timing in conjunction with a PLL. The crtc also determines > what part of the framebuffer is read; e.g., when multi-head is > enabled, each crtc scans out of a different part of vram; in clone > mode, each crtc scans out of the same part of vram. > - The encoder takes the digital bitstream from the crtc and converts > it to the appropriate analog levels for transmission across the > connector to the monitor. > - The connector provides the appropriate physical plug (HDMI, DVI-D, > VGA, S-video, etc.) for the monitor to connect to. > > crtcs are usually routeable and can be connected to one or many > encoders simultaneously. The encoders can also be connected to one or > more connectors (e.g., you might have a single TMDS encoder that is > connected to the digital portion of a DVI-I port and also to a HDMI > port, or you might have a DAC that is connected to a VGA port and an > S-video port). Finally i2c lines are associated with connectors, > since generally the i2c pins are wired to the connector and in many > cases, each connectors has it's own i2c line. For example, you might > have a single TMDS encoder that is wired to a DVI-D port with its own > i2c line and an HDMI port with its own i2c line. Each connector may > have it's own hotplug (HPD) pin as well. That way you could query the > EDID from each connector separately for example. > > Is the sii9022 being driven by the output of a DVO encoder from your > display hw? If so your display path would look like: > > crtc -> DVO (master encoder) -> sii9022 (slave encoder) -> HDMI plug -> > monitor > > The general GPU driver might register the i2c buses that are used by > the various parts (encoder, connector), then it's just a matter of > plugging in the right parts for each component (e.g. you'd hook up the > sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the > hdmi connector object, etc.). > > I hope this helps. Thanks, that helped a lot. There are most probably more questions but for the moment I'll continue digging myself through the maze ;) Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #23 from Bob Ham 2011-05-27 09:50:18 PDT --- Created an attachment (id=47235) --> (https://bugs.freedesktop.org/attachment.cgi?id=47235) Kernel log with strange time out behaviour following X load Above I've stated that the machine locks hard. From this log it shows the Magic SysRq key is still working so evidently it isn't a hard lock. -- 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 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #23 from Bob Ham 2011-05-27 09:50:18 PDT --- Created an attachment (id=47235) --> (https://bugs.freedesktop.org/attachment.cgi?id=47235) Kernel log with strange time out behaviour following X load Above I've stated that the machine locks hard. From this log it shows the Magic SysRq key is still working so evidently it isn't a hard lock. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #22 from Bob Ham 2011-05-27 09:47:15 PDT --- I've done a bisect on GPU lockups with warzone 2100. During this bisect there were some kernels that displayed bad GL rendering (lots of artifacts, flickering textures, etc.), some of which locked up the GPU and some of which didn't. I've treated these kernels as 'good' if they do not lock up because bad rendering is not a problem with recent kernels so it's likely to have been a different issue. The last commit identified by the bisect caused the kernel to behave in a strange way with various bits timing out (particular on file system access) as soon as X was loaded, prior to any GL activity. The system is unusable and the time outs continue until the machine locks hard. I'll attached a log of the kernel's output. I'm not sure if this is the bug I'm chasing. Marking the commit as "skip" during the bisect unfortunately produces the following report: There are only 'skip'ped commits left to test. The first bad commit could be any of: b7ae5056c94a8191c1fd0b5697707377516c0c5d 5480f727dc4c049eb46b191bfaeb034067aa6835 We cannot bisect more! The possibilities are as follows: Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ae5056c94a8191c1fd0b5697707377516c0c5d Revert "drm/radeon/kms: remove some pll algo flags" http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5480f727dc4c049eb46b191bfaeb034067aa6835 -- 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 34313] RV770 lock-up with OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=34313 --- Comment #22 from Bob Ham 2011-05-27 09:47:15 PDT --- I've done a bisect on GPU lockups with warzone 2100. During this bisect there were some kernels that displayed bad GL rendering (lots of artifacts, flickering textures, etc.), some of which locked up the GPU and some of which didn't. I've treated these kernels as 'good' if they do not lock up because bad rendering is not a problem with recent kernels so it's likely to have been a different issue. The last commit identified by the bisect caused the kernel to behave in a strange way with various bits timing out (particular on file system access) as soon as X was loaded, prior to any GL activity. The system is unusable and the time outs continue until the machine locks hard. I'll attached a log of the kernel's output. I'm not sure if this is the bug I'm chasing. Marking the commit as "skip" during the bisect unfortunately produces the following report: There are only 'skip'ped commits left to test. The first bad commit could be any of: b7ae5056c94a8191c1fd0b5697707377516c0c5d 5480f727dc4c049eb46b191bfaeb034067aa6835 We cannot bisect more! The possibilities are as follows: Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ae5056c94a8191c1fd0b5697707377516c0c5d Revert "drm/radeon/kms: remove some pll algo flags" http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5480f727dc4c049eb46b191bfaeb034067aa6835 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 --- Comment #4 from Denis Washington 2011-05-27 09:30:10 --- I have talked to Dave Airlie on IRC (#radeon at freenode) today and it seems that my assumption that thermal sensor access is needed for proper fan control is wrong. Rather, the GPU seems to do fan control automatically and can only be influenced by the driver by giving a new policy table to the graphics card's BIOS. The radeon driver doesn't currently do this, however, and relies on the BIOS' defaults, which however seem to be bad on my machine. This is why my fan mostly runs in full speed. Dave says he thinks that there's some of the code lying around inside AMD to do proper fan control setup, but still in need of a lot of review. If this is the case, I would be happy to test the code once it's published in git. (Please correct me if I am wrong about anything I've written here.) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 --- Comment #2 from almos 2011-05-27 08:02:01 PDT --- Created an attachment (id=47231) --> (https://bugs.freedesktop.org/attachment.cgi?id=47231) ut2004.jpg I now spotted this phenomenon in ut2004 on the ONS-ArcticStronghold level. Normally this is not visible due to the fog (show fog turns it off). It is interesting that only the remote objects have incorrect geometry, never the close ones. -- 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 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 --- Comment #2 from almos 2011-05-27 08:02:01 PDT --- Created an attachment (id=47231) --> (https://bugs.freedesktop.org/attachment.cgi?id=47231) ut2004.jpg I now spotted this phenomenon in ut2004 on the ONS-ArcticStronghold level. Normally this is not visible due to the fog (show fog turns it off). It is interesting that only the remote objects have incorrect geometry, never the close ones. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915 "black screen of death" clearly still an issue
i just built a kernel for my ubuntu 10.10 system and forgot to include the following patch which is what i've needed to avoid the dreaded black screen of death: diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c index d2c7104..a1a5d03 100644 --- a/drivers/gpu/drm/i915/intel_opregion.c +++ b/drivers/gpu/drm/i915/intel_opregion.c @@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 bclp) struct opregion_asle *asle = dev_priv->opregion.asle; u32 max; +return ASLE_BACKLIGHT_FAILED; // rday + if (!(bclp & ASLE_BCLP_VALID)) return ASLE_BACKLIGHT_FAILED; and i once again got the black screen. is this still a known and unresolved issue? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 --- Comment #5 from Alex Deucher 2011-05-27 14:23:25 --- Laptops don't generally use the onboard GPU fan controller and thermal sensor since they usually have a single fan for both the GPU and the CPU. The fan and thermal zones are generally exposed via ACPI or a vendor specific control. For more info on the power management options in the driver see the page I linked in comment #1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37652] [r300g] No texture shadow in ogre3d
https://bugs.freedesktop.org/show_bug.cgi?id=37652 --- Comment #6 from Sven-Hendrik Haase 2011-05-27 07:10:38 PDT --- For those without ogre3d, here is an apitrace: http://ompldr.org/vOHRlOQ The character should show a shadow on the ground. It currently doesn't on r300g. -- 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 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #7 from almos 2011-05-27 07:10:29 PDT --- (In reply to comment #6) > Similarly on RV530 I'm seeing frequent (but relatively minor) corruption in > UT2004 with a number of maps which appears to be triangular blocks of old > scenes (not textures AFAICT). However these were not from previously rendered > frames at same location. The skybox is rendered into those tiles (perhaps Z order is wrong?). It's very apparent on CTF-FaceClassic for example. -- 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 37652] [r300g] No texture shadow in ogre3d
https://bugs.freedesktop.org/show_bug.cgi?id=37652 --- Comment #6 from Sven-Hendrik Haase 2011-05-27 07:10:38 PDT --- For those without ogre3d, here is an apitrace: http://ompldr.org/vOHRlOQ The character should show a shadow on the ground. It currently doesn't on r300g. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33648] Black line in Lightsmark with Z compression enabled (RV530)
https://bugs.freedesktop.org/show_bug.cgi?id=33648 --- Comment #7 from almos 2011-05-27 07:10:29 PDT --- (In reply to comment #6) > Similarly on RV530 I'm seeing frequent (but relatively minor) corruption in > UT2004 with a number of maps which appears to be triangular blocks of old > scenes (not textures AFAICT). However these were not from previously rendered > frames at same location. The skybox is rendered into those tiles (perhaps Z order is wrong?). It's very apparent on CTF-FaceClassic for example. -- 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/kms: viewport height has to be even
Otherwise, no vblank interrupts. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37522 Signed-off-by: Alex Deucher Cc: sta...@kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index ec84878..84a69e7 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1045,7 +1045,7 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc, uint64_t fb_location; uint32_t fb_format, fb_pitch_pixels, tiling_flags; u32 fb_swap = EVERGREEN_GRPH_ENDIAN_SWAP(EVERGREEN_GRPH_ENDIAN_NONE); - u32 tmp; + u32 tmp, viewport_w, viewport_h; int r; /* no fb bound */ @@ -1171,8 +1171,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc, y &= ~1; WREG32(EVERGREEN_VIEWPORT_START + radeon_crtc->crtc_offset, (x << 16) | y); + viewport_w = crtc->mode.hdisplay; + viewport_h = (crtc->mode.vdisplay + 1) & ~1; WREG32(EVERGREEN_VIEWPORT_SIZE + radeon_crtc->crtc_offset, - (crtc->mode.hdisplay << 16) | crtc->mode.vdisplay); + (viewport_w << 16) | viewport_h); /* pageflip setup */ /* make sure flip is at vb rather than hb */ @@ -1213,7 +1215,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, uint64_t fb_location; uint32_t fb_format, fb_pitch_pixels, tiling_flags; u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE; - u32 tmp; + u32 tmp, viewport_w, viewport_h; int r; /* no fb bound */ @@ -1338,8 +1340,10 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc, y &= ~1; WREG32(AVIVO_D1MODE_VIEWPORT_START + radeon_crtc->crtc_offset, (x << 16) | y); + viewport_w = crtc->mode.hdisplay; + viewport_h = (crtc->mode.vdisplay + 1) & ~1; WREG32(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset, - (crtc->mode.hdisplay << 16) | crtc->mode.vdisplay); + (viewport_w << 16) | viewport_h); /* pageflip setup */ /* make sure flip is at vb rather than hb */ -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30052] Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 Marco Trevisan (Treviño) changed: What|Removed |Added CC||m...@3v1n0.net --- Comment #14 from Marco Trevisan (Treviño) 2011-05-27 12:57:16 --- Could this related to Bug 15851 too? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37660] regression after "st/mesa: rewrite st_choose_format() to be table driven"
https://bugs.freedesktop.org/show_bug.cgi?id=37660 Marek Olšák changed: What|Removed |Added Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 37660] regression after "st/mesa: rewrite st_choose_format() to be table driven"
https://bugs.freedesktop.org/show_bug.cgi?id=37660 Marek Ol??k changed: What|Removed |Added Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37660] New: regression after "st/mesa: rewrite st_choose_format() to be table driven"
https://bugs.freedesktop.org/show_bug.cgi?id=37660 Summary: regression after "st/mesa: rewrite st_choose_format() to be table driven" Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: rand...@mail.ru Running 3DMark2001se under wine (wine-1.3.20-439-g1ec78b8) and mesa-git gives me black screen at loading, with many err:d3d_draw:drawStridedFast > GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawElements @ drawprim.c / 43 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8 cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40). fixme:d3d:context_check_fbo_status Color attachment 0: (0x199fd0) WINED3DFMT_B8G8R8X8_UNORM 1024x768 fixme:d3d:context_check_fbo_status Depth attachment: (0x19a128) WINED3DFMT_D32_UNORM 1024x768 err:d3d_draw:drawStridedFast > GL_INVALID_FRAMEBUFFER_OPERATION (0x506) bisecting points at d57e95f22af1a1b2d9013db7a15524717bd29579 is the first bad commit commit d57e95f22af1a1b2d9013db7a15524717bd29579 Author: Brian Paul Date: Sat May 21 10:43:49 2011 -0600 st/mesa: rewrite st_choose_format() to be table driven guest@slax:~/botva/src/src/mesa$ git bisect log git bisect start # bad: [f7b3f40b70dc7dd602897d364011089047583c5d] i965: Pack the lookup and line_aa bits into the first dword of the key. git bisect bad f7b3f40b70dc7dd602897d364011089047583c5d # good: [fd6f2d6e5783d8810d0ab88e1c470958fd5eb2eb] st/mesa: assign renderbuffer's format field when allocating storage git bisect good fd6f2d6e5783d8810d0ab88e1c470958fd5eb2eb # bad: [a9e65097855468529242f9076bd6ef2a6c8062c1] intel: Add is_hiz_depth_format() to intel_contex.vtbl git bisect bad a9e65097855468529242f9076bd6ef2a6c8062c1 # bad: [3869be74afb184dbdf9d67fda3de3e3ac7e3db6c] glx: More comment cleanup git bisect bad 3869be74afb184dbdf9d67fda3de3e3ac7e3db6c # bad: [d57e95f22af1a1b2d9013db7a15524717bd29579] st/mesa: rewrite st_choose_format() to be table driven git bisect bad d57e95f22af1a1b2d9013db7a15524717bd29579 # good: [e8b1c6d6f55f5be3bef25084fdd8b6127517e137] mesa: Fix return type of _mesa_get_format_bytes() (#37351) git bisect good e8b1c6d6f55f5be3bef25084fdd8b6127517e137 # good: [c3c1976f522a67be6a0619e938a90cf186ad42e6] wgl: Don't hold on to user supplied HDC. git bisect good c3c1976f522a67be6a0619e938a90cf186ad42e6 hw: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AR [Radeon 9600] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Sapphire Radeon 9600XT Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at e800 (32-bit, prefetchable) [size=128M] I/O ports at c800 [size=256] Memory at ff8f (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff8c [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 Kernel driver in use: radeon Kernel modules: radeon kernel: 2.6.39-rc7+ X server - 1.9 branch ddx - 557f46dc2f18734ecf1f18dee7e951e0bf062e63 libdrm - ba11501bb9f5bd98110dfe1385b4501c0a9a643a -- 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 37660] New: regression after "st/mesa: rewrite st_choose_format() to be table driven"
https://bugs.freedesktop.org/show_bug.cgi?id=37660 Summary: regression after "st/mesa: rewrite st_choose_format() to be table driven" Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: randrik at mail.ru Running 3DMark2001se under wine (wine-1.3.20-439-g1ec78b8) and mesa-git gives me black screen at loading, with many err:d3d_draw:drawStridedFast > GL_INVALID_FRAMEBUFFER_OPERATION (0x506) from glDrawElements @ drawprim.c / 43 fixme:d3d:context_check_fbo_status FBO status GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8 cd6) fixme:d3d:context_check_fbo_status Location SFLAG_INTEXTURE (0x40). fixme:d3d:context_check_fbo_status Color attachment 0: (0x199fd0) WINED3DFMT_B8G8R8X8_UNORM 1024x768 fixme:d3d:context_check_fbo_status Depth attachment: (0x19a128) WINED3DFMT_D32_UNORM 1024x768 err:d3d_draw:drawStridedFast > GL_INVALID_FRAMEBUFFER_OPERATION (0x506) bisecting points at d57e95f22af1a1b2d9013db7a15524717bd29579 is the first bad commit commit d57e95f22af1a1b2d9013db7a15524717bd29579 Author: Brian Paul Date: Sat May 21 10:43:49 2011 -0600 st/mesa: rewrite st_choose_format() to be table driven guest at slax:~/botva/src/src/mesa$ git bisect log git bisect start # bad: [f7b3f40b70dc7dd602897d364011089047583c5d] i965: Pack the lookup and line_aa bits into the first dword of the key. git bisect bad f7b3f40b70dc7dd602897d364011089047583c5d # good: [fd6f2d6e5783d8810d0ab88e1c470958fd5eb2eb] st/mesa: assign renderbuffer's format field when allocating storage git bisect good fd6f2d6e5783d8810d0ab88e1c470958fd5eb2eb # bad: [a9e65097855468529242f9076bd6ef2a6c8062c1] intel: Add is_hiz_depth_format() to intel_contex.vtbl git bisect bad a9e65097855468529242f9076bd6ef2a6c8062c1 # bad: [3869be74afb184dbdf9d67fda3de3e3ac7e3db6c] glx: More comment cleanup git bisect bad 3869be74afb184dbdf9d67fda3de3e3ac7e3db6c # bad: [d57e95f22af1a1b2d9013db7a15524717bd29579] st/mesa: rewrite st_choose_format() to be table driven git bisect bad d57e95f22af1a1b2d9013db7a15524717bd29579 # good: [e8b1c6d6f55f5be3bef25084fdd8b6127517e137] mesa: Fix return type of _mesa_get_format_bytes() (#37351) git bisect good e8b1c6d6f55f5be3bef25084fdd8b6127517e137 # good: [c3c1976f522a67be6a0619e938a90cf186ad42e6] wgl: Don't hold on to user supplied HDC. git bisect good c3c1976f522a67be6a0619e938a90cf186ad42e6 hw: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AR [Radeon 9600] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Sapphire Radeon 9600XT Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at e800 (32-bit, prefetchable) [size=128M] I/O ports at c800 [size=256] Memory at ff8f (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff8c [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 Kernel driver in use: radeon Kernel modules: radeon kernel: 2.6.39-rc7+ X server - 1.9 branch ddx - 557f46dc2f18734ecf1f18dee7e951e0bf062e63 libdrm - ba11501bb9f5bd98110dfe1385b4501c0a9a643a -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #15 from Anisse Astier 2011-05-27 10:48:09 --- Created an attachment (id=59672) --> (https://bugzilla.kernel.org/attachment.cgi?id=59672) xrandr output before and after first patch Here you can see the output of xrandr before and after applying patch in comment 11 . Adding patch in comment 12 didn't change anything. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #14 from Anisse Astier 2011-05-27 10:45:53 --- Created an attachment (id=59662) --> (https://bugzilla.kernel.org/attachment.cgi?id=59662) Dmesg with 1st patch applied As you asked, I tried with first patch, then second patch on top of it. No change on display (still blank, no backlight) in any case. But we can see here a difference in modesets shown kernel log, before and after first patch. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #13 from Anisse Astier 2011-05-27 10:34:38 --- Created an attachment (id=59652) --> (https://bugzilla.kernel.org/attachment.cgi?id=59652) Xorg log with drm-radeon-testing as of 05/26 (no patch applied) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 and boot freeze
On Wed, 25 May 2011 10:38:59 -0300, Yermandu Patapitafious wrote: > Hello Jean, > > Thanks for answer, i will take more atention in subjects, > > > What is the last kernel that works for you? > > > > Are you running self-built or distribution kernels? > > Can we please see the kernel configuration file? > > My Last kernel working from git repository was 2.6.38-rc8+, the stable > line .38.X work fines. OK, this is good, it means the bisection domain isn't too big. Can you remember if you made any kernel configuration change between 2.6.38 and 2.6.39? > I use the git version from kernel.org site pull and build manually be > me. The Latest Stable Kernel is from gentoo-sources, and i always > compile manually too. > I have attached .config kernel in mail. I see you have many debug options enabled. I suggest you try building a kernel without these and see if it makes a difference. > > It would be great > > if you were able to get us the kernel logs in a text form, using some > > form of serial console. > > Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues > happing I looking for some way to send panic log in text, but no > success yet. If you can't get a serial console to capture the complete error log, the other approach is to bisect between kernels 2.6.38 and 2.6.39, to find the faulty commit. If you're used to building your kernel yourself, it shouldn't be too difficult. Just clone Linus' kernel tree and follow the git bisect manual page: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Jean Delvare ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 --- Comment #4 from Denis Washington 2011-05-27 09:30:10 --- I have talked to Dave Airlie on IRC (#radeon at freenode) today and it seems that my assumption that thermal sensor access is needed for proper fan control is wrong. Rather, the GPU seems to do fan control automatically and can only be influenced by the driver by giving a new policy table to the graphics card's BIOS. The radeon driver doesn't currently do this, however, and relies on the BIOS' defaults, which however seem to be bad on my machine. This is why my fan mostly runs in full speed. Dave says he thinks that there's some of the code lying around inside AMD to do proper fan control setup, but still in need of a lot of review. If this is the case, I would be happy to test the code once it's published in git. (Please correct me if I am wrong about anything I've written here.) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: connector - encoder relationship
On Wed, May 25, 2011 at 12:07:33PM -0400, Alex Deucher wrote: > On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer wrote: > > Hi All, > > > > I'm currently looking into implementing a SoC graphics core with KMS. > > > > What I wonder about is the relationship between connectors and encoders. > > On my board I have a sii9022 HDMI encoder connected via i2c. This chip > > supports reading edid data, tracks the connection status of the display > > and needs to be configured when the resolution changes. So my first > > guess is that I have to implement an encoder. looking at struct > > drm_encoder_funcs there are no callbacks suitable for this. struct > > drm_connector_funcs on the other hand has all the callbacks I need. > > Now I look at drivers/gpu/drm/i2c. The drivers there implement a > > drm_encoder_slave which also has all the callbacks I need. So from > > one point of view the functions should be implemented in the connector, > > while in the i2c case it's implemented in the (slave-) encoder. > > Generally I have the feeling that my sii9022 should be both an encoder > > and a connector, but this doesn't fit into the current scheme. > > > > I'm confused. Could someone clarify this a bit? > > The general idea is this: > framebuffer -> crtc -> encoder -> connector -> monitor > > - The framebuffer is just a buffer vram that has an image encoded in > it as an array of pixels. > - The crtc reads the data out of the framebuffer and generates the > video mode timing in conjunction with a PLL. The crtc also determines > what part of the framebuffer is read; e.g., when multi-head is > enabled, each crtc scans out of a different part of vram; in clone > mode, each crtc scans out of the same part of vram. > - The encoder takes the digital bitstream from the crtc and converts > it to the appropriate analog levels for transmission across the > connector to the monitor. > - The connector provides the appropriate physical plug (HDMI, DVI-D, > VGA, S-video, etc.) for the monitor to connect to. > > crtcs are usually routeable and can be connected to one or many > encoders simultaneously. The encoders can also be connected to one or > more connectors (e.g., you might have a single TMDS encoder that is > connected to the digital portion of a DVI-I port and also to a HDMI > port, or you might have a DAC that is connected to a VGA port and an > S-video port). Finally i2c lines are associated with connectors, > since generally the i2c pins are wired to the connector and in many > cases, each connectors has it's own i2c line. For example, you might > have a single TMDS encoder that is wired to a DVI-D port with its own > i2c line and an HDMI port with its own i2c line. Each connector may > have it's own hotplug (HPD) pin as well. That way you could query the > EDID from each connector separately for example. > > Is the sii9022 being driven by the output of a DVO encoder from your > display hw? If so your display path would look like: > > crtc -> DVO (master encoder) -> sii9022 (slave encoder) -> HDMI plug -> > monitor > > The general GPU driver might register the i2c buses that are used by > the various parts (encoder, connector), then it's just a matter of > plugging in the right parts for each component (e.g. you'd hook up the > sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the > hdmi connector object, etc.). > > I hope this helps. Thanks, that helped a lot. There are most probably more questions but for the moment I'll continue digging myself through the maze ;) Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
