search for: chan

From: Ben Skeggs <bskeggs at redhat.com> --- src/nv50_accel.c | 38 ++++++++------------------------------ src/nv50_accel.h | 1 - src/nv50_exa.c | 45 ++++++++++++++++++++------------------------- 3 files changed, 28 insertions(+), 56 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 1218e18..db8c744 100644 --- a/src/nv50_accel.c +++ b/src/nv50_accel.c @@ -213,7 +213,7 @@ NVAccelInitNV50TCL(ScrnInfoPtr pScrn) OUT_RING (chan, (0 << NV50TCL_CB_DEF_SET_BUFFER_SHIFT) | 0x4000);...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a astunicall-1.4 setup with a te110p to a nortel pbx in Mexico. (Hate R2!). This is what I get when trying to call to * box using testcall: ./testcall Chan 31, class 'mfcr2', variant 'mx,20,4', end 0, caller 0, from '' to '' Loading protocol mfcr2 Thread for channel 0 MFC/R2 Chan 31: Call control(9) MFC/R2 Chan 31: Unblock MFC/R2 Chan 31: 1001 -> [1/BLOCKED /Idle /Idle ] MFC/R2 Chan 31: far...

...eau_screen.h | 3 +++ src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +++++++++++++ src/gallium/drivers/nv50/nv50_screen.c | 23 +++++++++++++++++++++++ src/gallium/drivers/nv50/nv50_screen.h | 2 ++ src/gallium/drivers/nv50/nv50_state_validate.c | 3 +++ 6 files changed, 65 insertions(+), 0 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 0437af3..7ebc94e 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -127,8 +127,18 @@ nou...

A cleanup of nouveau_dma_wait(): extract a sub-function and eliminate two variables to improve readability. No functional changes. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_dma.c | 72 ++++++++++++++++++--------------- 1 files changed, 39 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c b/drivers/gpu/drm/nouveau/nouveau_dma.c index b1f3a71.....

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 2 -- drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nv04_graph.c | 1 - 4 files changed, 4 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_chan...

This patch changes the pushbuffer ABI to: 1. No longer use/expose nouveau_pushbuffer. Everything is directly in nouveau_channel. This saves the extra "pushbuf" pointer dereference. 2. Use cur/end pointers instead of tracking the remaining size. Pushing data now only needs to alter cur and not bot...

I have a wired problem, i can recive call but i can't make any call. ATT say that is my problema because the call is operator mode (???) The log is MFC/R2 Chan 1: Call control(1) MFC/R2 Chan 1: Make call MFC/R2 Chan 1: Making a new call with CRN 32772 MFC/R2 Chan 1: 0001 -> [1/ 1/Idle /Idle ] Chan 1: -- Dialing on channel 0 Chan 1: -- Dialing on channel 0 MFC/R2 Chan 1: <- 1101 [1/ 40/Seize...

Use ioremap() for mapping the channel user regs (that are never exposed to user space) instead of drm_addmap(). This removes the last use cases of drm_addmap/drm_rmmap from Nouveau. Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 13 ++++++------- drivers/gpu/drm/nouveau/nouvea...

* Kill the A8+A8 hack. Recent enough X servers (>=1.7) fall back to ARGB glyphs for drivers not supporting A8 render targets. * Kill all the global state. It doesn't matter a lot yet but it might if we get multicard working at some point. * Other random clean-ups with no functional changes. Some numbers from x11perf -aa10text -aa24text -comppixwin10 -comppixwin500: * Before, with A glyphs: 12000000 trep @ 0.0025 msec (394000.0/sec): Char in 80-char aa line (Charter 10) 3200000 trep @ 0.0119 msec ( 84300.0/sec): Char in 30-char aa line (Charter 24) 8000000 trep @...

...both cards, and compiled all the required software... The problem is every call (outgoing or incoming) got dropped, complaining about some "T1 timed out" Only for testing purposes I'm using an application called testcall included on the lib-unicall package, and this are the logs: Chan 1, class 'mfcr2', variant 'mx,0,4', end 335544324, caller 1, from '7000' to '6640' Loading protocol mfcr2 Thread for channel 0 MFC/R2 Chan 1: Call control(8) MFC/R2 Chan 1: Unblock MFC/R2 Chan 1: 1001 -> [1/40000000/Idle /Idle ] MFC/R...

...rc/gallium/drivers/nv40/nv40_context.h | 1 + src/gallium/drivers/nv40/nv40_state_emit.c | 10 +++++- src/gallium/drivers/nv50/nv50_query.c | 2 +- src/gallium/drivers/nv50/nv50_surface.c | 2 + src/gallium/drivers/nv50/nv50_transfer.c | 4 +- 11 files changed, 69 insertions(+), 18 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h b/src/gallium/drivers/nouveau/nouveau_stateobj.h index b595405..67b6c94 100644 --- a/src/gallium/drivers/nouveau/nouveau_stateobj.h +++ b/src/gallium/drivers/nouveau/nouveau_stateobj.h @@ -111,19 +111...

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_graph.c | 571 ++++++++++++++++++++++++++++++++-- 1 files changed, 538 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_graph.c b/drivers/gpu/drm/nouveau/nv04_graph.c index d96c351..1b0af3a 100644 --- a/drivers/gpu/drm/nouveau/nv04_graph.c +++ b/drivers/gpu/drm/nouveau/nv04_graph.c @@ -532,9 +532,82 @@ nv04_graph_mthd_set_ref(struct no...

...ndependent of nouveau and could be moved into gallium/auxiliary. --- src/gallium/drivers/nouveau/nouveau_util.h | 107 ++++++++--- src/gallium/drivers/nv30/nv30_vbo.c | 287 ++++++++++++++++------------ src/gallium/drivers/nv40/nv40_vbo.c | 280 +++++++++++++++------------ 3 files changed, 403 insertions(+), 271 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_util.h b/src/gallium/drivers/nouveau/nouveau_util.h index a10114b..a74d75d 100644 --- a/src/gallium/drivers/nouveau/nouveau_util.h +++ b/src/gallium/drivers/nouveau/nouveau_util.h @@ -1,63 +1,124 @@ #ifndef _...

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau...

Since www.bkw.org seems not to exist anymore (getting response from some hosting provider), does anyone happend to have a copy of app_valetparking.c from www.bkw.org - the one that should work with * stable 1.0.X ? If so please contact me. One that can be downloaded from www.loligo.com dosn't compile with 1.0.X, and SuperValletParking (www.asterlink.com/svp/) seems to be for * HEAD

Nope ! This is the one that tries to include PRE 1.0.X header file <parking.h>. It cannot compile on * 1.0.X (I have tried also to include <features.h> instead of <parking.h> (as far as I know features.h is successor to parking.h), but still without results). Thanks anyway. Nenad > > Try this > >> Since www.bkw.org seems not to exist anymore (getting

...a while. When I tried to shut down the macro TWO_PATH in Speex AEC to save space, an error occurred. Dbf is undefined. The 1.2rc1 code is like this Dbf = 0; See = 0; #ifdef TWO_PATH /* Difference in response, this is used to estimate the variance of our residual power estimate */ for (chan = 0; chan < C; chan++) { spectral_mul_accum(st->X, st->W+chan*N*K*M, st->Y+chan*N, N, M*K); spx_ifft(st->fft_table, st->Y+chan*N, st->y+chan*N); for (i=0;i<st->frame_size;i++) st->e[chan*N+i] = st->e[chan*N+i+st->frame_size] - st-&gt...

Hi, would be glad to be contributing with this question to all the comunity. I?m having a weird issue, suddenly I get channels on IDLE 0x00 state until I do a dahdi restart. Trying to do a call trace to see whats going on deeper, I get surprised when tried to open the .call file to see the log this is incomplete. This is what I see [root at localhost telefonica]# nano chan-9-backward-804-20130507123100.call ........

...ann at suse.de> --- drivers/gpu/drm/nouveau/nouveau_display.h | 1 - drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 +++--- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 3 +++ drivers/gpu/drm/nouveau/nv50_fbcon.c | 9 ++++----- drivers/gpu/drm/nouveau/nvc0_fbcon.c | 9 ++++----- 5 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h b/drivers/gpu/drm/nouveau/nouveau_display.h index e397b3d246e5..0b3eb04b95a7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.h +++ b/drivers/gpu/drm/nouveau/nouveau_display.h @@ -11,7 +11,6 @@ struct...

Turns out we used a misaligned long instruction near the end, and the shader was getting killed after writing R, A components. This has gone unnoticed since the remaining G, B outputs aren't actually used. --- src/nv50_accel.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/nv50_accel.c b/src/nv50_accel.c index 5fa539c..1218e18 100644 --- a/src/nv50_accel.c +++ b/src/nv50_accel.c @@ -291,7 +291,7 @@ NVAccelInitNV50TCL(ScrnInfoPtr pScrn) OUT_RING (chan, (0 << NV50TCL_CB_DEF_SET_BUFFER_SHIFT) | 0x4000); BE...