Re: 3.5-rc5: radeon acceleration regression on Transmeta system
On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos wrote: > In 2.6.32, radeon worked fine. > > In 3.4, radeon worked with a glitch - window titles were see-throug (not > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables > acceleration on this system at all. Full dmesg below. Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? if I had to guess something broke in the dma area elsewhere, but not sure. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
> Thanks for tracking down the source of this corruption. I don't have > any such hardware, so until someone can figure it out, I think we > should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450
https://bugzilla.kernel.org/show_bug.cgi?id=44121 --- Comment #13 from Jean Delvare 2012-07-05 07:30:03 --- Reproducibility information: * I cannot reproduce the GPU lockup on a Radeon HD 4350 card. * On the Radeon HD 6450, I can reproduce the GPU lockup with applications other than Firefox. I was able to do so with Claws Mail for example. The parent window has to be maximized for it to happen. Then, as soon as a title-less dialog box is opened (for example by pressing Ctrl+S for "Save As..."), the GPU lockup happens. -- 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
3.5-rc5: radeon acceleration regression on Transmeta system
In 2.6.32, radeon worked fine. In 3.4, radeon worked with a glitch - window titles were see-throug (not drawn). In 3.5-rc5, radeon driver seems to be more careful and disables acceleration on this system at all. Full dmesg below. Fujitsu Lifebook P series, 256M RAM, 239 usable. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos@raamat) (gcc version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009bfff] usable [0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0efd] usable [0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data [0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS [0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08 02/24/2005 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10 [0.00] initial memory mapped: [mem 0x-0x017f] [0.00] Base memory trampoline at [c0098000] 98000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x0efd] [0.00] [mem 0x-0x003f] page 4k [0.00] [mem 0x0040-0x0ebf] page 2M [0.00] [mem 0x0ec0-0x0efd] page 4k [0.00] kernel direct mapping tables up to 0xefd @ [mem 0x017fa000-0x017f] [0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ ) [0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3 0108 MSFT 0107) [0.00] ACPI: FACS 0efeffc0 00040 [0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD ACPIPST1 0001 PTL 0001) [0.00] 239MB LOWMEM available. [0.00] mapped low ram: 0 - 0efe [0.00] low ram: 0 - 0efe [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x0efd] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009bfff] [0.00] node 0: [mem 0x0010-0x0efd] [0.00] On node 0 totalpages: 61292 [0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map cee00200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3948 pages, LIFO batch:0 [0.00] Normal zone: 448 pages used for memmap [0.00] Normal zone: 56864 pages, LIFO batch:15 [0.00] ACPI: PM-Timer IO Port: 0xff08 [0.00] PM: Registered nosave memory: 0009c000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e8000 [0.00] PM: Registered nosave memory: 000e8000 - 0010 [0.00] e820: [mem 0x0f10-0xffef] available for PCI devices [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60812 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug radeon.modeset=1 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Initializing CPU#0 [0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k reserved, 984k data, 284k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfffe4000 - 0xf000 ( 108 kB) [0.00] vmalloc : 0xcf7e - 0xfffe2000 ( 776 MB) [0.00] lowmem : 0xc000 - 0xcefe ( 239 MB) [0.00] .init : 0xc1305000 - 0xc134c000 ( 284 kB) [0.00] .data : 0xc120de7e - 0xc13040c0 ( 984 kB) [0.00] .text : 0xc100 - 0xc120de7e (2103 kB) [0.00] Checking if this processor honours the WP bit even in supervisor mode...Ok. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] CPU 0 irqstacks, hard=ce806
Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > Thanks for tracking down the source of this corruption. I don't have > > any such hardware, so until someone can figure it out, I think we > > should apply this patch. > > In that case, I would have to massage the patch a bit first; it > creates a problem with suspend/resume. Might be something with > nva3_pm.c, who knows. I am really stabbing in the dark here. :-) It seems the suspend/resume problem is unrelated (bad systemd update), so I am fine with applying this as is. Obviously not the best solution, and if I have time I will continue to look for problems in the nva3 copy code, but for now, Signed-off-by: Henrik Rydberg Thanks, Henrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check framebuffer stride more thoroughly
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make sure the the framebuffer stride is smaller than the maximum
> accepted by any plane.
>
> Also when using a tiled memory make sure the object stride matches
> the framebuffer stride.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7cf639c..8fea475 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6643,6 +6643,17 @@ static const struct drm_framebuffer_funcs
> intel_fb_funcs = {
> .create_handle = intel_user_framebuffer_create_handle,
> };
>
> +static unsigned int intel_max_fb_stride(const struct drm_device *dev)
> +{
> + /* FIXME: BSpec for pre-Gen5 is a bit unclear on stride limits */
> + if (INTEL_INFO(dev)->gen <= 3)
> + return 8192;
8k pitch limit is gen2, gen3 can have a 4kx4k framebuffer @32bit.
-Daniel
> + else if (INTEL_INFO(dev)->gen <= 4)
> + return 16384;
Iirc gen4 can also do 32k, see the pixel-based limits in
intel_modset_init.
> + else
> + return 32768;
> +}
> +
> int intel_framebuffer_init(struct drm_device *dev,
> struct intel_framebuffer *intel_fb,
> struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -6656,6 +6667,13 @@ int intel_framebuffer_init(struct drm_device *dev,
> if (mode_cmd->pitches[0] & 63)
> return -EINVAL;
>
> + if (mode_cmd->pitches[0] > intel_max_fb_stride(dev))
> + return -EINVAL;
> +
> + if (obj->tiling_mode != I915_TILING_NONE &&
> + mode_cmd->pitches[0] != obj->stride)
> + return -EINVAL;
> +
> /* Reject formats not supported by any plane early. */
> switch (mode_cmd->pixel_format) {
> case DRM_FORMAT_C8:
> --
> 1.7.3.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Zero initialize mode_cmd
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Zero initialize the mode_cmd structure when creating the kernel > framebuffer. Avoids having uninitialized data in offsets[0] for > instance. > > Signed-off-by: Ville Syrjälä Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote: > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > > > On Thu, 24 May 2012 21:08:58 +0300 > > > ville.syrj...@linux.intel.com wrote: > > > > > > > From: Ville Syrjälä > > > > > > > > Take fb->offset[0] into account when calculating the linear and tile x/y > > > > offsets. > > > > > > > > For non-tiled surfaces fb->offset[0] is simply added to the linear > > > > byte offset. > > > > > > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the > > > > linearized view of the surface. So we end up converting fb->offsets[0] > > > > into additional x and y offsets. > > > > > > Do you have code using a non-zero offsets[0]? At least for current > > > code that would indicate some kind of problem... though hopefully we'll > > > be adding planar support back again sometime soon. > > > > I did have some test app that used offsets[] at some point, but tbh I > > didn't excercise these changes with it. > > > > I have a sort of semi working skeleton of a test app which I just modify > > for various use cases as need arises. I really should try to clean it up > > a bit and generalize it so that it wouldn't need constant code changes > > to test different scenarios. > > Yeah, I want these little test apps as testcases in i-g-t. Ping about these testcases, ported to i-g-t ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Reject page flips with changed format/offset/pitch
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > MI display flips can't handle some changes in the framebuffer > format or layout. Return an error in such cases. > > Signed-off-by: Ville Syrjälä Queued for -next, thanks for the patch. I've punted on the others, hoping for a few i-g-t tests (and maybe someone else that could review them). Safe for the uninitialized stack var patch and this one, because we need this check to fix up gen4+ tileoffset limitations. Yours, Daniel > --- > drivers/gpu/drm/i915/intel_display.c | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f4338cb..72ac2f9 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6217,6 +6217,19 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, > unsigned long flags; > int ret; > > + /* Can't change pixel format via MI display flips. */ > + if (fb->pixel_format != crtc->fb->pixel_format) > + return -EINVAL; > + > + /* > + * TILEOFF/LINOFF registers can't be changed via MI display flips. > + * Note that pitch changes could also affect these register. > + */ > + if (INTEL_INFO(dev)->gen > 3 && > + (fb->offsets[0] != crtc->fb->offsets[0] || > + fb->pitches[0] != crtc->fb->pitches[0])) > + return -EINVAL; > + > work = kzalloc(sizeof *work, GFP_KERNEL); > if (work == NULL) > return -ENOMEM; > -- > 1.7.3.4 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Check framebuffer stride more thoroughly
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make sure the the framebuffer stride is smaller than the maximum
> > accepted by any plane.
> >
> > Also when using a tiled memory make sure the object stride matches
> > the framebuffer stride.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 18 ++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7cf639c..8fea475 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6643,6 +6643,17 @@ static const struct drm_framebuffer_funcs
> > intel_fb_funcs = {
> > .create_handle = intel_user_framebuffer_create_handle,
> > };
> >
> > +static unsigned int intel_max_fb_stride(const struct drm_device *dev)
> > +{
> > + /* FIXME: BSpec for pre-Gen5 is a bit unclear on stride limits */
> > + if (INTEL_INFO(dev)->gen <= 3)
> > + return 8192;
>
> 8k pitch limit is gen2, gen3 can have a 4kx4k framebuffer @32bit.
OK. I was just looking at BSpec but there were gaps in the docs. For
example, for gen3, only the limit for the OVL (8k) and tiled DSP (8k)
were mentioned. Nothing about non-tiled DSP. OTOH I don't know if even
the documented limits were really correct.
> -Daniel
>
> > + else if (INTEL_INFO(dev)->gen <= 4)
> > + return 16384;
>
> Iirc gen4 can also do 32k, see the pixel-based limits in
> intel_modset_init.
OK, BSpec was equally unclear here. Only tiled limit (16k) was
mentioned.
Seeing as the limits are a bit unclear, I don't know if I should even
try to add these checks. Unfortunately I don't have any pre-gen6
hardware, so I can't coax the real limits out of the hardware
empirically.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote: > > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrjälä wrote: > > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > > > > On Thu, 24 May 2012 21:08:58 +0300 > > > > ville.syrj...@linux.intel.com wrote: > > > > > > > > > From: Ville Syrjälä > > > > > > > > > > Take fb->offset[0] into account when calculating the linear and tile > > > > > x/y > > > > > offsets. > > > > > > > > > > For non-tiled surfaces fb->offset[0] is simply added to the linear > > > > > byte offset. > > > > > > > > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the > > > > > linearized view of the surface. So we end up converting fb->offsets[0] > > > > > into additional x and y offsets. > > > > > > > > Do you have code using a non-zero offsets[0]? At least for current > > > > code that would indicate some kind of problem... though hopefully we'll > > > > be adding planar support back again sometime soon. > > > > > > I did have some test app that used offsets[] at some point, but tbh I > > > didn't excercise these changes with it. > > > > > > I have a sort of semi working skeleton of a test app which I just modify > > > for various use cases as need arises. I really should try to clean it up > > > a bit and generalize it so that it wouldn't need constant code changes > > > to test different scenarios. > > > > Yeah, I want these little test apps as testcases in i-g-t. > > Ping about these testcases, ported to i-g-t ... Sorry, haven't had time to look at those. I'm going on vacation after tomorrow but I'll add a task to the list so I won't forget about this. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Tegra DRM device tree bindings
Here's a new proposal that should address all issues collected during
the discussion of the previous one:
From tegra20.dtsi:
host1x {
compatible = "nvidia,tegra20-host1x", "simple-bus";
reg = <0x5000 0x00024000>;
interrupts = <0 65 0x04 /* mpcore syncpt */
0 67 0x04>; /* mpcore general */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x5400 0x5400 0x0400>;
/* video-encoding/decoding */
mpe {
reg = <0x5404 0x0004>;
interrupts = <0 68 0x04>;
};
/* video input */
vi {
reg = <0x5408 0x0004>;
interrupts = <0 69 0x04>;
};
/* EPP */
epp {
reg = <0x540c 0x0004>;
interrupts = <0 70 0x04>;
};
/* ISP */
isp {
reg = <0x5410 0x0004>;
interrupts = <0 71 0x04>;
};
/* 2D engine */
gr2d {
reg = <0x5414 0x0004>;
interrupts = <0 72 0x04>;
};
/* 3D engine */
gr3d {
reg = <0x5418 0x0004>;
};
/* display controllers */
dc@5420 {
compatible = "nvidia,tegra20-dc";
reg = <0x5420 0x0004>;
interrupts = <0 73 0x04>;
rgb {
status = "disabled";
};
};
dc@5424 {
compatible = "nvidia,tegra20-dc";
reg = <0x5424 0x0004>;
interrupts = <0 74 0x04>;
rgb {
status = "disabled";
};
};
/* outputs */
hdmi {
compatible = "nvidia,tegra20-hdmi";
reg = <0x5428 0x0004>;
interrupts = <0 75 0x04>;
status = "disabled";
};
tvo {
compatible = "nvidia,tegra20-tvo";
reg = <0x542c 0x0004>;
interrupts = <0 76 0x04>;
status = "disabled";
};
dsi {
compatible = "nvidia,tegra20-dsi";
reg = <0x5430 0x0004>;
status = "disabled";
};
};
From tegra20-medcom.dts:
host1x {
dc@5420 {
rgb {
nvidia,edid = /incbin/("tegra20-medcom.edid");
status = "okay";
};
};
};
From tegra20-plutux.dts:
host1x {
hdmi {
vdd-supply = <&ldo7_reg>;
pll-supply = <&ldo8_reg>;
nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
nvidia,ddc-i2c-bus = <&ddc>;
status = "okay";
};
};
One problem I've come across when trying to get some rudimentary code
working with this is that there's no longer a device which the DRM
driver can bind to, because the top-level device (host1x) now has a
separate driver.
I've briefly discussed this with Dave Airlie on IRC and there are
basically two solutions:
a) Use a fake platform device, instantiated from the device tree or at
module initialization time, so that the drm_platform_init()
function can be used.
b) Implement a custom drm_bus and reimplement most of the
functionality provided by drm_platform_init().
Alternative a) is what Sascha has been doing for i.MX and is the most
straightforward. One variant of this would be to add another virtual
device node below host1x that groups gr2d, gr3d, both dcs and the three
output nodes. The down-side of this being that it doesn't describe the
hardware of course, and therefore really shouldn't go into the device
tree. Instantiating at module initalization time has the disadvantage
that the parent-child relationship is lost.
Using b) isn't optimal either because DRM requires at least a struct
device which can be associated with the drm_device. So the question is
which struct device that should be?
Thierry
pgp2yZUyYBbMq.pgp
Description: PGP signature
___
dri-devel mailing list
Re: Linux 3.2: After resume screen only turned on after switching terminals
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote: > Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher: >> On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote: >> > Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul Menzel: >> >> Am Dienstag, den 26.06.2012, 07:42 +0200 schrieb Michel Dänzer: >> >> > On Mon, 2012-06-25 at 21:14 +0200, Paul Menzel wrote: >> >> > > >> >> > > resuming from suspend to RAM the monitor was indicating by a blinking >> >> > > LED that it did not receive any signal. This is the first time this >> >> > > happened. Resuming from suspend to RAM had worked without problems >> >> > > before (and probably will work again the next tries). >> >> > > >> >> > > Logging in from SSH worked fine though. Switching terminal to tty1 >> >> > > nothing changed but going back to tty7, where X was supposed to run), >> >> > > and the monitor detected a signal and showed the screensaver. >> >> > > >> >> > > Switching to tty1 still does not work though, that means the monitor >> >> > > indicates that it gets no signal. >> >> > >> >> > What about tty2-6 or any others? >> >> >> >> It just happened again. tty2–6 also do not show anything. >> >> >> >> > What does fbset -i say when the problem occurs? >> >> >> >> I logged in over SSH not having switched the ttys yet. This is the >> >> result. >> >> >> >> $ fbset -i >> >> >> >> mode "1280x1024" >> >> geometry 1280 1024 1280 1024 32 >> >> timings 0 0 0 0 0 0 0 >> >> accel true >> >> rgba 8/16,8/8,8/0,0/0 >> >> endmode >> >> >> >> Frame buffer device information: >> >> Name: radeondrmfb >> >> Address : 0xd0142000 >> >> Size: 5242880 >> >> Type: PACKED PIXELS >> >> Visual : TRUECOLOR >> >> XPanStep: 1 >> >> YPanStep: 1 >> >> YWrapStep : 0 >> >> LineLength : 5120 >> >> Accelerator : No >> >> >> >> This does not differ though after having switched between ttys and >> >> getting a working X server again. The other ttys do not just show black. >> >> When switching from tty7 with the X server running to a console(?) tty >> >> then I shortly (half second) see some kind of test image, which contains >> >> four horizontal colored stripes red, green, blue and white(?). >> >> >> >> I could not find anything in the output of `dmesg`, but >> >> `/var/log/syslog` contains several of the following lines. >> >> >> >> Jun 29 19:44:57 debian-host acpid: client 8677[0:0] has >> >> disconnected >> >> Jun 29 19:45:08 debian-host acpid: client connected from 8677[0:0] >> >> Jun 29 19:45:08 debian-host acpid: 1 client rule loaded >> > >> > Does someone have an idea what the problem might be and how to fix it? >> >> Is this a regression? If so can you bisect? > > I do not think so. But the problem is I just got that board, have only > used it with Linux 3.2.x (from Debian Sid/unstable) and this issue is > not reproducible, that means, it happens in less then 5(?) percent of > the suspend and resume cycles. > > Any idea what these acpid messages could mean? Nope sorry. Alex > > > Thanks, > > Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] of: Add videomode helper
Hi Sascha,
Thanks for the patch.
On Wednesday 04 July 2012 09:56:35 Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the
> devicetree. The videomode can be either converted to a struct
> drm_display_mode or a struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v1:
> - use hyphens instead of underscores for property names
>
> .../devicetree/bindings/video/displaymode | 40
> drivers/of/Kconfig |5 +
> drivers/of/Makefile|1 +
> drivers/of/of_videomode.c | 108 +
> include/linux/of_videomode.h | 19
> 5 files changed, 173 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/displaymode
> create mode 100644 drivers/of/of_videomode.c
> create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Documentation/devicetree/bindings/video/displaymode new file mode 100644
> index 000..43cc17d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/displaymode
> @@ -0,0 +1,40 @@
> +videomode bindings
> +==
> +
> +Required properties:
> + - xres, yres: Display resolution
> + - left-margin, right-margin, hsync-len: Horizontal Display timing
> parameters + in pixels
> + upper-margin, lower-margin, vsync-len: Vertical display timing
> parameters in + lines
> + - clock: displayclock in Hz
> +
> +Optional properties:
> + - width-mm, height-mm: Display dimensions in mm
I've always had mixed feelings about the physical display dimension being part
of the display mode. Those are properties of the panel/display instead of the
mode. Storing them as part of the mode can be convenient, but we then run into
consistency issues (developers have to remember in which display mode
instances the values are available, and in which instances they're set to 0
for instance). If we want to clean this up, this patch would be a good
occasion.
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
> + - interlaced (bool): This is an interlaced mode
> + - doublescan (bool): This is a doublescan mode
> +
> +There are different ways of describing a display mode. The devicetree
> representation +corresponds to the one used by the Linux Framebuffer
> framework described here in +Documentation/fb/framebuffer.txt. This
> representation has been chosen because it's +the only format which does not
> allow for inconsistent parameters.Unlike the Framebuffer +framework the
> devicetree has the clock in Hz instead of ps.
> +
> +Example:
> +
> + display@0 {
> + /* 1920x1080p24 */
> + clock = <5200>;
> + xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-margin = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
> + };
> +
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 15486] amd_adac error
https://bugzilla.kernel.org/show_bug.cgi?id=15486 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Component|kvm |Video(DRI - non Intel) Version|unspecified |2.5 Resolution||OBSOLETE AssignedTo|virtualization_kvm@kernel-b |drivers_video-dri@kernel-bu |ugs.osdl.org|gs.osdl.org Product|Virtualization |Drivers -- 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 15486] amd_adac error
https://bugzilla.kernel.org/show_bug.cgi?id=15486 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2012-07-05 16:16:35 --- Is this still an issue with a newer kernel? -- 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
Re: [PATCH v2] of: Add videomode helper
On Thu, Jul 05, 2012 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> Thanks for the patch.
>
> > +++ b/Documentation/devicetree/bindings/video/displaymode
> > @@ -0,0 +1,40 @@
> > +videomode bindings
> > +==
> > +
> > +Required properties:
> > + - xres, yres: Display resolution
> > + - left-margin, right-margin, hsync-len: Horizontal Display timing
> > parameters + in pixels
> > + upper-margin, lower-margin, vsync-len: Vertical display timing
> > parameters in + lines
> > + - clock: displayclock in Hz
> > +
> > +Optional properties:
> > + - width-mm, height-mm: Display dimensions in mm
>
> I've always had mixed feelings about the physical display dimension being
> part
> of the display mode. Those are properties of the panel/display instead of the
> mode. Storing them as part of the mode can be convenient, but we then run
> into
> consistency issues (developers have to remember in which display mode
> instances the values are available, and in which instances they're set to 0
> for instance). If we want to clean this up, this patch would be a good
> occasion.
This sounds like a display node with one or more node subnodes, like:
display {
width_mm = <>;
height_mm = <>;
mode {
xres = <>;
yres = <>;
...
};
};
Is that what you mean or are you thinking of something else?
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
Re: [PATCH v2] of: Add videomode helper
On Thu, Jul 05, 2012 at 09:51:39AM -0500, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> > +
> > +There are different ways of describing a display mode. The devicetree
> > representation
> > +corresponds to the one used by the Linux Framebuffer framework described
> > here in
> > +Documentation/fb/framebuffer.txt. This representation has been chosen
> > because it's
> > +the only format which does not allow for inconsistent parameters.Unlike
> > the Framebuffer
> > +framework the devicetree has the clock in Hz instead of ps.
>
> This implies you are putting linux settings into DT rather than
> describing the h/w. I'm not saying the binding is wrong, but documenting
> it this way makes it seem so.
The major reason to use these values was that they do not allow for
inconsistent values (as opposed to for example with hsync_start which you
would have to check for hsync_start >= xres).
I could rephrase this if it looks too much like modelled-after-Linux
instead of modelled-after-hardware.
>
> One important piece missing (and IIRC linux doesn't really support) is
> defining the pixel format of the interface.
I could use this aswell. I think this can be specified as additional
properties later, right? I'm afraid this needs a lot of discussion so
we should delay this to the next round.
>
> > +Example:
> > +
> > + display@0 {
> > + /* 1920x1080p24 */
> > + clock = <5200>;
>
> Should this use the clock binding? You probably need both constraints
> and clock binding though.
Is the clock binding suitable for this? Here we are not interested where
the clock comes from, but instead which range is allowed.
>
> Often you don't know the frequency up front and/or have limited control
> of the frequency (i.e. integer dividers). Then you have to adjust the
> margins to get the desired refresh rate. To do that, you need to know
> the ranges of values a panel can support. Perhaps you just assume you
> can increase the right-margin and lower-margins as I think you will hit
> pixel clock frequency max before any limit on margins.
Most datasheets specify min,typ,max triplets. We could do this instead
of using single fixed values for the margins:
left_margin = <0 10 40>;
Right now we have nothing in the kernel that could handle this, but
getting the interface to the devicetree right seems indeed important.
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
Re: [PATCH v2] of: Add videomode helper
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v1:
> - use hyphens instead of underscores for property names
>
> .../devicetree/bindings/video/displaymode | 40
> drivers/of/Kconfig |5 +
> drivers/of/Makefile|1 +
> drivers/of/of_videomode.c | 108
>
> include/linux/of_videomode.h | 19
> 5 files changed, 173 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/displaymode
> create mode 100644 drivers/of/of_videomode.c
> create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Documentation/devicetree/bindings/video/displaymode
> new file mode 100644
> index 000..43cc17d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/displaymode
> @@ -0,0 +1,40 @@
> +videomode bindings
> +==
> +
> +Required properties:
> + - xres, yres: Display resolution
> + - left-margin, right-margin, hsync-len: Horizontal Display timing parameters
> + in pixels
> + upper-margin, lower-margin, vsync-len: Vertical display timing parameters
> in
> + lines
> + - clock: displayclock in Hz
> +
> +Optional properties:
> + - width-mm, height-mm: Display dimensions in mm
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
> + - interlaced (bool): This is an interlaced mode
> + - doublescan (bool): This is a doublescan mode
> +
> +There are different ways of describing a display mode. The devicetree
> representation
> +corresponds to the one used by the Linux Framebuffer framework described
> here in
> +Documentation/fb/framebuffer.txt. This representation has been chosen
> because it's
> +the only format which does not allow for inconsistent parameters.Unlike the
> Framebuffer
> +framework the devicetree has the clock in Hz instead of ps.
This implies you are putting linux settings into DT rather than
describing the h/w. I'm not saying the binding is wrong, but documenting
it this way makes it seem so.
One important piece missing (and IIRC linux doesn't really support) is
defining the pixel format of the interface.
> +Example:
> +
> + display@0 {
> + /* 1920x1080p24 */
> + clock = <5200>;
Should this use the clock binding? You probably need both constraints
and clock binding though.
Often you don't know the frequency up front and/or have limited control
of the frequency (i.e. integer dividers). Then you have to adjust the
margins to get the desired refresh rate. To do that, you need to know
the ranges of values a panel can support. Perhaps you just assume you
can increase the right-margin and lower-margins as I think you will hit
pixel clock frequency max before any limit on margins.
Rob
> + xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-margin = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
> + };
> +
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index dfba3e6..a3acaa3 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -83,4 +83,9 @@ config OF_MTD
> depends on MTD
> def_bool y
>
> +config OF_VIDEOMODE
> + def_bool y
> + help
> + helper to parse videomodes from the devicetree
> +
> endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index e027f44..80e6db3 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_MTD) += of_mtd.o
> +obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
> diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> new file mode 100644
> index 000..50d3bd2
> --- /dev/null
> +++ b/drivers/of/of_videomode.c
> @@ -0,0 +1,108 @@
> +/*
> + * OF helpers for parsing display modes
> + *
> + * Copyright (c) 2012 Sascha Hauer , Pengutronix
> + *
> + * This file is released under the GPLv2
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +int of_get_video_mode(struct device_node *np, struct drm_display_mode *dmode,
> + struct fb_videomode *fbmode)
> +{
> + int ret = 0;
> + u32 left_margin, xres, right_margin, hsync_len;
> + u32 upper_margin, yres, lower_margin, vsync_len;
> + u32 width_mm = 0, height_mm = 0;
> + u32 clock;
> + bool hah = false, vah = false, interlaced = false, do
Re: 3.5-rc5: radeon acceleration regression on Transmeta system
> > In 3.4, radeon worked with a glitch - window titles were see-throug (not > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables > > acceleration on this system at all. Full dmesg below. > > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? That was a good question. I did some more tries, and it was not repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, no borders except when maximized, otherwise worked. Total 3 failures and 6 successes in intializing the card so far. > if I had to guess something broke in the dma area elsewhere, but not sure. Initial windows border problem seems to have been introduced between 2.6.37 and 2.6.38, bisect is slow. "Good" dmesg: [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos@raamat) (gcc version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009bfff] usable [0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0efd] usable [0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data [0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS [0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08 02/24/2005 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10 [0.00] initial memory mapped: [mem 0x-0x017f] [0.00] Base memory trampoline at [c0098000] 98000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x0efd] [0.00] [mem 0x-0x003f] page 4k [0.00] [mem 0x0040-0x0ebf] page 2M [0.00] [mem 0x0ec0-0x0efd] page 4k [0.00] kernel direct mapping tables up to 0xefd @ [mem 0x017fa000-0x017f] [0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ ) [0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3 0108 MSFT 0107) [0.00] ACPI: FACS 0efeffc0 00040 [0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD ACPIPST1 0001 PTL 0001) [0.00] 239MB LOWMEM available. [0.00] mapped low ram: 0 - 0efe [0.00] low ram: 0 - 0efe [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x0efd] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009bfff] [0.00] node 0: [mem 0x0010-0x0efd] [0.00] On node 0 totalpages: 61292 [0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map cee00200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3948 pages, LIFO batch:0 [0.00] Normal zone: 448 pages used for memmap [0.00] Normal zone: 56864 pages, LIFO batch:15 [0.00] ACPI: PM-Timer IO Port: 0xff08 [0.00] PM: Registered nosave memory: 0009c000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e8000 [0.00] PM: Registered nosave memory: 000e8000 - 0010 [0.00] e820: [mem 0x0f10-0xffef] available for PCI devices [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60812 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug radeon.modeset=1 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Initializing CPU#0 [0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k reserved, 984k data, 284k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfffe4000 - 0xf000 ( 108 kB) [0.00] vmalloc : 0xcf7e -
RE: Tegra DRM device tree bindings
> From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra-
> ow...@vger.kernel.org] On Behalf Of Thierry Reding
> Sent: Thursday, July 05, 2012 8:15 PM
> To: linux-te...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org; dri-devel@lists.freedesktop.org
> Subject: Re: Tegra DRM device tree bindings
>
> * PGP Signed by an unknown key
>
> Here's a new proposal that should address all issues collected during the
> discussion of the previous one:
>
> From tegra20.dtsi:
>
> host1x {
> compatible = "nvidia,tegra20-host1x", "simple-bus";
> reg = <0x5000 0x00024000>;
> interrupts = <0 65 0x04 /* mpcore syncpt */
> 0 67 0x04>; /* mpcore general */
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> ranges = <0x5400 0x5400 0x0400>;
>
> /* video-encoding/decoding */
> mpe {
> reg = <0x5404 0x0004>;
> interrupts = <0 68 0x04>;
> };
>
> /* video input */
> vi {
> reg = <0x5408 0x0004>;
> interrupts = <0 69 0x04>;
> };
>
> /* EPP */
> epp {
> reg = <0x540c 0x0004>;
> interrupts = <0 70 0x04>;
> };
>
> /* ISP */
> isp {
> reg = <0x5410 0x0004>;
> interrupts = <0 71 0x04>;
> };
>
> /* 2D engine */
> gr2d {
> reg = <0x5414 0x0004>;
> interrupts = <0 72 0x04>;
> };
>
> /* 3D engine */
> gr3d {
> reg = <0x5418 0x0004>;
> };
>
> /* display controllers */
> dc@5420 {
> compatible = "nvidia,tegra20-dc";
> reg = <0x5420 0x0004>;
> interrupts = <0 73 0x04>;
>
> rgb {
> status = "disabled";
> };
> };
>
> dc@5424 {
> compatible = "nvidia,tegra20-dc";
> reg = <0x5424 0x0004>;
> interrupts = <0 74 0x04>;
>
> rgb {
> status = "disabled";
> };
> };
>
> /* outputs */
> hdmi {
> compatible = "nvidia,tegra20-hdmi";
> reg = <0x5428 0x0004>;
> interrupts = <0 75 0x04>;
> status = "disabled";
> };
>
> tvo {
> compatible = "nvidia,tegra20-tvo";
> reg = <0x542c 0x0004>;
> interrupts = <0 76 0x04>;
> status = "disabled";
> };
>
> dsi {
> compatible = "nvidia,tegra20-dsi";
> reg = <0x5430 0x0004>;
> status = "disabled";
> };
> };
>
> From tegra20-medcom.dts:
>
> host1x {
> dc@5420 {
> rgb {
> nvidia,edid = /incbin/("tegra20-medcom.edid");
> status = "okay";
> };
> };
> };
>
> From tegra20-plutux.dts:
>
> host1x {
> hdmi {
> vdd-supply = <&ldo7_reg>;
> pll-supply = <&ldo8_reg>;
>
> nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
> nvidia,ddc-i2c-bus = <&ddc>;
>
> status = "okay";
> };
> };
>
> One problem I've come across when trying to get some rudimentary code
> working with this is that there's no longer a device which the DRM driver can
> bind
> to, because the top-level device (host1x) now has a separate driver.
>
> I've briefly discussed this with Dave Airlie on IRC and there are basically
> two
> solutions:
>
> a) Use a fake platform device, instantiated from the device tree or at
> module initialization time, so that the drm_platform_init()
> function can be used.
If we change the dts to this version, that means we should register all
drivers(dc/rgb/dsi...) during host1x driver initialization.
In that case, I think we can register drm driver as well.
It's not a good idea to add drm into dts cause just as you said, it's not a
real device at all.
> b) Implement a custom drm_bus and reimplement most of the
> functionality provided by drm_platform_init().
>
> Alternative a) is what Sascha has been
Re: [bisected] nouveau: "Failed to idle channel x" after resume
On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> after resuming from suspend nouveau starts writing Failed to idle
> channel x (where x is 2 or 3) to the log and X appears to stop and
> then restart only to stop again. Starting Firefox after resuming
> triggers the bugs every time, and bisecting leads to 03bd6efa
> ("drm/nv50/fifo: use hardware channel kickoff functionality").
Hi Ben,
I'm still seeing this bug with the latest from Linus
(v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
lspci output:
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
8400M GS] (rev a1)
Sorry I haven't followed up on this earlier,
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
Hi Ben, Dave, Since 3.5-rc0, I have been experiencing occasional screen corruption on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver version is xf86-video-nouvea-1.0.1-1 (arch). I do not know what the root problem is, but I have been able to isolate the symptoms to the usage of nva3_copy.c. The patch below is the least intrusive way I could find which kills the symptoms. Hopefully this will sched some light on the true problem, such that a fix can be found for 3.5. Thanks, Henrik The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. --- drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 19706f0..b466937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; }
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 08:31:13AM +0200, Henrik Rydberg wrote: > Hi Ben, Dave, Hey Henrik, > > Since 3.5-rc0, I have been experiencing occasional screen corruption > on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver > version is xf86-video-nouvea-1.0.1-1 (arch). > > I do not know what the root problem is, but I have been able to > isolate the symptoms to the usage of nva3_copy.c. The patch below is > the least intrusive way I could find which kills the symptoms. > > Hopefully this will sched some light on the true problem, such that a > fix can be found for 3.5. Thanks for tracking down the source of this corruption. I don't have any such hardware, so until someone can figure it out, I think we should apply this patch. Cheers, Ben. > > Thanks, > Henrik > > The nva3 copy engine exhibits random memory corruption in at least one > case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch > omits creating the engine for the specific chipset, falling back to > M2MF, which kills the symptoms. > --- Signed-off-by: Ben Skeggs > drivers/gpu/drm/nouveau/nouveau_state.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c > b/drivers/gpu/drm/nouveau/nouveau_state.c > index 19706f0..b466937 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_state.c > +++ b/drivers/gpu/drm/nouveau/nouveau_state.c > @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) > case 0xa3: > case 0xa5: > case 0xa8: > - case 0xaf: > nva3_copy_create(dev); > break; > } > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.5-rc5: radeon acceleration regression on Transmeta system
On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos wrote: > In 2.6.32, radeon worked fine. > > In 3.4, radeon worked with a glitch - window titles were see-throug (not > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables > acceleration on this system at all. Full dmesg below. Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? if I had to guess something broke in the dma area elsewhere, but not sure. Dave.
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
> Thanks for tracking down the source of this corruption. I don't have > any such hardware, so until someone can figure it out, I think we > should apply this patch. In that case, I would have to massage the patch a bit first; it creates a problem with suspend/resume. Might be something with nva3_pm.c, who knows. I am really stabbing in the dark here. :-) Thanks, Henrik
[Bug 44121] Reproducible GPU lockup CP stall on Radeon HD 6450
https://bugzilla.kernel.org/show_bug.cgi?id=44121 --- Comment #13 from Jean Delvare 2012-07-05 07:30:03 --- Reproducibility information: * I cannot reproduce the GPU lockup on a Radeon HD 4350 card. * On the Radeon HD 6450, I can reproduce the GPU lockup with applications other than Firefox. I was able to do so with Claws Mail for example. The parent window has to be maximized for it to happen. Then, as soon as a title-less dialog box is opened (for example by pressing Ctrl+S for "Save As..."), the GPU lockup happens. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
3.5-rc5: radeon acceleration regression on Transmeta system
In 2.6.32, radeon worked fine. In 3.4, radeon worked with a glitch - window titles were see-throug (not drawn). In 3.5-rc5, radeon driver seems to be more careful and disables acceleration on this system at all. Full dmesg below. Fujitsu Lifebook P series, 256M RAM, 239 usable. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos at raamat) (gcc version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009bfff] usable [0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0efd] usable [0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data [0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS [0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08 02/24/2005 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10 [0.00] initial memory mapped: [mem 0x-0x017f] [0.00] Base memory trampoline at [c0098000] 98000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x0efd] [0.00] [mem 0x-0x003f] page 4k [0.00] [mem 0x0040-0x0ebf] page 2M [0.00] [mem 0x0ec0-0x0efd] page 4k [0.00] kernel direct mapping tables up to 0xefd @ [mem 0x017fa000-0x017f] [0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ ) [0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3 0108 MSFT 0107) [0.00] ACPI: FACS 0efeffc0 00040 [0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD ACPIPST1 0001 PTL 0001) [0.00] 239MB LOWMEM available. [0.00] mapped low ram: 0 - 0efe [0.00] low ram: 0 - 0efe [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x0efd] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009bfff] [0.00] node 0: [mem 0x0010-0x0efd] [0.00] On node 0 totalpages: 61292 [0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map cee00200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3948 pages, LIFO batch:0 [0.00] Normal zone: 448 pages used for memmap [0.00] Normal zone: 56864 pages, LIFO batch:15 [0.00] ACPI: PM-Timer IO Port: 0xff08 [0.00] PM: Registered nosave memory: 0009c000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e8000 [0.00] PM: Registered nosave memory: 000e8000 - 0010 [0.00] e820: [mem 0x0f10-0xffef] available for PCI devices [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60812 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug radeon.modeset=1 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Initializing CPU#0 [0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k reserved, 984k data, 284k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfffe4000 - 0xf000 ( 108 kB) [0.00] vmalloc : 0xcf7e - 0xfffe2000 ( 776 MB) [0.00] lowmem : 0xc000 - 0xcefe ( 239 MB) [0.00] .init : 0xc1305000 - 0xc134c000 ( 284 kB) [0.00] .data : 0xc120de7e - 0xc13040c0 ( 984 kB) [0.00] .text : 0xc100 - 0xc120de7e (2103 kB) [0.00] Checking if this processor honours the WP bit even in supervisor mode...Ok. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] CPU 0 irqstacks, hard=ce
[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: > > Thanks for tracking down the source of this corruption. I don't have > > any such hardware, so until someone can figure it out, I think we > > should apply this patch. > > In that case, I would have to massage the patch a bit first; it > creates a problem with suspend/resume. Might be something with > nva3_pm.c, who knows. I am really stabbing in the dark here. :-) It seems the suspend/resume problem is unrelated (bad systemd update), so I am fine with applying this as is. Obviously not the best solution, and if I have time I will continue to look for problems in the nva3 copy code, but for now, Signed-off-by: Henrik Rydberg Thanks, Henrik
[Intel-gfx] [PATCH 2/6] drm/i915: Check framebuffer stride more thoroughly
On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Make sure the the framebuffer stride is smaller than the maximum
> accepted by any plane.
>
> Also when using a tiled memory make sure the object stride matches
> the framebuffer stride.
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7cf639c..8fea475 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6643,6 +6643,17 @@ static const struct drm_framebuffer_funcs
> intel_fb_funcs = {
> .create_handle = intel_user_framebuffer_create_handle,
> };
>
> +static unsigned int intel_max_fb_stride(const struct drm_device *dev)
> +{
> + /* FIXME: BSpec for pre-Gen5 is a bit unclear on stride limits */
> + if (INTEL_INFO(dev)->gen <= 3)
> + return 8192;
8k pitch limit is gen2, gen3 can have a 4kx4k framebuffer @32bit.
-Daniel
> + else if (INTEL_INFO(dev)->gen <= 4)
> + return 16384;
Iirc gen4 can also do 32k, see the pixel-based limits in
intel_modset_init.
> + else
> + return 32768;
> +}
> +
> int intel_framebuffer_init(struct drm_device *dev,
> struct intel_framebuffer *intel_fb,
> struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -6656,6 +6667,13 @@ int intel_framebuffer_init(struct drm_device *dev,
> if (mode_cmd->pitches[0] & 63)
> return -EINVAL;
>
> + if (mode_cmd->pitches[0] > intel_max_fb_stride(dev))
> + return -EINVAL;
> +
> + if (obj->tiling_mode != I915_TILING_NONE &&
> + mode_cmd->pitches[0] != obj->stride)
> + return -EINVAL;
> +
> /* Reject formats not supported by any plane early. */
> switch (mode_cmd->pixel_format) {
> case DRM_FORMAT_C8:
> --
> 1.7.3.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[Intel-gfx] [PATCH 3/6] drm/i915: Zero initialize mode_cmd
On Thu, May 24, 2012 at 09:08:56PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Zero initialize the mode_cmd structure when creating the kernel > framebuffer. Avoids having uninitialized data in offsets[0] for > instance. > > Signed-off-by: Ville Syrj?l? Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]
On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote: > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > > > On Thu, 24 May 2012 21:08:58 +0300 > > > ville.syrjala at linux.intel.com wrote: > > > > > > > From: Ville Syrj?l? > > > > > > > > Take fb->offset[0] into account when calculating the linear and tile x/y > > > > offsets. > > > > > > > > For non-tiled surfaces fb->offset[0] is simply added to the linear > > > > byte offset. > > > > > > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the > > > > linearized view of the surface. So we end up converting fb->offsets[0] > > > > into additional x and y offsets. > > > > > > Do you have code using a non-zero offsets[0]? At least for current > > > code that would indicate some kind of problem... though hopefully we'll > > > be adding planar support back again sometime soon. > > > > I did have some test app that used offsets[] at some point, but tbh I > > didn't excercise these changes with it. > > > > I have a sort of semi working skeleton of a test app which I just modify > > for various use cases as need arises. I really should try to clean it up > > a bit and generalize it so that it wouldn't need constant code changes > > to test different scenarios. > > Yeah, I want these little test apps as testcases in i-g-t. Ping about these testcases, ported to i-g-t ... -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Intel-gfx] [PATCH 6/6] drm/i915: Reject page flips with changed format/offset/pitch
On Thu, May 24, 2012 at 09:08:59PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > MI display flips can't handle some changes in the framebuffer > format or layout. Return an error in such cases. > > Signed-off-by: Ville Syrj?l? Queued for -next, thanks for the patch. I've punted on the others, hoping for a few i-g-t tests (and maybe someone else that could review them). Safe for the uninitialized stack var patch and this one, because we need this check to fix up gen4+ tileoffset limitations. Yours, Daniel > --- > drivers/gpu/drm/i915/intel_display.c | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index f4338cb..72ac2f9 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -6217,6 +6217,19 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, > unsigned long flags; > int ret; > > + /* Can't change pixel format via MI display flips. */ > + if (fb->pixel_format != crtc->fb->pixel_format) > + return -EINVAL; > + > + /* > + * TILEOFF/LINOFF registers can't be changed via MI display flips. > + * Note that pitch changes could also affect these register. > + */ > + if (INTEL_INFO(dev)->gen > 3 && > + (fb->offsets[0] != crtc->fb->offsets[0] || > + fb->pitches[0] != crtc->fb->pitches[0])) > + return -EINVAL; > + > work = kzalloc(sizeof *work, GFP_KERNEL); > if (work == NULL) > return -ENOMEM; > -- > 1.7.3.4 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Intel-gfx] [PATCH 2/6] drm/i915: Check framebuffer stride more thoroughly
On Thu, Jul 05, 2012 at 01:27:47PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 09:08:55PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Make sure the the framebuffer stride is smaller than the maximum
> > accepted by any plane.
> >
> > Also when using a tiled memory make sure the object stride matches
> > the framebuffer stride.
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 18 ++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7cf639c..8fea475 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6643,6 +6643,17 @@ static const struct drm_framebuffer_funcs
> > intel_fb_funcs = {
> > .create_handle = intel_user_framebuffer_create_handle,
> > };
> >
> > +static unsigned int intel_max_fb_stride(const struct drm_device *dev)
> > +{
> > + /* FIXME: BSpec for pre-Gen5 is a bit unclear on stride limits */
> > + if (INTEL_INFO(dev)->gen <= 3)
> > + return 8192;
>
> 8k pitch limit is gen2, gen3 can have a 4kx4k framebuffer @32bit.
OK. I was just looking at BSpec but there were gaps in the docs. For
example, for gen3, only the limit for the OVL (8k) and tiled DSP (8k)
were mentioned. Nothing about non-tiled DSP. OTOH I don't know if even
the documented limits were really correct.
> -Daniel
>
> > + else if (INTEL_INFO(dev)->gen <= 4)
> > + return 16384;
>
> Iirc gen4 can also do 32k, see the pixel-based limits in
> intel_modset_init.
OK, BSpec was equally unclear here. Only tiled limit (16k) was
mentioned.
Seeing as the limits are a bit unclear, I don't know if I should even
try to add these checks. Unfortunately I don't have any pre-gen6
hardware, so I can't coax the real limits out of the hardware
empirically.
--
Ville Syrj?l?
Intel OTC
[Intel-gfx] [PATCH 5/6] drm/i915: Handle framebuffer offsets[]
On Thu, Jul 05, 2012 at 01:29:36PM +0200, Daniel Vetter wrote: > On Thu, May 24, 2012 at 09:01:24PM +0200, Daniel Vetter wrote: > > On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote: > > > On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote: > > > > On Thu, 24 May 2012 21:08:58 +0300 > > > > ville.syrjala at linux.intel.com wrote: > > > > > > > > > From: Ville Syrj?l? > > > > > > > > > > Take fb->offset[0] into account when calculating the linear and tile > > > > > x/y > > > > > offsets. > > > > > > > > > > For non-tiled surfaces fb->offset[0] is simply added to the linear > > > > > byte offset. > > > > > > > > > > For tiled surfaces treat fb->offsets[0] as a byte offset into the > > > > > linearized view of the surface. So we end up converting fb->offsets[0] > > > > > into additional x and y offsets. > > > > > > > > Do you have code using a non-zero offsets[0]? At least for current > > > > code that would indicate some kind of problem... though hopefully we'll > > > > be adding planar support back again sometime soon. > > > > > > I did have some test app that used offsets[] at some point, but tbh I > > > didn't excercise these changes with it. > > > > > > I have a sort of semi working skeleton of a test app which I just modify > > > for various use cases as need arises. I really should try to clean it up > > > a bit and generalize it so that it wouldn't need constant code changes > > > to test different scenarios. > > > > Yeah, I want these little test apps as testcases in i-g-t. > > Ping about these testcases, ported to i-g-t ... Sorry, haven't had time to look at those. I'm going on vacation after tomorrow but I'll add a task to the list so I won't forget about this. -- Ville Syrj?l? Intel OTC
Tegra DRM device tree bindings
Here's a new proposal that should address all issues collected during the discussion of the previous one:
Linux 3.2: After resume screen only turned on after switching terminals
On Wed, Jul 4, 2012 at 10:11 AM, Paul Menzel wrote: > Am Mittwoch, den 04.07.2012, 09:55 -0400 schrieb Alex Deucher: >> On Wed, Jul 4, 2012 at 9:41 AM, Paul Menzel wrote: >> > Am Samstag, den 30.06.2012, 21:00 +0200 schrieb Paul Menzel: >> >> Am Dienstag, den 26.06.2012, 07:42 +0200 schrieb Michel D?nzer: >> >> > On Mon, 2012-06-25 at 21:14 +0200, Paul Menzel wrote: >> >> > > >> >> > > resuming from suspend to RAM the monitor was indicating by a blinking >> >> > > LED that it did not receive any signal. This is the first time this >> >> > > happened. Resuming from suspend to RAM had worked without problems >> >> > > before (and probably will work again the next tries). >> >> > > >> >> > > Logging in from SSH worked fine though. Switching terminal to tty1 >> >> > > nothing changed but going back to tty7, where X was supposed to run), >> >> > > and the monitor detected a signal and showed the screensaver. >> >> > > >> >> > > Switching to tty1 still does not work though, that means the monitor >> >> > > indicates that it gets no signal. >> >> > >> >> > What about tty2-6 or any others? >> >> >> >> It just happened again. tty2?6 also do not show anything. >> >> >> >> > What does fbset -i say when the problem occurs? >> >> >> >> I logged in over SSH not having switched the ttys yet. This is the >> >> result. >> >> >> >> $ fbset -i >> >> >> >> mode "1280x1024" >> >> geometry 1280 1024 1280 1024 32 >> >> timings 0 0 0 0 0 0 0 >> >> accel true >> >> rgba 8/16,8/8,8/0,0/0 >> >> endmode >> >> >> >> Frame buffer device information: >> >> Name: radeondrmfb >> >> Address : 0xd0142000 >> >> Size: 5242880 >> >> Type: PACKED PIXELS >> >> Visual : TRUECOLOR >> >> XPanStep: 1 >> >> YPanStep: 1 >> >> YWrapStep : 0 >> >> LineLength : 5120 >> >> Accelerator : No >> >> >> >> This does not differ though after having switched between ttys and >> >> getting a working X server again. The other ttys do not just show black. >> >> When switching from tty7 with the X server running to a console(?) tty >> >> then I shortly (half second) see some kind of test image, which contains >> >> four horizontal colored stripes red, green, blue and white(?). >> >> >> >> I could not find anything in the output of `dmesg`, but >> >> `/var/log/syslog` contains several of the following lines. >> >> >> >> Jun 29 19:44:57 debian-host acpid: client 8677[0:0] has >> >> disconnected >> >> Jun 29 19:45:08 debian-host acpid: client connected from 8677[0:0] >> >> Jun 29 19:45:08 debian-host acpid: 1 client rule loaded >> > >> > Does someone have an idea what the problem might be and how to fix it? >> >> Is this a regression? If so can you bisect? > > I do not think so. But the problem is I just got that board, have only > used it with Linux 3.2.x (from Debian Sid/unstable) and this issue is > not reproducible, that means, it happens in less then 5(?) percent of > the suspend and resume cycles. > > Any idea what these acpid messages could mean? Nope sorry. Alex > > > Thanks, > > Paul
[PATCH v2] of: Add videomode helper
Hi Sascha,
Thanks for the patch.
On Wednesday 04 July 2012 09:56:35 Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the
> devicetree. The videomode can be either converted to a struct
> drm_display_mode or a struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v1:
> - use hyphens instead of underscores for property names
>
> .../devicetree/bindings/video/displaymode | 40
> drivers/of/Kconfig |5 +
> drivers/of/Makefile|1 +
> drivers/of/of_videomode.c | 108 +
> include/linux/of_videomode.h | 19
> 5 files changed, 173 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/displaymode
> create mode 100644 drivers/of/of_videomode.c
> create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Documentation/devicetree/bindings/video/displaymode new file mode 100644
> index 000..43cc17d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/displaymode
> @@ -0,0 +1,40 @@
> +videomode bindings
> +==
> +
> +Required properties:
> + - xres, yres: Display resolution
> + - left-margin, right-margin, hsync-len: Horizontal Display timing
> parameters + in pixels
> + upper-margin, lower-margin, vsync-len: Vertical display timing
> parameters in + lines
> + - clock: displayclock in Hz
> +
> +Optional properties:
> + - width-mm, height-mm: Display dimensions in mm
I've always had mixed feelings about the physical display dimension being part
of the display mode. Those are properties of the panel/display instead of the
mode. Storing them as part of the mode can be convenient, but we then run into
consistency issues (developers have to remember in which display mode
instances the values are available, and in which instances they're set to 0
for instance). If we want to clean this up, this patch would be a good
occasion.
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
> + - interlaced (bool): This is an interlaced mode
> + - doublescan (bool): This is a doublescan mode
> +
> +There are different ways of describing a display mode. The devicetree
> representation +corresponds to the one used by the Linux Framebuffer
> framework described here in +Documentation/fb/framebuffer.txt. This
> representation has been chosen because it's +the only format which does not
> allow for inconsistent parameters.Unlike the Framebuffer +framework the
> devicetree has the clock in Hz instead of ps.
> +
> +Example:
> +
> + display at 0 {
> + /* 1920x1080p24 */
> + clock = <5200>;
> + xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-margin = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
> + };
> +
--
Regards,
Laurent Pinchart
[Bug 15486] amd_adac error
https://bugzilla.kernel.org/show_bug.cgi?id=15486 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Component|kvm |Video(DRI - non Intel) Version|unspecified |2.5 Resolution||OBSOLETE AssignedTo|virtualization_kvm at kernel-b |drivers_video-dri at kernel-bu |ugs.osdl.org|gs.osdl.org Product|Virtualization |Drivers -- 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 15486] amd_adac error
https://bugzilla.kernel.org/show_bug.cgi?id=15486 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2012-07-05 16:16:35 --- Is this still an issue with a newer kernel? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH v2] of: Add videomode helper
On Thu, Jul 05, 2012 at 04:08:07PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> Thanks for the patch.
>
> > +++ b/Documentation/devicetree/bindings/video/displaymode
> > @@ -0,0 +1,40 @@
> > +videomode bindings
> > +==
> > +
> > +Required properties:
> > + - xres, yres: Display resolution
> > + - left-margin, right-margin, hsync-len: Horizontal Display timing
> > parameters + in pixels
> > + upper-margin, lower-margin, vsync-len: Vertical display timing
> > parameters in + lines
> > + - clock: displayclock in Hz
> > +
> > +Optional properties:
> > + - width-mm, height-mm: Display dimensions in mm
>
> I've always had mixed feelings about the physical display dimension being
> part
> of the display mode. Those are properties of the panel/display instead of the
> mode. Storing them as part of the mode can be convenient, but we then run
> into
> consistency issues (developers have to remember in which display mode
> instances the values are available, and in which instances they're set to 0
> for instance). If we want to clean this up, this patch would be a good
> occasion.
This sounds like a display node with one or more node subnodes, like:
display {
width_mm = <>;
height_mm = <>;
mode {
xres = <>;
yres = <>;
...
};
};
Is that what you mean or are you thinking of something else?
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- |
[PATCH v2] of: Add videomode helper
On Thu, Jul 05, 2012 at 09:51:39AM -0500, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> > +
> > +There are different ways of describing a display mode. The devicetree
> > representation
> > +corresponds to the one used by the Linux Framebuffer framework described
> > here in
> > +Documentation/fb/framebuffer.txt. This representation has been chosen
> > because it's
> > +the only format which does not allow for inconsistent parameters.Unlike
> > the Framebuffer
> > +framework the devicetree has the clock in Hz instead of ps.
>
> This implies you are putting linux settings into DT rather than
> describing the h/w. I'm not saying the binding is wrong, but documenting
> it this way makes it seem so.
The major reason to use these values was that they do not allow for
inconsistent values (as opposed to for example with hsync_start which you
would have to check for hsync_start >= xres).
I could rephrase this if it looks too much like modelled-after-Linux
instead of modelled-after-hardware.
>
> One important piece missing (and IIRC linux doesn't really support) is
> defining the pixel format of the interface.
I could use this aswell. I think this can be specified as additional
properties later, right? I'm afraid this needs a lot of discussion so
we should delay this to the next round.
>
> > +Example:
> > +
> > + display at 0 {
> > + /* 1920x1080p24 */
> > + clock = <5200>;
>
> Should this use the clock binding? You probably need both constraints
> and clock binding though.
Is the clock binding suitable for this? Here we are not interested where
the clock comes from, but instead which range is allowed.
>
> Often you don't know the frequency up front and/or have limited control
> of the frequency (i.e. integer dividers). Then you have to adjust the
> margins to get the desired refresh rate. To do that, you need to know
> the ranges of values a panel can support. Perhaps you just assume you
> can increase the right-margin and lower-margins as I think you will hit
> pixel clock frequency max before any limit on margins.
Most datasheets specify min,typ,max triplets. We could do this instead
of using single fixed values for the margins:
left_margin = <0 10 40>;
Right now we have nothing in the kernel that could handle this, but
getting the interface to the devicetree right seems indeed important.
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- |
[PATCH v2] of: Add videomode helper
On 07/04/2012 02:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v1:
> - use hyphens instead of underscores for property names
>
> .../devicetree/bindings/video/displaymode | 40
> drivers/of/Kconfig |5 +
> drivers/of/Makefile|1 +
> drivers/of/of_videomode.c | 108
>
> include/linux/of_videomode.h | 19
> 5 files changed, 173 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/displaymode
> create mode 100644 drivers/of/of_videomode.c
> create mode 100644 include/linux/of_videomode.h
>
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Documentation/devicetree/bindings/video/displaymode
> new file mode 100644
> index 000..43cc17d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/displaymode
> @@ -0,0 +1,40 @@
> +videomode bindings
> +==
> +
> +Required properties:
> + - xres, yres: Display resolution
> + - left-margin, right-margin, hsync-len: Horizontal Display timing parameters
> + in pixels
> + upper-margin, lower-margin, vsync-len: Vertical display timing parameters
> in
> + lines
> + - clock: displayclock in Hz
> +
> +Optional properties:
> + - width-mm, height-mm: Display dimensions in mm
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
> + - interlaced (bool): This is an interlaced mode
> + - doublescan (bool): This is a doublescan mode
> +
> +There are different ways of describing a display mode. The devicetree
> representation
> +corresponds to the one used by the Linux Framebuffer framework described
> here in
> +Documentation/fb/framebuffer.txt. This representation has been chosen
> because it's
> +the only format which does not allow for inconsistent parameters.Unlike the
> Framebuffer
> +framework the devicetree has the clock in Hz instead of ps.
This implies you are putting linux settings into DT rather than
describing the h/w. I'm not saying the binding is wrong, but documenting
it this way makes it seem so.
One important piece missing (and IIRC linux doesn't really support) is
defining the pixel format of the interface.
> +Example:
> +
> + display at 0 {
> + /* 1920x1080p24 */
> + clock = <5200>;
Should this use the clock binding? You probably need both constraints
and clock binding though.
Often you don't know the frequency up front and/or have limited control
of the frequency (i.e. integer dividers). Then you have to adjust the
margins to get the desired refresh rate. To do that, you need to know
the ranges of values a panel can support. Perhaps you just assume you
can increase the right-margin and lower-margins as I think you will hit
pixel clock frequency max before any limit on margins.
Rob
> + xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-margin = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
> + };
> +
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index dfba3e6..a3acaa3 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -83,4 +83,9 @@ config OF_MTD
> depends on MTD
> def_bool y
>
> +config OF_VIDEOMODE
> + def_bool y
> + help
> + helper to parse videomodes from the devicetree
> +
> endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index e027f44..80e6db3 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_MTD) += of_mtd.o
> +obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
> diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> new file mode 100644
> index 000..50d3bd2
> --- /dev/null
> +++ b/drivers/of/of_videomode.c
> @@ -0,0 +1,108 @@
> +/*
> + * OF helpers for parsing display modes
> + *
> + * Copyright (c) 2012 Sascha Hauer , Pengutronix
> + *
> + * This file is released under the GPLv2
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +int of_get_video_mode(struct device_node *np, struct drm_display_mode *dmode,
> + struct fb_videomode *fbmode)
> +{
> + int ret = 0;
> + u32 left_margin, xres, right_margin, hsync_len;
> + u32 upper_margin, yres, lower_margin, vsync_len;
> + u32 width_mm = 0, height_mm = 0;
> + u32 clock;
> + bool hah = false, vah = false, interlaced = false,
3.5-rc5: radeon acceleration regression on Transmeta system
> > In 3.4, radeon worked with a glitch - window titles were see-throug (not > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables > > acceleration on this system at all. Full dmesg below. > > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32? That was a good question. I did some more tries, and it was not repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, no borders except when maximized, otherwise worked. Total 3 failures and 6 successes in intializing the card so far. > if I had to guess something broke in the dma area elsewhere, but not sure. Initial windows border problem seems to have been introduced between 2.6.37 and 2.6.38, bisect is slow. "Good" dmesg: [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos at raamat) (gcc version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009bfff] usable [0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x0efd] usable [0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data [0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS [0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08 02/24/2005 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10 [0.00] initial memory mapped: [mem 0x-0x017f] [0.00] Base memory trampoline at [c0098000] 98000 size 16384 [0.00] init_memory_mapping: [mem 0x-0x0efd] [0.00] [mem 0x-0x003f] page 4k [0.00] [mem 0x0040-0x0ebf] page 2M [0.00] [mem 0x0ec0-0x0efd] page 4k [0.00] kernel direct mapping tables up to 0xefd @ [mem 0x017fa000-0x017f] [0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ ) [0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3 0108 FUJ 1000) [0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3 0108 MSFT 0107) [0.00] ACPI: FACS 0efeffc0 00040 [0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD ACPIPST1 0001 PTL 0001) [0.00] 239MB LOWMEM available. [0.00] mapped low ram: 0 - 0efe [0.00] low ram: 0 - 0efe [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] Normal [mem 0x0100-0x0efd] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009bfff] [0.00] node 0: [mem 0x0010-0x0efd] [0.00] On node 0 totalpages: 61292 [0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map cee00200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3948 pages, LIFO batch:0 [0.00] Normal zone: 448 pages used for memmap [0.00] Normal zone: 56864 pages, LIFO batch:15 [0.00] ACPI: PM-Timer IO Port: 0xff08 [0.00] PM: Registered nosave memory: 0009c000 - 000a [0.00] PM: Registered nosave memory: 000a - 000e8000 [0.00] PM: Registered nosave memory: 000e8000 - 0010 [0.00] e820: [mem 0x0f10-0xffef] available for PCI devices [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60812 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug radeon.modeset=1 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] Initializing CPU#0 [0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k reserved, 984k data, 284k init, 0k highmem) [0.00] virtual kernel memory layout: [0.00] fixmap : 0xfffe4000 - 0xf000 ( 108 kB) [0.00] vmalloc : 0xcf7e
[bisected] nouveau: "Failed to idle channel x" after resume
On Mon, 11 Jun 2012 23:18:42 +0200 Martin Nyhus wrote:
> after resuming from suspend nouveau starts writing Failed to idle
> channel x (where x is 2 or 3) to the log and X appears to stop and
> then restart only to stop again. Starting Firefox after resuming
> triggers the bugs every time, and bisecting leads to 03bd6efa
> ("drm/nv50/fifo: use hardware channel kickoff functionality").
Hi Ben,
I'm still seeing this bug with the latest from Linus
(v3.5-rc5-98-g9e85a6f) and linux-next (next-20120705).
lspci output:
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce
8400M GS] (rev a1)
Sorry I haven't followed up on this earlier,
Martin
