Building nv40_pm.o triggers these GCC warnings:
drivers/gpu/drm/nouveau/nv40_pm.c: In function 'nv40_pm_clocks_pre':
drivers/gpu/drm/nouveau/nv40_pm.c:164:41: warning: 'log2P' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:38: warning: 'M2' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:45: warning: 'M1' may be used uninitialized in this function [-Wmaybe-…
[View More]uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:25: warning: 'N2' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/nouveau/nv40_pm.c:165:51: warning: 'N1' may be used uninitialized in this function [-Wmaybe-uninitialized]
But these variables seem to be initialized when used there. If the
preceding call of nv40_calc_pll() fails it will return a negative value
and this code will never be run. And if that call succeeds it will
return zero and all those five variables ought to be initialized when
used there.
Anyhow, it turns out that these warnings can be silenced by giving GCC
slightly more detailed information a little earlier. See,
get_pll_limits() returns an error-code integer (ie, negative on failure,
zero on success). And a trivial tweak to nv40_calc_pll() that takes this
into account makes these errors go away.
Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl>
---
0) I noticed these warnings while building recent releases (eg,
v3.6-rc7, v3.6, and v3.6.1) on current Fedora 17, using Fedora's default
config. But I found identical warnings in a build log for release
v3.4-rc1. I didn't bother checking earlier releases.
1) Compile tested only (I do not have the hardware involved at hand).
2) This is not the only place where get_pll_limits()'s return value is
checked. But this is apparently the only place where GCC needs to know
that any non-zero return will be negative.
drivers/gpu/drm/nouveau/nv40_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c
index e66273a..3df30cb 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -114,7 +114,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct pll_lims *pll,
int ret;
ret = get_pll_limits(dev, reg, pll);
- if (ret)
+ if (ret < 0)
return ret;
if (clk < pll->vco1.maxfreq)
--
1.7.11.4
[View Less]
From: Alex Deucher <alexander.deucher(a)amd.com>
The actual set up and assignment of VM page tables
is done on the fly in radeon_gart.c.
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
---
drivers/gpu/drm/radeon/ni.c | 4 ++++
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
drivers/gpu/drm/radeon/si.c | 7 ++++---
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index …
[View More]48e2337..cfb9276 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -770,6 +770,10 @@ static int cayman_pcie_gart_enable(struct radeon_device *rdev)
WREG32(0x15DC, 0);
/* empty context1-7 */
+ /* Assign the pt base to something valid for now; the pts used for
+ * the VMs are determined by the application and setup and assigned
+ * on the fly in the vm part of radeon_gart.c
+ */
for (i = 1; i < 8; i++) {
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR + (i << 2), 0);
WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR + (i << 2), 0);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index 64a4264..1fad47e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1018,6 +1018,9 @@ int radeon_device_init(struct radeon_device *rdev,
return r;
/* initialize vm here */
mutex_init(&rdev->vm_manager.lock);
+ /* FIXME start with 4G, once using 2 level pt switch to full
+ * vm size space
+ */
rdev->vm_manager.max_pfn = 1 << 20;
INIT_LIST_HEAD(&rdev->vm_manager.lru_vm);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index c76825f..f272ead 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2407,12 +2407,13 @@ static int si_pcie_gart_enable(struct radeon_device *rdev)
WREG32(0x15DC, 0);
/* empty context1-15 */
- /* FIXME start with 4G, once using 2 level pt switch to full
- * vm size space
- */
/* set vm size, must be a multiple of 4 */
WREG32(VM_CONTEXT1_PAGE_TABLE_START_ADDR, 0);
WREG32(VM_CONTEXT1_PAGE_TABLE_END_ADDR, rdev->vm_manager.max_pfn);
+ /* Assign the pt base to something valid for now; the pts used for
+ * the VMs are determined by the application and setup and assigned
+ * on the fly in the vm part of radeon_gart.c
+ */
for (i = 1; i < 16; i++) {
if (i < 8)
WREG32(VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (i << 2),
--
1.7.7.5
[View Less]
On 05.10.12 15:37, intel-gfx-request(a)lists.freedesktop.org wrote:
>
> Today's Topics:
>
> 1. [RFC 0/4] drm: add raw monotonic timestamp support (Imre Deak)
> 2. [RFC 1/4] time: export getnstime_raw_and_real for DRM (Imre Deak)
> 3. [RFC 2/4] drm: make memset/calloc for _vblank_time more
> robust (Imre Deak)
> 4. [RFC 3/4] drm: use raw time in
> drm_calc_vbltimestamp_from_scanoutpos (Imre Deak)
> 5. [RFC 4/4] drm: add support for …
[View More]raw monotonic vblank
> timestamps (Imre Deak)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Oct 2012 16:36:58 +0300
> From: Imre Deak<imre.deak(a)intel.com>
> To: Daniel Vetter<daniel.vetter(a)ffwll.ch>, Chris Wilson
> <chris(a)chris-wilson.co.uk>, Kristian H?gsberg<krh(a)bitplanet.net>
> Cc:intel-gfx@lists.freedesktop.org,dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [RFC 0/4] drm: add raw monotonic timestamp
> support
> Message-ID:<1349444222-22274-1-git-send-email-imre.deak(a)intel.com>
>
> This is needed to make applications depending on vblank/page flip
> timestamps independent of time ajdustments.
>
> I've tested these with an updated intel-gpu-test/flip_test and will send
> the update for that once there's no objection about this patchset.
>
I'm mostly fine with this, although the wall time compatibility stuff
may not be useful given that userspace apps, e.g., OpenGL clients, have
no way to actually ask for wall vs. monotonic, and the spec actually
expects them to expect monotonic timestamps.
I also see that an update to nouveau-kms is missing? Afaik the vblank
timestamping on nouveau-kms is still handled by the fallback in the drm,
but pageflip completion uses do_gettimeofday() for the timestamping and
returns a hard-coded zero vblank count all time for pageflip events
(yay!). Lucas Stach and me have written and tested some patches to fix
this over a year ago, but somehow they never made it into the kms
driver, mostly due to bad timing in when stuff was submitted, reviewed
and revised, not for serious technical objections iirc.
Ideally we could give them another try, or at least update nouveaus
pageflip timestamping to avoid really bad breakage for OpenGL clients or
the nouveau-ddx due to inconsistent vblank vs. pageflip timestamps.
I quickly looked over the patches, i think they look mostly good, see
some small comments below.
> Subject: [Intel-gfx] [RFC 3/4] drm: use raw time in
> drm_calc_vbltimestamp_from_scanoutpos
> Message-ID: <1349444222-22274-4-git-send-email-imre.deak(a)intel.com>
>
> The timestamp is used here for handling the timeout case, so we don't
> want it to be affected by time adjustments.
>
> Signed-off-by: Imre Deak <imre.deak(a)intel.com>
> ---
> drivers/gpu/drm/drm_irq.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 77f6577..5e42981 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -576,7 +576,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> unsigned flags,
> struct drm_crtc *refcrtc)
> {
> - struct timeval stime, raw_time;
> + struct timespec raw_stime, raw_etime, real_etime;
> struct drm_display_mode *mode;
> int vbl_status, vtotal, vdisplay;
> int vpos, hpos, i;
> @@ -625,13 +625,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> preempt_disable();
>
> /* Get system timestamp before query. */
> - do_gettimeofday(&stime);
> + getrawmonotonic(&raw_stime);
>
> /* Get vertical and horizontal scanout pos. vpos, hpos. */
> vbl_status = dev->driver->get_scanout_position(dev, crtc, &vpos, &hpos);
>
> /* Get system timestamp after query. */
> - do_gettimeofday(&raw_time);
> + getnstime_raw_and_real(&raw_etime, &real_etime);
>
> preempt_enable();
>
> @@ -642,7 +642,8 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> return -EIO;
> }
>
> - duration_ns = timeval_to_ns(&raw_time) - timeval_to_ns(&stime);
> + duration_ns = timespec_to_ns(&raw_etime) -
> + timespec_to_ns(&raw_stime);
>
> /* Accept result with < max_error nsecs timing uncertainty. */
> if (duration_ns <= (s64) *max_error)
> @@ -692,11 +693,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> /* Subtract time delta from raw timestamp to get final
> * vblank_time timestamp for end of vblank.
> */
> - *vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
> + *vblank_time = ns_to_timeval(timeval_to_ns(&real_time) - delta_ns);
This commit without the followup commit wouldn't compile, because you
changed real_time into real_etime. Your followup commit fixes this, so
squash them into one to avoid compilation problems for bisection?
Then, for the followup patch "[RFC 4/4] drm: add support for raw
monotonic vblank timestamps"
> @@ -693,12 +694,13 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> /* Subtract time delta from raw timestamp to get final
> * vblank_time timestamp for end of vblank.
> */
> - *vblank_time = ns_to_timeval(timeval_to_ns(&real_time) - delta_ns);
> + vblank_time->real = ns_to_timeval(timespec_to_ns(&real_etime) - delta_ns);
> + vblank_time->raw = ns_to_timeval(timespec_to_ns(&raw_etime) - delta_ns);
>
> DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n",
> crtc, (int)vbl_status, hpos, vpos,
> (long)raw_stime.tv_sec, (long)raw_stime.tv_nsec / 1000,
This shouldn't be raw_stime, but real_etime, so the debug output of
these vars can be compared to the values of vblank_time->real.tv_sec etc.
> - (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
> + (long)vblank_time->real.tv_sec, (long)vblank_time->real.tv_usec,
> (int)duration_ns/1000, i);
>
>
thanks,
-mario
[View Less]
Dear Linux folks,
using Debian Sid/unstable, clicking on a mail address in Iceweasel
(Firefox) a composer window is opened in Evolution 3.4.3-1. But then the
windows are only gray and hang and the only way to fix this is to kill
the process. I reported this issue to the GNOME Bugzilla as 685640 and
the developer Matthew Barnes pointed out the following [1].
--- Comment #1 from Matthew Barnes <mbarnes(a)redhat.com> 2012-10-07 11:59:35 UTC ---
Radeon video driver thread …
[View More]looks stuck:
Thread 5 (Thread 0x7f6656d4d700 (LWP 4375)):
#0 pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
No locals.
#1 0x00007f6656f4c9f3 in pipe_semaphore_wait (sema=0x7f666b6577b8)
at ../../../../../src/gallium/auxiliary/os/os_thread.h:432
No locals.
#2 radeon_drm_cs_emit_ioctl (param=0x7f666b635c40) at radeon_drm_cs.c:401
cs = 0x7f666b635c40
Any hints how to fix this are much appreciated. If it is indeed a Linux
issue, I will gladly create a new ticket in the freedesktop.org
Bugzilla.
Thanks,
Paul
[1] https://bugzilla.gnome.org/show_bug.cgi?id=685640
[View Less]