[PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Christian Costa]

---
 rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
index 500cea9..e006dbe 100644
--- a/rnndb/memory/nvc0_pbfb.xml
+++ b/rnndb/memory/nvc0_pbfb.xml
@@ -49,23 +49,54 @@
 			Most bitfields are unknown.
 			</doc>
 		<bitfield high="7" low="0" name="RP">
-			<doc> RAS# precharge. </doc>
+			<doc> RAS# Precharge. </doc>
 		</bitfield>
 		<bitfield high="15" low="8" name="RAS">
-			<doc>Activate to precharge delay. </doc>
+			<doc> Activate to precharge delay. </doc>
 		</bitfield>
 		<bitfield high="23" low="16" name="RFC">
 			<doc> Refresh to activate delay. </doc>
 		</bitfield>
 		<bitfield high="31" low="24" name="RC">
-			<doc> Row cycle time. </doc>
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+	</reg32>
+
+	<reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
+		<doc> This, and the next 6 regs, are all related to memtimings.
+			A good place to read might be http://www.tweakers.fr/timings.html .
+			Most bitfields are unknown.
+			</doc>
+		<bitfield high="7" low="0" name="tRC">
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+		<bitfield high="15" low="8" name="tRFC">
+			<doc> Refresh to activate delay. </doc>
+		</bitfield>
+		<bitfield high="23" low="17" name="tRAS">
+			<doc> Activate to precharge delay. </doc>
+		</bitfield>
+		<bitfield high="31" low="24" name="tRCD">
+			<doc> RAS# to CAS# Delay. </doc>
 		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
+		<bitfield high="3" low="0" name="tCL">
+			<doc> Row Cycle time. </doc>
+		</bitfield>
+		<bitfield high="13" low="7" name="tCWL">
+			<doc> CAS# Write Latency. </doc>
+		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
+		<bitfield high="15" low="8" name="tWTR">
+			<doc> Write To Read delay. </doc>
+		</bitfield>
+		<bitfield high="23" low="15" name="tWR">
+			<doc> Write Recovery time. </doc>
+		</bitfield>
 	</reg32>
 
 	<reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">
-- 
1.9.1

[PATCH envytools] docs: Fix some spelling and remove some trailing spaces.

[Christian Costa]

---
 docs/hw/fifo/intro.rst | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/docs/hw/fifo/intro.rst b/docs/hw/fifo/intro.rst
index 8b1d69d..0e023bf 100644
--- a/docs/hw/fifo/intro.rst
+++ b/docs/hw/fifo/intro.rst
@@ -10,7 +10,7 @@ FIFO overview
 Introduction
 ============
 
-Commands to most of the engines are sent through a special engine caled PFIFO.
+Commands to most of the engines are sent through a special engine called PFIFO.
 PFIFO maintains multiple fully independent command queues, known as "channels"
 or "FIFO"s. Each channel is controlled through a "channel control area", which
 is a region of MMIO [pre-NVC0] or VRAM [NVC0+]. PFIFO intercepts all accesses
@@ -40,11 +40,11 @@ The engines that PFIFO controls on NV04:NVC0 are:
 == ========== =========================== =================================================== 
 Id Present on Name                        Description                                        
 == ========== =========================== =================================================== 
-0  all        SOFTWARE                    Not really an engine, causes interrupt for each    
-                                          command, can be used to execute driver functions   
-                                          in sync with other commands.                       
-1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.          
-2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.  
+0  all        SOFTWARE                    Not really an engine, causes interrupt for each
+                                          command, can be used to execute driver functions
+                                          in sync with other commands.
+1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
+2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
    NVA0:NVAA
 3  NV40:NV84  :ref:`PME <me-fifo>`        VPE motion estimation engine.
 4  NV41:NV84  :ref:`PVP1 <pvp1>`          VPE microcoded vector processor.
@@ -64,10 +64,10 @@ The engines that PFIFO controls on NVC0- are:
 ===== ========== =========================== =================================================== 
 Id    Present on Name                        Description                                        
 ===== ========== =========================== =================================================== 
-1f    all        SOFTWARE                    Not really an engine, causes interrupt for each    
-                                             command, can be used to execute driver functions   
-                                             in sync with other commands.                       
-0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.          
+1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
+                                             command, can be used to execute driver functions
+                                             in sync with other commands.
+0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
 1     all        :ref:`PVDEC <pvdec>`        falcon-based microcoded video decoder.
 2     all        :ref:`PPPP <pppp>`          falcon-based video post-processor.
 3     all        :ref:`PVLD <pvld>`          falcon-based variable length decoder.
@@ -93,7 +93,7 @@ The PFIFO can be split into roughly 4 pieces:
 - PFIFO puller: executes the commands, passes them to the proper engine,
   or to the driver.
 - PFIFO switcher: ticks out the time slices for the channels and saves /
-  restores the state of the channel between PFIFO registers and RAMFC
+  restores the state of the channels between PFIFO registers and RAMFC
   memory.
 
 A channel consists of the following:
@@ -133,7 +133,7 @@ is being submitted. See :ref:`nv03-pfifo-dma` for details.
 
 NV04 PFIFO greatly enhanced the DMA mode and made it controllable directly
 through the channel control area. Thus, commands can now be submitted by
-multiple applications simultanously, without coordination with each other
+multiple applications simultaneously, without coordination with each other
 and without kernel's help. DMA mode is described in :ref:`fifo-dma-pusher`.
 
 NV50 introduced IB mode. IB mode is a modified version of DMA mode that,
@@ -143,8 +143,8 @@ to stitch together parts of multiple memory areas into a single command stream
 memory written by earlier commands. IB mode is described along with DMA mode in
 :ref:`fifo-dma-pusher`.
 
-NVC0 rearchitected the whole PFIFO, made it possible to have up to 3 channels
-executing simultanously, and introduced a new DMA packet format.
+NVC0 rearchitectured the whole PFIFO, made it possible to have up to 3 channels
+executing simultaneously, and introduced a new DMA packet format.
 
 The commands, as stored in CACHE, are tuples of:
 
@@ -180,12 +180,12 @@ and engine-specific documentation.
 
 Pre-NV1A, PFIFO treats everything as little-endian. NV1A introduced big-endian
 mode, which affects pushbuffer/IB reads and semaphores. On NV1A:NV50 cards,
-the endian can be selected per channel via big_endian flag. On NV50+ cards,
+the endianness can be selected per channel via the big_endian flag. On NV50+ cards,
 PFIFO endianness is a global switch.
 
 .. todo:: look for NVC0 PFIFO endian switch
 
 The channel control area endianness is not affected by the big_endian flag or
-NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endian switch.
+NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endianness switch.
 
 .. todo:: is it still true for NVC0, with VRAM-backed channel control area?
-- 
1.9.1

Re: [PATCH envytools] docs: Fix some spelling and remove some trailing spaces.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   docs/hw/fifo/intro.rst | 32 ++++++++++++++++----------------
>   1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/docs/hw/fifo/intro.rst b/docs/hw/fifo/intro.rst
> index 8b1d69d..0e023bf 100644
> --- a/docs/hw/fifo/intro.rst
> +++ b/docs/hw/fifo/intro.rst
> @@ -10,7 +10,7 @@ FIFO overview
>   Introduction
>   ============
>   
> -Commands to most of the engines are sent through a special engine caled PFIFO.
> +Commands to most of the engines are sent through a special engine called PFIFO.
>   PFIFO maintains multiple fully independent command queues, known as "channels"
>   or "FIFO"s. Each channel is controlled through a "channel control area", which
>   is a region of MMIO [pre-NVC0] or VRAM [NVC0+]. PFIFO intercepts all accesses
> @@ -40,11 +40,11 @@ The engines that PFIFO controls on NV04:NVC0 are:
>   == ========== =========================== ===================================================
>   Id Present on Name                        Description
>   == ========== =========================== ===================================================
> -0  all        SOFTWARE                    Not really an engine, causes interrupt for each
> -                                          command, can be used to execute driver functions
> -                                          in sync with other commands.
> -1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> -2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
> +0  all        SOFTWARE                    Not really an engine, causes interrupt for each
> +                                          command, can be used to execute driver functions
> +                                          in sync with other commands.
> +1  all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> +2  NV31:NV98  :ref:`PMPEG <pmpeg>`        The PFIFO interface to VPE MPEG2 decoding engine.
>      NVA0:NVAA
>   3  NV40:NV84  :ref:`PME <me-fifo>`        VPE motion estimation engine.
>   4  NV41:NV84  :ref:`PVP1 <pvp1>`          VPE microcoded vector processor.
> @@ -64,10 +64,10 @@ The engines that PFIFO controls on NVC0- are:
>   ===== ========== =========================== ===================================================
>   Id    Present on Name                        Description
>   ===== ========== =========================== ===================================================
> -1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
> -                                             command, can be used to execute driver functions
> -                                             in sync with other commands.
> -0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
> +1f    all        SOFTWARE                    Not really an engine, causes interrupt for each
> +                                             command, can be used to execute driver functions
> +                                             in sync with other commands.
> +0     all        :ref:`PGRAPH <graph-intro>` Main engine of the card: 2d, 3d, compute.
>   1     all        :ref:`PVDEC <pvdec>`        falcon-based microcoded video decoder.
>   2     all        :ref:`PPPP <pppp>`          falcon-based video post-processor.
>   3     all        :ref:`PVLD <pvld>`          falcon-based variable length decoder.
> @@ -93,7 +93,7 @@ The PFIFO can be split into roughly 4 pieces:
>   - PFIFO puller: executes the commands, passes them to the proper engine,
>     or to the driver.
>   - PFIFO switcher: ticks out the time slices for the channels and saves /
> -  restores the state of the channel between PFIFO registers and RAMFC
> +  restores the state of the channels between PFIFO registers and RAMFC
>     memory.
>   
>   A channel consists of the following:
> @@ -133,7 +133,7 @@ is being submitted. See :ref:`nv03-pfifo-dma` for details.
>   
>   NV04 PFIFO greatly enhanced the DMA mode and made it controllable directly
>   through the channel control area. Thus, commands can now be submitted by
> -multiple applications simultanously, without coordination with each other
> +multiple applications simultaneously, without coordination with each other
>   and without kernel's help. DMA mode is described in :ref:`fifo-dma-pusher`.
>   
>   NV50 introduced IB mode. IB mode is a modified version of DMA mode that,
> @@ -143,8 +143,8 @@ to stitch together parts of multiple memory areas into a single command stream
>   memory written by earlier commands. IB mode is described along with DMA mode in
>   :ref:`fifo-dma-pusher`.
>   
> -NVC0 rearchitected the whole PFIFO, made it possible to have up to 3 channels
> -executing simultanously, and introduced a new DMA packet format.
> +NVC0 rearchitectured the whole PFIFO, made it possible to have up to 3 channels
> +executing simultaneously, and introduced a new DMA packet format.
>   
>   The commands, as stored in CACHE, are tuples of:
>   
> @@ -180,12 +180,12 @@ and engine-specific documentation.
>   
>   Pre-NV1A, PFIFO treats everything as little-endian. NV1A introduced big-endian
>   mode, which affects pushbuffer/IB reads and semaphores. On NV1A:NV50 cards,
> -the endian can be selected per channel via big_endian flag. On NV50+ cards,
> +the endianness can be selected per channel via the big_endian flag. On NV50+ cards,
>   PFIFO endianness is a global switch.
>   
>   .. todo:: look for NVC0 PFIFO endian switch
>   
>   The channel control area endianness is not affected by the big_endian flag or
> -NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endian switch.
> +NV50+ PFIFO endianness switch. Instead, it follows the PMC MMIO endianness switch.
>   
>   .. todo:: is it still true for NVC0, with VRAM-backed channel control area?

Looks good, I'll push it soon!

[PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

- Sort commands by name for easier update
- Make more readable
- Remove no more existing commands
---
 nva/README | 83 +++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 44 insertions(+), 39 deletions(-)

diff --git a/nva/README b/nva/README
index 625ea7c..d4347c5 100644
--- a/nva/README
+++ b/nva/README
@@ -3,7 +3,7 @@ registers.
 
 WARNING: these tools *can* and *will* hang your machine if you don't know
 what you're doing. Hardware destruction is likely also possible, although
-no incidents are known to have happened yet. In most cases it's also not
+no incident are known to have happened yet. In most cases it's also not
 recommended to use these tools while a driver is active for a given card.
 
 All programs except nvalist take an optional -c <card number> parameter.
@@ -13,43 +13,48 @@ by the nvalist program.
 
 The programs are:
 
-nvalist: prints a list of cards
-
-nvapeek <address> [<byte count>]: reads 32-bit MMIO register at <address>.
-If byte count is also given, reads all registers in range [address, address
-+ byte count).
-
-nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO accesses
-
-nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register at
-<address>.
-
-nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
-
-nvawatch [-t] <address>: reads MMIO register at <address> in a loop, prints
-the value every time it changes. If -t is specified, prints a timestamp
-and diff from the previous timestamp before the value. Never quits, needs
-to be manually aborted.
-
-nvahammer <address> <value>: like nvapoke, but repeats the write in
-an infinite loop. Needs to be manually aborted.
-
-nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
-method given as parameter and writes it to stdout. Method can be PROM or
-PRAMIN. If method is not given, defaults to something sensible.
-
-nvafuzz <address> [<byte count>]: writes random values to a register or
-a register range in an infinite loop. Needs to be manually aborted.
-
-nvascan [-as] <address> [<byte count>]: for each register in a range:
-read it, write 0xffffffff, read it, write 0, read it, write back the
-original value. Helpful to see the valid values for registers. If -s option
-is passed, does a slow scan - waits and reads PMC.ID register between scans
-to recover from errors caused by invalid register accesses. If -a option
-is passed, does a cross-test on all registers in the range to detect aliased
-addresses [not particularly reliable].
-
-nvatiming: attempts to measure what frequency various units of the card are
-running at by using misc tricks.
+nvafuzz <address> [<byte count>]
+    Writes random values to a register or
+    a register range in an infinite loop. Needs to be manually aborted.
+
+nvagetbios [-s <extraction method>]
+    Extracts the card's VBIOS using the
+    method given as parameter and writes it to stdout. Method can be PROM or
+    PRAMIN. If method is not given, defaults to something sensible.
+
+nvahammer <address> <value>
+    Like nvapoke, but repeats the write in
+    an infinite loop. Needs to be manually aborted.
+
+nvalist
+    Prints a list of cards
+
+nvapeek <address> [<byte count>]
+    Reads 32-bit MMIO register at <address>.
+    If byte count is also given, reads all registers in range [address, address
+    + byte count).
+
+nvapoke <address> <value>
+    Writes a 32-bit <value> to the MMIO register at
+    <address>.
+
+nvascan [-as] <address> [<byte count>]
+    For each register in a range:
+    read it, write 0xffffffff, read it, write 0, read it, write back the
+    original value. Helpful to see the valid values for registers. If -s option
+    is passed, does a slow scan - waits and reads PMC.ID register between scans
+    to recover from errors caused by invalid register accesses. If -a option
+    is passed, does a cross-test on all registers in the range to detect aliased
+    addresses [not particularly reliable].
+
+nvatiming
+    Attempts to measure what frequency various units of the card are
+    running at by using misc tricks.
+
+nvawatch [-t] <address>
+    Reads MMIO register at <address> in a loop, prints
+    the value every time it changes. If -t is specified, prints a timestamp
+    and diff from the previous timestamp before the value. Never quits, needs
+    to be manually aborted.
 
 [XXX: document the remaining tools]
-- 
1.9.1

Re: [PATCH envytools] nva: Clean up nva tools doc

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> - Sort commands by name for easier update
> - Make more readable
> - Remove no more existing commands
> ---
>   nva/README | 83 +++++++++++++++++++++++++++++++++-----------------------------
>   1 file changed, 44 insertions(+), 39 deletions(-)
>
> diff --git a/nva/README b/nva/README
> index 625ea7c..d4347c5 100644
> --- a/nva/README
> +++ b/nva/README
> @@ -3,7 +3,7 @@ registers.
>   
>   WARNING: these tools *can* and *will* hang your machine if you don't know
>   what you're doing. Hardware destruction is likely also possible, although
> -no incidents are known to have happened yet. In most cases it's also not
> +no incident are known to have happened yet. In most cases it's also not
IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could 
give us
a more definitive answer on this :)
>   recommended to use these tools while a driver is active for a given card.
>   
>   All programs except nvalist take an optional -c <card number> parameter.
> @@ -13,43 +13,48 @@ by the nvalist program.
>   
>   The programs are:
>   
> -nvalist: prints a list of cards
> -
> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at <address>.
> -If byte count is also given, reads all registers in range [address, address
> -+ byte count).
> -
> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO accesses
> -
> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register at
> -<address>.
> -
> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
> -
> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop, prints
> -the value every time it changes. If -t is specified, prints a timestamp
> -and diff from the previous timestamp before the value. Never quits, needs
> -to be manually aborted.
> -
> -nvahammer <address> <value>: like nvapoke, but repeats the write in
> -an infinite loop. Needs to be manually aborted.
> -
> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
> -method given as parameter and writes it to stdout. Method can be PROM or
> -PRAMIN. If method is not given, defaults to something sensible.
> -
> -nvafuzz <address> [<byte count>]: writes random values to a register or
> -a register range in an infinite loop. Needs to be manually aborted.
> -
> -nvascan [-as] <address> [<byte count>]: for each register in a range:
> -read it, write 0xffffffff, read it, write 0, read it, write back the
> -original value. Helpful to see the valid values for registers. If -s option
> -is passed, does a slow scan - waits and reads PMC.ID register between scans
> -to recover from errors caused by invalid register accesses. If -a option
> -is passed, does a cross-test on all registers in the range to detect aliased
> -addresses [not particularly reliable].
> -
> -nvatiming: attempts to measure what frequency various units of the card are
> -running at by using misc tricks.
> +nvafuzz <address> [<byte count>]
> +    Writes random values to a register or
> +    a register range in an infinite loop. Needs to be manually aborted.
> +
> +nvagetbios [-s <extraction method>]
> +    Extracts the card's VBIOS using the
> +    method given as parameter and writes it to stdout. Method can be PROM or
> +    PRAMIN. If method is not given, defaults to something sensible.
> +
> +nvahammer <address> <value>
> +    Like nvapoke, but repeats the write in
> +    an infinite loop. Needs to be manually aborted.
> +
> +nvalist
> +    Prints a list of cards
> +
> +nvapeek <address> [<byte count>]
> +    Reads 32-bit MMIO register at <address>.
> +    If byte count is also given, reads all registers in range [address, address
> +    + byte count).
> +
> +nvapoke <address> <value>
> +    Writes a 32-bit <value> to the MMIO register at
> +    <address>.
> +
> +nvascan [-as] <address> [<byte count>]
> +    For each register in a range:
> +    read it, write 0xffffffff, read it, write 0, read it, write back the
> +    original value. Helpful to see the valid values for registers. If -s option
> +    is passed, does a slow scan - waits and reads PMC.ID register between scans
> +    to recover from errors caused by invalid register accesses. If -a option
> +    is passed, does a cross-test on all registers in the range to detect aliased
> +    addresses [not particularly reliable].
> +
> +nvatiming
> +    Attempts to measure what frequency various units of the card are
> +    running at by using misc tricks.
> +
> +nvawatch [-t] <address>
> +    Reads MMIO register at <address> in a loop, prints
> +    the value every time it changes. If -t is specified, prints a timestamp
> +    and diff from the previous timestamp before the value. Never quits, needs
> +    to be manually aborted.
>   
>   [XXX: document the remaining tools]
Did you fix some spelling mistakes in while changing the order? I 
already suck at
comparing lines that are one on top of the other, so I don't even want 
to try checking!

Re: [PATCH envytools] nva: Clean up nva tools doc

[Ilia Mirkin]

On Mon, Aug 25, 2014 at 6:35 PM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
> On 25/08/2014 20:58, Christian Costa wrote:
>>
>> - Sort commands by name for easier update
>> - Make more readable
>> - Remove no more existing commands
>> ---
>>   nva/README | 83
>> +++++++++++++++++++++++++++++++++-----------------------------
>>   1 file changed, 44 insertions(+), 39 deletions(-)
>>
>> diff --git a/nva/README b/nva/README
>> index 625ea7c..d4347c5 100644
>> --- a/nva/README
>> +++ b/nva/README
>> @@ -3,7 +3,7 @@ registers.
>>     WARNING: these tools *can* and *will* hang your machine if you don't
>> know
>>   what you're doing. Hardware destruction is likely also possible,
>> although
>> -no incidents are known to have happened yet. In most cases it's also not
>> +no incident are known to have happened yet. In most cases it's also not
>
> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could give
> us
> a more definitive answer on this :)

Without being definitive, I believe the old way was fine. The new way,
however, is not. You could, alternatively say, "although no incident
is known to have happened yet" -- pretty sure that'd be correct too.

>
>>   recommended to use these tools while a driver is active for a given
>> card.
>>     All programs except nvalist take an optional -c <card number>
>> parameter.
>> @@ -13,43 +13,48 @@ by the nvalist program.
>>     The programs are:
>>   -nvalist: prints a list of cards
>> -
>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at
>> <address>.
>> -If byte count is also given, reads all registers in range [address,
>> address
>> -+ byte count).
>> -
>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO
>> accesses
>> -
>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register
>> at
>> -<address>.
>> -
>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>> -
>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop,
>> prints
>> -the value every time it changes. If -t is specified, prints a timestamp
>> -and diff from the previous timestamp before the value. Never quits, needs
>> -to be manually aborted.
>> -
>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>> -an infinite loop. Needs to be manually aborted.
>> -
>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
>> -method given as parameter and writes it to stdout. Method can be PROM or
>> -PRAMIN. If method is not given, defaults to something sensible.
>> -
>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>> -a register range in an infinite loop. Needs to be manually aborted.
>> -
>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>> -original value. Helpful to see the valid values for registers. If -s
>> option
>> -is passed, does a slow scan - waits and reads PMC.ID register between
>> scans
>> -to recover from errors caused by invalid register accesses. If -a option
>> -is passed, does a cross-test on all registers in the range to detect
>> aliased
>> -addresses [not particularly reliable].
>> -
>> -nvatiming: attempts to measure what frequency various units of the card
>> are
>> -running at by using misc tricks.
>> +nvafuzz <address> [<byte count>]
>> +    Writes random values to a register or
>> +    a register range in an infinite loop. Needs to be manually aborted.
>> +
>> +nvagetbios [-s <extraction method>]
>> +    Extracts the card's VBIOS using the
>> +    method given as parameter and writes it to stdout. Method can be PROM
>> or
>> +    PRAMIN. If method is not given, defaults to something sensible.
>> +
>> +nvahammer <address> <value>
>> +    Like nvapoke, but repeats the write in
>> +    an infinite loop. Needs to be manually aborted.
>> +
>> +nvalist
>> +    Prints a list of cards
>> +
>> +nvapeek <address> [<byte count>]
>> +    Reads 32-bit MMIO register at <address>.
>> +    If byte count is also given, reads all registers in range [address,
>> address
>> +    + byte count).
>> +
>> +nvapoke <address> <value>
>> +    Writes a 32-bit <value> to the MMIO register at
>> +    <address>.
>> +
>> +nvascan [-as] <address> [<byte count>]
>> +    For each register in a range:
>> +    read it, write 0xffffffff, read it, write 0, read it, write back the
>> +    original value. Helpful to see the valid values for registers. If -s
>> option
>> +    is passed, does a slow scan - waits and reads PMC.ID register between
>> scans
>> +    to recover from errors caused by invalid register accesses. If -a
>> option
>> +    is passed, does a cross-test on all registers in the range to detect
>> aliased
>> +    addresses [not particularly reliable].
>> +
>> +nvatiming
>> +    Attempts to measure what frequency various units of the card are
>> +    running at by using misc tricks.
>> +
>> +nvawatch [-t] <address>
>> +    Reads MMIO register at <address> in a loop, prints
>> +    the value every time it changes. If -t is specified, prints a
>> timestamp
>> +    and diff from the previous timestamp before the value. Never quits,
>> needs
>> +    to be manually aborted.
>>     [XXX: document the remaining tools]
>
> Did you fix some spelling mistakes in while changing the order? I already
> suck at
> comparing lines that are one on top of the other, so I don't even want to
> try checking!
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

Le 26/08/2014 00:55, Ilia Mirkin a écrit :
> On Mon, Aug 25, 2014 at 6:35 PM, Martin Peres <martin.peres-GANU6spQydw@public.gmane.org> wrote:
>> On 25/08/2014 20:58, Christian Costa wrote:
>>> - Sort commands by name for easier update
>>> - Make more readable
>>> - Remove no more existing commands
>>> ---
>>>    nva/README | 83
>>> +++++++++++++++++++++++++++++++++-----------------------------
>>>    1 file changed, 44 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/nva/README b/nva/README
>>> index 625ea7c..d4347c5 100644
>>> --- a/nva/README
>>> +++ b/nva/README
>>> @@ -3,7 +3,7 @@ registers.
>>>      WARNING: these tools *can* and *will* hang your machine if you don't
>>> know
>>>    what you're doing. Hardware destruction is likely also possible,
>>> although
>>> -no incidents are known to have happened yet. In most cases it's also not
>>> +no incident are known to have happened yet. In most cases it's also not
>> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could give
>> us
>> a more definitive answer on this :)
> Without being definitive, I believe the old way was fine. The new way,
> however, is not. You could, alternatively say, "although no incident
> is known to have happened yet" -- pretty sure that'd be correct too.
Oh. I intended to write "no incident is known" but forgot to change "are".
I'Il resend a patch with old way. Now, you're pointing out, I remember 
this is correct.
>
>>>    recommended to use these tools while a driver is active for a given
>>> card.
>>>      All programs except nvalist take an optional -c <card number>
>>> parameter.
>>> @@ -13,43 +13,48 @@ by the nvalist program.
>>>      The programs are:
>>>    -nvalist: prints a list of cards
>>> -
>>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at
>>> <address>.
>>> -If byte count is also given, reads all registers in range [address,
>>> address
>>> -+ byte count).
>>> -
>>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO
>>> accesses
>>> -
>>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register
>>> at
>>> -<address>.
>>> -
>>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>>> -
>>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop,
>>> prints
>>> -the value every time it changes. If -t is specified, prints a timestamp
>>> -and diff from the previous timestamp before the value. Never quits, needs
>>> -to be manually aborted.
>>> -
>>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>>> -an infinite loop. Needs to be manually aborted.
>>> -
>>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
>>> -method given as parameter and writes it to stdout. Method can be PROM or
>>> -PRAMIN. If method is not given, defaults to something sensible.
>>> -
>>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>>> -a register range in an infinite loop. Needs to be manually aborted.
>>> -
>>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>>> -original value. Helpful to see the valid values for registers. If -s
>>> option
>>> -is passed, does a slow scan - waits and reads PMC.ID register between
>>> scans
>>> -to recover from errors caused by invalid register accesses. If -a option
>>> -is passed, does a cross-test on all registers in the range to detect
>>> aliased
>>> -addresses [not particularly reliable].
>>> -
>>> -nvatiming: attempts to measure what frequency various units of the card
>>> are
>>> -running at by using misc tricks.
>>> +nvafuzz <address> [<byte count>]
>>> +    Writes random values to a register or
>>> +    a register range in an infinite loop. Needs to be manually aborted.
>>> +
>>> +nvagetbios [-s <extraction method>]
>>> +    Extracts the card's VBIOS using the
>>> +    method given as parameter and writes it to stdout. Method can be PROM
>>> or
>>> +    PRAMIN. If method is not given, defaults to something sensible.
>>> +
>>> +nvahammer <address> <value>
>>> +    Like nvapoke, but repeats the write in
>>> +    an infinite loop. Needs to be manually aborted.
>>> +
>>> +nvalist
>>> +    Prints a list of cards
>>> +
>>> +nvapeek <address> [<byte count>]
>>> +    Reads 32-bit MMIO register at <address>.
>>> +    If byte count is also given, reads all registers in range [address,
>>> address
>>> +    + byte count).
>>> +
>>> +nvapoke <address> <value>
>>> +    Writes a 32-bit <value> to the MMIO register at
>>> +    <address>.
>>> +
>>> +nvascan [-as] <address> [<byte count>]
>>> +    For each register in a range:
>>> +    read it, write 0xffffffff, read it, write 0, read it, write back the
>>> +    original value. Helpful to see the valid values for registers. If -s
>>> option
>>> +    is passed, does a slow scan - waits and reads PMC.ID register between
>>> scans
>>> +    to recover from errors caused by invalid register accesses. If -a
>>> option
>>> +    is passed, does a cross-test on all registers in the range to detect
>>> aliased
>>> +    addresses [not particularly reliable].
>>> +
>>> +nvatiming
>>> +    Attempts to measure what frequency various units of the card are
>>> +    running at by using misc tricks.
>>> +
>>> +nvawatch [-t] <address>
>>> +    Reads MMIO register at <address> in a loop, prints
>>> +    the value every time it changes. If -t is specified, prints a
>>> timestamp
>>> +    and diff from the previous timestamp before the value. Never quits,
>>> needs
>>> +    to be manually aborted.
>>>      [XXX: document the remaining tools]
>> Did you fix some spelling mistakes in while changing the order? I already
>> suck at
>> comparing lines that are one on top of the other, so I don't even want to
>> try checking!
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Re: [PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

Le 26/08/2014 00:35, Martin Peres a écrit :
> On 25/08/2014 20:58, Christian Costa wrote:
>> - Sort commands by name for easier update
>> - Make more readable
>> - Remove no more existing commands
>> ---
>>   nva/README | 83 
>> +++++++++++++++++++++++++++++++++-----------------------------
>>   1 file changed, 44 insertions(+), 39 deletions(-)
>>
>> diff --git a/nva/README b/nva/README
>> index 625ea7c..d4347c5 100644
>> --- a/nva/README
>> +++ b/nva/README
>> @@ -3,7 +3,7 @@ registers.
>>     WARNING: these tools *can* and *will* hang your machine if you 
>> don't know
>>   what you're doing. Hardware destruction is likely also possible, 
>> although
>> -no incidents are known to have happened yet. In most cases it's also 
>> not
>> +no incident are known to have happened yet. In most cases it's also not
> IIRC, "0" is considered plural in English. I'm sure Ilia or Ben could 
> give us
> a more definitive answer on this :)
Ok. I'll resend a patch after confirmation if needed.
>>   recommended to use these tools while a driver is active for a given 
>> card.
>>     All programs except nvalist take an optional -c <card number> 
>> parameter.
>> @@ -13,43 +13,48 @@ by the nvalist program.
>>     The programs are:
>>   -nvalist: prints a list of cards
>> -
>> -nvapeek <address> [<byte count>]: reads 32-bit MMIO register at 
>> <address>.
>> -If byte count is also given, reads all registers in range [address, 
>> address
>> -+ byte count).
>> -
>> -nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO 
>> accesses
>> -
>> -nvapoke <address> <value>: writes a 32-bit <value> to the MMIO 
>> register at
>> -<address>.
>> -
>> -nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
>> -
>> -nvawatch [-t] <address>: reads MMIO register at <address> in a loop, 
>> prints
>> -the value every time it changes. If -t is specified, prints a timestamp
>> -and diff from the previous timestamp before the value. Never quits, 
>> needs
>> -to be manually aborted.
>> -
>> -nvahammer <address> <value>: like nvapoke, but repeats the write in
>> -an infinite loop. Needs to be manually aborted.
>> -
>> -nvagetbios [-s <extraction method>]: extracts the card's VBIOS using 
>> the
>> -method given as parameter and writes it to stdout. Method can be 
>> PROM or
>> -PRAMIN. If method is not given, defaults to something sensible.
>> -
>> -nvafuzz <address> [<byte count>]: writes random values to a register or
>> -a register range in an infinite loop. Needs to be manually aborted.
>> -
>> -nvascan [-as] <address> [<byte count>]: for each register in a range:
>> -read it, write 0xffffffff, read it, write 0, read it, write back the
>> -original value. Helpful to see the valid values for registers. If -s 
>> option
>> -is passed, does a slow scan - waits and reads PMC.ID register 
>> between scans
>> -to recover from errors caused by invalid register accesses. If -a 
>> option
>> -is passed, does a cross-test on all registers in the range to detect 
>> aliased
>> -addresses [not particularly reliable].
>> -
>> -nvatiming: attempts to measure what frequency various units of the 
>> card are
>> -running at by using misc tricks.
>> +nvafuzz <address> [<byte count>]
>> +    Writes random values to a register or
>> +    a register range in an infinite loop. Needs to be manually aborted.
>> +
>> +nvagetbios [-s <extraction method>]
>> +    Extracts the card's VBIOS using the
>> +    method given as parameter and writes it to stdout. Method can be 
>> PROM or
>> +    PRAMIN. If method is not given, defaults to something sensible.
>> +
>> +nvahammer <address> <value>
>> +    Like nvapoke, but repeats the write in
>> +    an infinite loop. Needs to be manually aborted.
>> +
>> +nvalist
>> +    Prints a list of cards
>> +
>> +nvapeek <address> [<byte count>]
>> +    Reads 32-bit MMIO register at <address>.
>> +    If byte count is also given, reads all registers in range 
>> [address, address
>> +    + byte count).
>> +
>> +nvapoke <address> <value>
>> +    Writes a 32-bit <value> to the MMIO register at
>> +    <address>.
>> +
>> +nvascan [-as] <address> [<byte count>]
>> +    For each register in a range:
>> +    read it, write 0xffffffff, read it, write 0, read it, write back 
>> the
>> +    original value. Helpful to see the valid values for registers. 
>> If -s option
>> +    is passed, does a slow scan - waits and reads PMC.ID register 
>> between scans
>> +    to recover from errors caused by invalid register accesses. If 
>> -a option
>> +    is passed, does a cross-test on all registers in the range to 
>> detect aliased
>> +    addresses [not particularly reliable].
>> +
>> +nvatiming
>> +    Attempts to measure what frequency various units of the card are
>> +    running at by using misc tricks.
>> +
>> +nvawatch [-t] <address>
>> +    Reads MMIO register at <address> in a loop, prints
>> +    the value every time it changes. If -t is specified, prints a 
>> timestamp o
>> +    and diff from the previous timestamp before the value. Never 
>> quits, needs
>> +    to be manually aborted.
>>     [XXX: document the remaining tools]
> Did you fix some spelling mistakes in while changing the order? I 
> already suck at
> comparing lines that are one on top of the other, so I don't even want 
> to try checking!
No. Only "incidents" in this patch.

[PATCH envytools] nvbios: Return an error if mem train subentries is above the limit to avoid stack corruption.

[Christian Costa]

---
 nvbios/mem.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/nvbios/mem.c b/nvbios/mem.c
index 911ce5c..2c8a929 100644
--- a/nvbios/mem.c
+++ b/nvbios/mem.c
@@ -111,6 +111,10 @@ envy_bios_parse_mem_train (struct envy_bios *bios) {
 		struct envy_bios_mem_train_entry *entry = &mt->entries[i];
 		entry->offset = mt->offset + mt->hlen + ((mt->rlen + mt->subentries * mt->subentrylen) * i);
 		err |= bios_u8(bios, entry->offset, &entry->u00);
+		if (mt->subentries > sizeof(entry->subentry)) {
+			ENVY_BIOS_ERR("Error when parsing mem train: subentries = %d > %lu\n", mt->subentries, sizeof(entry->subentry));
+			return -EFAULT;
+		}
 		int j;
 		for (j = 0; j < mt->subentries; j++) {
 			err |= bios_u8(bios, entry->offset+j+1, &entry->subentry[j]);
-- 
1.9.1

[PATCH envytools] nvbios: Write missing null terminating byte.

[Christian Costa]

---
 nvbios/nvbios.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
index 4fc667b..7bb768a 100644
--- a/nvbios/nvbios.c
+++ b/nvbios/nvbios.c
@@ -797,9 +797,9 @@ void find_strap(char *filename) {
 
 	path = (char*) malloc(base_length + strlen(strap_filename)+1);
 	strncpy(path, filename, base_length);
-	strncpy(path+base_length, strap_filename, strlen(strap_filename));
+	strncpy(path+base_length, strap_filename, strlen(strap_filename)+1);
 
-	if(!set_strap_from_file(path))
+	if (!set_strap_from_file(path))
 		printf("Strap register found in '%s'\n", path);
 
 	free(path);
-- 
1.9.1

Re: [PATCH envytools] nvbios: Write missing null terminating byte.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   nvbios/nvbios.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/nvbios/nvbios.c b/nvbios/nvbios.c
> index 4fc667b..7bb768a 100644
> --- a/nvbios/nvbios.c
> +++ b/nvbios/nvbios.c
> @@ -797,9 +797,9 @@ void find_strap(char *filename) {
>   
>   	path = (char*) malloc(base_length + strlen(strap_filename)+1);
>   	strncpy(path, filename, base_length);
> -	strncpy(path+base_length, strap_filename, strlen(strap_filename));
> +	strncpy(path+base_length, strap_filename, strlen(strap_filename)+1);
>   
> -	if(!set_strap_from_file(path))
> +	if (!set_strap_from_file(path))
>   		printf("Strap register found in '%s'\n", path);
>   
>   	free(path);
Looks good

[PATCH envytools] nvbios: Check if HWEA entry length == -1.

[Christian Costa]

---
 nvbios/bios.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/nvbios/bios.c b/nvbios/bios.c
index fac3840..ca8c54e 100644
--- a/nvbios/bios.c
+++ b/nvbios/bios.c
@@ -276,9 +276,14 @@ int envy_bios_parse (struct envy_bios *bios) {
 					pos += 4;
 					if (entry.type > 1)
 						ENVY_BIOS_WARN("Unknown HWEA entry type %d\n", entry.type);
+					if (entry.len == (uint32_t)-1) {
+						/* Maybe this should be treated as for length == 0 */
+						ENVY_BIOS_ERR("Invalid HWEA entry length %d\n", entry.len);
+						break;
+					}
 				} else {
 					entry.base = word & 0x1fffffc;
-					entry.type = word&3;
+					entry.type = word & 3;
 					switch (entry.type) {
 						case 0:
 						case 1:
-- 
1.9.1

[PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Christian Costa]

---
 nvbios/info.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/nvbios/info.c b/nvbios/info.c
index 87a33d8..6b8d209 100644
--- a/nvbios/info.c
+++ b/nvbios/info.c
@@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
 			bios->chipset_name = "G72";
 			break;
 		case 0x0573:
+			if (!bios->parts) {
+				ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");
+				break;
+			}
 			/* yeah, ain't this one hilarious... */
 			if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
 				bios->chipset = 0x63;
-- 
1.9.1

Re: [PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Ilia Mirkin]

On Mon, Aug 25, 2014 at 2:58 PM, Christian Costa <titan.costa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> ---
>  nvbios/info.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/nvbios/info.c b/nvbios/info.c
> index 87a33d8..6b8d209 100644
> --- a/nvbios/info.c
> +++ b/nvbios/info.c
> @@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
>                         bios->chipset_name = "G72";
>                         break;
>                 case 0x0573:
> +                       if (!bios->parts) {
> +                               ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");

parts

> +                               break;
> +                       }
>                         /* yeah, ain't this one hilarious... */
>                         if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
>                                 bios->chipset = 0x63;
> --
> 1.9.1
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] Don't try to use bios->pars if NULL (parse_pcir function has probably failed).

[Christian Costa]

Le 25/08/2014 21:09, Ilia Mirkin a écrit :
> On Mon, Aug 25, 2014 at 2:58 PM, Christian Costa <titan.costa@gmail.com> wrote:
>> ---
>>   nvbios/info.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/nvbios/info.c b/nvbios/info.c
>> index 87a33d8..6b8d209 100644
>> --- a/nvbios/info.c
>> +++ b/nvbios/info.c
>> @@ -119,6 +119,10 @@ int envy_bios_parse_bit_i (struct envy_bios *bios, struct envy_bios_bit_entry *b
>>                          bios->chipset_name = "G72";
>>                          break;
>>                  case 0x0573:
>> +                       if (!bios->parts) {
>> +                               ENVY_BIOS_ERR("Failed to detect board (bios->pars is NULL, parse_pcir function has probably failed)\n");
> parts
Ok. I'll a resend a patch. Thanks!
>
>> +                               break;
>> +                       }
>>                          /* yeah, ain't this one hilarious... */
>>                          if ((bios->parts[0].pcir_device & 0xfff0) == 0x7e0) {
>>                                  bios->chipset = 0x63;
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Martin Peres]

On 25/08/2014 20:58, Christian Costa wrote:
> ---
>   rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
>   1 file changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
> index 500cea9..e006dbe 100644
> --- a/rnndb/memory/nvc0_pbfb.xml
> +++ b/rnndb/memory/nvc0_pbfb.xml
> @@ -49,23 +49,54 @@
>   			Most bitfields are unknown.
>   			</doc>
>   		<bitfield high="7" low="0" name="RP">
> -			<doc> RAS# precharge. </doc>
> +			<doc> RAS# Precharge. </doc>
>   		</bitfield>
>   		<bitfield high="15" low="8" name="RAS">
> -			<doc>Activate to precharge delay. </doc>
> +			<doc> Activate to precharge delay. </doc>
>   		</bitfield>
>   		<bitfield high="23" low="16" name="RFC">
>   			<doc> Refresh to activate delay. </doc>
>   		</bitfield>
>   		<bitfield high="31" low="24" name="RC">
> -			<doc> Row cycle time. </doc>
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +	</reg32>
> +
> +	<reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
> +		<doc> This, and the next 6 regs, are all related to memtimings.
> +			A good place to read might be http://www.tweakers.fr/timings.html .
> +			Most bitfields are unknown.
> +			</doc>
> +		<bitfield high="7" low="0" name="tRC">
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +		<bitfield high="15" low="8" name="tRFC">
> +			<doc> Refresh to activate delay. </doc>
> +		</bitfield>
> +		<bitfield high="23" low="17" name="tRAS">
> +			<doc> Activate to precharge delay. </doc>
> +		</bitfield>
> +		<bitfield high="31" low="24" name="tRCD">
> +			<doc> RAS# to CAS# Delay. </doc>
>   		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
> +		<bitfield high="3" low="0" name="tCL">
> +			<doc> Row Cycle time. </doc>
> +		</bitfield>
> +		<bitfield high="13" low="7" name="tCWL">
> +			<doc> CAS# Write Latency. </doc>
> +		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
> +		<bitfield high="15" low="8" name="tWTR">
> +			<doc> Write To Read delay. </doc>
> +		</bitfield>
> +		<bitfield high="23" low="15" name="tWR">
> +			<doc> Write Recovery time. </doc>
> +		</bitfield>
>   	</reg32>
>   
>   	<reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">

Thanks for the patch but where did you get this knowledge? By comparing 
with nv50 and the vbios table?

Re: [PATCH envytools] demmio: Add decoding of some MEM_TIMINGS registers for NVC0.

[Christian Costa]

Le 26/08/2014 00:30, Martin Peres a écrit :
> On 25/08/2014 20:58, Christian Costa wrote:
>> ---
>>   rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++---
>>   1 file changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml
>> index 500cea9..e006dbe 100644
>> --- a/rnndb/memory/nvc0_pbfb.xml
>> +++ b/rnndb/memory/nvc0_pbfb.xml
>> @@ -49,23 +49,54 @@
>>               Most bitfields are unknown.
>>               </doc>
>>           <bitfield high="7" low="0" name="RP">
>> -            <doc> RAS# precharge. </doc>
>> +            <doc> RAS# Precharge. </doc>
>>           </bitfield>
>>           <bitfield high="15" low="8" name="RAS">
>> -            <doc>Activate to precharge delay. </doc>
>> +            <doc> Activate to precharge delay. </doc>
>>           </bitfield>
>>           <bitfield high="23" low="16" name="RFC">
>>               <doc> Refresh to activate delay. </doc>
>>           </bitfield>
>>           <bitfield high="31" low="24" name="RC">
>> -            <doc> Row cycle time. </doc>
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +    </reg32>
>> +
>> +    <reg32 offset="0x290" name="MEM_TIMINGS_0" variants="NVC0-">
>> +        <doc> This, and the next 6 regs, are all related to memtimings.
>> +            A good place to read might be 
>> http://www.tweakers.fr/timings.html .
>> +            Most bitfields are unknown.
>> +            </doc>
>> +        <bitfield high="7" low="0" name="tRC">
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +        <bitfield high="15" low="8" name="tRFC">
>> +            <doc> Refresh to activate delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="23" low="17" name="tRAS">
>> +            <doc> Activate to precharge delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="31" low="24" name="tRCD">
>> +            <doc> RAS# to CAS# Delay. </doc>
>>           </bitfield>
>>       </reg32>
>>         <reg32 offset="0x294" name="MEM_TIMINGS_1" variants="NVC0-">
>> +        <bitfield high="3" low="0" name="tCL">
>> +            <doc> Row Cycle time. </doc>
>> +        </bitfield>
>> +        <bitfield high="13" low="7" name="tCWL">
>> +            <doc> CAS# Write Latency. </doc>
>> +        </bitfield>
>>       </reg32>
>>         <reg32 offset="0x298" name="MEM_TIMINGS_2" variants="NVC0-">
>> +        <bitfield high="15" low="8" name="tWTR">
>> +            <doc> Write To Read delay. </doc>
>> +        </bitfield>
>> +        <bitfield high="23" low="15" name="tWR">
>> +            <doc> Write Recovery time. </doc>
>> +        </bitfield>
>>       </reg32>
>>         <reg32 offset="0x29c" name="MEM_TIMINGS_3" variants="NVC0-">
>
> Thanks for the patch but where did you get this knowledge? By 
> comparing with nv50 and the vbios table?

It's based on the code in nvbios.c:

                         reg_100220 = (tRCD << 24 | (tRAS&0x7f) << 17 | 
tRFC << 8 | tRC);
                         reg_100224 = 0x4c << 24 | (tUNK_11&0x0f) << 20 
| (tCWL << 7) | (tCL & 0x0f);
                         reg_100228 = 0x44000011 | tWR << 16 | tWTR << 8;
                         reg_10022c = tUNK_20 << 9 | tUNK_13;
                         reg_100230 = 0x42e00069 | tUNK_12 << 15;

                         printf("Registers: 290: 0x%08x 0x%08x 0x%08x 
0x%08x\n",
                         reg_100220, reg_100224,
                         reg_100228, reg_10022c);
                         printf("           2a0: 0x%08x 0x%08x 0x%08x 
0x%08x\n",
                         reg_100230, reg_100234,
                         reg_100238, reg_10023c);

[PATCH envytools] nva: Clean up nva tools doc

[Christian Costa]

- Sort commands by name for easier update
- Make more readable
- Remove no more existing commands
---
 nva/README | 81 +++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 43 insertions(+), 38 deletions(-)

diff --git a/nva/README b/nva/README
index 625ea7c..cbe6ae3 100644
--- a/nva/README
+++ b/nva/README
@@ -13,43 +13,48 @@ by the nvalist program.
 
 The programs are:
 
-nvalist: prints a list of cards
-
-nvapeek <address> [<byte count>]: reads 32-bit MMIO register at <address>.
-If byte count is also given, reads all registers in range [address, address
-+ byte count).
-
-nvapeek8 <address> [<byte count>]: like nvapeek, but does 8-bit MMIO accesses
-
-nvapoke <address> <value>: writes a 32-bit <value> to the MMIO register at
-<address>.
-
-nvapoke8 <address> <value>: like nvapoke, but does 8-bit MMIO access
-
-nvawatch [-t] <address>: reads MMIO register at <address> in a loop, prints
-the value every time it changes. If -t is specified, prints a timestamp
-and diff from the previous timestamp before the value. Never quits, needs
-to be manually aborted.
-
-nvahammer <address> <value>: like nvapoke, but repeats the write in
-an infinite loop. Needs to be manually aborted.
-
-nvagetbios [-s <extraction method>]: extracts the card's VBIOS using the
-method given as parameter and writes it to stdout. Method can be PROM or
-PRAMIN. If method is not given, defaults to something sensible.
-
-nvafuzz <address> [<byte count>]: writes random values to a register or
-a register range in an infinite loop. Needs to be manually aborted.
-
-nvascan [-as] <address> [<byte count>]: for each register in a range:
-read it, write 0xffffffff, read it, write 0, read it, write back the
-original value. Helpful to see the valid values for registers. If -s option
-is passed, does a slow scan - waits and reads PMC.ID register between scans
-to recover from errors caused by invalid register accesses. If -a option
-is passed, does a cross-test on all registers in the range to detect aliased
-addresses [not particularly reliable].
-
-nvatiming: attempts to measure what frequency various units of the card are
-running at by using misc tricks.
+nvafuzz <address> [<byte count>]
+    Writes random values to a register or
+    a register range in an infinite loop. Needs to be manually aborted.
+
+nvagetbios [-s <extraction method>]
+    Extracts the card's VBIOS using the
+    method given as parameter and writes it to stdout. Method can be PROM or
+    PRAMIN. If method is not given, defaults to something sensible.
+
+nvahammer <address> <value>
+    Like nvapoke, but repeats the write in
+    an infinite loop. Needs to be manually aborted.
+
+nvalist
+    Prints a list of cards
+
+nvapeek <address> [<byte count>]
+    Reads 32-bit MMIO register at <address>.
+    If byte count is also given, reads all registers in range [address, address
+    + byte count).
+
+nvapoke <address> <value>
+    Writes a 32-bit <value> to the MMIO register at
+    <address>.
+
+nvascan [-as] <address> [<byte count>]
+    For each register in a range:
+    read it, write 0xffffffff, read it, write 0, read it, write back the
+    original value. Helpful to see the valid values for registers. If -s option
+    is passed, does a slow scan - waits and reads PMC.ID register between scans
+    to recover from errors caused by invalid register accesses. If -a option
+    is passed, does a cross-test on all registers in the range to detect aliased
+    addresses [not particularly reliable].
+
+nvatiming
+    Attempts to measure what frequency various units of the card are
+    running at by using misc tricks.
+
+nvawatch [-t] <address>
+    Reads MMIO register at <address> in a loop, prints
+    the value every time it changes. If -t is specified, prints a timestamp
+    and diff from the previous timestamp before the value. Never quits, needs
+    to be manually aborted.
 
 [XXX: document the remaining tools]
-- 
1.9.1

Re: [PATCH envytools] nva: Clean up nva tools doc

[Martin Peres]

Whole serie applied (all 7 patches). Thank you again :)

Looking at the patches, it would seem like you were fixing
potential bugs. Remember that envytools is meant for
developers and we like stuff to break in catastrophic ways
when the vbios (for instance) does not follow our expectations.

Of course, crashing or corruption is not acceptable, but I'm all
for a good-old assert or at least big fat warnings. Just don't
waste too much time sanitizing nvbios since it clearly isn't meant
for production.

Thanks again and congrats for actually reading the code and
documentation before contributing! I wish you good luck in
generating the nvc0 memory timings :)

Martin

PS: Sorry it took me so long...