[Bug 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #6 from Pavel Ondračka 2012-02-15 00:12:15 UTC --- (In reply to comment #5) > I'm guessing that this is a bug in the vertex shader. Does running with > RADEON_NO_TCL=1 fix it? Yes, the test pass with RADEON_NO_TCL=1 set. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
Hi, Status update about the problem 'Occasionally "GPU lockup" after resuming from suspend.' First, this could happen when system returns from a STR(suspend to ram) or STD(suspend to disk, aka hibernation). When returns from STD, the initialization process is most similar to the normal boot. The standby is ok, which is similar to STR, except that standby will not shutdown the power of CPU,GPU etc. We've dumped and compared the registers, and found something: CP_STAT normal value: 0x value when this problem occurred: 0x802100C1 or 0x802300C1 CP_ME_CNTL normal value: 0x00FF value when this problem occurred: always 0x20FF in our test Questions: According to the manual, CP_STAT = 0x802100C1 means CSF_RING_BUSY(bit 0): The Ring fetcher still has command buffer data to fetch, or the PFP still has data left to process from the reorder queue. CSF_BUSY(bit 6): The input FIFOs have command buffers to fetch, or one or more of the fetchers are busy, or the arbiter has a request to send to the MIU. MIU_RDREQ_BUSY(bit 7): The read path logic inside the MIU is busy. MEQ_BUSY(bit 16): The PFP-to-ME queue has valid data in it. SURFACE_SYNC_BUSY(bit 21): The Surface Sync unit is busy. CP_BUSY(bit 31): Any block in the CP is busy. What does it suggest? What does it mean if bit 29 of CP_ME_CNTL is set? BTW, how does the dummy page work in GART? Regards, -- Chen Jie 在 2011年12月7日 下午10:21，Alex Deucher 写道： > 2011/12/7 : >> When "MC timeout" happens at GPU reset, we found the 12th and 13th >> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these >> two bits are like this: >> #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1) >> #define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1) >> >> Could you please tell me what does they mean? And if possible, > > They refer to sub-blocks in the memory controller. I don't really > know off hand what the name mean. > >> I want to know the functionalities of these 5 registers in detail: >> #define R_000E60_SRBM_SOFT_RESET 0x0E60 >> #define R_000E50_SRBM_STATUS 0x0E50 >> #define R_008020_GRBM_SOFT_RESET0x8020 >> #define R_008010_GRBM_STATUS0x8010 >> #define R_008014_GRBM_STATUS2 0x8014 >> >> A bit more info: If I reset the MC after resetting CP (this is what >> Linux-2.6.34 does, but removed since 2.6.35), then "MC timeout" will >> disappear, but there is still "ring test failed". > > The bits are defined in r600d.h. As to the acronyms: > BIF - Bus InterFace > CG - clocks > DC - Display Controller > GRBM - Graphics block (3D engine) > HDP - Host Data Path (CPU access to vram via the PCI BAR) > IH, RLC - Interrupt controller > MC - Memory controller > ROM - ROM > SEM - semaphore controller > > When you reset the MC, you will probably have to reset just about > everything else since most blocks depend on the MC for access to > memory. If you do reset the MC, you should do it at prior to calling > asic_init so you make sure all the hw gets re-initialized properly. > Additionally, you should probably reset the GRBM either via > SRBM_SOFT_RESET or the individual sub-blocks via GRBM_SOFT_RESET. > > Alex > >> >> Huacai Chen >> >>> 2011/11/8 : And, I want to know something: 1, Does GPU use MC to access GTT? >>> >>> Yes. All GPU clients (display, 3D, etc.) go through the MC to access >>> memory (vram or gart). >>> 2, What can cause MC timeout？ >>> >>> Lots of things. Some GPU client still active, some GPU client hung or >>> not properly initialized. >>> >>> Alex >>> > Hi, > > Some status update. > 在 2011年9月29日 下午5:17，Chen Jie 写道： >> Hi, >> Add more information. >> We got occasionally "GPU lockup" after resuming from suspend(on mipsel >> platform with a mips64 compatible CPU and rs780e, the kernel is >> 3.1.0-rc8 >> 64bit). Related kernel message: >> /* return from STR */ >> [ 156.152343] radeon :01:05.0: WB enabled >> [ 156.187500] [drm] ring test succeeded in 0 usecs >> [ 156.187500] [drm] ib test succeeded in 0 usecs >> [ 156.398437] ata2: SATA link down (SStatus 0 SControl 300) >> [ 156.398437] ata3: SATA link down (SStatus 0 SControl 300) >> [ 156.398437] ata4: SATA link down (SStatus 0 SControl 300) >> [ 156.578125] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> [ 156.597656] ata1.00: configured for UDMA/133 >> [ 156.613281] usb 1-5: reset high speed USB device number 4 using >> ehci_hcd >> [ 157.027343] usb 3-2: reset low speed USB device number 2 using >> ohci_hcd >> [ 157.609375] usb 3-3: reset low speed USB device number 3 using >> ohci_hcd >> [ 157.683593] r8169 :02:00.0: eth0: link up >> [ 165.621093] PM: resume
Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> gmbus_xfer with a single message (particularly a single message write) would
> set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> No Index, Stop cycle. This would not start single message i2c transactions.
>
> Also, gmbus_xfer done: will disable the interface without checking if
> it is idle. In the case of writes, there will be no wait on status or delay
> to ensure the write starts and completes before the interface is turned off.
>
> Fixed the former issue by using the same cycle selection as used in the
> I2C_M_RD for the write case.
> GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
>
> Signed-off-by: Benson Leung
Can you clarify the commit message a bit and say that the first hunk is
just for optics and the issue is only with the write path (because the
read path is correct already). Silly me is just to easily confused ;-)
Btw, I've reworked the gmbus -> gpio bit-banging fallback code a bit and
if that passes review and all I'll reenable gmbus by default again. See
http://cgit.freedesktop.org/~danvet/drm/log/?h=gmbus
Yours, Daniel
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d30..64bb9cd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -249,7 +249,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> if (msgs[i].flags & I2C_M_RD) {
> I915_WRITE(GMBUS1 + reg_offset,
> -GMBUS_CYCLE_WAIT | (i + 1 == num ?
> GMBUS_CYCLE_STOP : 0) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
> @@ -278,7 +279,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> I915_WRITE(GMBUS3 + reg_offset, val);
> I915_WRITE(GMBUS1 + reg_offset,
> -(i + 1 == num ? GMBUS_CYCLE_STOP :
> GMBUS_CYCLE_WAIT) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -317,9 +319,12 @@ clear_err:
> I915_WRITE(GMBUS1 + reg_offset, 0);
>
> done:
> - /* Mark the GMBUS interface as disabled. We will re-enable it at the
> - * start of the next xfer, till then let it sleep.
> + /* Mark the GMBUS interface as disabled after waiting for idle.
> + * We will re-enable it at the start of the next xfer,
> + * till then let it sleep.
>*/
> + if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
> + DRM_INFO("GMBUS timed out waiting for idle\n");
> I915_WRITE(GMBUS0 + reg_offset, 0);
> return i;
>
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
On Wed, Feb 15, 2012 at 05:32:35PM +0800, Chen Jie wrote: > Hi, > > Status update about the problem 'Occasionally "GPU lockup" after > resuming from suspend.' > > First, this could happen when system returns from a STR(suspend to > ram) or STD(suspend to disk, aka hibernation). > When returns from STD, the initialization process is most similar to > the normal boot. > The standby is ok, which is similar to STR, except that standby will > not shutdown the power of CPU,GPU etc. > > We've dumped and compared the registers, and found something: > CP_STAT > normal value: 0x > value when this problem occurred: 0x802100C1 or 0x802300C1 > > CP_ME_CNTL > normal value: 0x00FF > value when this problem occurred: always 0x20FF in our test > > Questions: > According to the manual, > CP_STAT = 0x802100C1 means > CSF_RING_BUSY(bit 0): > The Ring fetcher still has command buffer data to fetch, or the > PFP > still has data left to process from the reorder queue. > CSF_BUSY(bit 6): > The input FIFOs have command buffers to fetch, or one or more > of the > fetchers are busy, or the arbiter has a request to send to the MIU. > MIU_RDREQ_BUSY(bit 7): > The read path logic inside the MIU is busy. > MEQ_BUSY(bit 16): > The PFP-to-ME queue has valid data in it. > SURFACE_SYNC_BUSY(bit 21): > The Surface Sync unit is busy. > CP_BUSY(bit 31): > Any block in the CP is busy. > What does it suggest? > > What does it mean if bit 29 of CP_ME_CNTL is set? > > BTW, how does the dummy page work in GART? > > > Regards, > -- Chen Jie To me it looks like the CP is trying to fetch memory but the GPU memory controller fail to fullfill cp request. Did you check the PCI configuration before & after (when things don't work) My best guest is PCI bus mastering is no properly working or the PCIE GPU gart table as wrong data. Maybe one need to drop bus master and reenable bus master to work around some bug... Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote: > > > Btw, to sum up the list of Power Architecture machines with PCIE that > > > aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac > > > Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last > > > two, on present evidence (my attempts), aren't able to boot up if > > > bootkernel has kms enabled. > > > > Which radeon card, kernel log please ? > > See > http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html > (start of this thread) and > http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html . Ok, so for the 460EX, I am not surprised things aren't working with KMS & DRI2... the 460 is not cache coherent, and this is not handled by TTM as far as I can tell. The second case with no firmware is a bit more surprising, looks like something bad happened on the PCI express bus or the kernel tried to access something that the card rejected (target abort or PCIe equivalent most likely), thus triggering a PLB error . That could be investigated a bit more. Note that you say this is smoe kind of "SAM460EX" card... but it claims to be a Canyonlands in the device-tree... is that expected or do we have yet another case of a vendor claiming to be the eval board they based their design upon and generally screwing up in a major way ? IE. does it indeed work with an -identical- device-tree to a canyonland and no patches added to the machine support at all ? Cheers, Ben. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drivers/gpu/drm/i915/intel_overlay.c needs seq_file.h"
This reverts commit e167976ee7f5fe4b80f7e8f55e087f6c67cf9562, Since this was already fixed in commit 3bd3c9329973a93fa3ef5e9840f2fd6fa2889e3f some days before this commit cause seq_file.h to be included twice. Signed-off-by: Danny Kukawka --- drivers/gpu/drm/i915/intel_overlay.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index cdf17d4..134c42a 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -25,8 +25,6 @@ * * Derived from Xorg ddx, xf86-video-intel, src/i830_video.c */ - -#include #include "drmP.h" #include "drm.h" #include "i915_drm.h" -- 1.7.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Add support for extension blocks beyond the first
Hi Ville,
On Monday 13 February 2012 07:24:23 pm Ville Syrjälä wrote:
> On Wed, Dec 07, 2011 at 03:11:07PM +0100, Jean Delvare wrote:
> > When 2 or more EDID extension blocks are present, segment must be
> > selected prior to reading the extended EDID block over the DDC
> > channel. Add support for this.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Adam Jackson
> > ---
> > This needs testing by someone with access to such a display.
> >
> > drivers/gpu/drm/drm_edid.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > --- linux-3.2-rc3.orig/drivers/gpu/drm/drm_edid.c 2011-11-09
> > 15:53:31.0 +0100 +++
> > linux-3.2-rc3/drivers/gpu/drm/drm_edid.c2011-12-03
> > 10:12:47.0 +0100 @@ -242,7 +242,8 @@ static int
> > drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char
> > *buf, int block, int len)
> > {
> > - unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned char start = (block & 0x01) * EDID_LENGTH;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> > the @@ -254,6 +255,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> > do {
> > struct i2c_msg msgs[] = {
> > {
> > + .addr = DDC_SEGMENT_ADDR,
> > + .flags = 0,
> > + .len= 1,
> > + .buf= &segment,
> > + }, {
> > .addr = DDC_ADDR,
> > .flags = 0,
> > .len= 1,
> > @@ -265,7 +271,18 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > +
> > + /* Don't write segment if it is 0, for compatibility */
> > + if (segment) {
> > + ret = i2c_transfer(adapter, msgs, 3);
> > + /* The E-DDC specification says that the first ack is
> > +* optional, so retry in ignore-nak mode if we get no
> > +* ack at first.
> > +*/
> > + if (ret == -ENXIO)
> > + msgs[0].flags |= I2C_M_IGNORE_NAK;
>
> This seems a bit wrong to me. The spec says that the ack for the
> segment address is "don't care", but for the segment pointer the ack
> is required (when segment != 0).
Correct.
> With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from
> a non E-DDC display, if we try to read segment != 0 from it. Of
> course we shouldn't do that unless the display lied to us about what
> extension blocks it provides.
Still correct.
> So I'm not sure if it would be better to trust that the display never
> lies about the extension blocks, or if we should just assume all
> E-DDC displays ack both segment addr and pointer.
I went for the former, as should be obvious from my proposed
implementation. Whether this is the best decision is impossible to tell
until the code is tested in the fields.
> The no-ack feature
> seems to there for backwards compatibility, for cases where the host
> always sends the segment addr/pointer even when reading segment 0
> (which your code doesn't do).
I agree.
> To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be
> split into two flags (one for addr, other for data).
This is correct, but this seemed a little overkill. I would only
implement this in i2c-core if it turns out to be absolutely necessary to
properly handle one real-world display.
I would suggest that my patch gets applied as is for now, and it can be
adjusted later if needed. It is certainly better than the current code
anyway.
Thanks for the review,
--
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/atom: bios scratch reg handling updates
If the atombios bits for dpms state are still used from dce4, we would miss explicitly the DFP6 device in radeon_atombios_encoder_dpms_scratch_regs, wouldn't we? -- Sylvain (or sylware on phoronix.com) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vgem: getparam ioctl
On 2/8/12 6:19 PM, Ben Widawsky wrote: Similar to i915, it's nice to be able to query this device uniquely and get some info Signed-off-by: Ben Widawsky So, this is actually not especially useful as written. You'd like to be able to use this to find the vgem device node, but since it's a device-specific ioctl it collides with whatever happens to be device-specific ioctl number 2 on whatever device you've opened. On i915, that's I915_FLIP, and you promptly oops the machine. Comedy. Gold. Which is fine, really. The way I was anticipating finding the vgem node was to just scrape the device node name out of /sys/bus/platform/devices/vgem/cardN, because why do anything O(n) when you could do it O(1). I guess that doesn't help OSes that aren't Linux, and I guess if pressed to care about that I'd say hang it off drm_getcap. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #4 from lschin...@gmail.com 2012-02-15 14:14:36 UTC --- The patch partially work. glxgears now work ok, but vmware (with 3d acceleration) cause Xorg crashed. (file "kern2.log" attached) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #5 from lschin...@gmail.com 2012-02-15 14:15:18 UTC --- Created attachment 57121 --> https://bugs.freedesktop.org/attachment.cgi?id=57121 crash log after fix applied -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm: atomic mode set API
Many of us really want (and need) a way to set the whole display
configuration atomically, as well as test a global config.
In talking with Rob and Alex here at ELC a bit, I think this may be
enough:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 2a2acda..2864b02 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -157,6 +157,26 @@ struct drm_mode_get_plane_res {
__u32 count_planes;
};
+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
for validity */
+
+struct drm_mode_set_config {
+ __u64 crtcs;
+ __u64 crtc_fbs;
+ __u64 crtc_xpos; /* array of x coords for crtcs */
+ __u64 crtc_ypos; /* array of y coords for crtcs */
+ __u32 count_crtcs;
+
+ __u64 plane_sets; /* array of set_plane structs */
+
+ __u32 count_planes;
+
+ __u64 connectors;
+ __u64 connector_modes;
+ __u32 count_connectors;
+
+ __u32 flags;
+};
+
#define DRM_MODE_ENCODER_NONE 0
#define DRM_MODE_ENCODER_DAC 1
#define DRM_MODE_ENCODER_TMDS 2
This allows you to bind a bunch of fbs to crtcs with independent
positions, as well as set a bunch of planes to specific fbs and
layouts. Finally, it lets you change the connector config at the same
time, with a flag to simply test a config instead of actually setting
it.
Any comments? Do we also need to set gamma or other properties as part
of this? What about cursors?
Thanks,
Jesse
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: atomic mode set API
On 2/15/12 5:42 PM, Jesse Barnes wrote:
+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
for validity */
+
+struct drm_mode_set_config {
+ __u64 crtcs;
+ __u64 crtc_fbs;
+ __u64 crtc_xpos; /* array of x coords for crtcs */
+ __u64 crtc_ypos; /* array of y coords for crtcs */
+ __u32 count_crtcs;
+
+ __u64 plane_sets; /* array of set_plane structs */
+
+ __u32 count_planes;
+
+ __u64 connectors;
+ __u64 connector_modes;
+ __u32 count_connectors;
+
+ __u32 flags;
+};
This appears to be missing some []s, but I think the intent is clear.
#define DRM_MODE_ENCODER_NONE 0
#define DRM_MODE_ENCODER_DAC 1
#define DRM_MODE_ENCODER_TMDS 2
This allows you to bind a bunch of fbs to crtcs with independent
positions, as well as set a bunch of planes to specific fbs and
layouts. Finally, it lets you change the connector config at the same
time, with a flag to simply test a config instead of actually setting
it.
Any comments? Do we also need to set gamma or other properties as part
of this? What about cursors?
I guess you might want to set gamma atomically, but I can't imagine it
being a factor in anyone's "can I do this" logic.
How do you pass in pixel format? Do you just assume the existing fb is
already in the correct format? That could work but it kind of sucks for
low-memory environments since you'd need to have enough room to
pre-create all the fbs. You could still do the "tear everything down
first" approach to work around that, but then you'd still have the
possibility of having nothing lit up _and_ not being able to set what
was requested, and then needing to unwind in userspace.
I'd sort of also want to see audio reflected in this (sigh), since
that's going to affect the bandwidth math. DP 1.2 makes that even worse.
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patches][nouveau/kms]: Precise Vblank and pageflip timestamping
Hi, these are two patches against the nouveau kms driver. The first patch makes sure that pageflip completion events get their vblank count and timestamp from the drm. The second patch from Lucas Stach, here included with his permission, makes sure that the timestamps of vblanks are calculated with high precision and robustness. Both patches together make sure that all timestamps returned by the kms driver are consistent with each other and conform to the OML_sync_control specification. With Lucas permission i've already integrated my feedback from reviewing his patch into the patch. The patches have been applied against Linux 3.2 and tested with special measurement equipment on a GeForce 7800, a GeForce 8800 and some QuadroFX 570 and 370. The timestamps are accurate to less than 30 usecs deviation from the ground truth measured with the external equipment. I'll send out a couple of nouveau ddx patches that make use of these timestamps. It would be great if these could be reviewed and possibly included for the Linux 3.4 merge window. Thanks, -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau: Use drm_vblank_count_and_time() for pageflip completion events.
Emit kms pageflip completion events with proper vblank count
and timestamp for the vblank interval in which the pageflip
completed. This makes the timestamps and counts consistent with
what the OML_sync_control spec defines.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/nouveau/nouveau_display.c | 29 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |1 +
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index b12fd2c..5bd392f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -295,7 +295,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
*s = (struct nouveau_page_flip_state)
{ { }, event, nouveau_crtc(crtc)->index,
fb->bits_per_pixel, fb->pitch, crtc->x, crtc->y,
- new_bo->bo.offset };
+ new_bo->bo.offset, crtc->framedur_ns };
/* Choose the channel the flip will be handled in */
chan = nouveau_fence_channel(new_bo->bo.sync_obj);
@@ -338,6 +338,9 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
struct drm_device *dev = chan->dev;
struct nouveau_page_flip_state *s;
unsigned long flags;
+ struct timeval tnow, tvbl;
+
+ do_gettimeofday(&tnow);
spin_lock_irqsave(&dev->event_lock, flags);
@@ -351,12 +354,26 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
struct nouveau_page_flip_state, head);
if (s->event) {
struct drm_pending_vblank_event *e = s->event;
- struct timeval now;
- do_gettimeofday(&now);
- e->event.sequence = 0;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
+ e->event.sequence = drm_vblank_count_and_time(dev, s->crtc,
&tvbl);
+
+ /* Called before vblank count and timestamp have
+* been updated for the vblank interval of flip
+* completion? If so, need to increment vblank count and
+* add one videorefresh duration to returned timestamp
+* to account for this. We assume this happened if we
+* get called over 0.9 frame durations after the last
+* timestamped vblank.
+*/
+ if (10 * (timeval_to_ns(&tnow) - timeval_to_ns(&tvbl)) >
+9 * s->framedur_ns) {
+ e->event.sequence++;
+ tvbl = ns_to_timeval(timeval_to_ns(&tvbl) +
+ s->framedur_ns);
+ }
+
+ e->event.tv_sec = tvbl.tv_sec;
+ e->event.tv_usec = tvbl.tv_usec;
list_add_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 4c0be3a..f489c22 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -202,6 +202,7 @@ struct nouveau_page_flip_state {
struct drm_pending_vblank_event *event;
int crtc, bpp, pitch, x, y;
uint64_t offset;
+ s64 framedur_ns;
};
enum nouveau_channel_mutex_class {
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] nouveau: implement precise vblank timestamping
From: Lucas Stach
This patch implements the drivers hooks needed for precise vblank
timestamping. This is a complementary patch to Mario Kleiner's
patches to improve swap scheduling. With the complete
patchset applied nouveau will be able to provide correct and
precise pageflip timestamps (compliant to OML_sync_control spec)
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach
Reviewed-by: Mario Kleiner
Tested-by: Mario Kleiner
---
drivers/gpu/drm/nouveau/nouveau_display.c | 124 +
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +
drivers/gpu/drm/nouveau/nouveau_drv.h |5 +
drivers/gpu/drm/nouveau/nouveau_reg.h |9 ++-
drivers/gpu/drm/nouveau/nv50_crtc.c | 19 +
drivers/gpu/drm/nouveau/nvreg.h |1 +
6 files changed, 159 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 5bd392f..7fdd6a4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -431,3 +431,127 @@ nouveau_display_dumb_map_offset(struct drm_file
*file_priv,
return -ENOENT;
}
+
+int
+nouveau_get_scanoutpos(struct drm_device *dev, int crtc, int *vpos, int *hpos)
+{
+ struct drm_nouveau_private *dev_priv = dev->dev_private;
+ int vline, hline, ret = 0;
+ u32 vbias, hbias, reg, vbl_start, vbl_end;
+ struct drm_crtc *drmcrtc;
+
+ if (crtc < 0 || crtc >= dev->num_crtcs) {
+ DRM_ERROR("Invalid crtc %d\n", crtc);
+ return -EINVAL;
+ }
+
+ list_for_each_entry(drmcrtc, &dev->mode_config.crtc_list, head) {
+ if(nouveau_crtc(drmcrtc)->index == crtc)
+ /* stop if we have found crtc with matching index */
+ break;
+ }
+
+ if(dev_priv->card_type >= NV_50) {
+ /* get vsync and hsync area */
+ reg = nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ SYNC_START_TO_BLANK_END));
+ vbias = (reg >> 16) & 0x;
+ hbias = reg & 0x;
+
+ /* get vertical display size including bias as vbl_start
+* and vtotal as vbl_end */
+ vbl_start = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ VBL_START)) >> 16) & 0x;
+ vbl_end = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ DISPLAY_TOTAL)) >> 16) & 0x;
+
+ /* get current scanout position from PDISPLAY */
+ vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
+
+ /*
+* vline == 0 could be invalid:
+* Some gpu's get stuck on that value inside vblank. Try again
+* after one scanline duration, if it still reads 0 give up.
+*/
+ if (vline == 0) {
+ ndelay(drmcrtc->linedur_ns & 0x);
+ vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
+ }
+
+ hline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_HORZ(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_HORZ_HLINE__MASK;
+
+ if((vline > 0) && (vline < vbl_end))
+ ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
+
+ if((vline >= vbl_start) || (vline < vbias)) {
+ /* we are in vblank so do a neg countdown */
+ ret |= DRM_SCANOUTPOS_INVBL;
+ vline -= (vline < vbias) ? vbias : (vbl_end + vbias);
+ hline -= hbias;
+ } else {
+ /* apply corrective offset */
+ vline -= vbias;
+ hline -= hbias;
+ }
+ } else {
+ /* get vsync area from PRAMDAC */
+ vbl_start = NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VDISPLAY_END)
+ & 0x;
+ vbl_end = (NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VTOTAL)
+ & 0x) + 1;
+
+ /* get current scanout position from PCRTC */
+ vline = nv_rd32(dev, NV_PCRTC_STAT(crtc)) & 0x;
+
+ /*
+* vline == 0 could be invalid:
+* Some gpu's get stuck on that value inside vblank. Try again
+* after one scanline duration, if it still reads 0 give up.
+*/
+ if (vline == 0) {
+ ndelay(drmcrtc->linedur_ns & 0x);
+ vline = nv_rd32(dev, NV_PCRTC_STAT(crtc)) & 0x;
+ }
+
+ if(vline > 0)
+
Re: [RFC] drm: atomic mode set API
On Wed, Feb 15, 2012 at 05:59:45PM -0500, Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
> >+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
> >for validity */
> >+
> >+struct drm_mode_set_config {
> >+__u64 crtcs;
> >+__u64 crtc_fbs;
> >+__u64 crtc_xpos; /* array of x coords for crtcs */
> >+__u64 crtc_ypos; /* array of y coords for crtcs */
> >+__u32 count_crtcs;
> >+
> >+__u64 plane_sets; /* array of set_plane structs */
> >+
> >+__u32 count_planes;
> >+
> >+__u64 connectors;
> >+__u64 connector_modes;
> >+__u32 count_connectors;
> >+
> >+__u32 flags;
> >+};
>
> This appears to be missing some []s, but I think the intent is clear.
>
> > #define DRM_MODE_ENCODER_NONE 0
> > #define DRM_MODE_ENCODER_DAC 1
> > #define DRM_MODE_ENCODER_TMDS 2
> >
> >This allows you to bind a bunch of fbs to crtcs with independent
> >positions, as well as set a bunch of planes to specific fbs and
> >layouts. Finally, it lets you change the connector config at the same
> >time, with a flag to simply test a config instead of actually setting
> >it.
> >
> >Any comments? Do we also need to set gamma or other properties as part
> >of this? What about cursors?
>
> I guess you might want to set gamma atomically, but I can't imagine
> it being a factor in anyone's "can I do this" logic.
>
> How do you pass in pixel format? Do you just assume the existing fb
> is already in the correct format? That could work but it kind of
> sucks for low-memory environments since you'd need to have enough
> room to pre-create all the fbs. You could still do the "tear
> everything down first" approach to work around that, but then you'd
> still have the possibility of having nothing lit up _and_ not being
> able to set what was requested, and then needing to unwind in
> userspace.
>
> I'd sort of also want to see audio reflected in this (sigh), since
> that's going to affect the bandwidth math. DP 1.2 makes that even
> worse.
Yeah, I think we should include any funky connector, crtc, plane
properties (the latter don't exist yet, but I guess they will sooner or
later) because they all might affect how many and which hw resources we
need (I'm thinking e.g. of plane setups for hw that reuses crtc engines as
planes, but where you can use the crtc scanout engine for something else
if it's completely occluded or set to just scan out the black borders with
a parameter).
-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: [BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode
On Wed, Feb 15, 2012 at 03:16:52PM -0500, Mathieu Desnoyers wrote: > * Mathieu Desnoyers (mathieu.desnoy...@efficios.com) wrote: > > Hi Keith, > > > > * Keith Packard (kei...@keithp.com) wrote: > > > On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers > > > wrote: > > > > > > > Dell U3011 monitor turns to power saving mode when resolution set to > > > > 2560 x 1600 > > > > (intermittent) > > > > > > > > Reproduced with: > > > > Linux 2.6.38-1-amd64 (Debian kernel) > > > > Linux 3.1.0-1-amd64 (Debian kernel) > > > > Linux 3.2.0-1-amd64 (Debian kernel) > > > > > > > > The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200 > > > > docking station. The docking station uses a DisplayPort cable to connect > > > > to the monitor. I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14 > > > > (latest), which did not fix the problem. I cannot use anything else > > > > than DisplayPort in this case to connect the monitor at 2560 x 1600, > > > > because this resolution requires either the bandwidth provided by a > > > > dual-link DVI (which I cannot connect in my docking station), or > > > > DisplayPort. > > > > > > I use this same monitor, and have run it with an X200 in the past. > > > > > > Can you capture a dmesg output with the kernel parameter drm.debug=0xe > > > set? That will let us see the DP link training adventure and see what's > > > broken. If you can, separate traces of working and non-working tries > > > would be nice. > > > > > > And, of course, trying 3.3-rc1 would be helpful as that's what any > > > test patches would be developed on top of. > > > > I've compiled and launched a 3.3-rc1 kernel for the following tests. The > > dmesg log follows. > > > > FWIW, when I get the screen to run, if I launch this 1080p video with > > either mplayer or vlc (http://www.bigbuckbunny.org/index.php/download/, > > 1920x1080, mp4 format) in full screen, I get an horizontal line of blur > > at about 7/8 of the screen (from the top) when there is a lot of > > movement in the movie. This looks like a vertical refresh sync issue > > and/or too small buffers for double(/triple)-buffering. I'm aware that > > this is a separate issue, but it might help the current investigation. > > The xrandr -q --verbose gives "+HSync -VSync" for the monitor, even > > though its EDID (taken with get-edid/parse-edid) specifies "Flags > > "-HSync" "+VSync"". So hsync and vsync +/- seems to be mixed up. > > Another piece of information on this issue: I tried the monitor with an > Apple PowerBook running MacOS X, and the monitor works flawlessly > (monitor always brought up, and the same video works without glitch with > vlc). > > I also simplified my routine that successfully bring the monitor into a > working state: running 5 to 20 times the following script ends up doing > the trick: > > xrandr --output DP1 --off > sleep 1 > xrandr --output DP1 --mode 2560x1600 > > Please let me know if I can provide more information on the issue than > the detailed logs (success/fail) below. I would also like to know if > there is a knob somewhere in the Intel driver I could play with to > provide more time for the screen to send its EDID information. Based on > this info: http://www.intel.com/support/graphics/sb/CS-028366.htm, Intel > provide a modified Windows driver that might target this kind of issue, > and I assume they possibly let more time than the spec requires for the > screen to send EDID info. Well, we unfortunately have a bunch of dp link training issues left. But currently I'm not aware of any patches that might help. The best way forward is likely to file a bugzilla on bugs.freedesktop.org with all the information you've already gathered (against DRI, DRM/Intel) so that this won't get lost. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #16 from Alexandre Demers 2012-02-15 15:54:48 PST --- With yesterday's gits (mesa, drum, ddx), Gnome-shell is now freezing right after I log in. From time to time, I receive GPU hanged for X msec and then it resets. I'll try to bisect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 16 Feb 2012 07:28:10 +1100 Benjamin Herrenschmidt wrote: > On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote: > > > > > Btw, to sum up the list of Power Architecture machines with > > > > PCIE that aim to be a desktop/workstation: Apple iMac G5 > > > > (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and > > > > Acube Sam460ex . And the last two, on present evidence (my > > > > attempts), aren't able to boot up if bootkernel has kms enabled. > > > > > > Which radeon card, kernel log please ? > > > > See > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html > > (start of this thread) and > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html . > > Ok, so for the 460EX, I am not surprised things aren't working with > KMS & DRI2... the 460 is not cache coherent, and this is not handled > by TTM as far as I can tell. > > The second case with no firmware is a bit more surprising, looks like > something bad happened on the PCI express bus or the kernel tried to > access something that the card rejected (target abort or PCIe > equivalent most likely), thus triggering a PLB error . That could be > investigated a bit more. > > Note that you say this is smoe kind of "SAM460EX" card... but it > claims to be a Canyonlands in the device-tree... is that expected or > do we have yet another case of a vendor claiming to be the eval board > they based their design upon and generally screwing up in a major > way ? IE. does it indeed work with an -identical- device-tree to a > canyonland and no patches added to the machine support at all ? > Guys, thank you very much for your replies, i know it's a very common (bad) scenario, thanks for your opinion i already informed the vendor to suggest a _real_ linux kernel porting and i'll do it again. Anyway after nearly ten years, due a lack in resources, i'm sadly going to suspend the CRUX PPC project and my activism pro free software thus i'm unable to follow these debug. I'll hold on to me the only YDL Powerstation then from the next weeks i'll can only follow trying to help in debug [1] on this specific machine. [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html all the best and again THANKS for all your work, - --nico - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk88VnEACgkQxq34tDeO7Lg1NQCgkcHSqVxtJ2pfw2x+fyyuTLpx llMAn1h0szhNtxusxjCsBzjj5LQ/v6VZ =Uszy -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: atomic mode set API
On Wed, 15 Feb 2012 17:59:45 -0500
Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
> > +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > it for validity */
> > +
> > +struct drm_mode_set_config {
> > + __u64 crtcs;
> > + __u64 crtc_fbs;
> > + __u64 crtc_xpos; /* array of x coords for crtcs */
> > + __u64 crtc_ypos; /* array of y coords for crtcs */
> > + __u32 count_crtcs;
> > +
> > + __u64 plane_sets; /* array of set_plane structs */
> > +
> > + __u32 count_planes;
> > +
> > + __u64 connectors;
> > + __u64 connector_modes;
> > + __u32 count_connectors;
> > +
> > + __u32 flags;
> > +};
>
> This appears to be missing some []s, but I think the intent is clear.
Yeah, all the u64s are arrays.
> > #define DRM_MODE_ENCODER_NONE 0
> > #define DRM_MODE_ENCODER_DAC 1
> > #define DRM_MODE_ENCODER_TMDS 2
> >
> > This allows you to bind a bunch of fbs to crtcs with independent
> > positions, as well as set a bunch of planes to specific fbs and
> > layouts. Finally, it lets you change the connector config at the same
> > time, with a flag to simply test a config instead of actually setting
> > it.
> >
> > Any comments? Do we also need to set gamma or other properties as part
> > of this? What about cursors?
>
> I guess you might want to set gamma atomically, but I can't imagine it
> being a factor in anyone's "can I do this" logic.
>
> How do you pass in pixel format? Do you just assume the existing fb is
> already in the correct format? That could work but it kind of sucks for
> low-memory environments since you'd need to have enough room to
> pre-create all the fbs. You could still do the "tear everything down
> first" approach to work around that, but then you'd still have the
> possibility of having nothing lit up _and_ not being able to set what
> was requested, and then needing to unwind in userspace.
Yeah, the assumption is that the fbs have already been set up. You'll
need to do that anyway if you want to queue to a flip chain or
whatever. I don't see an easy way of linking that in here, since to
format an fb you need an underlying buffer allocated, which is where
the memory issues you mentioned come in. So in that sense, it works
like the other APIs in that it assumes you have an object with content
and the right pixel format all ready to go.
> I'd sort of also want to see audio reflected in this (sigh), since
> that's going to affect the bandwidth math. DP 1.2 makes that even worse.
Requesting a specific audio config? Or just returning an informative
error code about why the mode was rejected (e.g. you're playing 7.1
audio on this link and there's not enough bw for the config you wanted)?
How to reasonably return errors from this is an open question; should
we return an array of error codes to indicate all the possible issues?
Or just try our best with a single dimension and hope userspace can
figure things out?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: atomic mode set API
On Thu, 16 Feb 2012 00:12:49 +0100
Daniel Vetter wrote:
> On Wed, Feb 15, 2012 at 05:59:45PM -0500, Adam Jackson wrote:
> > On 2/15/12 5:42 PM, Jesse Barnes wrote:
> >
> > >+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > >it for validity */
> > >+
> > >+struct drm_mode_set_config {
> > >+ __u64 crtcs;
> > >+ __u64 crtc_fbs;
> > >+ __u64 crtc_xpos; /* array of x coords for crtcs */
> > >+ __u64 crtc_ypos; /* array of y coords for crtcs */
> > >+ __u32 count_crtcs;
> > >+
> > >+ __u64 plane_sets; /* array of set_plane structs */
> > >+
> > >+ __u32 count_planes;
> > >+
> > >+ __u64 connectors;
> > >+ __u64 connector_modes;
> > >+ __u32 count_connectors;
> > >+
> > >+ __u32 flags;
> > >+};
> >
> > This appears to be missing some []s, but I think the intent is clear.
> >
> > > #define DRM_MODE_ENCODER_NONE0
> > > #define DRM_MODE_ENCODER_DAC 1
> > > #define DRM_MODE_ENCODER_TMDS2
> > >
> > >This allows you to bind a bunch of fbs to crtcs with independent
> > >positions, as well as set a bunch of planes to specific fbs and
> > >layouts. Finally, it lets you change the connector config at the same
> > >time, with a flag to simply test a config instead of actually setting
> > >it.
> > >
> > >Any comments? Do we also need to set gamma or other properties as part
> > >of this? What about cursors?
> >
> > I guess you might want to set gamma atomically, but I can't imagine
> > it being a factor in anyone's "can I do this" logic.
> >
> > How do you pass in pixel format? Do you just assume the existing fb
> > is already in the correct format? That could work but it kind of
> > sucks for low-memory environments since you'd need to have enough
> > room to pre-create all the fbs. You could still do the "tear
> > everything down first" approach to work around that, but then you'd
> > still have the possibility of having nothing lit up _and_ not being
> > able to set what was requested, and then needing to unwind in
> > userspace.
> >
> > I'd sort of also want to see audio reflected in this (sigh), since
> > that's going to affect the bandwidth math. DP 1.2 makes that even
> > worse.
>
> Yeah, I think we should include any funky connector, crtc, plane
> properties (the latter don't exist yet, but I guess they will sooner or
> later) because they all might affect how many and which hw resources we
> need (I'm thinking e.g. of plane setups for hw that reuses crtc engines as
> planes, but where you can use the crtc scanout engine for something else
> if it's completely occluded or set to just scan out the black borders with
> a parameter).
So just an array of set_property structs per object as well? That came
up at today's meeting... Seems doable.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] nouveau: implement precise vblank timestamping
On Wed, 2012-02-15 at 23:55 +0100, Mario Kleiner wrote:
> From: Lucas Stach
>
> This patch implements the drivers hooks needed for precise vblank
> timestamping. This is a complementary patch to Mario Kleiner's
> patches to improve swap scheduling. With the complete
> patchset applied nouveau will be able to provide correct and
> precise pageflip timestamps (compliant to OML_sync_control spec)
My only real issue with this patch after a quick review is that
NV50_PDISP_CRTC_P (proposed) is being used instead of _C (current).
There's also some minor formatting issues such as "if(blah)" instead of
"if (blah)" in a few places.
Ben.
>
> Kudos to Mario for his many helpful comments and testing.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Mario Kleiner
> Tested-by: Mario Kleiner
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 124
> +
> drivers/gpu/drm/nouveau/nouveau_drv.c |2 +
> drivers/gpu/drm/nouveau/nouveau_drv.h |5 +
> drivers/gpu/drm/nouveau/nouveau_reg.h |9 ++-
> drivers/gpu/drm/nouveau/nv50_crtc.c | 19 +
> drivers/gpu/drm/nouveau/nvreg.h |1 +
> 6 files changed, 159 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 5bd392f..7fdd6a4 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -431,3 +431,127 @@ nouveau_display_dumb_map_offset(struct drm_file
> *file_priv,
>
> return -ENOENT;
> }
> +
> +int
> +nouveau_get_scanoutpos(struct drm_device *dev, int crtc, int *vpos, int
> *hpos)
> +{
> + struct drm_nouveau_private *dev_priv = dev->dev_private;
> + int vline, hline, ret = 0;
> + u32 vbias, hbias, reg, vbl_start, vbl_end;
> + struct drm_crtc *drmcrtc;
> +
> + if (crtc < 0 || crtc >= dev->num_crtcs) {
> + DRM_ERROR("Invalid crtc %d\n", crtc);
> + return -EINVAL;
> + }
> +
> + list_for_each_entry(drmcrtc, &dev->mode_config.crtc_list, head) {
> + if(nouveau_crtc(drmcrtc)->index == crtc)
> + /* stop if we have found crtc with matching index */
> + break;
> + }
> +
> + if(dev_priv->card_type >= NV_50) {
> + /* get vsync and hsync area */
> + reg = nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
> +SYNC_START_TO_BLANK_END));
> + vbias = (reg >> 16) & 0x;
> + hbias = reg & 0x;
> +
> + /* get vertical display size including bias as vbl_start
> + * and vtotal as vbl_end */
> + vbl_start = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
> + VBL_START)) >> 16) & 0x;
> + vbl_end = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
> + DISPLAY_TOTAL)) >> 16) & 0x;
> +
> + /* get current scanout position from PDISPLAY */
> + vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
> + & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
> +
> + /*
> + * vline == 0 could be invalid:
> + * Some gpu's get stuck on that value inside vblank. Try again
> + * after one scanline duration, if it still reads 0 give up.
> + */
> + if (vline == 0) {
> + ndelay(drmcrtc->linedur_ns & 0x);
> + vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
> + & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
> + }
> +
> + hline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_HORZ(crtc))
> + & NV50_PDISPLAY_CRTC_STAT_HORZ_HLINE__MASK;
> +
> + if((vline > 0) && (vline < vbl_end))
> + ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
> +
> + if((vline >= vbl_start) || (vline < vbias)) {
> + /* we are in vblank so do a neg countdown */
> + ret |= DRM_SCANOUTPOS_INVBL;
> + vline -= (vline < vbias) ? vbias : (vbl_end + vbias);
> + hline -= hbias;
> + } else {
> + /* apply corrective offset */
> + vline -= vbias;
> + hline -= hbias;
> + }
> + } else {
> + /* get vsync area from PRAMDAC */
> + vbl_start = NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VDISPLAY_END)
> + & 0x;
> + vbl_end = (NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VTOTAL)
> +& 0x) + 1;
> +
> + /* get current scanout position from PCRTC */
> + vline = nv_rd32(dev, NV_PCRTC_STAT(crtc)) & 0x;
> +
> + /*
> + * vline == 0 could be invalid:
> + * S
Mode validation outside of connector or encoder (i.e. at CRTC or drm_driver level)
Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this? I expected to see a mode_valid callback in crtc or somewhere similar. What I've got right now is a drm connector and encoder, which are describing a silicon image hdmi transmitter, and an embedded crtc connected to it. While the transmitter is fairly capable the crtc in the SoC is not (it has a maximum pixel clock limitation of 133MHz which means I have to kill off modes above that like 1080p@60. There are other things I may need to limit too). How do I coordinate such things from the drm_driver or crtc level up to the connector/encoder without making the connector/encoder intimately knowledgeable about the underlying crtc? Currently my only resort is to put the limits in platform data for the connector/encoder and use the mode_valid I already have to parse and discard modes which are plainly not going to be able to be clocked. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/vgem: getparam ioctl
On Wed, Feb 15, 2012 at 9:22 PM, Adam Jackson wrote: > On 2/8/12 6:19 PM, Ben Widawsky wrote: >> >> Similar to i915, it's nice to be able to query this device uniquely and >> get some info >> >> Signed-off-by: Ben Widawsky > > > So, this is actually not especially useful as written. You'd like to be > able to use this to find the vgem device node, but since it's a > device-specific ioctl it collides with whatever happens to be > device-specific ioctl number 2 on whatever device you've opened. On i915, > that's I915_FLIP, and you promptly oops the machine. > We have DRM level caps that we could use for that if necessary. I'm not sure we need a getparam for vgem if the only thing it reports is VGEM status. Though yeah what ajax said looking in /sys is the discovery path of choice. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Don, 2012-02-16 at 01:05 +, acrux wrote: > On Thu, 16 Feb 2012 07:28:10 +1100 > Benjamin Herrenschmidt wrote: > > > On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote: > > > > > > > Btw, to sum up the list of Power Architecture machines with > > > > > PCIE that aim to be a desktop/workstation: Apple iMac G5 > > > > > (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and > > > > > Acube Sam460ex . And the last two, on present evidence (my > > > > > attempts), aren't able to boot up if bootkernel has kms enabled. > > > > > > > > Which radeon card, kernel log please ? > > > > > > See > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html > > > (start of this thread) and > > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html > > > . > > > > Ok, so for the 460EX, I am not surprised things aren't working with > > KMS & DRI2... the 460 is not cache coherent, and this is not handled > > by TTM as far as I can tell. > > > > The second case with no firmware is a bit more surprising, looks like > > something bad happened on the PCI express bus or the kernel tried to > > access something that the card rejected (target abort or PCIe > > equivalent most likely), thus triggering a PLB error . That could be > > investigated a bit more. AFAICT in both cases the immediate problem is the PLB error on first access to VRAM, indicating some kind of problem with ioremap_wc() or generally PCIe device memory access. > Anyway after nearly ten years, due a lack in resources, i'm sadly going > to suspend the CRUX PPC project and my activism pro free > software thus i'm unable to follow these debug. I'll hold on to me > the only YDL Powerstation then from the next weeks i'll can only follow > trying to help in debug [1] on this specific machine. > > [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html For that one, I'd try adding some more debugging output to radeon_get_bios() to find out which method it ends up using to retrieve the ROM contents, and why it doesn't look like it's an ATOM BIOS. Does the same card work in an x86 machine? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm: atomic mode set API
On Wed, Feb 15, 2012 at 4:59 PM, Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
>> +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
>> it for validity */
>> +
>> +struct drm_mode_set_config {
>> + __u64 crtcs;
>> + __u64 crtc_fbs;
>> + __u64 crtc_xpos; /* array of x coords for crtcs */
>> + __u64 crtc_ypos; /* array of y coords for crtcs */
>> + __u32 count_crtcs;
>> +
>> + __u64 plane_sets; /* array of set_plane structs */
>> +
>> + __u32 count_planes;
>> +
>> + __u64 connectors;
>> + __u64 connector_modes;
>> + __u32 count_connectors;
>> +
>> + __u32 flags;
>> +};
>
>
> This appears to be missing some []s, but I think the intent is clear.
>
>
>> #define DRM_MODE_ENCODER_NONE 0
>> #define DRM_MODE_ENCODER_DAC 1
>> #define DRM_MODE_ENCODER_TMDS 2
>>
>> This allows you to bind a bunch of fbs to crtcs with independent
>> positions, as well as set a bunch of planes to specific fbs and
>> layouts. Finally, it lets you change the connector config at the same
>> time, with a flag to simply test a config instead of actually setting
>> it.
>>
>> Any comments? Do we also need to set gamma or other properties as part
>> of this? What about cursors?
>
>
> I guess you might want to set gamma atomically, but I can't imagine it being
> a factor in anyone's "can I do this" logic.
>
> How do you pass in pixel format? Do you just assume the existing fb is
> already in the correct format? That could work but it kind of sucks for
> low-memory environments since you'd need to have enough room to pre-create
> all the fbs. You could still do the "tear everything down first" approach
> to work around that, but then you'd still have the possibility of having
> nothing lit up _and_ not being able to set what was requested, and then
> needing to unwind in userspace.
>
> I'd sort of also want to see audio reflected in this (sigh), since that's
> going to affect the bandwidth math. DP 1.2 makes that even worse.
Just to be devil's advocate here.. audio settings wouldn't change
before/after as a result of modeset change (I guess). And on the
other side, if you are changing some audio setting via alsa, which
makes your previous valid mode configuration invalid, then you are
kinda screwed..
As far as other sort of properties that matter (beyond color format,
which is already an attribute of the fb), the one that immediately
comes to mind is z-order.
BR,
-R
> - ajax
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] drm/exynos: fixed exynos drm driver.
Hi, Dave. I'm so sorry. I will resent it removing new feature. Thanks, Inki Dae > -Original Message- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Tuesday, February 14, 2012 7:54 PM > To: Inki Dae > Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org; > kyungmin.park at samsung.com; sw0312.kim at samsung.com > Subject: Re: [PATCH 00/11] drm/exynos: fixed exynos drm driver. > > On Tue, Feb 14, 2012 at 7:52 AM, Inki Dae wrote: > > this patch set fixes page flip and mode setting issues and also > > hdmi v1.4 support. > > Adding hdmi v1.4 support doesn't seem like a fix to me, it seems like > a new feature. > > This should be in a -next tree, if you want to have fixes in 3.3 then > please resend a -fixes tree > with no new features, and put hdmi1.4 into a -next branch. > > Dave.
linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Sun, 12 Feb 2012 11:00:43 +0100 Michel D?nzer wrote: > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: > > > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE > > videocards and both them are not able to boot with radeonkms. > > Modern PCI-E videocards are not recognized by the old linux framebuffer > > subsystem and they solely can be managed by the new KMS frame buffer > > that doesn't work properly on Power Architecture. > > That's too broad a statement, it works fine on other PowerPC machines > (PowerMacs, some embedded boards). > hi Michel, thanks a lot for your help, i really appreciate it. If you say they were tested on real Power Architecture boards with PCIE videocards thus it is reassuring... and i'm happy that you understand my previus assertion wasn't affected by malevolence or sarcasm. Indeed i'm also a bit troubled 'n frustrated thinking that next release of mesa 'll do extend use of llvm (that doesn't work properly on linuxppc and totally untested on linuxppc64) Btw, to sum up the list of Power Architecture machines with PCIE that aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last two, on present evidence (my attempts), aren't able to boot up if bootkernel has kms enabled. Furthermore the first tree ones can fallback to the legacy OpenFirmware framebuffer and safely get a console. > It looks like there's a problem with accessing the PCIe device memory, > and at this point it's not even 100% clear that this is due to a problem > in the driver, as opposed to e.g. in the platform code. > it could be the right problem and i've CC BenH that has a better global perspective. all the best, --nico -- acrux
[RESEND][PATCH 0/9] drm/exynos: fixed exynos drm driver.
I am resending the patch set removing new features from previous one. this patch set fixes page flip issue and releases some resources and these new features will be sent to drm-next later. this is based on git repository below: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, branch name: drm-fixes commit-id: 6f9f8a61089bb177e53e14ee62f4a65134f3692f and you can refer to our working repository below: http://git.infradead.org/users/kmpark/linux-2.6-samsung, branch name: exynos-drm-fixes Thanks. Eun-Chul Kim (1): drm/exynos: added panel physical size. Inki Dae (4): drm/exynos: added possible_clones setup function. drm/exynos: fixed page flip issue. drm/exynos: removed exynos_drm_fbdev_recreate function. drm/exynos: added postclose to release resource. Joonyoung Shim (2): drm/exynos: changed priority of mixer layers. drm/exynos: removed pageflip_event_list init code when closed. Kamil Debski (1): drm/exynos: exynos_drm.h header file fixes Masanari Iida (1): drm/exynos: Fix typo in exynos_mixer.c drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 -- drivers/gpu/drm/exynos/exynos_drm_core.c |3 + drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 ++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 +++- drivers/gpu/drm/exynos/exynos_mixer.c | 19 --- include/drm/Kbuild|1 + include/drm/exynos_drm.h | 22 +++- 12 files changed, 128 insertions(+), 108 deletions(-) -- 1.7.4.1
[RESEND][PATCH 3/9] drm/exynos: removed pageflip_event_list init code when closed.
From: Joonyoung Shim
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyoungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 35889ca..2ef12aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -141,16 +141,10 @@ static int exynos_drm_unload(struct drm_device *dev)
}
static void exynos_drm_preclose(struct drm_device *dev,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
- struct exynos_drm_private *dev_priv = dev->dev_private;
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
- /*
-* drm framework frees all events at release time,
-* so private event list should be cleared.
-*/
- if (!list_empty(&dev_priv->pageflip_event_list))
- INIT_LIST_HEAD(&dev_priv->pageflip_event_list);
}
static void exynos_drm_lastclose(struct drm_device *dev)
--
1.7.4.1
[RESEND][PATCH 1/9] drm/exynos: Fix typo in exynos_mixer.c
From: Masanari Iida Correct spelling "sucessful" to "successful" in drivers/gpu/drm/exynos/exynos_mixer.c Signed-off-by: Masanari Iida Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ac24cff..33afd0c 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1044,7 +1044,7 @@ static int mixer_remove(struct platform_device *pdev) platform_get_drvdata(pdev); struct mixer_context *ctx = (struct mixer_context *)drm_hdmi_ctx->ctx; - dev_info(dev, "remove sucessful\n"); + dev_info(dev, "remove successful\n"); mixer_resource_poweroff(ctx); mixer_resources_cleanup(ctx); -- 1.7.4.1
[RESEND][PATCH 4/9] drm/exynos: added possible_clones setup function.
basically, all crtcs are possible to clone each other.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c|3 ++
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 +
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 661a035..d08a558 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -193,6 +193,9 @@ int exynos_drm_subdrv_register(struct exynos_drm_subdrv
*subdrv)
return err;
}
+ /* setup possible_clones. */
+ exynos_drm_encoder_setup(drm_dev);
+
/*
* if any specific driver such as fimd or hdmi driver called
* exynos_drm_subdrv_register() later than drm_load(),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2ef12aa..76a111f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -33,6 +33,7 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
+#include "exynos_drm_encoder.h"
#include "exynos_drm_fbdev.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
@@ -99,6 +100,9 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto err_vblank;
+ /* setup possible_clones. */
+ exynos_drm_encoder_setup(dev);
+
/*
* create and configure fb helper and also exynos specific
* fbdev object.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 86b93dd..ef4754f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -195,6 +195,40 @@ static struct drm_encoder_funcs exynos_encoder_funcs = {
.destroy = exynos_drm_encoder_destroy,
};
+static unsigned int exynos_drm_encoder_clones(struct drm_encoder *encoder)
+{
+ struct drm_encoder *clone;
+ struct drm_device *dev = encoder->dev;
+ struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
+ struct exynos_drm_display_ops *display_ops =
+ exynos_encoder->manager->display_ops;
+ unsigned int clone_mask = 0;
+ int cnt = 0;
+
+ list_for_each_entry(clone, &dev->mode_config.encoder_list, head) {
+ switch (display_ops->type) {
+ case EXYNOS_DISPLAY_TYPE_LCD:
+ case EXYNOS_DISPLAY_TYPE_HDMI:
+ clone_mask |= (1 << (cnt++));
+ break;
+ default:
+ continue;
+ }
+ }
+
+ return clone_mask;
+}
+
+void exynos_drm_encoder_setup(struct drm_device *dev)
+{
+ struct drm_encoder *encoder;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
+ encoder->possible_clones = exynos_drm_encoder_clones(encoder);
+}
+
struct drm_encoder *
exynos_drm_encoder_create(struct drm_device *dev,
struct exynos_drm_manager *manager,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index 97b087a..eb7d231 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -30,6 +30,7 @@
struct exynos_drm_manager;
+void exynos_drm_encoder_setup(struct drm_device *dev);
struct drm_encoder *exynos_drm_encoder_create(struct drm_device *dev,
struct exynos_drm_manager *mgr,
unsigned int possible_crtcs);
--
1.7.4.1
[RESEND][PATCH 2/9] drm/exynos: changed priority of mixer layers.
From: Joonyoung Shim Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_mixer.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 33afd0c..4796167 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -779,15 +779,15 @@ static void mixer_win_reset(struct mixer_context *ctx) mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, MXR_STATUS_BURST_MASK); - /* setting default layer priority: layer1 > video > layer0 + /* setting default layer priority: layer1 > layer0 > video * because typical usage scenario would be +* layer1 - OSD * layer0 - framebuffer * video - video overlay -* layer1 - OSD */ - val = MXR_LAYER_CFG_GRP0_VAL(1); - val |= MXR_LAYER_CFG_VP_VAL(2); - val |= MXR_LAYER_CFG_GRP1_VAL(3); + val = MXR_LAYER_CFG_GRP1_VAL(3); + val |= MXR_LAYER_CFG_GRP0_VAL(2); + val |= MXR_LAYER_CFG_VP_VAL(1); mixer_reg_write(res, MXR_LAYER_CFG, val); /* setting background color */ -- 1.7.4.1
[RESEND][PATCH 5/9] drm/exynos: fixed page flip issue.
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |7 ++-
drivers/gpu/drm/exynos/exynos_mixer.c|7 ++-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e3861ac..de81883 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -307,9 +307,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
*/
event->pipe = exynos_crtc->pipe;
- list_add_tail(&event->base.link,
- &dev_priv->pageflip_event_list);
-
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -318,6 +315,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}
+ list_add_tail(&event->base.link,
+ &dev_priv->pageflip_event_list);
+
crtc->fb = fb;
ret = exynos_drm_crtc_update(crtc);
if (ret) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b6a737d..0dbb32b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -604,7 +604,12 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
}
if (is_checked) {
- drm_vblank_put(drm_dev, crtc);
+ /*
+* call drm_vblank_put only in case that drm_vblank_get was
+* called.
+*/
+ if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
+ drm_vblank_put(drm_dev, crtc);
/*
* don't off vblank if vblank_disable_allowed is 1,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4796167..93846e8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -712,7 +712,12 @@ static void mixer_finish_pageflip(struct drm_device
*drm_dev, int crtc)
}
if (is_checked)
- drm_vblank_put(drm_dev, crtc);
+ /*
+* call drm_vblank_put only in case that drm_vblank_get was
+* called.
+*/
+ if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
+ drm_vblank_put(drm_dev, crtc);
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
}
--
1.7.4.1
[RESEND][PATCH 6/9] drm/exynos: removed exynos_drm_fbdev_recreate function.
this function ins't needed anymore.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++---
1 files changed, 4 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index d7ae29d..3508700 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -195,66 +195,6 @@ out:
return ret;
}
-static bool
-exynos_drm_fbdev_is_samefb(struct drm_framebuffer *fb,
- struct drm_fb_helper_surface_size *sizes)
-{
- if (fb->width != sizes->surface_width)
- return false;
- if (fb->height != sizes->surface_height)
- return false;
- if (fb->bits_per_pixel != sizes->surface_bpp)
- return false;
- if (fb->depth != sizes->surface_depth)
- return false;
-
- return true;
-}
-
-static int exynos_drm_fbdev_recreate(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct drm_device *dev = helper->dev;
- struct exynos_drm_fbdev *exynos_fbdev = to_exynos_fbdev(helper);
- struct exynos_drm_gem_obj *exynos_gem_obj;
- struct drm_framebuffer *fb = helper->fb;
- struct drm_mode_fb_cmd2 mode_cmd = { 0 };
- unsigned long size;
-
- DRM_DEBUG_KMS("%s\n", __FILE__);
-
- if (exynos_drm_fbdev_is_samefb(fb, sizes))
- return 0;
-
- mode_cmd.width = sizes->surface_width;
- mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = sizes->surface_width * (sizes->surface_bpp >> 3);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
-
- if (exynos_fbdev->exynos_gem_obj)
- exynos_drm_gem_destroy(exynos_fbdev->exynos_gem_obj);
-
- if (fb->funcs->destroy)
- fb->funcs->destroy(fb);
-
- size = mode_cmd.pitches[0] * mode_cmd.height;
- exynos_gem_obj = exynos_drm_gem_create(dev, size);
- if (IS_ERR(exynos_gem_obj))
- return PTR_ERR(exynos_gem_obj);
-
- exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
-
- helper->fb = exynos_drm_framebuffer_init(dev, &mode_cmd,
- &exynos_gem_obj->base);
- if (IS_ERR_OR_NULL(helper->fb)) {
- DRM_ERROR("failed to create drm framebuffer.\n");
- return PTR_ERR(helper->fb);
- }
-
- return exynos_drm_fbdev_update(helper, helper->fb);
-}
-
static int exynos_drm_fbdev_probe(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
@@ -262,6 +202,10 @@ static int exynos_drm_fbdev_probe(struct drm_fb_helper
*helper,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ /*
+* with !helper->fb, it means that this funcion is called first time
+* and after that, the helper->fb would be used as clone mode.
+*/
if (!helper->fb) {
ret = exynos_drm_fbdev_create(helper, sizes);
if (ret < 0) {
@@ -274,12 +218,6 @@ static int exynos_drm_fbdev_probe(struct drm_fb_helper
*helper,
* because register_framebuffer() should be called.
*/
ret = 1;
- } else {
- ret = exynos_drm_fbdev_recreate(helper, sizes);
- if (ret < 0) {
- DRM_ERROR("failed to reconfigure fbdev\n");
- return ret;
- }
}
return ret;
--
1.7.4.1
[RESEND][PATCH 7/9] drm/exynos: added postclose to release resource.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 76a111f..58820eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -151,6 +151,17 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
+static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (!file->driver_priv)
+ return;
+
+ kfree(file->driver_priv);
+ file->driver_priv = NULL;
+}
+
static void exynos_drm_lastclose(struct drm_device *dev)
{
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -193,6 +204,7 @@ static struct drm_driver exynos_drm_driver = {
.unload = exynos_drm_unload,
.preclose = exynos_drm_preclose,
.lastclose = exynos_drm_lastclose,
+ .postclose = exynos_drm_postclose,
.get_vblank_counter = drm_vblank_count,
.enable_vblank = exynos_drm_crtc_enable_vblank,
.disable_vblank = exynos_drm_crtc_disable_vblank,
--
1.7.4.1
[RESEND][PATCH 9/9] drm/exynos: exynos_drm.h header file fixes
From: Kamil Debski
First of all #ifdef __KERNEL__ was added to exynos_drm.h to
mark the part that should be left out of userspace.
Secondly exynos_drm.h was added to include/drm/Kbuild, so it
will be included when doing make headers_install.
Signed-off-by: Kamil Debski
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
include/drm/Kbuild |1 +
include/drm/exynos_drm.h |5 -
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/drm/Kbuild b/include/drm/Kbuild
index a5c0e10..1e38a19 100644
--- a/include/drm/Kbuild
+++ b/include/drm/Kbuild
@@ -2,6 +2,7 @@ header-y += drm.h
header-y += drm_fourcc.h
header-y += drm_mode.h
header-y += drm_sarea.h
+header-y += exynos_drm.h
header-y += i810_drm.h
header-y += i915_drm.h
header-y += mga_drm.h
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index 308575e..1ed3aae 100644
--- a/include/drm/exynos_drm.h
+++ b/include/drm/exynos_drm.h
@@ -97,6 +97,8 @@ struct drm_exynos_plane_set_zpos {
#define DRM_IOCTL_EXYNOS_PLANE_SET_ZPOSDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_PLANE_SET_ZPOS, struct drm_exynos_plane_set_zpos)
+#ifdef __KERNEL__
+
/**
* A structure for lcd panel information.
*
@@ -152,4 +154,5 @@ struct exynos_drm_hdmi_pdata {
unsigned intbpp;
};
-#endif
+#endif /* __KERNEL__ */
+#endif /* _EXYNOS_DRM_H_ */
--
1.7.4.1
linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Wed, 2012-02-15 at 03:23 +0100, acrux wrote: > On Sun, 12 Feb 2012 11:00:43 +0100 > Michel D?nzer wrote: > > > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: > > > > > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE > > > videocards and both them are not able to boot with radeonkms. > > > Modern PCI-E videocards are not recognized by the old linux framebuffer > > > subsystem and they solely can be managed by the new KMS frame buffer > > > that doesn't work properly on Power Architecture. > > > > That's too broad a statement, it works fine on other PowerPC machines > > (PowerMacs, some embedded boards). > > > > hi Michel, > thanks a lot for your help, i really appreciate it. > > If you say they were tested on real Power Architecture boards with PCIE > videocards thus it is reassuring... and i'm happy that you understand > my previus assertion wasn't affected by malevolence or sarcasm. Indeed > i'm also a bit troubled 'n frustrated thinking that next release of > mesa 'll do extend use of llvm (that doesn't work properly on linuxppc > and totally untested on linuxppc64) > > Btw, to sum up the list of Power Architecture machines with PCIE that > aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac > Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last > two, on present evidence (my attempts), aren't able to boot up if > bootkernel has kms enabled. Which radeon card, kernel log please ? I've successfully booted various reasonably modern radeons on these. I've also used gnome3 with GL acceleration etc... on some of these. Granted that was a few month ago so it's possible that something regressed. > Furthermore the first tree ones can > fallback to the legacy OpenFirmware framebuffer and safely get a > console. > > > It looks like there's a problem with accessing the PCIe device memory, > > and at this point it's not even 100% clear that this is due to a problem > > in the driver, as opposed to e.g. in the platform code. > > > > it could be the right problem and i've CC BenH that has a better global > perspective. Can you give me more data about the problem please ? It could be a recent regression or some setup problem. Also I've noticed on the PowerStation some issues where heavy DMA use by a video card will eventually lock up the system. From what I can tell this is an issue with the northbridge, though a Quad G5 with the same bridge (tho not quite the same revision) doesn't show the problem. Could be a configuration issue. Cheers, Ben.
[Bug 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #5 from Tom Stellard 2012-02-14 19:38:21 PST --- I'm guessing that this is a bug in the vertex shader. Does running with RADEON_NO_TCL=1 fix it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably
https://bugs.freedesktop.org/show_bug.cgi?id=27184 --- Comment #22 from tomi.orava at ncircle.nullnet.fi 2012-02-14 22:49:18 PST --- (In reply to comment #20) > Does kernel 3.3rc3 or newer work any better? I tested with the latest git version from yesterday evening (13d261932bbfff7f45f288c5c8cce43177cccd3b) and unfortunately none of the "xset dpms force off, standby or suspend" worked any differently than before. The BenQ monitor just decides to stay in power saving mode and the only way to wake it up is to power cycle the monitor. There really is nothing wrong with the hardware as the fglrx is able to use dpms power management just fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie
On Mit, 2012-02-15 at 13:50 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2012-02-15 at 03:23 +0100, acrux wrote: > > On Sun, 12 Feb 2012 11:00:43 +0100 > > Michel D?nzer wrote: > > > > > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: > > > > > > > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE > > > > videocards and both them are not able to boot with radeonkms. > > > > Modern PCI-E videocards are not recognized by the old linux framebuffer > > > > subsystem and they solely can be managed by the new KMS frame buffer > > > > that doesn't work properly on Power Architecture. > > > > > > That's too broad a statement, it works fine on other PowerPC machines > > > (PowerMacs, some embedded boards). > > > > > > > hi Michel, > > thanks a lot for your help, i really appreciate it. > > > > If you say they were tested on real Power Architecture boards with PCIE > > videocards thus it is reassuring... and i'm happy that you understand > > my previus assertion wasn't affected by malevolence or sarcasm. Indeed > > i'm also a bit troubled 'n frustrated thinking that next release of > > mesa 'll do extend use of llvm (that doesn't work properly on linuxppc > > and totally untested on linuxppc64) I don't see any reason to worry yet. LLVM is still completely optional in Mesa 8.0, and if you're worrying about the upcoming use of LLVM in the drivers for newer Radeons, I don't think the current problems in the LLVM usage of llvmpipe/draw on PPC will necessarily translate to that, as I suspect at least some of the issues are specific to the LLVM PPC backend, which won't be used in that case. > > Btw, to sum up the list of Power Architecture machines with PCIE that > > aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac > > Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last > > two, on present evidence (my attempts), aren't able to boot up if > > bootkernel has kms enabled. > > Which radeon card, kernel log please ? See http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html (start of this thread) and http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html . -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #6 from Pavel Ondra?ka 2012-02-15 00:12:15 UTC --- (In reply to comment #5) > I'm guessing that this is a bug in the vertex shader. Does running with > RADEON_NO_TCL=1 fix it? Yes, the test pass with RADEON_NO_TCL=1 set. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
Hi, Status update about the problem 'Occasionally "GPU lockup" after resuming from suspend.' First, this could happen when system returns from a STR(suspend to ram) or STD(suspend to disk, aka hibernation). When returns from STD, the initialization process is most similar to the normal boot. The standby is ok, which is similar to STR, except that standby will not shutdown the power of CPU,GPU etc. We've dumped and compared the registers, and found something: CP_STAT normal value: 0x value when this problem occurred: 0x802100C1 or 0x802300C1 CP_ME_CNTL normal value: 0x00FF value when this problem occurred: always 0x20FF in our test Questions: According to the manual, CP_STAT = 0x802100C1 means CSF_RING_BUSY(bit 0): The Ring fetcher still has command buffer data to fetch, or the PFP still has data left to process from the reorder queue. CSF_BUSY(bit 6): The input FIFOs have command buffers to fetch, or one or more of the fetchers are busy, or the arbiter has a request to send to the MIU. MIU_RDREQ_BUSY(bit 7): The read path logic inside the MIU is busy. MEQ_BUSY(bit 16): The PFP-to-ME queue has valid data in it. SURFACE_SYNC_BUSY(bit 21): The Surface Sync unit is busy. CP_BUSY(bit 31): Any block in the CP is busy. What does it suggest? What does it mean if bit 29 of CP_ME_CNTL is set? BTW, how does the dummy page work in GART? Regards, -- Chen Jie ? 2011?12?7? ??10:21?Alex Deucher ??? > 2011/12/7 : >> When "MC timeout" happens at GPU reset, we found the 12th and 13th >> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these >> two bits are like this: >> #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1) >> #define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1) >> >> Could you please tell me what does they mean? And if possible, > > They refer to sub-blocks in the memory controller. I don't really > know off hand what the name mean. > >> I want to know the functionalities of these 5 registers in detail: >> #define R_000E60_SRBM_SOFT_RESET 0x0E60 >> #define R_000E50_SRBM_STATUS 0x0E50 >> #define R_008020_GRBM_SOFT_RESET0x8020 >> #define R_008010_GRBM_STATUS0x8010 >> #define R_008014_GRBM_STATUS2 0x8014 >> >> A bit more info: If I reset the MC after resetting CP (this is what >> Linux-2.6.34 does, but removed since 2.6.35), then "MC timeout" will >> disappear, but there is still "ring test failed". > > The bits are defined in r600d.h. As to the acronyms: > BIF - Bus InterFace > CG - clocks > DC - Display Controller > GRBM - Graphics block (3D engine) > HDP - Host Data Path (CPU access to vram via the PCI BAR) > IH, RLC - Interrupt controller > MC - Memory controller > ROM - ROM > SEM - semaphore controller > > When you reset the MC, you will probably have to reset just about > everything else since most blocks depend on the MC for access to > memory. If you do reset the MC, you should do it at prior to calling > asic_init so you make sure all the hw gets re-initialized properly. > Additionally, you should probably reset the GRBM either via > SRBM_SOFT_RESET or the individual sub-blocks via GRBM_SOFT_RESET. > > Alex > >> >> Huacai Chen >> >>> 2011/11/8 : And, I want to know something: 1, Does GPU use MC to access GTT? >>> >>> Yes. All GPU clients (display, 3D, etc.) go through the MC to access >>> memory (vram or gart). >>> 2, What can cause MC timeout? >>> >>> Lots of things. Some GPU client still active, some GPU client hung or >>> not properly initialized. >>> >>> Alex >>> > Hi, > > Some status update. > ? 2011?9?29? ??5:17?Chen Jie ??? >> Hi, >> Add more information. >> We got occasionally "GPU lockup" after resuming from suspend(on mipsel >> platform with a mips64 compatible CPU and rs780e, the kernel is >> 3.1.0-rc8 >> 64bit). Related kernel message: >> /* return from STR */ >> [ 156.152343] radeon :01:05.0: WB enabled >> [ 156.187500] [drm] ring test succeeded in 0 usecs >> [ 156.187500] [drm] ib test succeeded in 0 usecs >> [ 156.398437] ata2: SATA link down (SStatus 0 SControl 300) >> [ 156.398437] ata3: SATA link down (SStatus 0 SControl 300) >> [ 156.398437] ata4: SATA link down (SStatus 0 SControl 300) >> [ 156.578125] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> [ 156.597656] ata1.00: configured for UDMA/133 >> [ 156.613281] usb 1-5: reset high speed USB device number 4 using >> ehci_hcd >> [ 157.027343] usb 3-2: reset low speed USB device number 2 using >> ohci_hcd >> [ 157.609375] usb 3-3: reset low speed USB device number 3 using >> ohci_hcd >> [ 157.683593] r8169 :02:00.0: eth0: link up >> [ 165.621093] PM: resume
[PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> gmbus_xfer with a single message (particularly a single message write) would
> set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> No Index, Stop cycle. This would not start single message i2c transactions.
>
> Also, gmbus_xfer done: will disable the interface without checking if
> it is idle. In the case of writes, there will be no wait on status or delay
> to ensure the write starts and completes before the interface is turned off.
>
> Fixed the former issue by using the same cycle selection as used in the
> I2C_M_RD for the write case.
> GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
>
> Signed-off-by: Benson Leung
Can you clarify the commit message a bit and say that the first hunk is
just for optics and the issue is only with the write path (because the
read path is correct already). Silly me is just to easily confused ;-)
Btw, I've reworked the gmbus -> gpio bit-banging fallback code a bit and
if that passes review and all I'll reenable gmbus by default again. See
http://cgit.freedesktop.org/~danvet/drm/log/?h=gmbus
Yours, Daniel
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d30..64bb9cd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -249,7 +249,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> if (msgs[i].flags & I2C_M_RD) {
> I915_WRITE(GMBUS1 + reg_offset,
> -GMBUS_CYCLE_WAIT | (i + 1 == num ?
> GMBUS_CYCLE_STOP : 0) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
> @@ -278,7 +279,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> I915_WRITE(GMBUS3 + reg_offset, val);
> I915_WRITE(GMBUS1 + reg_offset,
> -(i + 1 == num ? GMBUS_CYCLE_STOP :
> GMBUS_CYCLE_WAIT) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -317,9 +319,12 @@ clear_err:
> I915_WRITE(GMBUS1 + reg_offset, 0);
>
> done:
> - /* Mark the GMBUS interface as disabled. We will re-enable it at the
> - * start of the next xfer, till then let it sleep.
> + /* Mark the GMBUS interface as disabled after waiting for idle.
> + * We will re-enable it at the start of the next xfer,
> + * till then let it sleep.
>*/
> + if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
> + DRM_INFO("GMBUS timed out waiting for idle\n");
> I915_WRITE(GMBUS0 + reg_offset, 0);
> return i;
>
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
On Wed, Feb 15, 2012 at 05:32:35PM +0800, Chen Jie wrote: > Hi, > > Status update about the problem 'Occasionally "GPU lockup" after > resuming from suspend.' > > First, this could happen when system returns from a STR(suspend to > ram) or STD(suspend to disk, aka hibernation). > When returns from STD, the initialization process is most similar to > the normal boot. > The standby is ok, which is similar to STR, except that standby will > not shutdown the power of CPU,GPU etc. > > We've dumped and compared the registers, and found something: > CP_STAT > normal value: 0x > value when this problem occurred: 0x802100C1 or 0x802300C1 > > CP_ME_CNTL > normal value: 0x00FF > value when this problem occurred: always 0x20FF in our test > > Questions: > According to the manual, > CP_STAT = 0x802100C1 means > CSF_RING_BUSY(bit 0): > The Ring fetcher still has command buffer data to fetch, or the > PFP > still has data left to process from the reorder queue. > CSF_BUSY(bit 6): > The input FIFOs have command buffers to fetch, or one or more > of the > fetchers are busy, or the arbiter has a request to send to the MIU. > MIU_RDREQ_BUSY(bit 7): > The read path logic inside the MIU is busy. > MEQ_BUSY(bit 16): > The PFP-to-ME queue has valid data in it. > SURFACE_SYNC_BUSY(bit 21): > The Surface Sync unit is busy. > CP_BUSY(bit 31): > Any block in the CP is busy. > What does it suggest? > > What does it mean if bit 29 of CP_ME_CNTL is set? > > BTW, how does the dummy page work in GART? > > > Regards, > -- Chen Jie To me it looks like the CP is trying to fetch memory but the GPU memory controller fail to fullfill cp request. Did you check the PCI configuration before & after (when things don't work) My best guest is PCI bus mastering is no properly working or the PCIE GPU gart table as wrong data. Maybe one need to drop bus master and reenable bus master to work around some bug... Cheers, Jerome
[PATCH] drm/edid: Add support for extension blocks beyond the first
Hi Ville,
On Monday 13 February 2012 07:24:23 pm Ville Syrj?l? wrote:
> On Wed, Dec 07, 2011 at 03:11:07PM +0100, Jean Delvare wrote:
> > When 2 or more EDID extension blocks are present, segment must be
> > selected prior to reading the extended EDID block over the DDC
> > channel. Add support for this.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Adam Jackson
> > ---
> > This needs testing by someone with access to such a display.
> >
> > drivers/gpu/drm/drm_edid.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > --- linux-3.2-rc3.orig/drivers/gpu/drm/drm_edid.c 2011-11-09
> > 15:53:31.0 +0100 +++
> > linux-3.2-rc3/drivers/gpu/drm/drm_edid.c2011-12-03
> > 10:12:47.0 +0100 @@ -242,7 +242,8 @@ static int
> > drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char
> > *buf, int block, int len)
> > {
> > - unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned char start = (block & 0x01) * EDID_LENGTH;
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> > the @@ -254,6 +255,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> > do {
> > struct i2c_msg msgs[] = {
> > {
> > + .addr = DDC_SEGMENT_ADDR,
> > + .flags = 0,
> > + .len= 1,
> > + .buf= &segment,
> > + }, {
> > .addr = DDC_ADDR,
> > .flags = 0,
> > .len= 1,
> > @@ -265,7 +271,18 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > +
> > + /* Don't write segment if it is 0, for compatibility */
> > + if (segment) {
> > + ret = i2c_transfer(adapter, msgs, 3);
> > + /* The E-DDC specification says that the first ack is
> > +* optional, so retry in ignore-nak mode if we get no
> > +* ack at first.
> > +*/
> > + if (ret == -ENXIO)
> > + msgs[0].flags |= I2C_M_IGNORE_NAK;
>
> This seems a bit wrong to me. The spec says that the ack for the
> segment address is "don't care", but for the segment pointer the ack
> is required (when segment != 0).
Correct.
> With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from
> a non E-DDC display, if we try to read segment != 0 from it. Of
> course we shouldn't do that unless the display lied to us about what
> extension blocks it provides.
Still correct.
> So I'm not sure if it would be better to trust that the display never
> lies about the extension blocks, or if we should just assume all
> E-DDC displays ack both segment addr and pointer.
I went for the former, as should be obvious from my proposed
implementation. Whether this is the best decision is impossible to tell
until the code is tested in the fields.
> The no-ack feature
> seems to there for backwards compatibility, for cases where the host
> always sends the segment addr/pointer even when reading segment 0
> (which your code doesn't do).
I agree.
> To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be
> split into two flags (one for addr, other for data).
This is correct, but this seemed a little overkill. I would only
implement this in i2c-core if it turns out to be absolutely necessary to
properly handle one real-world display.
I would suggest that my patch gets applied as is for now, and it can be
adjusted later if needed. It is certainly better than the current code
anyway.
Thanks for the review,
--
Jean Delvare
Suse L3
[PATCH] Revert "drivers/gpu/drm/i915/intel_overlay.c needs seq_file.h"
This reverts commit e167976ee7f5fe4b80f7e8f55e087f6c67cf9562, Since this was already fixed in commit 3bd3c9329973a93fa3ef5e9840f2fd6fa2889e3f some days before this commit cause seq_file.h to be included twice. Signed-off-by: Danny Kukawka --- drivers/gpu/drm/i915/intel_overlay.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index cdf17d4..134c42a 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -25,8 +25,6 @@ * * Derived from Xorg ddx, xf86-video-intel, src/i830_video.c */ - -#include #include "drmP.h" #include "drm.h" #include "i915_drm.h" -- 1.7.8.3
[PATCH] drm/radeon/kms/atom: bios scratch reg handling updates
If the atombios bits for dpms state are still used from dce4, we would miss explicitly the DFP6 device in radeon_atombios_encoder_dpms_scratch_regs, wouldn't we? -- Sylvain (or sylware on phoronix.com)
[BUG] Intel HD Graphic QM57 chipset: Dell U3011 monitor turns to power saving mode
* Mathieu Desnoyers (mathieu.desnoyers at efficios.com) wrote: > Hi Keith, > > * Keith Packard (keithp at keithp.com) wrote: > > On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers > efficios.com> wrote: > > > > > Dell U3011 monitor turns to power saving mode when resolution set to 2560 > > > x 1600 > > > (intermittent) > > > > > > Reproduced with: > > > Linux 2.6.38-1-amd64 (Debian kernel) > > > Linux 3.1.0-1-amd64 (Debian kernel) > > > Linux 3.2.0-1-amd64 (Debian kernel) > > > > > > The computer is a Lenovo X201 Tablet (Intel QM57 chipset), on a X200 > > > docking station. The docking station uses a DisplayPort cable to connect > > > to the monitor. I tried upgrading my Bios from 1.34/1.13 to 1.38/1.14 > > > (latest), which did not fix the problem. I cannot use anything else > > > than DisplayPort in this case to connect the monitor at 2560 x 1600, > > > because this resolution requires either the bandwidth provided by a > > > dual-link DVI (which I cannot connect in my docking station), or > > > DisplayPort. > > > > I use this same monitor, and have run it with an X200 in the past. > > > > Can you capture a dmesg output with the kernel parameter drm.debug=0xe > > set? That will let us see the DP link training adventure and see what's > > broken. If you can, separate traces of working and non-working tries > > would be nice. > > > > And, of course, trying 3.3-rc1 would be helpful as that's what any > > test patches would be developed on top of. > > I've compiled and launched a 3.3-rc1 kernel for the following tests. The > dmesg log follows. > > FWIW, when I get the screen to run, if I launch this 1080p video with > either mplayer or vlc (http://www.bigbuckbunny.org/index.php/download/, > 1920x1080, mp4 format) in full screen, I get an horizontal line of blur > at about 7/8 of the screen (from the top) when there is a lot of > movement in the movie. This looks like a vertical refresh sync issue > and/or too small buffers for double(/triple)-buffering. I'm aware that > this is a separate issue, but it might help the current investigation. > The xrandr -q --verbose gives "+HSync -VSync" for the monitor, even > though its EDID (taken with get-edid/parse-edid) specifies "Flags > "-HSync" "+VSync"". So hsync and vsync +/- seems to be mixed up. Another piece of information on this issue: I tried the monitor with an Apple PowerBook running MacOS X, and the monitor works flawlessly (monitor always brought up, and the same video works without glitch with vlc). I also simplified my routine that successfully bring the monitor into a working state: running 5 to 20 times the following script ends up doing the trick: xrandr --output DP1 --off sleep 1 xrandr --output DP1 --mode 2560x1600 Please let me know if I can provide more information on the issue than the detailed logs (success/fail) below. I would also like to know if there is a knob somewhere in the Intel driver I could play with to provide more time for the screen to send its EDID information. Based on this info: http://www.intel.com/support/graphics/sb/CS-028366.htm, Intel provide a modified Windows driver that might target this kind of issue, and I assume they possibly let more time than the spec requires for the screen to send EDID info. Thanks, Mathieu > > > * 3.3-rc1 up until Xorg is running, screen does not work > > ] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:12:VGA-1] > [ 14.440212] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug > adpa=0xf4, result 0 > [ 14.440216] [drm:intel_crt_detect], CRT not detected via hotplug > [ 14.440220] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:12:VGA-1] disconnected > [ 14.440229] [drm:drm_mode_getconnector], [CONNECTOR:15:?] > [ 14.440234] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:15:HDMI-A-1] > [ 14.451677] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:15:HDMI-A-1] disconnected > [ 14.451686] [drm:drm_mode_getconnector], [CONNECTOR:15:?] > [ 14.451691] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:15:HDMI-A-1] > [ 14.463035] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:15:HDMI-A-1] disconnected > [ 14.463048] [drm:drm_mode_getconnector], [CONNECTOR:18:?] > [ 14.463050] [drm:drm_helper_probe_single_connector_modes], > [CONNECTOR:18:DP-1] > [ 14.463365] [drm:intel_dp_detect], DPCD: 110a840101000100 > [ 14.464389] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.491348] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.518291] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.518294] [drm:drm_detect_monitor_audio], Monitor has basic audio support > [ 14.519321] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.546261] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.573232] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return 2 > [ 14.573265] [drm:drm_edid_to_eld], ELD monitor DELL U3011 > [ 14.573266] [drm:drm_edid_to
[PATCH 4/5] drm/vgem: getparam ioctl
On 2/8/12 6:19 PM, Ben Widawsky wrote: > Similar to i915, it's nice to be able to query this device uniquely and > get some info > > Signed-off-by: Ben Widawsky So, this is actually not especially useful as written. You'd like to be able to use this to find the vgem device node, but since it's a device-specific ioctl it collides with whatever happens to be device-specific ioctl number 2 on whatever device you've opened. On i915, that's I915_FLIP, and you promptly oops the machine. Comedy. Gold. Which is fine, really. The way I was anticipating finding the vgem node was to just scrape the device node name out of /sys/bus/platform/devices/vgem/cardN, because why do anything O(n) when you could do it O(1). I guess that doesn't help OSes that aren't Linux, and I guess if pressed to care about that I'd say hang it off drm_getcap. - ajax
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #4 from lsching17 at gmail.com 2012-02-15 14:14:36 UTC --- The patch partially work. glxgears now work ok, but vmware (with 3d acceleration) cause Xorg crashed. (file "kern2.log" attached) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45880] Xorg crash with ColorTiling2D patch (r600g)
https://bugs.freedesktop.org/show_bug.cgi?id=45880 --- Comment #5 from lsching17 at gmail.com 2012-02-15 14:15:18 UTC --- Created attachment 57121 --> https://bugs.freedesktop.org/attachment.cgi?id=57121 crash log after fix applied -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: atomic mode set API
Many of us really want (and need) a way to set the whole display
configuration atomically, as well as test a global config.
In talking with Rob and Alex here at ELC a bit, I think this may be
enough:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 2a2acda..2864b02 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -157,6 +157,26 @@ struct drm_mode_get_plane_res {
__u32 count_planes;
};
+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
for validity */
+
+struct drm_mode_set_config {
+ __u64 crtcs;
+ __u64 crtc_fbs;
+ __u64 crtc_xpos; /* array of x coords for crtcs */
+ __u64 crtc_ypos; /* array of y coords for crtcs */
+ __u32 count_crtcs;
+
+ __u64 plane_sets; /* array of set_plane structs */
+
+ __u32 count_planes;
+
+ __u64 connectors;
+ __u64 connector_modes;
+ __u32 count_connectors;
+
+ __u32 flags;
+};
+
#define DRM_MODE_ENCODER_NONE 0
#define DRM_MODE_ENCODER_DAC 1
#define DRM_MODE_ENCODER_TMDS 2
This allows you to bind a bunch of fbs to crtcs with independent
positions, as well as set a bunch of planes to specific fbs and
layouts. Finally, it lets you change the connector config at the same
time, with a flag to simply test a config instead of actually setting
it.
Any comments? Do we also need to set gamma or other properties as part
of this? What about cursors?
Thanks,
Jesse
[RFC] drm: atomic mode set API
On 2/15/12 5:42 PM, Jesse Barnes wrote:
> +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
> for validity */
> +
> +struct drm_mode_set_config {
> + __u64 crtcs;
> + __u64 crtc_fbs;
> + __u64 crtc_xpos; /* array of x coords for crtcs */
> + __u64 crtc_ypos; /* array of y coords for crtcs */
> + __u32 count_crtcs;
> +
> + __u64 plane_sets; /* array of set_plane structs */
> +
> + __u32 count_planes;
> +
> + __u64 connectors;
> + __u64 connector_modes;
> + __u32 count_connectors;
> +
> + __u32 flags;
> +};
This appears to be missing some []s, but I think the intent is clear.
> #define DRM_MODE_ENCODER_NONE 0
> #define DRM_MODE_ENCODER_DAC1
> #define DRM_MODE_ENCODER_TMDS 2
>
> This allows you to bind a bunch of fbs to crtcs with independent
> positions, as well as set a bunch of planes to specific fbs and
> layouts. Finally, it lets you change the connector config at the same
> time, with a flag to simply test a config instead of actually setting
> it.
>
> Any comments? Do we also need to set gamma or other properties as part
> of this? What about cursors?
I guess you might want to set gamma atomically, but I can't imagine it
being a factor in anyone's "can I do this" logic.
How do you pass in pixel format? Do you just assume the existing fb is
already in the correct format? That could work but it kind of sucks for
low-memory environments since you'd need to have enough room to
pre-create all the fbs. You could still do the "tear everything down
first" approach to work around that, but then you'd still have the
possibility of having nothing lit up _and_ not being able to set what
was requested, and then needing to unwind in userspace.
I'd sort of also want to see audio reflected in this (sigh), since
that's going to affect the bandwidth math. DP 1.2 makes that even worse.
- ajax
[Patches][nouveau/kms]: Precise Vblank and pageflip timestamping
Hi, these are two patches against the nouveau kms driver. The first patch makes sure that pageflip completion events get their vblank count and timestamp from the drm. The second patch from Lucas Stach, here included with his permission, makes sure that the timestamps of vblanks are calculated with high precision and robustness. Both patches together make sure that all timestamps returned by the kms driver are consistent with each other and conform to the OML_sync_control specification. With Lucas permission i've already integrated my feedback from reviewing his patch into the patch. The patches have been applied against Linux 3.2 and tested with special measurement equipment on a GeForce 7800, a GeForce 8800 and some QuadroFX 570 and 370. The timestamps are accurate to less than 30 usecs deviation from the ground truth measured with the external equipment. I'll send out a couple of nouveau ddx patches that make use of these timestamps. It would be great if these could be reviewed and possibly included for the Linux 3.4 merge window. Thanks, -mario
[PATCH 1/2] drm/nouveau: Use drm_vblank_count_and_time() for pageflip completion events.
Emit kms pageflip completion events with proper vblank count
and timestamp for the vblank interval in which the pageflip
completed. This makes the timestamps and counts consistent with
what the OML_sync_control spec defines.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/nouveau/nouveau_display.c | 29 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |1 +
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index b12fd2c..5bd392f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -295,7 +295,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
*s = (struct nouveau_page_flip_state)
{ { }, event, nouveau_crtc(crtc)->index,
fb->bits_per_pixel, fb->pitch, crtc->x, crtc->y,
- new_bo->bo.offset };
+ new_bo->bo.offset, crtc->framedur_ns };
/* Choose the channel the flip will be handled in */
chan = nouveau_fence_channel(new_bo->bo.sync_obj);
@@ -338,6 +338,9 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
struct drm_device *dev = chan->dev;
struct nouveau_page_flip_state *s;
unsigned long flags;
+ struct timeval tnow, tvbl;
+
+ do_gettimeofday(&tnow);
spin_lock_irqsave(&dev->event_lock, flags);
@@ -351,12 +354,26 @@ nouveau_finish_page_flip(struct nouveau_channel *chan,
struct nouveau_page_flip_state, head);
if (s->event) {
struct drm_pending_vblank_event *e = s->event;
- struct timeval now;
- do_gettimeofday(&now);
- e->event.sequence = 0;
- e->event.tv_sec = now.tv_sec;
- e->event.tv_usec = now.tv_usec;
+ e->event.sequence = drm_vblank_count_and_time(dev, s->crtc,
&tvbl);
+
+ /* Called before vblank count and timestamp have
+* been updated for the vblank interval of flip
+* completion? If so, need to increment vblank count and
+* add one videorefresh duration to returned timestamp
+* to account for this. We assume this happened if we
+* get called over 0.9 frame durations after the last
+* timestamped vblank.
+*/
+ if (10 * (timeval_to_ns(&tnow) - timeval_to_ns(&tvbl)) >
+9 * s->framedur_ns) {
+ e->event.sequence++;
+ tvbl = ns_to_timeval(timeval_to_ns(&tvbl) +
+ s->framedur_ns);
+ }
+
+ e->event.tv_sec = tvbl.tv_sec;
+ e->event.tv_usec = tvbl.tv_usec;
list_add_tail(&e->base.link, &e->base.file_priv->event_list);
wake_up_interruptible(&e->base.file_priv->event_wait);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 4c0be3a..f489c22 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -202,6 +202,7 @@ struct nouveau_page_flip_state {
struct drm_pending_vblank_event *event;
int crtc, bpp, pitch, x, y;
uint64_t offset;
+ s64 framedur_ns;
};
enum nouveau_channel_mutex_class {
--
1.7.5.4
[PATCH 2/2] nouveau: implement precise vblank timestamping
From: Lucas Stach
This patch implements the drivers hooks needed for precise vblank
timestamping. This is a complementary patch to Mario Kleiner's
patches to improve swap scheduling. With the complete
patchset applied nouveau will be able to provide correct and
precise pageflip timestamps (compliant to OML_sync_control spec)
Kudos to Mario for his many helpful comments and testing.
Signed-off-by: Lucas Stach
Reviewed-by: Mario Kleiner
Tested-by: Mario Kleiner
---
drivers/gpu/drm/nouveau/nouveau_display.c | 124 +
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +
drivers/gpu/drm/nouveau/nouveau_drv.h |5 +
drivers/gpu/drm/nouveau/nouveau_reg.h |9 ++-
drivers/gpu/drm/nouveau/nv50_crtc.c | 19 +
drivers/gpu/drm/nouveau/nvreg.h |1 +
6 files changed, 159 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 5bd392f..7fdd6a4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -431,3 +431,127 @@ nouveau_display_dumb_map_offset(struct drm_file
*file_priv,
return -ENOENT;
}
+
+int
+nouveau_get_scanoutpos(struct drm_device *dev, int crtc, int *vpos, int *hpos)
+{
+ struct drm_nouveau_private *dev_priv = dev->dev_private;
+ int vline, hline, ret = 0;
+ u32 vbias, hbias, reg, vbl_start, vbl_end;
+ struct drm_crtc *drmcrtc;
+
+ if (crtc < 0 || crtc >= dev->num_crtcs) {
+ DRM_ERROR("Invalid crtc %d\n", crtc);
+ return -EINVAL;
+ }
+
+ list_for_each_entry(drmcrtc, &dev->mode_config.crtc_list, head) {
+ if(nouveau_crtc(drmcrtc)->index == crtc)
+ /* stop if we have found crtc with matching index */
+ break;
+ }
+
+ if(dev_priv->card_type >= NV_50) {
+ /* get vsync and hsync area */
+ reg = nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ SYNC_START_TO_BLANK_END));
+ vbias = (reg >> 16) & 0x;
+ hbias = reg & 0x;
+
+ /* get vertical display size including bias as vbl_start
+* and vtotal as vbl_end */
+ vbl_start = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ VBL_START)) >> 16) & 0x;
+ vbl_end = (nv_rd32(dev, NV50_PDISPLAY_CRTC_P(crtc,
+ DISPLAY_TOTAL)) >> 16) & 0x;
+
+ /* get current scanout position from PDISPLAY */
+ vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
+
+ /*
+* vline == 0 could be invalid:
+* Some gpu's get stuck on that value inside vblank. Try again
+* after one scanline duration, if it still reads 0 give up.
+*/
+ if (vline == 0) {
+ ndelay(drmcrtc->linedur_ns & 0x);
+ vline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_VERT(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_VERT_VLINE__MASK;
+ }
+
+ hline = nv_rd32(dev, NV50_PDISPLAY_CRTC_STAT_HORZ(crtc))
+ & NV50_PDISPLAY_CRTC_STAT_HORZ_HLINE__MASK;
+
+ if((vline > 0) && (vline < vbl_end))
+ ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
+
+ if((vline >= vbl_start) || (vline < vbias)) {
+ /* we are in vblank so do a neg countdown */
+ ret |= DRM_SCANOUTPOS_INVBL;
+ vline -= (vline < vbias) ? vbias : (vbl_end + vbias);
+ hline -= hbias;
+ } else {
+ /* apply corrective offset */
+ vline -= vbias;
+ hline -= hbias;
+ }
+ } else {
+ /* get vsync area from PRAMDAC */
+ vbl_start = NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VDISPLAY_END)
+ & 0x;
+ vbl_end = (NVReadRAMDAC(dev, crtc, NV_PRAMDAC_FP_VTOTAL)
+ & 0x) + 1;
+
+ /* get current scanout position from PCRTC */
+ vline = nv_rd32(dev, NV_PCRTC_STAT(crtc)) & 0x;
+
+ /*
+* vline == 0 could be invalid:
+* Some gpu's get stuck on that value inside vblank. Try again
+* after one scanline duration, if it still reads 0 give up.
+*/
+ if (vline == 0) {
+ ndelay(drmcrtc->linedur_ns & 0x);
+ vline = nv_rd32(dev, NV_PCRTC_STAT(crtc)) & 0x;
+ }
+
+ if(vline > 0)
+
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #16 from Alexandre Demers 2012-02-15 15:54:48 PST --- With yesterday's gits (mesa, drum, ddx), Gnome-shell is now freezing right after I log in. From time to time, I receive GPU hanged for X msec and then it resets. I'll try to bisect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] drm: atomic mode set API
On Wed, 15 Feb 2012 17:59:45 -0500
Adam Jackson wrote:
> On 2/15/12 5:42 PM, Jesse Barnes wrote:
>
> > +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > it for validity */
> > +
> > +struct drm_mode_set_config {
> > + __u64 crtcs;
> > + __u64 crtc_fbs;
> > + __u64 crtc_xpos; /* array of x coords for crtcs */
> > + __u64 crtc_ypos; /* array of y coords for crtcs */
> > + __u32 count_crtcs;
> > +
> > + __u64 plane_sets; /* array of set_plane structs */
> > +
> > + __u32 count_planes;
> > +
> > + __u64 connectors;
> > + __u64 connector_modes;
> > + __u32 count_connectors;
> > +
> > + __u32 flags;
> > +};
>
> This appears to be missing some []s, but I think the intent is clear.
Yeah, all the u64s are arrays.
> > #define DRM_MODE_ENCODER_NONE 0
> > #define DRM_MODE_ENCODER_DAC 1
> > #define DRM_MODE_ENCODER_TMDS 2
> >
> > This allows you to bind a bunch of fbs to crtcs with independent
> > positions, as well as set a bunch of planes to specific fbs and
> > layouts. Finally, it lets you change the connector config at the same
> > time, with a flag to simply test a config instead of actually setting
> > it.
> >
> > Any comments? Do we also need to set gamma or other properties as part
> > of this? What about cursors?
>
> I guess you might want to set gamma atomically, but I can't imagine it
> being a factor in anyone's "can I do this" logic.
>
> How do you pass in pixel format? Do you just assume the existing fb is
> already in the correct format? That could work but it kind of sucks for
> low-memory environments since you'd need to have enough room to
> pre-create all the fbs. You could still do the "tear everything down
> first" approach to work around that, but then you'd still have the
> possibility of having nothing lit up _and_ not being able to set what
> was requested, and then needing to unwind in userspace.
Yeah, the assumption is that the fbs have already been set up. You'll
need to do that anyway if you want to queue to a flip chain or
whatever. I don't see an easy way of linking that in here, since to
format an fb you need an underlying buffer allocated, which is where
the memory issues you mentioned come in. So in that sense, it works
like the other APIs in that it assumes you have an object with content
and the right pixel format all ready to go.
> I'd sort of also want to see audio reflected in this (sigh), since
> that's going to affect the bandwidth math. DP 1.2 makes that even worse.
Requesting a specific audio config? Or just returning an informative
error code about why the mode was rejected (e.g. you're playing 7.1
audio on this link and there's not enough bw for the config you wanted)?
How to reasonably return errors from this is an open question; should
we return an array of error codes to indicate all the possible issues?
Or just try our best with a single dimension and hope userspace can
figure things out?
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120215/c9f83573/attachment.pgp>
[RFC] drm: atomic mode set API
On Thu, 16 Feb 2012 00:12:49 +0100
Daniel Vetter wrote:
> On Wed, Feb 15, 2012 at 05:59:45PM -0500, Adam Jackson wrote:
> > On 2/15/12 5:42 PM, Jesse Barnes wrote:
> >
> > >+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test
> > >it for validity */
> > >+
> > >+struct drm_mode_set_config {
> > >+ __u64 crtcs;
> > >+ __u64 crtc_fbs;
> > >+ __u64 crtc_xpos; /* array of x coords for crtcs */
> > >+ __u64 crtc_ypos; /* array of y coords for crtcs */
> > >+ __u32 count_crtcs;
> > >+
> > >+ __u64 plane_sets; /* array of set_plane structs */
> > >+
> > >+ __u32 count_planes;
> > >+
> > >+ __u64 connectors;
> > >+ __u64 connector_modes;
> > >+ __u32 count_connectors;
> > >+
> > >+ __u32 flags;
> > >+};
> >
> > This appears to be missing some []s, but I think the intent is clear.
> >
> > > #define DRM_MODE_ENCODER_NONE0
> > > #define DRM_MODE_ENCODER_DAC 1
> > > #define DRM_MODE_ENCODER_TMDS2
> > >
> > >This allows you to bind a bunch of fbs to crtcs with independent
> > >positions, as well as set a bunch of planes to specific fbs and
> > >layouts. Finally, it lets you change the connector config at the same
> > >time, with a flag to simply test a config instead of actually setting
> > >it.
> > >
> > >Any comments? Do we also need to set gamma or other properties as part
> > >of this? What about cursors?
> >
> > I guess you might want to set gamma atomically, but I can't imagine
> > it being a factor in anyone's "can I do this" logic.
> >
> > How do you pass in pixel format? Do you just assume the existing fb
> > is already in the correct format? That could work but it kind of
> > sucks for low-memory environments since you'd need to have enough
> > room to pre-create all the fbs. You could still do the "tear
> > everything down first" approach to work around that, but then you'd
> > still have the possibility of having nothing lit up _and_ not being
> > able to set what was requested, and then needing to unwind in
> > userspace.
> >
> > I'd sort of also want to see audio reflected in this (sigh), since
> > that's going to affect the bandwidth math. DP 1.2 makes that even
> > worse.
>
> Yeah, I think we should include any funky connector, crtc, plane
> properties (the latter don't exist yet, but I guess they will sooner or
> later) because they all might affect how many and which hw resources we
> need (I'm thinking e.g. of plane setups for hw that reuses crtc engines as
> planes, but where you can use the crtc scanout engine for something else
> if it's completely occluded or set to just scan out the black borders with
> a parameter).
So just an array of set_property structs per object as well? That came
up at today's meeting... Seems doable.
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120215/a7fbb75b/attachment-0001.pgp>
Mode validation outside of connector or encoder (i.e. at CRTC or drm_driver level)
Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this? I expected to see a mode_valid callback in crtc or somewhere similar. What I've got right now is a drm connector and encoder, which are describing a silicon image hdmi transmitter, and an embedded crtc connected to it. While the transmitter is fairly capable the crtc in the SoC is not (it has a maximum pixel clock limitation of 133MHz which means I have to kill off modes above that like 1080p at 60. There are other things I may need to limit too). How do I coordinate such things from the drm_driver or crtc level up to the connector/encoder without making the connector/encoder intimately knowledgeable about the underlying crtc? Currently my only resort is to put the limits in platform data for the connector/encoder and use the mode_valid I already have to parse and discard modes which are plainly not going to be able to be clocked. -- Matt Sealey Product Development Analyst, Genesi USA, Inc.
