Re: drm i915 hangs on heavy io load
On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining wrote: > Hi all, > > On Di, 30 Okt 2012, Dave Airlie wrote: >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 >> final to 3.7-rc1 or maybe -rc2. > > Sorry for my ignorance ... I did on master branch > $ git checkout v3.7-rc1 > ... > $ git bisect start drivers/gpu/drm/i915 > $ git bisect bad > $ git bisect good v3.6 > Bisecting: 121 revisions left to test after this (roughly 7 steps) > [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new > set_mode code flow > $ > after that I am back somewhere around > 3.6.0-rc2 > ??? > > Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2? > How can I go back to 3.6.0-rc2? Yeah thats fine, bisecting works by going to where commits were originally committed, so drm-intel-next was 3.6.0-rc2 at some point was only merged into Linus later. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/16] drivers/gpu/drm/drm_cache.c: use WARN_ONCE
From: Julia Lawall Use WARN_ONCE rather than printk followed by WARN_ON_ONCE(1), for conciseness. A simplified version of the semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ expression list es; @@ -printk( +WARN_ONCE(1, es); -WARN_ON_ONCE(1); // Signed-off-by: Julia Lawall --- drivers/gpu/drm/drm_cache.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index a575cb2..8df9a7b 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -94,8 +94,7 @@ drm_clflush_pages(struct page *pages[], unsigned long num_pages) kunmap_atomic(page_virtual); } #else - printk(KERN_ERR "Architecture has no drm_cache.c support\n"); - WARN_ON_ONCE(1); + WARN_ONCE(1, KERN_ERR "Architecture has no drm_cache.c support\n"); #endif } EXPORT_SYMBOL(drm_clflush_pages); @@ -119,8 +118,7 @@ drm_clflush_sg(struct sg_table *st) if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0) printk(KERN_ERR "Timed out waiting for cache flush.\n"); #else - printk(KERN_ERR "Architecture has no drm_cache.c support\n"); - WARN_ON_ONCE(1); + WARN_ONCE(1, KERN_ERR "Architecture has no drm_cache.c support\n"); #endif } EXPORT_SYMBOL(drm_clflush_sg); @@ -142,8 +140,7 @@ drm_clflush_virt_range(char *addr, unsigned long length) if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0) printk(KERN_ERR "Timed out waiting for cache flush.\n"); #else - printk(KERN_ERR "Architecture has no drm_cache.c support\n"); - WARN_ON_ONCE(1); + WARN_ONCE(1, KERN_ERR "Architecture has no drm_cache.c support\n"); #endif } EXPORT_SYMBOL(drm_clflush_virt_range); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm: exynos: fix for mapping non contig dma buffers
This patch fixes the problem of mapping gem objects which are non-contigous
dma buffers. These buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous.
Current implementation just maps the first page of each SG List and leave
the other pages unmapped, leading to a crash.
Given solution finds the page struct for the faulting page through parsing SG
table and map it.
This patch is based on branch exynos-drm-next-iommu at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
v1:
1) instead of mapping whole section, mapping single page.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8cb6824..c557ac7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,13 +95,31 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
*obj,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+ struct scatterlist *sgl;
unsigned long pfn;
+ int i;
if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
- if (!buf->pages)
+ if (!buf->sgt)
return -EINTR;
- pfn = page_to_pfn(buf->pages[page_offset++]);
+ sgl = buf->sgt->sgl;
+ for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
+ if (!sgl) {
+ DRM_ERROR("invalid SG table\n");
+ return -EINTR;
+ }
+ if (page_offset < (sgl->length >> PAGE_SHIFT))
+ break;
+ page_offset -= (sgl->length >> PAGE_SHIFT);
+ }
+
+ if (i >= buf->sgt->nents) {
+ DRM_ERROR("invalid page offset\n");
+ return -EINVAL;
+ }
+
+ pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
} else
pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers
This patch fixes the problem of mapping contigous dma buffers. Currently page
struct is calculated from the buf->dma_addr which is not the physical address.
It is replaced by buf->pages which points to the page struct of the first page
of contigous memory chunk. This gives the correct page frame number for
mapping.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index c557ac7..50d73f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -120,8 +120,12 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
*obj,
}
pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
- } else
- pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
+ } else {
+ if (!buf->pages)
+ return -EINTR;
+
+ pfn = page_to_pfn(buf->pages[0]) + page_offset;
+ }
return vm_insert_mixed(vma, f_vaddr, pfn);
}
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56620] r600g: ETQW renders garbage with --enable-r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=56620 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Laurent carlier --- Fixed with tstellar repo (http://cgit.freedesktop.org/~tstellar/llvm/) and AMDGPU experimental target enabled. -- 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 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #3 from Andriy Gapon --- Is KMS needed for r600g? -- 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 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #4 from Alex Deucher --- (In reply to comment #3) > Is KMS needed for r600g? Yes, KMS is required for r600g. Support for UMS in general is deprecated. -- 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 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #5 from Andriy Gapon --- That was my impression, thank you for the confirmation. (please see the Platform header of this report) Unfortunately, FreeBSD doesn't have KMS support for ati yet... -- 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
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off and then turn TV on and - xrandr --output DVI-0 --auto to bring up the the TV and get a clone of monitor. This still works with drm-core-next but not with drm-fixes (todays or from a few days ago). With df I now loose the monitor with signal out of range when doing above, the TV output is OK. To get the monitor back I need to turn off TV, then off/auto the monitor. xrandr --output DVI-0 --off xrandr --output DVI-1 --off xrandr --output DVI-1 --auto The output from xrandr while the monitor is showing signal out of range looks normal. If I boot with the TV on it works OK. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: > For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 > and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off > and then turn TV on and - > > xrandr --output DVI-0 --auto > > to bring up the the TV and get a clone of monitor. > > This still works with drm-core-next but not with drm-fixes (todays or from a > few days ago). > > With df I now loose the monitor with signal out of range when doing above, > the TV output is OK. To get the monitor back I need to turn off TV, then > off/auto the monitor. > > xrandr --output DVI-0 --off > xrandr --output DVI-1 --off > xrandr --output DVI-1 --auto > > The output from xrandr while the monitor is showing signal out of range > looks normal. > > If I boot with the TV on it works OK. Can you bisect? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56743] New: Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 Priority: medium Bug ID: 56743 Assignee: dri-devel@lists.freedesktop.org Summary: Invalid command stream (bad START_3D) on DIS gpu Severity: normal Classification: Unclassified OS: Linux (All) Reporter: intergalactic.anonym...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 69522 --> https://bugs.freedesktop.org/attachment.cgi?id=69522&action=edit dmesg output On my muxed hybrid system (Lenovo IdeaPad U455) X works fine with IGD gpu (RS780M), but screen gets garbled when DIS gpu (RV710) is active. In dmesg output there are lots of following messages: [drm:r600_packet3_check] *ERROR* bad START_3D [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! My system is: Lenovo IdeaPad U455 with RS780M and RV710 gpus. linux-3.7.0-rc3+ libdrm-2.4.39 xf86-video-ati-6.14.6 mesa-9.0 glu-9.0 xorg-server-1.12.3 -- 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 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #1 from Igor Murzov --- Created attachment 69523 --> https://bugs.freedesktop.org/attachment.cgi?id=69523&action=edit lspci -vvv -- 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 v7 1/8] video: add display_timing struct and helpers
On Thu, Nov 01, 2012 at 09:08:42PM +0100, Thierry Reding wrote:
> On Wed, Oct 31, 2012 at 10:28:01AM +0100, Steffen Trumtrar wrote:
> [...]
> > +void timings_release(struct display_timings *disp)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < disp->num_timings; i++)
> > + kfree(disp->timings[i]);
> > +}
> > +
> > +void display_timings_release(struct display_timings *disp)
> > +{
> > + timings_release(disp);
> > + kfree(disp->timings);
> > +}
>
> I'm not quite sure I understand how these are supposed to be used. The
> only use-case where a struct display_timings is dynamically allocated is
> for the OF helpers. In that case, wouldn't it be more useful to have a
> function that frees the complete structure, including the struct
> display_timings itself? Something like this, which has all of the above
> rolled into one:
>
> void display_timings_free(struct display_timings *disp)
> {
> if (disp->timings) {
> unsigned int i;
>
> for (i = 0; i < disp->num_timings; i++)
> kfree(disp->timings[i]);
> }
>
> kfree(disp->timings);
> kfree(disp);
> }
>
Well, you are right. They can be rolled into one function.
The extra function call is useless and as it seems confusing.
Regards,
Steffen
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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
[Bug 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #2 from Igor Murzov --- Created attachment 69524 --> https://bugs.freedesktop.org/attachment.cgi?id=69524&action=edit /var/log/Xorg.0.log -- 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 v7 2/8] of: add helper to parse display timings
On Thu, Nov 01, 2012 at 09:15:10PM +0100, Thierry Reding wrote: > On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote: > [...] > > diff --git a/Documentation/devicetree/bindings/video/display-timings.txt > > b/Documentation/devicetree/bindings/video/display-timings.txt > [...] > > @@ -0,0 +1,139 @@ > > +display-timings bindings > > +== > > + > > +display-timings-node > > + > > Maybe extend the underline to the length of the section and subsection > titles respectively? > > > +struct display_timing > > +=== > > Same here. > > > +config OF_DISPLAY_TIMINGS > > + def_bool y > > + depends on DISPLAY_TIMING > > Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING, > or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency? > Yes, to all three above. > > +/** > > + * of_get_display_timing_list - parse all display_timing entries from a > > device_node > > + * @np: device_node with the subnodes > > + **/ > > +struct display_timings *of_get_display_timing_list(struct device_node *np) > > Perhaps this would better be named of_get_display_timings() to match the > return type? > Hm, I'm not really sure about that. I found it to error prone, to have a function of_get_display_timing and of_get_display_timings. That's why I chose of_get_display_timing_list. But you are correct, that it doesn't match the return value. Maybe I should just make the first function static and change the name as you suggested. > > + disp = kzalloc(sizeof(*disp), GFP_KERNEL); > > Shouldn't you be checking this for allocation failures? > > > + disp->timings = kzalloc(sizeof(struct display_timing > > *)*disp->num_timings, > > + GFP_KERNEL); > > Same here. > Yes, to both. Regards, Steffen -- 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
Re: [PATCH v7 2/8] of: add helper to parse display timings
Hi!
On Fri, Nov 02, 2012 at 10:49:47PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
> > +static int parse_property(struct device_node *np, char *name,
> > + struct timing_entry *result)
> > +{
> > + struct property *prop;
> > + int length;
> > + int cells;
> > + int ret;
> > +
> > + prop = of_find_property(np, name, &length);
> > + if (!prop) {
> > + pr_err("%s: could not find property %s\n", __func__, name);
> > + return -EINVAL;
> > + }
> > +
> > + cells = length / sizeof(u32);
> > + if (cells == 1) {
> > + ret = of_property_read_u32_array(np, name, &result->typ,
> > cells);
>
> As you are reading only one vaue, you can use of_property_read_u32 instead.
>
Yes, thats copypasta, no need for _array here.
> > + result->min = result->typ;
> > + result->max = result->typ;
> > + } else if (cells == 3) {
> > + ret = of_property_read_u32_array(np, name, &result->min,
> > cells);
>
> You are considering only min element, what about typ and max elements?
>
I start at the address of result->min and read three u32-values, therefore all
three (min,typ,max) are filled with values.
> > +
> > +/**
> > + * of_display_timings_exists - check if a display-timings node is provided
> > + * @np: device_node with the timing
> > + **/
> > +int of_display_timings_exists(struct device_node *np)
> > +{
> > + struct device_node *timings_np;
> > + struct device_node *default_np;
> > +
> > + if (!np)
> > + return -EINVAL;
> > +
> > + timings_np = of_parse_phandle(np, "display-timings", 0);
> > + if (!timings_np)
> > + return -EINVAL;
> > +
> > + return -EINVAL;
>
> Here it should return success instead of -EINVAL.
>
Yes.
> And one query.. are the binding properties names and "display-timings"
> node structure template finalized..?
>
I sure hope so. There actually is one error in the examples though.
The property clock is called clock-frequency. I included it correctly
at the top of display-timings.txt, but overlooked it in the examples.
Regards,
Steffen
--
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
[Bug 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #3 from Alex Deucher --- The r6xx command stream is getting sent to the r7xx kernel driver instance. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
Alex Deucher wrote: On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off and then turn TV on and - xrandr --output DVI-0 --auto to bring up the the TV and get a clone of monitor. This still works with drm-core-next but not with drm-fixes (todays or from a few days ago). With df I now loose the monitor with signal out of range when doing above, the TV output is OK. To get the monitor back I need to turn off TV, then off/auto the monitor. xrandr --output DVI-0 --off xrandr --output DVI-1 --off xrandr --output DVI-1 --auto The output from xrandr while the monitor is showing signal out of range looks normal. If I boot with the TV on it works OK. Can you bisect? 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 Author: Alex Deucher Date: Fri Oct 5 10:22:02 2012 -0400 drm/radeon: allocate PPLLs from low to high The order shouldn't matter, but there have been problems reported on certain older asics. This behaves more like the original code before the PPLL allocation rework. Signed-off-by: Alex Deucher Cc: Markus Trippelsdorf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49351] vga_switcheroo results in black screen (bisected)
https://bugzilla.kernel.org/show_bug.cgi?id=49351 Igor Murzov changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #19 from Igor Murzov 2012-11-04 21:05:05 --- Fixed by: commit 0b90365e7a32317b948583c4b5c2712d84610b08 Author: Alex Deucher Date: Tue Oct 23 17:57:54 2012 -0400 drm/radeon: fix ATPX regression in acpi rework Copy and paste typo in the apci rework. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=49351 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24694] R6xx kms gloss corruption.
https://bugs.freedesktop.org/show_bug.cgi?id=24694 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andy Furniss --- Closing - ancient - R600 Classic long gone -- 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: drm i915 hangs on heavy io load
On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/exynos: add iommu support for exynos drm framework
Changelog v4:
- fix condition to drm_iommu_detach_device funtion.
Changelog v3:
- add dma_parms->max_segment_size setting of drm_device->dev.
- use devm_kzalloc instead of kzalloc.
Changelog v2:
- fix iommu attach condition.
. check archdata.dma_ops of drm device instead of
subdrv device's one.
- code clean to exynos_drm_iommu.c file.
. remove '#ifdef CONFIG_ARM_DMA_USE_IOMMU' from exynos_drm_iommu.c
and add it to driver/gpu/drm/exynos/Kconfig.
Changelog v1:
This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.
GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig |6 +
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos_drm_buf.c| 88 +
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 87 +---
drivers/gpu/drm/exynos/exynos_drm_drv.c| 23 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 ++
drivers/gpu/drm/exynos/exynos_drm_fb.c | 52 +++-
drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 ++--
drivers/gpu/drm/exynos/exynos_drm_gem.h|1 +
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 150
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 85 +++
11 files changed, 409 insertions(+), 305 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 59a26e5..4ea8cdc 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -10,6 +10,12 @@ config DRM_EXYNOS
Choose this option if you have a Samsung SoC EXYNOS chipset.
If M is selected the module will be called exynosdrm.
+config DRM_EXYNOS_IOMMU
+ bool "EXYNOS DRM IOMMU Support"
+ depends on DRM_EXYNOS && EXYNOS_IOMMU && ARM_DMA_USE_IOMMU
+ help
+ Choose this option if you want to use IOMMU feature for DRM.
+
config DRM_EXYNOS_DMABUF
bool "EXYNOS DRM DMABUF"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index eb651ca..26813b8 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,6 +8,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 118c117..48c5896 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -33,71 +33,58 @@
static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
{
- dma_addr_t start_addr;
+ int ret = 0;
unsigned int npages, i = 0;
struct scatterlist *sgl;
- int ret = 0;
+ enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (IS_NONCONTIG_BUFFER(flags)) {
- DRM_DEBUG_KMS("not support allocation type.\n");
- return -EINVAL;
- }
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}
- if (buf->size >= SZ_1M) {
- npages = buf->size >> SECTION_SHIFT;
- buf->page_size = SECTION_SIZE;
- } else if (buf->size >= SZ_64K) {
- npages = buf->size >> 16;
- buf->page_size = SZ_64K;
- } else {
- npages = buf->size >> PAGE_SHIFT;
- buf->page_size = PAGE_SIZE;
+ init_dma_attrs(&buf->dma_attrs);
+
+ if (flags & EXYNOS_BO_NONCONTIG)
+ attr = DMA_ATTR_WRITE_COMBINE;
+
+ dma_set_attr(attr, &buf->dma_attrs);
+
+ buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
+ if (!buf->kvaddr) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ return -ENOMEM;
}
buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!buf->sgt) {
DRM_ERROR("failed to allocate sg table.\n");
- return -E
[PATCH] drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |3 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 342 --
drivers/gpu/drm/exynos/exynos_drm_gem.c | 123 +++
drivers/gpu/drm/exynos/exynos_drm_gem.h | 45
include/uapi/drm/exynos_drm.h | 13 +-
5 files changed, 499 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a9db025..a4702a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -231,8 +231,7 @@ struct exynos_drm_g2d_private {
struct device *dev;
struct list_headinuse_cmdlist;
struct list_headevent_list;
- struct list_headgem_list;
- unsigned intgem_nr;
+ struct list_headuserptr_list;
};
struct drm_exynos_file_private {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index bac2399..a9002ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -97,11 +97,19 @@
#define MAX_BUF_ADDR_NR6
+/* maximum buffer pool size of userptr is 64MB as default */
+#define MAX_POOL (64 * 1024 * 1024)
+
+enum {
+ BUF_TYPE_GEM = 1,
+ BUF_TYPE_USERPTR,
+};
+
/* cmdlist data structure */
struct g2d_cmdlist {
- u32 head;
- u32 data[G2D_CMDLIST_DATA_NUM];
- u32 last; /* last data offset */
+ u32 head;
+ unsigned long data[G2D_CMDLIST_DATA_NUM];
+ u32 last; /* last data offset */
};
struct drm_exynos_pending_g2d_event {
@@ -109,11 +117,26 @@ struct drm_exynos_pending_g2d_event {
struct drm_exynos_g2d_event event;
};
+struct g2d_cmdlist_userptr {
+ struct list_headlist;
+ dma_addr_t dma_addr;
+ unsigned long userptr;
+ uns
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #11 from Alexandre Demers --- Found what is wrong with the help of a few printk and by comparing to the code being replaced. All the logic is good (going through crtc, disabling them, waiting for vblank) BUT setting "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. If I do as in the previous code by setting tmp = 0 and then continuing with: radeon_wait_for_vblank(rdev, i); WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); everything works fine as before. What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? From what I read with printk, it is far from a 0 or a 1. Is this normal? -- 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 29318] Marbleblast textures broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=29318 Adam K Kirchhoff changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #4 from Adam K Kirchhoff --- No, it works fine with the r600 gallium driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/3912c2a3/attachment.html>
[Bug 29317] Neverwinter night cloak texture is broken on r600
https://bugs.freedesktop.org/show_bug.cgi?id=29317 Adam K Kirchhoff changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #4 from Adam K Kirchhoff --- Nope, it's fixed with the r600 gallium driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/de0bcbab/attachment.html>
drm i915 hangs on heavy io load
Hi all,
On Di, 30 Okt 2012, Dave Airlie wrote:
> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> final to 3.7-rc1 or maybe -rc2.
Sorry for my ignorance ... I did on master branch
$ git checkout v3.7-rc1
...
$ git bisect start drivers/gpu/drm/i915
$ git bisect bad
$ git bisect good v3.6
Bisecting: 121 revisions left to test after this (roughly 7 steps)
[25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new
set_mode code flow
$
after that I am back somewhere around
3.6.0-rc2
???
Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2?
How can I go back to 3.6.0-rc2?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREEB (n.)
To make the noise of a nylon anorak rubbing against a pair of corduroy
trousers.
--- Douglas Adams, The Meaning of Liff
drm i915 hangs on heavy io load
On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining wrote: > Hi all, > > On Di, 30 Okt 2012, Dave Airlie wrote: >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 >> final to 3.7-rc1 or maybe -rc2. > > Sorry for my ignorance ... I did on master branch > $ git checkout v3.7-rc1 > ... > $ git bisect start drivers/gpu/drm/i915 > $ git bisect bad > $ git bisect good v3.6 > Bisecting: 121 revisions left to test after this (roughly 7 steps) > [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new > set_mode code flow > $ > after that I am back somewhere around > 3.6.0-rc2 > ??? > > Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2? > How can I go back to 3.6.0-rc2? Yeah thats fine, bisecting works by going to where commits were originally committed, so drm-intel-next was 3.6.0-rc2 at some point was only merged into Linus later. Dave.
[Bug 56620] r600g: ETQW renders garbage with --enable-r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=56620 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Laurent carlier --- Fixed with tstellar repo (http://cgit.freedesktop.org/~tstellar/llvm/) and AMDGPU experimental target enabled. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/6bbe4aa4/attachment.html>
[Bug 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #3 from Andriy Gapon --- Is KMS needed for r600g? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/c20859d0/attachment.html>
[Bug 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #4 from Alex Deucher --- (In reply to comment #3) > Is KMS needed for r600g? Yes, KMS is required for r600g. Support for UMS in general is deprecated. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/503659a4/attachment-0001.html>
[Bug 52574] crash in memcpy_texture because of NULL dstAddr (gl_texture_image.Data)
https://bugs.freedesktop.org/show_bug.cgi?id=52574 --- Comment #5 from Andriy Gapon --- That was my impression, thank you for the confirmation. (please see the Platform header of this report) Unfortunately, FreeBSD doesn't have KMS support for ati yet... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/9410ada8/attachment.html>
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off and then turn TV on and - xrandr --output DVI-0 --auto to bring up the the TV and get a clone of monitor. This still works with drm-core-next but not with drm-fixes (todays or from a few days ago). With df I now loose the monitor with signal out of range when doing above, the TV output is OK. To get the monitor back I need to turn off TV, then off/auto the monitor. xrandr --output DVI-0 --off xrandr --output DVI-1 --off xrandr --output DVI-1 --auto The output from xrandr while the monitor is showing signal out of range looks normal. If I boot with the TV on it works OK.
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: > For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 > and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off > and then turn TV on and - > > xrandr --output DVI-0 --auto > > to bring up the the TV and get a clone of monitor. > > This still works with drm-core-next but not with drm-fixes (todays or from a > few days ago). > > With df I now loose the monitor with signal out of range when doing above, > the TV output is OK. To get the monitor back I need to turn off TV, then > off/auto the monitor. > > xrandr --output DVI-0 --off > xrandr --output DVI-1 --off > xrandr --output DVI-1 --auto > > The output from xrandr while the monitor is showing signal out of range > looks normal. > > If I boot with the TV on it works OK. Can you bisect? Alex
[Bug 56743] New: Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 Priority: medium Bug ID: 56743 Assignee: dri-devel at lists.freedesktop.org Summary: Invalid command stream (bad START_3D) on DIS gpu Severity: normal Classification: Unclassified OS: Linux (All) Reporter: intergalactic.anonymous at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 69522 --> https://bugs.freedesktop.org/attachment.cgi?id=69522&action=edit dmesg output On my muxed hybrid system (Lenovo IdeaPad U455) X works fine with IGD gpu (RS780M), but screen gets garbled when DIS gpu (RV710) is active. In dmesg output there are lots of following messages: [drm:r600_packet3_check] *ERROR* bad START_3D [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! My system is: Lenovo IdeaPad U455 with RS780M and RV710 gpus. linux-3.7.0-rc3+ libdrm-2.4.39 xf86-video-ati-6.14.6 mesa-9.0 glu-9.0 xorg-server-1.12.3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/cf2b3e3f/attachment.html>
[Bug 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #1 from Igor Murzov --- Created attachment 69523 --> https://bugs.freedesktop.org/attachment.cgi?id=69523&action=edit lspci -vvv -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/54d2cbfc/attachment.html>
[PATCH v7 1/8] video: add display_timing struct and helpers
On Thu, Nov 01, 2012 at 09:08:42PM +0100, Thierry Reding wrote:
> On Wed, Oct 31, 2012 at 10:28:01AM +0100, Steffen Trumtrar wrote:
> [...]
> > +void timings_release(struct display_timings *disp)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < disp->num_timings; i++)
> > + kfree(disp->timings[i]);
> > +}
> > +
> > +void display_timings_release(struct display_timings *disp)
> > +{
> > + timings_release(disp);
> > + kfree(disp->timings);
> > +}
>
> I'm not quite sure I understand how these are supposed to be used. The
> only use-case where a struct display_timings is dynamically allocated is
> for the OF helpers. In that case, wouldn't it be more useful to have a
> function that frees the complete structure, including the struct
> display_timings itself? Something like this, which has all of the above
> rolled into one:
>
> void display_timings_free(struct display_timings *disp)
> {
> if (disp->timings) {
> unsigned int i;
>
> for (i = 0; i < disp->num_timings; i++)
> kfree(disp->timings[i]);
> }
>
> kfree(disp->timings);
> kfree(disp);
> }
>
Well, you are right. They can be rolled into one function.
The extra function call is useless and as it seems confusing.
Regards,
Steffen
> ___
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
--
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 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #2 from Igor Murzov --- Created attachment 69524 --> https://bugs.freedesktop.org/attachment.cgi?id=69524&action=edit /var/log/Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/3ddbbd90/attachment.html>
[PATCH v7 2/8] of: add helper to parse display timings
On Thu, Nov 01, 2012 at 09:15:10PM +0100, Thierry Reding wrote: > On Wed, Oct 31, 2012 at 10:28:02AM +0100, Steffen Trumtrar wrote: > [...] > > diff --git a/Documentation/devicetree/bindings/video/display-timings.txt > > b/Documentation/devicetree/bindings/video/display-timings.txt > [...] > > @@ -0,0 +1,139 @@ > > +display-timings bindings > > +== > > + > > +display-timings-node > > + > > Maybe extend the underline to the length of the section and subsection > titles respectively? > > > +struct display_timing > > +=== > > Same here. > > > +config OF_DISPLAY_TIMINGS > > + def_bool y > > + depends on DISPLAY_TIMING > > Maybe this should be called OF_DISPLAY_TIMING to match DISPLAY_TIMING, > or rename DISPLAY_TIMING to DISPLAY_TIMINGS for the sake of consistency? > Yes, to all three above. > > +/** > > + * of_get_display_timing_list - parse all display_timing entries from a > > device_node > > + * @np: device_node with the subnodes > > + **/ > > +struct display_timings *of_get_display_timing_list(struct device_node *np) > > Perhaps this would better be named of_get_display_timings() to match the > return type? > Hm, I'm not really sure about that. I found it to error prone, to have a function of_get_display_timing and of_get_display_timings. That's why I chose of_get_display_timing_list. But you are correct, that it doesn't match the return value. Maybe I should just make the first function static and change the name as you suggested. > > + disp = kzalloc(sizeof(*disp), GFP_KERNEL); > > Shouldn't you be checking this for allocation failures? > > > + disp->timings = kzalloc(sizeof(struct display_timing > > *)*disp->num_timings, > > + GFP_KERNEL); > > Same here. > Yes, to both. Regards, Steffen -- 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- |
[PATCH v7 2/8] of: add helper to parse display timings
Hi!
On Fri, Nov 02, 2012 at 10:49:47PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> On Wed, Oct 31, 2012 at 2:58 PM, Steffen Trumtrar
> > +static int parse_property(struct device_node *np, char *name,
> > + struct timing_entry *result)
> > +{
> > + struct property *prop;
> > + int length;
> > + int cells;
> > + int ret;
> > +
> > + prop = of_find_property(np, name, &length);
> > + if (!prop) {
> > + pr_err("%s: could not find property %s\n", __func__, name);
> > + return -EINVAL;
> > + }
> > +
> > + cells = length / sizeof(u32);
> > + if (cells == 1) {
> > + ret = of_property_read_u32_array(np, name, &result->typ,
> > cells);
>
> As you are reading only one vaue, you can use of_property_read_u32 instead.
>
Yes, thats copypasta, no need for _array here.
> > + result->min = result->typ;
> > + result->max = result->typ;
> > + } else if (cells == 3) {
> > + ret = of_property_read_u32_array(np, name, &result->min,
> > cells);
>
> You are considering only min element, what about typ and max elements?
>
I start at the address of result->min and read three u32-values, therefore all
three (min,typ,max) are filled with values.
> > +
> > +/**
> > + * of_display_timings_exists - check if a display-timings node is provided
> > + * @np: device_node with the timing
> > + **/
> > +int of_display_timings_exists(struct device_node *np)
> > +{
> > + struct device_node *timings_np;
> > + struct device_node *default_np;
> > +
> > + if (!np)
> > + return -EINVAL;
> > +
> > + timings_np = of_parse_phandle(np, "display-timings", 0);
> > + if (!timings_np)
> > + return -EINVAL;
> > +
> > + return -EINVAL;
>
> Here it should return success instead of -EINVAL.
>
Yes.
> And one query.. are the binding properties names and "display-timings"
> node structure template finalized..?
>
I sure hope so. There actually is one error in the examples though.
The property clock is called clock-frequency. I included it correctly
at the top of display-timings.txt, but overlooked it in the examples.
Regards,
Steffen
--
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 56743] Invalid command stream (bad START_3D) on DIS gpu
https://bugs.freedesktop.org/show_bug.cgi?id=56743 --- Comment #3 from Alex Deucher --- The r6xx command stream is getting sent to the r7xx kernel driver instance. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/3baf9985/attachment.html>
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
Alex Deucher wrote: > On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: >> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 >> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off >> and then turn TV on and - >> >> xrandr --output DVI-0 --auto >> >> to bring up the the TV and get a clone of monitor. >> >> This still works with drm-core-next but not with drm-fixes (todays or from a >> few days ago). >> >> With df I now loose the monitor with signal out of range when doing above, >> the TV output is OK. To get the monitor back I need to turn off TV, then >> off/auto the monitor. >> >> xrandr --output DVI-0 --off >> xrandr --output DVI-1 --off >> xrandr --output DVI-1 --auto >> >> The output from xrandr while the monitor is showing signal out of range >> looks normal. >> >> If I boot with the TV on it works OK. > > Can you bisect? 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 Author: Alex Deucher Date: Fri Oct 5 10:22:02 2012 -0400 drm/radeon: allocate PPLLs from low to high The order shouldn't matter, but there have been problems reported on certain older asics. This behaves more like the original code before the PPLL allocation rework. Signed-off-by: Alex Deucher Cc: Markus Trippelsdorf
[Bug 49351] vga_switcheroo results in black screen (bisected)
https://bugzilla.kernel.org/show_bug.cgi?id=49351 Igor Murzov changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #19 from Igor Murzov 2012-11-04 21:05:05 --- Fixed by: commit 0b90365e7a32317b948583c4b5c2712d84610b08 Author: Alex Deucher Date: Tue Oct 23 17:57:54 2012 -0400 drm/radeon: fix ATPX regression in acpi rework Copy and paste typo in the apci rework. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=49351 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 24694] R6xx kms gloss corruption.
https://bugs.freedesktop.org/show_bug.cgi?id=24694 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andy Furniss --- Closing - ancient - R600 Classic long gone -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121104/a1943106/attachment.html>
